另外一方面，我们知道JNI层面 C++ new/malloc申请的内存，分配中在 native heap，native heap的增长并不受vm heap大小的限制，只受限于RAM，如果RAM不足，那么进程也会被杀死导致闪退。
所以如果只是从dex merge方面思考，在JNI层进行dex merge可以有效避免OOM，提高dex 合并的成功率，只是JNI层实现起来比较复杂而已。
Sophix另辟蹊径，寻求一种既能无侵入打包，又能将热部署模式作为补充解决方案，下面分别的 DVM和ART虚拟机的冷启动方案分别进行介绍。
如果仅仅是把补丁类打入补丁包中而不做任何处理的话，那么在运行时类加载的时候会产生异常并且退出，接下来看下抛出这个异常的前因后果。
加载一个dex文件到本地内存的时候，如果不存在 odex文件，那么首先会执行dexopt，dexopt的入口在 davilk/opt/OptMain.cpp的main方法中，最后调用到 verifyAndOptimizeClass()执行真正的 verify/optimize操作
在第一次安装Apk的时候，会对原先dex执行dexopt，此时假如APK只存在一个dex，dvmVerifyClass()就会返回true。然后Apk中所有的类都会被打上 CLASS_ISPREVERIFIED的标识，接下来执行 dvmOptimizeClass()，类接着被打上 CLASS_ISOPTIMIZED标识。
dvmVerifyClass()
类校验，简单来说，类校验的目的是为了防止校验类的合法性被篡改。此时会对类的每个方法进行校验，这里我们只需要知道如果类的所有方法中直接引用到的类（第一层级关系，不会进行递归搜索）和当前的类都在一个dex中的话，该方法就会返回true。
dvmOptimizeClass()
类优化，简单来说就这个过程会把部分指令优化成虚拟机的内部指令，比如方法调用指令 invoke-*变成了 invoke-*-quick，quick指令会从类的vtable表中直接获取，vtable简单来说就是类的所有方法的一张大表，因此提高了方法的执行速率。
现在假定A类是补丁类，所以补丁A类在单独的dex中。类B中的某个方法引用到补丁类A，所以执行该方法会尝试解析类A。
通过上面代码得知，类B由于被打上了 CLASS_ISPREVERIFIED标志，接下来referrer是类B，resClassCheck是补丁类A，他们属于不同的dex，就抛出了 dvmThrowIllegalAccessError的异常了。
所以为了解决这个问题，而引申出插桩的方案，下面通过流程来介绍下这个方案：
-
创建一个单独的无关帮助类，并将这个类打包时放到一个单独的dex文件中
-
原来的dex文件（也就是我们自己原有的程序），所有的类的构造函数都要引入第一步中的类
当然不是我们自己手动在所有类的构造函数里面加，而是通过 .class字节码修改技术，在所有的 .class类的构造函数中加入这个类的引用。
-
在安装Apk的时期，会走到上述的
verifyAndOptimizeClass()方法校验类方法dvmVerifyClass()，在这个方法中由于发现了 原有的代码（自己代码）引用到了一个非本代码所在dex的其他方法（即帮助类方法），所以dvmVerifyClass()返回了false，这就导致虚拟机不会给所有的 类打上CLASS_ISPREVERIFIED标识。 -
基于步骤3，在冷启动加载时，源程序引用了补丁类中的方法时，会去解析补丁类，走
dvmResolveClass()方法，里面会做检验，由于源程序所有类都没有被打上CLASS_ISPERVERIFIED标识，所以该方法不会抛出错误。
而上面步骤1所用到的无关帮助类，以及步骤2所涉及到的字节码修改技术，就是插桩方案的核心。
但是插桩会给类加载效率带来比较严重的影响，熟悉DVM开发的人知道，一个类的加载通常有三个阶段： dvmResolveClass()、dvmLinkClass()、dvmlnitClass()。dvmInitClass()阶段在类解析完成并尝试初始化类的执行，这个方法主要完成父类的初始化、当前类的初始化、静态变量的初始化赋值等操作：
bool dvmInitClass(ClassObject* clazz) {
if(clazz->status < CLASS_VERIFIED) { // 1
clazz->status = CLASS_VERIFYING;
if (!dvmVerifyClass(clazz)) { // 2
…
}
clazz->status = CLASS_VERIFIED;
}
if (!IS_CLASS_FLAG_SET(clazz, CLASS_ISPOTIMIZED) && gDvm.optimizing) { //3
dvmOptimizeClass(clazz, essentialOnly); // 4
SET_CLASS_FLAG(clazz, CLASS_ISOPTIMIZED);
}
…
}
注释1： 如果类没有打上 IS_PERVERIFIED标识，那么由于枚举类型，它是小于 CLASS_VERIFIED的，即这个if里面的内容会执行的。
注释2：执行了 dvmVerifyClass()方法校验类。
注释3：如果类没有打上 IS_OPTIMIZED的标识，那么 注释3的if语句里面的内容会执行
注释4：执行 dvmOptimizeClass做类优化。
综上可知，如果类没有在加载时的verifyAndOptimizeClass()的方法打上 CLASS_ISPERVERIFIED/CLASS_ISOPTIMIZED这两个标识，则会在 类的初始化时去执行类的校验和优化。
由于类检验的任务可以认为是很重的，因为会对类的所有方法中的所有指令都做校验，单个类加载时耗时并不多，但是同一个时间点加载大量的类情况下，这种耗时就会被放大。所以这也是插桩给类的加载效率带来比较大影响的后果。（因为这些情况都是放在第一次安装Apk的时候做的）
我们知道若采用插桩，会导致所有类都非perverify，从而导致类校验和类优化会在类加载时触发。
平均每个类检验与优化的耗时并不长， 而且这个耗时每个类只有一次（类只会加载一次）。但是由于在应用刚启动这种场景下一般会同时加载大量的类，因此在这种情况下影响还是蛮大的，启动的时候就容易白屏，这一点用户是无法容忍的。
手机QQ热补丁轻量级 QFix方案提供了一种不同的思路：
上图是 dvmResolveClass()的内容，从1.2节中我们知道，如果不插桩，会走到上图的第二个方框的if语句内，该判断检验两个东西：
-
类的
CLASS_ISPERVERIFIED是否为true（插桩方案就是使这个判断为false） -
fromUnverifiedConstant是否为false
而QFix的思路则是将着手点放在fromUnverifiedConstant上，如果它为true，那么就不用再使用 插桩的方案了。
那该怎样改变这个字段的值呢？
我们首先要保证 resClass不为null，即 dvmDexGetResolvedClass()的返回结果不为null，如果保证这个方法的返回值不为null呢？
我们只需要调用过一次 dvmDexSetResolvedClass(pDvmDex, classIdx, resClass);就可以了，下面举个例子来简单说明：
public class B {
public static void test() {
A.a();
}
}
我们此时需要打包的类A，所以类A被打入到一个独立的补丁 dex文件中。
那么执行到类B的test方法时，A.a(); 这行代码就会尝试去解析类A，此时进行 dvmResolveClass(const ClassObject* referrer, u4 classIdx, bool fromUnverifiedConstant).
-
referrer：实际上是类B
-
classIdx：类A在原dex文件结构类区中的索引ID
-
fromUnverifiedConstant：是否执行 const-class/instance-of 指令
此时调用的是类A的静态a方法， invoke-static指令不属于 const-class/instance-of这两个指令。如果不做任何处理，dvmDexGetResolvedClass()的返回值时null。因为类A是从补丁dex中解析加载的，类B是在原dex中，所以 B->pDvmDex != A->pDvmDex，接下来就会看到 dvmThrowIllegalAccessError从而导致运行异常。
为了避免异常，必须要在开始的时候，就把补丁类A添加到原有dex(pDvmDex)的pResClasses数组中。这样就确保了在执行类B的test方法时，dvmDexGetResolvedClass()返回值不为null了。这样就会在图片中注释3的下面一行，直接返回这个resClass，而不会去执行后续类A和类B的dex一致性校验了。
具体实现，首先通过补丁工具反编译dex为smali文件拿到以下文件。
preResolveClz
需要打包的类A的描述符，非必须，为了调试方便加上该参数而已
referClz
需要打包的类A所在的dex文件的任何一个类描述符，注意，这里不限定必须是引用补丁类A的某个类，实际上只要是同一个dex中的任意一个类都可以。所以我们直接拿原dex中的第一个类即可。
classIdx
需要打包的类A在原有dex文件中的类索引ID。
然后通过dlopen 拿到 libdvm.so库的句柄，通过 dlsym拿到该so库的 dvmResolveClass/dvmFindLoadedClass函数指针。首先需要预加载引用类xxx/xxx/class，这样dvmFindLoadedClass(xxx/xxx/class)返回值才不为null，然后 dvmFindLoadedClass()的执行结果得到的 ClassObejct作为第一个参数执行 dvmResolvedClass(class,id ,true)即可。
下面来看下JNI层代码实现。实际上可以看到 preResolveClz参数是非必须的：
jboolean resolveClodPatchClasses(JNIEnv *env, jclass clz, jstring preResolveClz, jstring refererClz, jlong classIdx, dexstuff_t *dexstuff) {
LOGD(“start resolveClodPatchClasses”);
ClassObject *refererObj = dexstuff->dvmFindLoadedClass_fnPtr(
Jstring2CStr(env, refererClz)); //通过refererClz 调用dvmFindLoadedClass加载补丁类
LOGD(“referrer ClassObject: %s\n”, refererObj->decriptor);
if (strlen(refererObj->descriptor) == 0) {
return JNI_FALSE;
}
ClassObject *resolveClass = dexstuff->dvmResolveClass-fnPtr(refererObj, classIdx, true); //调用dvmResolveClass方法
LOGD(“classIDx ClassObject: %s\n”, resolveClass->descriptor);
if (strlen(resolveClass->descriptor) == 0) {
return JNI_FLASE;
}
return JNI_TRUE;
}
这个思路不同于去Hook某个系统方法，而是从native层直接调用，同时更不需要插桩。具体实现需要注意以下3点：
-
dvmResolveClass的第三个参数 fromUnverifiedConstant必须为true。
-
在Apk多dex的情况下，
dvmResolveClass()的第一个参数referrer类必须跟需要打包的类在同一个dex中，但是它们两个类不需要存在任何引用关系，任何一个在同一个dex中的类作为referrer都可以。 -
referrer类必须提前加载。
然而，QFix的方案有它独特的缺陷，由于是在dexopt后绕过的，dexopt会改变原有的很多逻辑，许多odex层面的优化会固定字段和方法的访问偏移，这就会导致比较严重的bug，在2.2节会详细讲解这一影响。最后采用的是自研的全量dex方案，具体在下一章讲解。
前面说过补丁在热部署模式下是一个完整的类，补丁的粒度是类。现在的需求是补丁既能走热部署模式也能走冷启动模式，为了减小补丁包的大小，并没有为热部署和冷启动分别准备一套补丁，而是在同一个热部署模式下补丁能够降级直接走冷启动，所以不需要做dex merge。
但是通过前面的阅读，我们知道了为了解决Art下类地址写死的问题，Tinker通过 dex merge成一个全新完整的新dex整体替换掉旧的dexElements数组。事实上，Art虚拟机下面默许已经支持多dex压缩文件的加载。
下面分别来看一下 DVM和ART对 DexFile.loadDex()尝试把一个dex文件解析加载到native中，内存都发生了什么。实际上都是调用了 DexFile.openDexFileNative()这个native方法。看下 native层对应的 C/C++代码具体实现。
（1）在DVM中的实现：
// dalvik/vm/native/dalvik_system_DexFile.cpp
static void Dalvik_dalvik_system_DexFile_openDexFileNative(const u4* args,
JValue* pResult)
{
…
if (hasDexExtension(sourceName)
&& dvmRawDexFileOpen(sourceName, outputName, &pRawDexFile, false) == 0) { //加载一个原始dex文件
ALOGV(“Opening DEX file ‘%s’ (DEX)”, sourceName);
pDexOrJar = (DexOrJar*) malloc(sizeof(DexOrJar));
pDexOrJar->isDex = true;
pDexOrJar->pRawDexFile = pRawDexFile;
pDexOrJar->pDexMemory = NULL;
} else if (dvmJarFileOpen(sourceName, outputName, &pJarFile, false) == 0) { //加载一个压缩文件
ALOGV(“Opening DEX file ‘%s’ (Jar)”, sourceName);
pDexOrJar = (DexOrJar*) malloc(sizeof(DexOrJar));
pDexOrJar->isDex = false;
pDexOrJar->pJarFile = pJarFile;
pDexOrJar->pDexMemory = NULL;
} else {
ALOGV(“Unable to open DEX file ‘%s’”, sourceName);
dvmThrowIOException(“unable to open DEX file”);
}
…
}
int dvmJarFileOpen(…){
…
entry = dexZipFindEntry(&archive, kDexInJarName); /* kDexInJarName==“classes.dex”，说明只加载一个dex */
…
}
在 dvmJarFileOpen()方法中，Dalvik尝试加载一个压缩文件的时候只会去把 classes.dex加载到内存中。如果此时压缩文件中有多个dex文件，那么除了classes.dex之外的其他dex文件将会被直接忽略掉。
在Art虚拟机下：方法调用链 DexFile_openDexFileNative -> OpenDex.FilesFromOat -> LoadDexFiles
具体代码就不展示了，我们只需要知道，在Art下默认已经支持加载压缩文件中包含多个dex，首先肯定加载primary dex也就是 classes.dex，后续会加载其他的dex。所以补丁类只需要放到classes.dex中即可，后续出现在其他dex中的“补丁类”是不会被重复加载的。
所以Sophix得到在Art最终的冷启动方案：我们只要把补丁dex命名为classes.dex。原Apk中的dex依次命名为 classes(2,3,4...).dex就可以了，然后一起打包为一个压缩文件，在通过 DexFile.loadDex()得到DexFile对象，最后用该DexFile对象整体替换旧的dexElements数组就可以了。
Sophix方案和Tinker方案的不同点如下所示：
需要注意：
-
补丁dex必须命名为
classes.dex -
用
loadDex()得到的DexFile完整替换掉 dexElements数组而不是插入。
我们知道DexFile.loadDex()尝试把一个dex文件解析并加载到native内存， 在加载到native内存之前， 如果dex不存在对应的odex， 那么Dalvik下会执行dexopt， Art下会执行dexoat， 最后得到的都是一个优化后的odex。 实际上最后虚拟机执行的是这个odex而不是dex。
现在有这么一个问题，如果dex足够大那么dexopt/dexoat实际上是很耗时的，根据上面我们提到的方案， Dalvik下实际上影响比较小， 因为loadDex仅仅是补丁包。 但是Art下影响是非常大的， 因为loadDex是补丁dex和apk中原dex合并成的一个完整补丁压缩包， 所以dexoat非常耗时。
所以如果优化后的odex文件没生成或者没生成一个完整的odex文件， 那么loadDex便不能在应用启动的时候进行的， 因为会阻塞loadDex线程， 一般是主线程。 所以为了解决这个问题， 我们把loadDex当做一个事务来看， 如果中途被打断， 那么就删除odex文件， 重启的时候如果发现存在odex文件， loadDex完之后， 反射注入/替换dexElements数组， 实现patch。 如果不存在odex文件， 那么重启另一个子线程loadDex， 重启之后再生效。
另外一方面为了patch补丁的安全性， 虽然对补丁包进行签名校验， 这个时候能够防止整个补丁包被篡改， 但是实际上因为虚拟机执行的是odex而不是dex， 还需要对odex文件进行md5完整性校验， 如果匹配， 则直接加载。 不匹配，则重新生成一遍odex文件， 防止odex文件被篡改。
代码修复冷启动方案由于它的高兼容性， 几乎可以修复任何代码修复的场景， 但是注入前被加载的类（比如：Application类）肯定是不能被修复的。 所以我们把它作为一个兜底的方案， 在没法走热部署或者热部署失败的情况， 最后都会走代码冷启动重启生效， 所以我们的补丁是同一套的。 具体实施方案对Dalvik下和Art下分别做了处理：
-
Dalvik下通过巧妙的方式避免插桩， 没有带来任何类加载效率的影响。
-
Art下本质上虚拟机已经支持多dex的加载， 我们要做的仅仅是把补丁dex作为主dex(classes.dex)加载而已。
===============================================================================
前面我们知道冷启动方案几乎可以修复任何场景的代码缺陷，但Dalvik下的QFix方案存在很大的限制，下面将深入介绍在目前方案下为什么会有这些限制，同时给出具体的解决方案。
实现多态的技术一般叫做动态绑定，是指在执行期间判断所引用对象的实际类型，根据其实际的类型调用其相应的方法。多态一般指的是非静态私有方法的多态，field和静态方法不具有多态性。示例如下：
public class B extends A {
Strign name = “B name”;
@Override
void a_t1() {
System.out.println(“B a_t1”);
}
void b_t1(){}
public static void main(String[] args) {
A obj = new B();
System.out.println(obj.name);
obj.a_t1();
}
}
class A {
String name = “A name”;
void a_t1() {
System.out.println(“A a_1…”);
}
void a_t2();
}
输出结果： A name / B a_t1
可以看到name这个field没有多态性，print这个方法具有多态性，这里先分析一下方法多态性的实现。首先 new B()的执行会尝试加载类B，方法调用链 dvmResolveClass->dvmLinkClass->createVtable，此时会为类B创建一个vtable，其实在虚拟机中加载每个类都会为这个类生成一张vtable表，vtable表就是当前类的所有virtual方法的一个数组，当前类和所有继承父类的public/protected/default方法就是virtual方法，因为public/protected/default修饰的方法是可以被继承的。private/static方法不属于这个范畴，因为不能被继承。
这里就不放 createVtable()的代码了，有兴趣的可以自行上网查阅，这里来大概说一下它做了什么，子类vtable的大小等于子类virtual方法数+父类vtable的大小：
-
整体复制父类的vtable到子类的vtable
-
遍历子类的virtual方法集合，如果方法原型一致，说明是重写父类方法，那么在相同索引位置处，子类重写方法覆盖掉vtable中父类的方法
-
若方法原型不一致，那么把该方法添加到vtable末尾。
所以在上述示例中，假如父类A的vtable是 vtable[0]=A.a_t1, vtable[1]=A.a_t2，那么B类的vtable就是 vtable[0]=B.a_t1, vtable[1]=A.a_t2, vtable[2]=B.b_t1。接下来 obj.a_t1()发生了什么。invoke-virtual指令的解释如下：
最后
**一个零基础的新人，我认为坚持是最最重要的。**我的很多朋友都找我来学习过，我也很用心的教他们，可是不到一个月就坚持不下来了。我认为他们坚持不下来有两点主要原因：
他们打算入行不是因为兴趣，而是因为所谓的IT行业工资高，或者说完全对未来没有任何规划。
刚开始学的时候确实很枯燥，这确实对你是个考验，所以说坚持下来也很不容易，但是如果你有兴趣就不会认为这是累，不会认为这很枯燥，总之还是贵在坚持。
技术提升遇到瓶颈了？缺高级Android进阶视频学习提升自己吗？还有大量大厂面试题为你面试做准备！
提升自己去挑战一下BAT面试难关吧
对于很多Android工程师而言，想要提升技能，往往是自己摸索成长，不成体系的学习效果低效漫长且无助。整理的这些知识图谱希望对Android开发的朋友们有所参考以及少走弯路，本文的重点是你有没有收获与成长，其余的都不重要，希望读者们能谨记这一点。
不论遇到什么困难，都不应该成为我们放弃的理由！
如果有什么疑问的可以直接私我，我尽自己最大力量帮助你！
最后祝各位新人都能坚持下来，学有所成。
《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》，点击传送门，即可获取！
两点主要原因：
他们打算入行不是因为兴趣，而是因为所谓的IT行业工资高，或者说完全对未来没有任何规划。
刚开始学的时候确实很枯燥，这确实对你是个考验，所以说坚持下来也很不容易，但是如果你有兴趣就不会认为这是累，不会认为这很枯燥，总之还是贵在坚持。
技术提升遇到瓶颈了？缺高级Android进阶视频学习提升自己吗？还有大量大厂面试题为你面试做准备！
提升自己去挑战一下BAT面试难关吧
[外链图片转存中…(img-t7VvXoOw-1715340655619)]
对于很多Android工程师而言，想要提升技能，往往是自己摸索成长，不成体系的学习效果低效漫长且无助。整理的这些知识图谱希望对Android开发的朋友们有所参考以及少走弯路，本文的重点是你有没有收获与成长，其余的都不重要，希望读者们能谨记这一点。
不论遇到什么困难，都不应该成为我们放弃的理由！
如果有什么疑问的可以直接私我，我尽自己最大力量帮助你！
最后祝各位新人都能坚持下来，学有所成。
《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》，点击传送门，即可获取！
1607
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
