Android热更新学习记录

热更新重点

1. dex热更新，即Java代码热更新

阿里系(AndFix,Hotfix)走的底层替换方案，好处在于实时生效，腾讯系(Tinker)走的是类加载方案，好处在于高兼容性。

阿里百川系（Sophix）就有点机智了，两种方案都有使用，还进行了一定的升级，优先走底层替换方案，底层替换方案走不下去了就走类加载方案。

AndFix(HotFix)的底层替换方案已过时，Sophix的无视底层具体结构的底层替换方案较新。

Tinker的类加载方案，需要重启应用后让Classloader去加载新类。因为Android上无法对一个类进行卸载，不重启，则无法加载新类。

2. 资源文件热更新

这里也是有两个流派，一个流派是参考Instant Run通过addAssetPath加载新的资源包到AssetsManager，然后再替换Resource中的AssetsManager；一个流派是构造新的R文件资源地址以0x66开头的资源包，再通过addAssetPath加载新的资源包到AssetsManager，因为新的R文件资源地址以0x66开头，新的Java代码里，也引用0x66开头的资源，这样就可以新旧资源不干扰且都能生效。

Tinker属于第一个流派，Sophix属于第二个流派。

3. so文件热更新

Build.VERSION.SDK_INT >= 23 是把补丁so库的路径加入后，跟systemNativeLibraryDirectories 合并,通过makePathElements方法反射，设置进nativeLibraryPathElements

Build.VERSION.SDK_INT >= 14 是把补丁so库的路径插入到nativeLibraryDirectories数组的最前面

基于java加载机制，研究热修复，可参考文章：

https://juejin.cn/post/6844903985602789384  从零开始手撸一个热修复框架

https://www.jianshu.com/p/22b6a169e6bd     Muitldex热更新修复方案原理