Android 热修复小结

主流热更新方案对比

QZone超级补丁

  • 实现原理:

    • 将需要修复的类打包成dex补丁文件

    • 客户端下载补丁包后,在下次app启动时检测到补丁包进行加载

    • 在类加载器中会将加载的dex保存到一个数组里pathList:DexPathList,由于双亲委托机制,如果数组前面的dex文件已经包含需要加载的类,则不会从后面的dex中查找该类

    • Path/DexClassLoader->BaseDexClassLoader->ClassLoader->PathDexList->dexElements->makePathElements

    • 所以应用启动时会将补丁包通过反射调用makePathElements方法,生成一个新的数组,然后与旧的dex数组合并,将补丁包的dex放到数组前面,这样就会优先加载修复后的类

  • 优点:兼容性和稳定性比较好,修复的成功率比较高,可以整个类替换

  • 缺点:

    • 如果修复的类比较多,补丁包会比较大,加载补丁包会比较耗时

    • 不能实时修复问题,需要重启后才可以

    • 在低版本dalvik虚拟机中会因为一个类调用另一个Dex中的类,导致修复失败问题;出现这个问题是因为虚拟机对于没有引用另一个dex文件中的类会做一个标记叫做class_is_pre_verified,这样它就不会再去其他dex中查找引用到的类,如果原来引用的类是在同一个dex中,但是修复后的类在另一个dex中,就会报错

    • 解决的方案是编译时钦通过修改字节码,在构造方法中去引用另一个dex中的固定类来避免被虚拟机标记

Tinker

  • 实现原理:整体上与QZone流程一致,主要区别在于它是通过BSDiffer与原dex文件进行对比生成差分包;

  • 优点:

    • 补丁包相比QZone更小

    • 差分包下发到客户端后会重新合成新的dex修复包,它加载时会整体替换旧的dex,避免了跨dex类调用问题

  • 缺点:

    • 不能实时修复问题,需要重启app才可以

    • dex的合并会在新的进程中进行,如果有多个dex需要合并时,合成的失败率可能也会高一些,而且下发的dex补丁包也会较多

  • 资源修复:将下发的补丁包资源通过AssertManager反射调用方法构建,然后替换掉原来的AssertManager

  • so修复:使用Tinker的类去加载so库,它会先查找是否有so库的更新包,如果没有就加载旧的

AndFix

  • 实现原理:核心原理是在native层查找到需要修复的方法结构体ArtMethod,然后把它替换成我们修复后的方法

  • 优点:不需要重启app,可以实时生效

  • 缺点:

    • 兼容性不大好,因为每个Android系统版本对这个ArtMethod结构会有些变化,比较难适配

    • 不支持新增字段、资源替换等

Robust

  • 实现原理:在编译期间,通过Gradle插件进行代码插桩,在每个类里加上一个静态变量,静态变量指向修复后的接口,每个方法内部,插入if/else代码,判断如果静态变量不为空,则执行修复后的代码;修复补丁下发后,会先通过ClassLoader加载到内存中,然后通过反射修改需要修复的那个类里的静态变量,让它指向修复后的类,当下次调用该方法时就会if语句执行修复后的代码

  • 优点:不需要重启app,可以实时生效,兼容性很好

  • 缺点:

    • 对项目代码有侵入性,增加了很多代码量,使得安装包会增大

    • 不支持资源和so修复

