Tinker源码分析

Tinker是微信出品的热更新方案,采用类似QQ空间热修复的原理,是市面上不多的成熟方案。热修复牵扯的知识很多,而Tinker则做的比想象的更多。很好奇tinker是怎么实现的热修复,于是就有了这一系列文章,代码版本为1.9.14。
以tinker为代表的热修复方案的典型流程如下:

热修复步骤
1 获取当前应用的pathClassLoader
2 反射获取DexPathList属性PathList
3 反射修改pathlist的dexElement
3.1 将补丁包patch.dex转换为Elelment(patch)
3.2 获得pathList的dexElements属性 (old)
3.3 patch+old合并,并反射赋值给pathlist的DexElements属性

tinker热修复 可以分为patch打包和patch合成这两部分,可能牵扯的文件有dex,so,resource文件。合成也包括了patch的合成和加载这两部分,下载到patch时会进行patch的合成,而下次启动时就会开始加载合成之后的文件。
合成的流程图如下:


截屏2020-05-17下午5.27.54.png

加载的流程图大致如下:


截屏2020-05-17下午3.58.46.png

因此本系列文章分为以下几篇:

Tinker的补丁生成过程

Tinker的补丁加载-dex加载
Tinker的补丁加载-资源加载
[Tinker的补丁加载-so加载]

结合日志,对tinker的流程有个大概的了解。但是比较缺乏理论,比如之前有篇文章Android N混合编译与对热补丁影响解析,读了几遍后大概知道怎么回事,但是没有对应到tinker的源码。
今天学习的时候才对应上,tinker采用的方案是运行时替换PathClassLoader方案,这个对应的d代码时NewClassLoaderInjector中的doInject()方法,直接将系统的系统的classLoader替换为自己的classLoader,这时候才恍然大悟。
以后要加强理论学习。

因技术水平有限,在阅读tinker代码时对热修复这部分知识并不是掌握,因此理解有误在所难免,请不吝指正。

你可能感兴趣的:(Tinker源码分析)