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代码时对热修复这部分知识并不是掌握，因此理解有误在所难免，请不吝指正。