《深入探索Android热修复技术原理》读后感以及插件化思考

最近编辑于2019/02/17

主要介绍了阿里Sophix方案。

热修复的概念：

AndroidManifest出现BUG是无法修复的，想增加四大组件，可通过预先在安装包的AndroidManifest里面埋入代理的组件，在每次新增组件时，通过预埋的代理组件实现与系统进程间的通信。

热修复需要在补丁包中包含一个新逻辑的dex文件。

资源的修复，主要通过修改资源包的内容。

so库修复是通过在加载时优先加载补丁包的so库。

 

热替换代码修复：

Andfix底层替换的局限性：Andfix是根据公开的Android源码对ArtMethod结构体里面的字段进行的修改。如果手机厂商修改了ArtMethod的结构体（其实是在结构体前面增加字段，编译为AOT机器码后发生替换错位），就会导致机型不支持。

而Sophix采用了整体替换ArtMethod的方案，就避免了手机厂商修改结构体的问题。但也带来需要计算ArtMethod大小的问题，后来发现ArtMethod Array的地址是紧密排列的，通过相邻两个ArtMethod的起始地址的差值计算出ArtMethod的大小。优点只要以后ArtMethod数组仍是以线性结构排列，该方案仍能适用。

访问权限的问题：通常是因为类是由不同的Classloader加载导致的，可以通过反射或者采用冷启动的方式来解决。

热替换的局限：因为热替换需要原有的类实例的结构不变。因此使用Sophix进行热修复，想让用户体验到热替换，只能在原有类的方法里修改或者新增一个原包不存在的新类（PS这样会使代码变乱，在上升级包前应该重新整理代码）。还有其他一些局限：比如尽量不要增加非静态内部类、需要混淆配置加上-donto