Android Hot Fix Detailed technical principle (the latest and most complete version)
This paper frame
- What is hot fixes?
- Hot Fix Framework Classification
- Principle and Features
- Tinker analytical framework
- Each frame comparison chart
- to sum up
By reading this article, you will have a better thermal remediation technology knowledge, this article lists the advantages and disadvantages of various types of technical principles and frameworks, the end of the article briefly describe the framework of Tinker.
First, what is hot fixes?
Normal development process
Hot Fix the development process
Hot Fix advantage
What fix?
Second, the hot fix Framework Classification
Status: Hundred Flowers
Simple classification
More reasonable classification
Third, the technical principles and characteristics
3.1 Ali Dexposed - native solutions
principle:
- Method structure information directly on the exchange native layer, thereby achieving perfect replacement of old and new methods, in order to achieve heat repair
His thoughts completely from the Xposed framework, the perfect interpretation of the AOP programming, used here is the core of knowledge acquisition in the native layer to the structure of the specified method, and then change his nativeFunc field value, and this value is that you can specify this native function pointers corresponding method, the layer jump start Java native layer, changing the value of the specified nativeFunc method, and then calls the callback function to Java layer after changing. Function to achieve the interception method.
- Xposed Based on open source framework, it is an AOP solution
- Hook App itself only process that does not require Root access
advantage:
- With immediate effect
- Without any compiler or instrumented code is rewritten, the normal operation does not introduce any performance overhead. This is like AspectJ framework can not match advantage;
- The method of rewriting of the performance overhead is extremely low (microseconds), substantially negligible;
- From an engineering perspective, the hotfix is only a small chopper pilot, its real power lies in "Online Debugging";
- Based Xposed realization of the principle AOP can not only hook your own code, the code can also hook Android SDK with the process, which also allows us to have the ability to fill in pits dug in Google's own App.
Disadvantages:
- On Dalvik almost perfect, it does not support ART (requires additional implementations), so can not be used more than 5.0;
- The biggest challenge lies in the stability and compatibility, and native abnormal investigation more difficult;
- Unable to increase class variables and other restrictions, can not do feature release level;
Related Links:
- 文章：https://www.zhihu.com/question/31894163
- 文章：
http://www.wjdiankong.cn/android%E4%B8%AD%E5%85%8Droot%E5%AE%9E%E7%8E%B0hook%E7%9A%84dexposed%E6%A1%86%E6%9E%B6%E5%AE%9E%E7%8E%B0%E5%8E%9F%E7%90%86%E8%A7%A3%E6%9E%90%E4%BB%A5%E5%8F%8A%E5%A6%82%E4%BD%95%E5%AE%9E%E7%8E%B0/ - Dexposed源码：https://github.com/alibaba/dexposed
- Xposed源码：https://github.com/rovo89/Xposed
3.2 阿里AndFix -- native解决方案
原理：
- 与Dexposed一样都基于开源框架Xposed实现，是一种AOP解决方案
优点：
- 即时生效
- 支持dalvik和art（AndFix supports Android version from 2.3 to 7.0, both ARM and X86 architecture, both Dalvik and ART runtime, both 32bit and 64bit.）
- 与Dexposed框架相比AndFix框架更加轻便好用，在进行热修复的过程中更加方便了
缺点：
- 面临稳定性与兼容性问题
- AndFix不支持新增方法，新增类，新增field等
AndFix（Dexpsed）框架不稳定的原因（痛点）
相关链接：
3.3 QQ空间--Dex插桩方案（大众点评的Nuwa参考其实现并开源）
原理：
- 原理是Hook了ClassLoader.pathList.dexElements[]。因为ClassLoader的findClass是通过遍历dexElements[]中的dex来寻找类的。当然为了支持4.x的机型，需要打包的时候进行插桩。
- 越靠前的Dex优先被系统使用，基于类级别的修复
优点：
- 不需要考虑对dalvik虚拟机和art虚拟机做适配
- 代码是非侵入式的，对apk体积影响不大
缺点：
- 需要下次启动才会生效
- 最大挑战在于性能，即Dalvik平台存在插桩导致的性能损耗，Art平台由于地址偏移问题导致补丁包可能过大的问题
- 虚拟机在安装期间为类打上CLASS_ISPREVERIFIED标志是为了提高性能的，我们强制防止类被打上标志是否会影响性能？这里我们会做一下更加详细的性能测试．但是在大项目中拆分dex的问题已经比较严重，很多类都没有被打上这个标志。
插桩方案性能上的痛点：
相关链接：
- 文章：https://zhuanlan.zhihu.com/magilu/20308548
- 文章：http://blog.csdn.net/sbsujjbcy/article/details/50812674
- Nuwa源码：https://github.com/jasonross/Nuwa
- HotFix源码：https://github.com/dodola/HotFix
- DroidFix源码：https://github.com/bunnyblue/DroidFix
3.4 美团Robust -- Instant Run 热插拔原理
原理：
- Robust插件对每个产品代码的每个函数都在编译打包阶段自动的插入了一段代码，插入过程对业务开发是完全透明
- 编译打包阶段自动为每个class都增加了一个类型为ChangeQuickRedirect的静态成员，而在每个方法前都插入了使用changeQuickRedirect相关的逻辑，当 changeQuickRedirect不为null时，可能会执行到accessDispatch从而替换掉之前老的逻辑，达到fix的目的。
优点：
- 几乎不会影响性能（方法调用，冷启动）
- 支持Android2.3-8.x版本
- 高兼容性（Robust只是在正常的使用DexClassLoader）、高稳定性，修复成功率高达99.9%
- 补丁实时生效，不需要重新启动
- 支持方法级别的修复，包括静态方法
- 支持增加方法和类
- 支持ProGuard的混淆、内联、优化等操作
缺点：
- 代码是侵入式的，会在原有的类中加入相关代码
- so和资源的替换暂时不支持
- 会增大apk的体积，平均一个函数会比原来增加17.47个字节，10万个函数会增加1.67M。
- 会增加少量方法数，使用了Robust插件后，原来能被ProGuard内联的函数不能被内联了
相关链接：
- 美团技术文章：https://tech.meituan.com/android_robust.html
- 美团技术文章：https://tech.meituan.com/android_autopatch.html
- Robust源码：https://github.com/Meituan-Dianping/Robust
3.5 微信Tinker
原理：
- 服务端做dex差量，将差量包下发到客户端，在ART模式的机型上本地跟原apk中的classes.dex做merge，merge成为一个新的merge.dex后将merge.dex插入pathClassLoader的dexElement，原理类同Q-Zone，为了实现差量包的最小化，Tinker自研了DexDiff/DexMerge算法。Tinker还支持资源和So包的更新，So补丁包使用BsDiff来生成，资源补丁包直接使用文件md5对比来生成，针对资源比较大的（默认大于100KB属于大文件）会使用BsDiff来对文件生成差量补丁。
优点：
- 支持动态下发代码
- 支持替换So库以及资源
缺点：
- 不能即时生效，需要下次启动
Tinker已知问题：
- Tinker不支持修改AndroidManifest.xml，Tinker不支持新增四大组件(1.9.0支持新增非export的Activity)；
- 由于Google Play的开发者条款限制，不建议在GP渠道动态更新代码；
- 在Android N上，补丁对应用启动时间有轻微的影响；
- 不支持部分三星android-21机型，加载补丁时会主动抛出"TinkerRuntimeException:checkDexInstall failed"；
- 对于资源替换，不支持修改remoteView。例如transition动画，notification icon以及桌面图标。
Tinker性能痛点：
- Dex合并内存消耗在vm head上，容易OOM，最后导致合并失败。
- 如果本身app占用内存已经比较高，可能容易导致app本系统杀掉。
相关链接：
3.6 阿里Sophix
原理(双剑合璧)：
优化Andfix（突破底层结构差异，解决稳定性问题）：
Andfix底层ArtMethod结构时采用内部变量一一替换，倒是这个各个厂商是会修改的，所以兼容性不好。
Sophix改变了一下思路，采用整体替换方法结构，忽略底层实现，从而解决兼容稳定性问题。
突破QQ和Tinker的缺陷
QQ和Tinker的缺陷
Sophix对dex的解决方案
- Dalvik下采用阿里自研的全量dex方案：不是考虑把补丁包的dex插到所有dex前面（dex插桩），而是想办法在原理的dex中删除（只是删除了类的定义）补丁dex中存在的类，这样让系统查找类的时候在原来的dex中找不到，那么只有补丁中的dex加载到系统中，系统自然就会从补丁包中找到对应的类。
- Art下本质上虚拟机以及支持多dex的加载，Sophix的做法仅仅是把补丁dex作为主dex（classes.dex）而已，相当于重新组织了所有的dex文件：把补丁包的dex改名为classes.dex，以前apk的所有dex依次改为classes2.dex、classes3.dex ... classesx.dex，如下图所示。
资源修复另辟蹊径
常用方案（Instant Run技术）：这种方案的兼容问题在于替换AssetManager的地方
Sophix资源修复方案
SO修复另辟蹊径
四、Tinker框架解析
之所以只贴了Tinker的代码框架，是因为目前开源的方案中是最好的，当然除了Robust。
代码结构
修复流程
这里后续再补一个详细的源码分析，敬请期待
五、对比图（来自不同的地方）
来自Tinker的对比
来自Sophix的对比
来自蘑菇街 Android 热修复探索之路
其他文章
浅谈Android热修复：
-
Android 热修复专题：支付宝、淘宝、微信、QQ空间、饿了么、美丽说蘑菇街、美团大众点评方案集 https://zhuanlan.zhihu.com/p/25863920
六、总结
如果不考虑增大apk的体积，只是简单的修复代码，不修复so和资源，选择Robust是最稳定的，否则的话选择Tinker是一个不错的方案。虽然阿里Sophix横空出世，但是它不开源，而且商业收费，所以一般不是很赚钱的app选择收费的可能就很小了。不过它确实各方面都做了大量的优化，本文中的很多知识点也来源于阿里的《Android热修复技术原理.pdf》一书，本书值得一读，里面就是基于Sophix框架来编排的。