通过反射来获取Intent中的Key

在项目中遇到一种情况,我想通过了解某个Intent里面到底存了哪些数据来解决这个问题。但是我们知道,Intent里面的数据需要知道key才能调用相应的函数取出来,所以如何才能找出这些key呢?通过对Intent代码里面对存数据的观察,我们可以看到,通过putExtra()存的数据,都放在一个叫做mE

在项目中遇到一种情况,我想通过了解某个Intent里面到底存了哪些数据来解决这个问题。但是我们知道,Intent里面的数据需要知道key才能调用相应的函数取出来,所以如何才能找出这些key呢?

通过对Intent代码里面对存数据的观察,我们可以看到,通过putExtra()存的数据,都放在一个叫做mExtrasBundle中。而Bundle继承自BaseBundle,并且其中申明了一个变量叫做ArrayMap<String, Object> mMap = null;

// Intent.java
public @NonNull Intent putExtra(String name, String value) {
    if (mExtras == null) {
        mExtras = new Bundle();
    }
    mExtras.putString(name, value);
    return this;
}
// BaseBundle.java
public void putString(@Nullable String key, @Nullable String value) {
    unparcel();
    mMap.put(key, value);
}

也不难理解它将数据以Object的方式存放在一个Map中,然后通过相应的get,将Object强转成相应的数据类型。

// Intent.java
public String getStringExtra(String name) {
    return mExtras == null ? null : mExtras.getString(name);
}

// BaseBundle.java
public String getString(@Nullable String key) {
    unparcel();
    final Object o = mMap.get(key);
    try {
        return (String) o;//强转成String
    } catch (ClassCastException e) {
        typeWarning(key, o, "String", e);
        return null;
    }
}

所以我们只需要获取到这个mMap,就可以获取到所有的key和数据。如何才能获取到它呢?Intent以及Bundle中都没有相应的获取方法,然后在BaseBundle中,mMap的申明和获取都是默认包访问权限。所以通过常规方法是无法获取到的。

// BaseBundle.java

ArrayMap<String, Object> mMap = null;//默认包访问权限

/** @hide */
ArrayMap<String, Object> getMap() {//默认包访问权限
    unparcel();
    return mMap;
}

听说反射可以做一些比较牛逼的事情,包括可以调用被@hide修饰的方法以及所有的方法、变量。在这里我们可以通过调用上面的那个get方法,也可以直接获取它的变量。在这里,我通过反射,来获取这个get方法,然后执行相应Bundle的该方法,成功获取到了mMap,并打印出其中的key

这个代码运行在一个普通的Android应用中,没有需要其他的权限。

private void showBundleContent(){
	try {
	    Class<BaseBundle> c = BaseBundle.class;
	    Method method = c.getDeclaredMethod("getMap");
	    method.setAccessible(true);
	    Object obj = method.invoke(getIntent().getExtras());
	    obj = (ArrayMap<String, Object>) obj;
	    Iterator it = ((ArrayMap<String, Object>) obj).keySet().iterator();
	    while (it.hasNext()){
	        Log.e("TAG", "set : "+(String)it.next());
	    }
	} catch (Exception e) {
	    e.printStackTrace();
	}
}

Read more

Volcano 与 Kubernetes GPU 调度学习笔记

本笔记系统整理 Volcano 调度器、Kubernetes 调度框架、GPU Device Plugin、HAMi 等云原生 AI 调度领域的核心知识,适合用于学习、复习和工程实践参考。 目录 * 第一部分:Volcano 入门 * 1. Volcano 是什么 * 2. 安装与快速使用 * 3. 核心特性一览 * 第二部分:Volcano 整体架构 * 4. Volcano 解决的核心问题 * 5. 整体架构与数据流 * 6. 三层抽象模型 * 第三部分:Volcano 核心实现原理 * 7. Session 机制 * 8. Gang Scheduling 实现 * 9. Queue 与 DRF 公平调度

容器镜像(4):镜像的常用工具箱

容器镜像(4):镜像的常用工具箱

前几篇在讲多架构镜像时已经用过 skopeo 和 crane 做镜像复制,这篇系统整理这两个工具的完整能力,同时介绍几个日常操作镜像时同样好用的工具。 一、skopeo:不依赖 Daemon 的镜像瑞士军刀 skopeo 的核心价值是绕过 Docker daemon,直接与 Registry API 交互。上一篇用它做镜像复制和离线传输,但它的能力远不止于此。 1.1 安装 # Ubuntu / Debian sudo apt install -y skopeo skopeo --version # skopeo version 1.15.1 1.2 inspect:免拉取检查镜像元数据 docker inspect 需要先把镜像拉到本地,skopeo inspect 直接向 Registry

容器镜像(3):多架构镜像构建

容器镜像(3):多架构镜像构建

一、什么是多架构镜像 1.1 OCI Image Index 上一篇介绍了单平台镜像的结构:一个 Manifest 指向 Config 和若干 Layer blob。多架构镜像在此之上多了一层——OCI Image Index(也叫 Manifest List),是一个轻量的索引文件,把多个单平台 Manifest 组织在一起: $ docker manifest inspect golang:1.22-alpine { "schemaVersion": 2, "mediaType": "application/vnd.oci.image.index.v1+json", "manifests&

容器镜像(2):containerd 视角下的镜像

容器镜像(2):containerd 视角下的镜像

一、为什么需要了解 containerd 如果你只用 docker run 跑容器,从来不关心底层,那可以不了解 containerd。但如果你在用 Kubernetes,或者想真正理解"容器运行时"是什么,containerd 是绕不开的。 事实上,当你执行 docker run 的时候,containerd 早就在后台悄悄工作了——Docker 从 1.11 版本开始,就把核心运行时剥离出来交给 containerd 负责。 1.1 Docker 的架构演变 早期的 Docker(1.10 及之前)是一个"大一统"的单体程序:一个 dockerd