Android 低版本上 APP 首次启动时间减少 80%（一）
8476188 00-00-1980 00:00 classes2.dex
7882916 00-00-1980 00:00 classes3.dex
9041240 00-00-1980 00:00 classes4.dex
8646596 00-00-1980 00:00 classes5.dex
8644640 00-00-1980 00:00 classes6.dex
5888368 00-00-1980 00:00 classes7.dex
Android 4.4 及以下采用的是 Dalvik 虚拟机，在通常情况下，Dalvik 虚拟机只能执行做过 OPT 优化的 DEX 文件，也就是我们常说的 ODEX 文件。
一个 APK 在安装的时候，其中的classes.dex会自动做 ODEX 优化，并在启动的时候由系统默认直接加载到 APP 的PathClassLoader里面，因此classes.dex中的类肯定能直接访问，不需要我们操心。
除它之外的 DEX 文件，也就是classes2.dex、classes3.dex、classes4.dex等 DEX 文件（这里我们统称为 Secondary DEX 文件），这些文件都需要靠我们自己进行 ODEX 优化，并加载到 ClassLoader 里，才能正常使用其中的类。否则在访问这些类的时候，就会抛出ClassNotFound异常从而引起崩溃。
因此，Android 官方推出了 MultiDex 方案。只需要在 APP 程序执行最早的入口，也就是Application.attachBaseContext里面直接调MultiDex.install，它会解开 APK 包，对第二个以后的 DEX 文件做 ODEX 优化并加载。这样，带有多个 DEX 文件的 APK 就可以顺利执行下去了。
这个操作会在 APP 安装或者更新后首次冷启动的时候发生，正是由于这个过程耗时漫长，才导致了我们最开始提到的耗时黑屏问题。
了解了这个背景之后，我们再来看 MultiDex 的实现，逻辑就比较清晰了。
首先，APK 里面的所有classes2.dex、classes3.dex、classes4.dex等 DEX 文件都会被解压出来。
然后，对每个 dex 进行 ZIP 压缩。生成 classesN.zip 文件。
接着，对每个 ZIP 文件做 ODEX 优化，生成 classesN.zip.odex 文件。
具体而言，我们可以看到 APP 的 code_cache 目录下有这些文件：
复制代码
com.bytedance.app.boost_multidex-1.apk.classes2.dex
com.bytedance.app.boost_multidex-1.apk.classes2.zip
com.bytedance.app.boost_multidex-1.apk.classes3.dex
com.bytedance.app.boost_multidex-1.apk.classes3.zip
com.bytedance.app.boost_multidex-1.apk.classes4.dex
com.bytedance.app.boost_multidex-1.apk.classes4.zip
这一步是通过DexFile.loadDex方法实现的，只需要指定原始 ZIP 文件和 ODEX 文件的路径，就能够根据 ZIP 中的 DEX 生成相应的 ODEX 产物，这个方法会最终返回一个DexFile对象。
最后，APP 把这些DexFile对象都添加到PathClassLoader的pathList里面，就可以让 APP 在运行期间，通过ClassLoader加载使用到这些 DEX 中的类。
在这整个过程中，生成 ZIP 和 ODEX 文件的过程都是比较耗时的，如果一个 APP 中有很多个 Secondary DEX 文件，就会加剧这一问题。尤其是生成 ODEX 的过程，Dalvik 虚拟机会把 DEX 格式的文件进行遍历扫描和优化重写处理，从而转换为 ODEX 文件，这就是其中最大的耗时瓶颈。
目前业界已经有了一些对 MultiDex 进行优化的方法，我们先来看下大家通常是怎么优化这一过程的。
异步化加载
把启动阶段要使用的类尽可能多地打包到主 Dex 里面，尽量多地不依赖 Secondary DEX 来跑业务代码。然后异步调用MultiDex.install，而在后续某个时间点需要用到 Secondary DEX 的时候，如果 MultiDex 还没执行完，就停下来同步等待它完成再继续执行后续的代码。
这样确实可以在 install 的同时往下执行部分代码，而不至于被完全堵住。然而要做到这点，必须首先梳理好启动逻辑的代码，明确知道哪些是可以并行执行的。另外，由于主 Dex 能放的代码本身就比较有限，业务在启动阶段如果有太多依赖，就不能完全放入主 Dex 里面，因此就需要合理地剥离依赖。
因此现实情况下这个方案效果比较有限，如果启动阶段牵扯了太多业务逻辑，很可能并行执行不了太多代码，就很快又被 install 堵住了。
模块懒加载
这个方案最早见于美团的文章，可以说是前一个方案的升级版。
它也是做异步 DEX 加载，不过不同之处在于，在编译期间就需要对 DEX 按模块进行拆分。
一般是把一级界面的 Activity、Service、Receiver、Provider 涉及到的代码都放到第一个 DEX 中，而把二级、三级页面的 Activity 以及非高频界面的代码放到了 Secondary DEX 中。
当后面需要执行某个模块的时候，先判断这个模块的 Class 是否已经加载完成，如果没有完成，就等待 install 完成后再继续执行。
可见，这个方案对业务的改造程度相当巨大，而且已经有了一些插件化框架的雏形。另外，想要做到能对模块的 Class 的加载情况进行判断，还得通过反射 ActivityThread 注入自己的 Instrumentation，在执行 Activity 之前插入自己的判断逻辑。这也会相应地引入机型兼容性问题。
多线程加载
原生的 MultiDex 是顺序依次对每个 DEX 文件做 ODEX 优化的。而多线程的思路是，把每个 DEX 分别用各自线程做 OPT。
这么乍看起来，似乎是能够并行地做 ODEX 来起到优化效果。然而我们项目中一共有 6 个 Secondary DEX 文件，实测发现，这种方式几乎没有优化效果。原因可能是 ODEX 本身其实是重度 I/O 类型的操作，对于并发而言，多个线程同时进行 I/O 操作并不能带来明显收益，并且多线程切换本身也会带来一定损耗。
后台进程加载
这个方案主要是防止主进程做 ODEX 太久导致 ANR。当点击 APP 的时候，先单独启动了一个非主进程来先做 ODEX，等非主进程做完 ODEX 后再叫起主进程，这样主进程起来直接取得做好的 ODEX 就可以直接执行。不过，这只是规避了主进程 ANR 的问题，第一次启动的整体等待时间并没有减少。
上述几个方案，在各个层面都尝试做了优化，然而仔细分析便会发现，它们都没有触及这个问题中根本，也就是就MultiDex.install操作本身。
MultiDex.install生成 ODEX 文件的过程，调用的方法是DexFile.loadDex，它会启动一个 dexopt 进程对输入的 DEX 文件进行 ODEX 转化。那么，这个 ODEX 优化的时间是否可以避免呢？
我们的 BoostMultiDex 方案，正是从这一点入手，从本质上优化 install 的耗时。
我们的做法是，在第一次启动的时候，直接加载没有经过 OPT 优化的原始 DEX，先使得 APP 能够正常启动。然后在后台启动一个单独进程，慢慢地做完 DEX 的 OPT 工作，尽可能避免影响到前台 APP 的正常使用。
突破口
这里的难点，自然是——如何做到可以直接加载原始 DEX，避免 ODEX 优化带来的耗时阻塞。
如果要避免 ODEX 优化，又想要 APP 能够正常运行，就意味着 Dalvik 虚拟机需要直接执行没有做过 OPT 的、原始的 DEX 文件。虚拟机是否支持直接执行 DEX 文件呢？毕竟 Dalvik 虚拟机是可以直接执行原始 DEX 字节码的，ODEX 相比 DEX 只是做了一些额外的分析优化。因此即使 DEX 不通过优化，理论上应该是可以正常执行的。
功夫不负有心人，经过我们的一番挖掘，在系统的 dalvik 源码里面果然找到了这一隐藏入口：
/*
private static int openDexFile(byte[] fileContents) throws IOException
Open a DEX file represented in a byte[], returning a pointer to our
internal data structure.
The system will only perform "essential" optimizations on the given file.
*/
static void Dalvik_dalvik_system_DexFile_openDexFile_bytearray(const u4* args,
JValue* pResult)
{
ArrayObject* fileContentsObj = (ArrayObject*) args[0];
u4 length;
u1* pBytes;
RawDexFile* pRawDexFile;
DexOrJar* pDexOrJar = NULL;
if (fileContentsObj == NULL) {
dvmThrowNullPointerException("fileContents == null");
RETURN_VOID();
}
/* TODO: Avoid making a copy of the array. (note array is modified) */
length = fileContentsObj->length;
pBytes = (u1*) malloc(length);
if (pBytes == NULL) {
dvmThrowRuntimeException("unable to allocate DEX memory");
RETURN_VOID();
}
memcpy(pBytes, fileContentsObj->contents, length);
if (dvmRawDexFileOpenArray(pBytes, length, &pRawDexFile) != 0) {
ALOGV("Unable to open in-memory DEX file");
free(pBytes);
dvmThrowRuntimeException("unable to open in-memory DEX file");
RETURN_VOID();
}
ALOGV("Opening in-memory DEX");
pDexOrJar = (DexOrJar*) malloc(sizeof(DexOrJar));
pDexOrJar->isDex = true;
pDexOrJar->pRawDexFile = pRawDexFile;
pDexOrJar->pDexMemory = pBytes;
pDexOrJar->fileName = strdup("<memory>"); // Needs to be free()able.
addToDexFileTable(pDexOrJar);
RETURN_PTR(pDexOrJar);
}
这个方法可以做到对原始 DEX 文件做加载，而不依赖 ODEX 文件，它其实就做了这么几件事：
接受一个
byte[]参数，也就是原始 DEX 文件的字节码。调用
dvmRawDexFileOpenArray函数来处理byte[]，生成RawDexFile对象由
RawDexFile对象生成一个DexOrJar，通过addToDexFileTable添加到虚拟机内部，这样后续就可以正常使用它了返回这个
DexOrJar的地址给上层，让上层用它作为 cookie 来构造一个合法的DexFile对象
这样，上层在取得所有 Seconary DEX 的DexFile对象后，调用 makeDexElements 插入到 ClassLoader 里面，就完成 install 操作了。如此一来，我们就能完美地避过 ODEX 优化，让 APP 正常执行下去了。
寻找入口
看起来似乎很顺利，然而在我们却遇到了一个意外状况。
我们从Dalvik_dalvik_system_DexFile_openDexFile_bytearray这个函数的名字可以明显看出，这是一个 JNI 方法，从 4.0 到 4.3 版本都能找到它的 Java 原型：
/*
Open a DEX file based on a {@code byte[]}. The value returned
is a magic VM cookie. On failure, a RuntimeException is thrown.
*/
native private static int openDexFile(byte[] fileContents);
然而我们在 4.4 版本上，Java 层它并没有对应的 native 方法。这样我们便无法直接在上层调用了。
当然，我们很容易想到，可以用 dlsym 来直接搜寻这个函数的符号来调用。但是可惜的是，Dalvik_dalvik_system_DexFile_openDexFile_bytearray这个方法是static的，因此它并没有被导出。我们实际去解析libdvm.so的时候，也确实没有找到Dalvik_dalvik_system_DexFile_openDexFile_bytearray这个符号。
不过，由于它是 JNI 函数，也是通过正常方式注册到虚拟机里面的。因此，我们可以找到它对应的函数注册表：
const DalvikNativeMethod dvm_dalvik_system_DexFile[] = {
{ "openDexFileNative", "(Ljava/lang/String;Ljava/lang/String;I)I",
Dalvik_dalvik_system_DexFile_openDexFileNative },
{ "openDexFile", "([B)I",
Dalvik_dalvik_system_DexFile_openDexFile_bytearray },
{ "closeDexFile", "(I)V",
Dalvik_dalvik_system_DexFile_closeDexFile },
{ "defineClassNative", "(Ljava/lang/String;Ljava/lang/ClassLoader;I)Ljava/lang/Class;",
Dalvik_dalvik_system_DexFile_defineClassNative },
{ "getClassNameList", "(I)[Ljava/lang/String;",
Dalvik_dalvik_system_DexFile_getClassNameList },
{ "isDexOptNeeded", "(Ljava/lang/String;)Z",
Dalvik_dalvik_system_DexFile_isDexOptNeeded },
{ NULL, NULL, NULL },
};
dvm_dalvik_system_DexFile这个数组需要被虚拟机在运行时动态地注册进去，因此，这个符号是一定会被导出的。
这么一来，我们也就可以通过 dlsym 取得这个数组，按照逐个元素字符串匹配的方式来搜寻openDexFile对应的Dalvik_dalvik_system_DexFile_openDexFile_bytearray方法了。
具体代码实现如下：
const char *name = "openDexFile";
JNINativeMethod* func = (JNINativeMethod*) dlsym(handler, "dvm_dalvik_system_DexFile");;
size_t len_name = strlen(name);
while (func->name != nullptr) {
if ((strncmp(name, func->name, len_name) == 0)
&& (strncmp("([B)I", func->signature, len_name) == 0)) {
return reinterpret_cast<func_openDexFileBytes>(func->fnPtr);
}
func++;
}
捋清步骤
小结一下，绕过 ODEX 直接加载 DEX 的方案，主要有以下步骤：
从 APK 中解压获取原始 Secondary DEX 文件的字节码
通过 dlsym 获取
dvm_dalvik_system_DexFile数组在数组中查询得到
Dalvik_dalvik_system_DexFile_openDexFile_bytearray函数调用该函数，逐个传入之前从 APK 获取的 DEX 字节码，完成 DEX 加载，得到合法的
DexFile对象把
DexFile对象都添加到 APP 的PathClassLoader的 pathList 里
完成了上述几步操作，我们就可以正常访问到 Secondary DEX 里面的类了
然而，正当我们顺利注入原始 DEX 往下执行的时候，却在 4.4 的机型上马上遇到了一个必现的崩溃：
JNI WARNING: JNI function NewGlobalRef called with exception pending
in Ljava/lang/Class;.getDex:()Lcom/android/dex/Dex; (NewGlobalRef)
Pending exception is:
java.lang.IndexOutOfBoundsException: index=0, limit=0
at java.nio.Buffer.checkIndex(Buffer.java:156)
at java.nio.DirectByteBuffer.get(DirectByteBuffer.java:157)
at com.android.dex.Dex.create(Dex.java:129)
at java.lang.Class.getDex(Native Method)
at libcore.reflect.AnnotationAccess.getSignature(AnnotationAccess.java:447)
at java.lang.Class.getGenericSuperclass(Class.java:824)
at com.google.gson.reflect.TypeToken.getSuperclassTypeParameter(TypeToken.java:82)
at com.google.gson.reflect.TypeToken.<init>(TypeToken.java:62)
at com.google.gson.Gson$1.<init>(Gson.java:112)
at com.google.gson.Gson.<clinit>(Gson.java:112)
... ...
可以看到，Gson 里面使用到了Class.getGenericSuperclass方法，而它最终调用了Class.getDex，它是一个 native 方法，对应实现如下：
JNIEXPORT jobject JNICALL Java_java_lang_Class_getDex(JNIEnv* env, jclass javaClass) {
Thread* self = dvmThreadSelf();
ClassObject* c = (ClassObject*) dvmDecodeIndirectRef(self, javaClass);
DvmDex* dvm_dex = c->pDvmDex;
if (dvm_dex == NULL) {
return NULL;
}
// Already cached?
if (dvm_dex->dex_object != NULL) {
return dvm_dex->dex_object;
}
jobject byte_buffer = env->NewDirectByteBuffer(dvm_dex->memMap.addr, dvm_dex->memMap.length);
if (byte_buffer == NULL) {
return NULL;
}
jclass com_android_dex_Dex = env->FindClass("com/android/dex/Dex");
if (com_android_dex_Dex == NULL) {
return NULL;
}
jmethodID com_android_dex_Dex_create =
env->GetStaticMethodID(com_android_dex_Dex,
"create", "(Ljava/nio/ByteBuffer;)Lcom/android/dex/Dex;");
if (com_android_dex_Dex_create == NULL) {
return NULL;
}
jvalue args[1];
args[0].l = byte_buffer;
jobject local_ref = env->CallStaticObjectMethodA(com_android_dex_Dex,
com_android_dex_Dex_create,
args);
if (local_ref == NULL) {
return NULL;
}
// Check another thread didn't cache an object, if we've won install the object.
ScopedPthreadMutexLock lock(&dvm_dex->modLock);
if (dvm_dex->dex_object == NULL) {
dvm_dex->dex_object = env->NewGlobalRef(local_ref);
}
return dvm_dex->dex_object;
}
结合堆栈和代码来看，崩溃的点是在 JNI 里面执行com.android.dex.Dex.create的时候：
jobject local_ref = env->CallStaticObjectMethodA(com_android_dex_Dex,
com_android_dex_Dex_create,
args);
由于是 JNI 方法，这个调用发生异常后如果没有 check，在后续执行到env->NewGlobalRef调用的时候会检查到前面发生了异常，从而抛出。
而com.android.dex.Dex.create之所以会执行失败，主要原因是入参有问题，这里的参数是dvm_dex->memMap取到的一块 map 内存。dvm_dex 是从这个 Class 里面取得的。虚拟机代码里面，每个 Class 对应是结构是ClassObject中，其中有这个字段：
还未添加个人签名 2021.10.31 加入
还未添加个人简介
评论