版本兼容性问题

  • 反射调用时源码上的差异

    • 低版本上PathDexList中将dex转成数组的方法叫makeDexElements但是高本版上叫makePathElements,参数也不一样
  • Android N混合编译执行问题

    • Android N开始为了解决ART虚拟机安装app比较慢的问题,在安装过程中只编译使用比较多的热代码,剩下的则在系统闲置时去编译

    • 在应用启用时会创建PathClassLoader,在构建PathClassLoader时,底层会优先加载已经编译好的热代码,这就导致正常情况下,我们无法再后续通过将补丁dex文件放到数组最前面来实现修复效果

    • 解决的办法就是,在应用启动时,重新构建一个新的PathClassLoader,然后将旧的PathClassLoader关键数据拷贝过来,忽略掉已经加载了的热代码,然后将我们创建的PathClassLoader替换要原来的ClassLoader

  • class_is_pre_verified问题:

    • 在dalvik虚拟机中,如果一个类没有引用其他dex里的类,就会被标记class_is_pre_verified,被标记后可以优化它的性能,如果修复的类里面,被引用的类又在另一个dex中,就会报错

    • 解决办法是在编译时期通过Gradle插件对代码插桩,在构造方法中去引用另一个dex中固定的类,从而避免被打上标签

资源修复

SO库修复

  • 加载so库的方式:

    • System.loadLibrary(libraryName):传入so库名称,位于libs目录下,最后会复制到apk安装目录

    • System.load(pathName):传入完整so库文件路径

    • 最后都会调用nativeLoad方法去加载so库文件

  • JNI方法动态注册和静态注册区别

    • 静态注册的方法需要在c/c++文件中以固定格式声明,Java开头,后面跟着完整类名+方法名;在方法调用时才去查找映射,效率较低

    • 动态注册方法需要实现JNI_OnLoad方法,并且注册一个JNINativeMethod数组;在so库加载时就完成映射,调用方法时效率高

  • 动态注册Native方法修复

    • 由于动态注册的native方法,方法映射是在so库加载时调用JNI_OnLoad方法完成的;所以只需要再次加载修复后的so库就可以了

    • 在ART虚拟机上是没问题的,但是在dalvik虚拟机里,它是根据so库文件名来判断so库是否已经加载过了,如果已经加载过了就不会去加载修复后的so库;ART虚拟机则是通过文件完整路径来判断是否加载过,所以没这个问题;我们可以通过改so库文件名来达到在dalvik虚拟机上修复的目的

  • 静态注册Native方法修复

    • JNI提供一个方法可以取消注册Native方法,但是重新加载so之后无法保证一定能修复,因为重新加载后的so可能在表中原来so的前面,也可能在后面
  • 所以没有可以同时兼容动态注册和静态注册实时修复so的方案,只能通过重启app进行修复

  • 冷修复so方案有两种:

    • 一种是提供一个加载so库的方法去替换自带的System.loadBinary方法,然后在自定义方法里优先去加载更新文件夹中的so库;这种方式会稍微麻烦点,需要开发者改代码,但是如果是第三方库里的代码就无法修改,这个情况也可以在我们代码中提前加载好第三方so库去实现,优点是没有版本兼容性问题

    • 另一种方法是通过反射修改DexPathList中存放so库路径的数组,将修复后的so路径添加到数组前面,这种方式就存在兼容性问题,如果Android版本对这个类有更新,就需要去适配,但是优点是可以做到无感修复,不需要开发者改代码

Resources资源修复

  • Android L(5.0)以及以上版本只要在原有AssertManager上反射调用addAssetPath方法将新apk资源路径添加进去就可以了

  • 【普遍实现方案】AndroidL(5.0)以下版本,由于native层查找资源时会优先查找旧的资源,所以需要重新创建一个AssetManager对象,并反射替换掉原来的AssetManager

  • 最佳实践:

    • AssetManager里有提供一个destroy方法用于释放资源,可以先调用该方法释放当前AssertManager中的资源,然后重新调用native层的init方法重新初始化当前AssetManager对象,最后再调用addAssetPath添加修复后的资源路径,从而实现不改变原有AssetManager对象进行资源修复

补丁包管理

  • 通过自定义Gradle插件,指定上个版本的混淆结果文件和R资源映射文件,在编译时期遍历所有的class文件并记录md5值,与上一个版本记录的md5值对比,将有修改过的class打包成dex补丁文件;或者打包结束后将生成的apk文件与上个版本apk文件使用差分工具bsdiff生成差分包作为补丁文件

你可能感兴趣的:(Android,架构设计,android,java,开发语言)