微信热修复方案深入理解

微信热修复框架出来已久,之前一直在用AndFix,感觉良好,但是对开发者不透明.再加上用的时间也长了,总想换个新的试一试.来了新的公司,就用新的方案,本人用的是腾讯Bugly集成的Tinker.虽然接入方式略有不同,但原理肯定大同小异不善口才和写作,写的不足之处,纰漏的地方请留言指正,Thanks♪(･ω･)ﾉ哦,还有,本文只介绍tinker的工作原理,不介绍如何集成和使用细节,因为官方github已经写得很明白了

先上一张流传已久的热修复方案比较图

这里关于即时生效补充一下,AndFix确实是及时生效的,但是Tinker,非但不是及时生效,经测试,甚至可能是在第三次,第四次重启进程之后才能生效

实际工作中,热修复用的最多的也就是代码,方法的替换,lib的替换和资源的替换,额,真的是用的比较少

目前热修复方案主要分为两大类:

一种如AndFix,主要在JNI之下,在native层做方法的替换,改变指针指向,从而达到了修复方法的效果

另一种就如Tinker,在Dex文件上做手脚,替换Dex文件,在DVM加载Dex时,是顺序遍历dexElements数组,dexElements就代表应用中所有的Dex文件(这也同样说明Tinker为何要和谷歌的mutidexDex一同使用),Tinker采用反射的机制,将PatchDex插入到dexElements最前,让DVM”顺理成章”的加载PatchDex
Tinker的替换Dex工作原理大致如此,除此之外还有资源,和lib,so的替换

基于替换Dex文件的热修复方案,都存在一个问题,那就是补丁包比较大,如Qzone的方案,这是BsDiff算法导致的必然结果,Tinker采用了腾讯自研的DexDiff算法,极大的降低了补丁包文件的大小.
Diff算法在commons包的algorithms.diff包内有详细的实现逻辑

这些类就是Tinker针对dex文件中不同数据片段执行不同的Diff的过程,从类名可见已经涵盖了所有的数据区
更多关于DexDiff算法,请参考
https://www.zybuluo.com/dodola/note/554061

在编译时,比较新旧两个Dex,生成差异dex文件,这个差异dex文件可以从编译后的apk中解压出来,通常也就几k的大小.
在运行时,将差异dex文件与APP中原dex文件整合为新的dex文件,这是在一个叫做patch的进程中进行的,当第二次启动APP时,执行的就是合并后的dex

关于tinker的修复dex就介绍到这里,以后会补充资源文件,so文件的修复原理

参考文章:
https://www.zybuluo.com/dodola/note/554061
http://blog.csdn.net/panespan/article/details/52686697
https://mp.weixin.qq.com/s?__biz=MzAwNDY1ODY2OQ==&mid=2649286306&idx=1&sn=d6b2865e033a99de60b2d4314c6e0a25&scene=1&srcid=0811AOttpqUnh1Wu5PYcXbnZ#rd