QFix探索之路——手Q热补丁轻量级方案
QFix 是手Q团队近期推出的一种新的 Android 热补丁方案，在不影响 app 运行时性能（无需插桩去 preverify）的前提下有效地规避了 dalvik 下”unexpected DEX”的异常，而且还是很轻量级的实现：只需调用一个很简单的方法就能办到。
热补丁方案及手Q上的使用
自2015年 Android 热补丁技术开始出现，之后各种方案和框架层出不穷，原创性的技术方案主要有以下几种：
手Q从去年开始研究补丁方案，当时微信的 Tinker 还没有推出，考虑到兼容性和稳定性，就选用了 java 反射 hack classloader 的方案，而且和当时已经很成熟的分 dex 从原理上很类似，主要的难点是如何解决 Qzone 发现的 dalvik 下”unexpected DEX”异常，由于没有研究出其它方法，就沿用了 Qzone 原创的插桩去 preverify 的解决方案，自2016年1月热补丁开始在手Q正式版本投入使用，至今解决问题十多个，修复效果十分明显，稳定性也很好。
性能无法提升，需要改变
插桩的解决方案会影响到运行时性能的原因在于：app 内的所有类都预埋引用一个独立 dex 的空类，导致安装 dexopt 阶段的 preverify 失败，运行时将再次 verify+optimize。近期我们通过 ReDex 尝试优化手Q的启动性能时发现：
保留手Q现有的插桩，启动性能没有任何优化效果
去掉插桩，优化手Q启动相关类的 dex 分布，启动性能提升 30%
另外即使后期手Q的发布版本实际上无需发布补丁，我们也需要预埋插桩的逻辑，这本身也是不合理的一点，所以确实有必要去探索新的方向，既保留补丁的能力，同时去掉插桩带来的负面影响。
重新分析”unexpected DEX”异常
寻找新的解决方案，还是需要回过头来分析下这个异常出现的条件：
这是 dalvik 的一段源码，当补丁安装后，首次使用到补丁里的类时会调用到这里，需要同时满足图中标出来的三个条件，才能出现异常，这三个条件的含义如下：
可以看出，Qzone 的插桩方案是突破了条件2的限制（统一去掉了所有引用类的 preverify 标志），而微信 Tinker 的 dex 增量合成方案是突破了条件3的限制（将补丁和 app dex 合成后替换，原先 app 里在同一个 dex 的两个类，其中一个后来打在补丁里，合成后还是会在同一个 dex里），那有没有办法从条件1入手呢？条件1中 fromUnverifiedConstant 为 true 就行，其实之前就有从这个条件进行突破的方案：
主要思路是：每当系统调用到这个方法，通过 native hook 拦截这个系统方法，更改这个方法的入口参数，将 fromUnverifiedConstant 统一改为 true，但和 Andfix 类似，native hook 方式存在各种兼容性和稳定性问题，而且拦截的是一个涉及 dalvik 基础功能同时调用很频繁的方法，无疑风险会大很多。
找到新的“大陆”
这段逻辑所在的方法是 dvmResolveClass，通过类之间的引用会调用这个方法，入口参数分别是引用类的 ClassObject，被引用类的 classIdx，以及引用关联的 dalvik 指令是否为 const-class/instance-of，返回的是被引用类的 ClassObject，经反复阅读分析，终于发现了一个可以利用的细节:
dvmResolveClass 在最开始会优先从当前 dex 已解析类的缓存里找被引用类，找到了直接返回，找不到时说明被引用类还没有被加载，接着加载成功后，会往当前 dex 缓存里设置上这个类的引用，后续所有对补丁类的解析引用都不会走到后面的“unexpected DEX”异常逻辑里，至于 dex 里已解析类 get/set 的相关逻辑如下：
结合以上分析，我想到一个思路：只需首次引用到补丁类时能够成功突破上述三个条件之一的限制即可，Qzone 突破条件2和 Tinker 突破条件3的方法操作过重，而且带来的影响是持续性的，而从条件1入手很简单：补丁安装后，预先以 const-class/instance-of 方式主动引用补丁类，这次引用会触发加载补丁类并将引用放入 dex 的已解析类缓存里，后续 app 实际业务逻辑引用到补丁类时，直接从已解析缓存里就能取到，这样很简单地就绕开了“unexpected DEX”异常，而且这里只是很简单地执行了一条轻量级的语句，并没有其它额外的影响。
另外考虑多 dex 的情况，补丁类很可能被多个不同 dex 里的类引用，那么需要在每个 dex 里找到一个引用类来预先引用补丁类吗？如果 app 里引用类和补丁类原本是在同一个 dex 里，引用类有可能是 preverify 的，这种情况是需要预先引用的；如果原本就不是一个 dex 里的，引用类由于有对其它 dex 类的依赖，就肯定不是 preverify 的，这种情况条件2本来就是不满足的，就没有必要预先引用了，所以可以推断出只需要针对补丁类在原先 app 所对应的 dex 进行预先引用即可。
梳理了思路后，马上在一个简单的 demo 上验证：
demo 里补丁包含的类是 BugObject，通过对比，如果代码不包含上图红框里的预先引用的逻辑，出现了预期的“unexpected DEX”异常，如果加上这一行代码，demo 运行正常，而且补丁的修复功能也生效。通过 dexdump 查看，确实是优先通过 const-class 指令引用补丁类的。
没那么简单，初步方案行不通
上面的 demo 预埋了补丁里包含的类，但在实际运用中我们是无法预先设定哪些类要打补丁的，dex 里对补丁类 const-class/instance-of 方式的引用指令是编译时确定的，但具体是哪些类又需要在运行时动态确定，所以这种动态方式行不通，最初想到的是类似插桩的做法，预先把 app 里所有类都以 const-class 方式引用一遍，但很明显有以下问题：
1）由于 app 里类的数量很多，所有类的预先引用统一放在一个地方肯定不现实，需要分散在多个区，只对补丁类所在的少数几个区执行预先引用的操作，但这里如何划分的粒度不好把握，而且 app 里的类及数量一直变化，我们做过一些尝试，但没有比较理想的可考量的方案。
2）预先引用解析所有类，会增加引用类的加载耗时和引用语句本身的执行耗时，对于执行耗时，可以通过添加条件判断来优化，如果要解析的类在补丁类名列表里就执行该语句，否则就不执行，对于加载耗时，初步的测试结果如下（这里一个划分的区包含500个左右的类，并进一步区分了是否 preverify，而测试的补丁包里包含2个类）：
从测试数据看，加载的耗时较长，而且补丁类不可预期，如果不巧分布在多个区里，累计耗时的影响将会严重得多。
3）该方案实现起来特别繁琐，不实用
确定最终方案
新的方案在 java 层找不到可行的实现方式，就尝试从 native 层切入，只需首次引用解析补丁类时，直接通过 jni 调用 dalvik 的 dvmResolveClass 这个方法，当然传入的参数 fromUnverifiedConstant 需要设为 true，这个思路与前面说的 native hook 方式不同，不会去 hook 这个系统方法，而是从 native 层直接调用：
dvmResolveClass 方法是在 dalvik 的系统库 /system/lib/libdvm.so 里，通过 dlopen 即可获取该系统库的句柄
通过 dlsym 获取 dvmResolveClass 这个方法的地址
设定 dvmResolveClass 这个方法的三个入口参数，再调用 dvmResolveClass：
1）引用类 referrer 的 ClassObject：这里需要设定一个引用类，并且能够获取到该类的 ClassObject
2）补丁类的 classIdx：需要获取补丁类在 app 原先所在 dex 的 classIdx，通过这个 classIdx 可以在 dex 里找到已解析的类或者获取类的名字
3）布尔值 fromUnverifiedConstant：在C/C++层，这个值可以固定设置为1或者 true
这里的关键是能获取到前两个参数的值，第一个参数引用类的 ClassObject，最初借鉴的是 dvmResolveClass 里调用的 dvmFindClassNoInit 这个方法，但这个方法获取一个类的 ClassObject 需要两个参数，其中类名很容易构造，但需要额外的操作获取引用类的 ClassLoader 对象的地址，之后又找到一个更便利的方法 dvmFindLoadedClass：
这个方法只用传入类的描述符即可，但必须是已经加载成功的类，在补丁注入成功后，在每个 dex 里找一个固定的已经加载成功的引用类并不难。对于主dex，直接用 XXXApplication 类就行，对于其它分 dex，手Q的分 dex 方案有这样的逻辑：每当一个分 dex 完成注入，手Q都会尝试加载该 dex 里的一个固定空类来验证分 dex 是否注入成功了，所以这个固定的空类可以作为补丁的引用类使用。第二个参数 classIdx，可以通过 dexdump -h 获取：
这个过程可以通过一个小程序自动进行：
输入：原有 apk 的所有 dex、补丁包所有的类名
输出：补丁包每个类所在 dex 的编号以及 classIdx 的值
注1：如果在补丁新增原 app 不存在的类，运行时新增类只会被补丁 dex 即同一个 dex 里的类所引用，所以新增的补丁类无需预先解析引用。
注2：由于”unexpected DEX”异常出现在 dalvik 的实现里，art 模式下不会存在，以上预先引用补丁类的逻辑只需用在5.0以下的系统。
最终新方案的整体实现流程如下图所示：
可以看出，新的方案是很轻量级的实现，只需一个很简单的 jni 方法调用就能解决问题，既不用构建时预先插桩去 preverify，也不用下载补丁后进行 dex 的全量合成。
兼容性问题及解决
这个方案由于是 native 层的，我们也通过众测方式对兼容性做了充分的验证：
不同系统版本导出符号：
在2.x版本dalvik是用C写的，2.3以上的4.x版本是用C++写的，基于C++ name mangling原理， dvmFindLoadedClass在编译后会变为_Z18dvmFindLoadedClassPKc，但经IDA反汇编libdvm.so分析，dvmResolveClass没有变化yunos ROM的兼容性问题：
在第一次众测任务中，有446位用户参与，其中有6位反馈补丁不生效的问题，从反馈的结果码看都是libdvm.so加载成功，但是符号导出为NULL导致的，后来发现这6位用户安装的都是yunos的rom，经分析定位到原因如下：
可以看到dlopen libdvm.so时将库的名字改为了libvmkid_lemur.so，yunos的dalvik实现实际上在后面这个库里，而且通过反汇编发现导出的符号名也变化了，但内部的实现逻辑没有变化：dvmResolveClass -> vResolveClass _Z18dvmFindLoadedClassPKc -> _Z18kvmFindLoadedClassPKc在dlsym调用时考虑以上两种可能的符号名即可，经本地和以上问题用户的再次验证，已成功解决。
x86平台的兼容性问题：
解决了yunos的兼容问题后，在第二次众测任务中，有1884位用户参与，有3位反馈异常，发现问题用户都是x86平台的，由于最开始未对x86平台作兼容，arm平台的动态库在x86手机上运行的异常有两种：
a) 部分手机一直卡在黑屏界面，经日志定位，这些手机都安装了houndini的第三方库，会自动将arm的so转换为x86平台兼容的，so加载及符号导出都没问题，在成功获取dvmResolveClass符号地址后，就一直卡在dvmResolveClass的调用逻辑里，应该是houndini库的转换问题
b) 部分手机运行正常，但导出符号都为NULL
在提供x86平台的so后，以上两个问题也成功解决了。
如果您觉得我们的内容还不错，就请扫描二维码赞赏作者并转发到朋友圈，和小伙伴一起分享吧~
本文系腾讯Bugly独家内容，转载请在文章开头显眼处注明作者和出处“腾讯Bugly(http://bugly.qq.com)”