热更新重点
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热更新修复方案原理