最近编辑于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