android热更新框架哪个好

Posted 2023-04-22

参考技术A 一.基础知识

1.阿里的热更新框架已经开源 了。但已经很久没有更新过新版本了。当前的版本只支持到了 android 4.4。由于 5.0 起新的 ART 虚拟机、更严格的 SELinux 策略以及对 64 位的支持之类的事，使得 Xposed 都在开发上做了很多调整。我不知道 Dexposed 现在是否支持，但至少阿里没有开源。

2.在本地动态执行远端下发的代码是极度危险的行为。利用此方法执行非法代码等或用于绕过 Google Play 等市场的审查是违反相关协议的，也是对用户极度不负责任的行为。

3.在一些访问非常密集的地方使用热更新可能会对效率产生相对比较大的影响，应该避免使用.

4.我们可以对 Java 的 ScriptEngine 进行一些封装成为一个 HotPatch 类使得它更适合做热更新的工作。

5.首先,检查热更新补丁的管道一定要建立在 https 上，因为下发代码是极其危险的，如果被劫持，后果是无法想象的。其次,请求时最好自动带上 Android 版本、手机型号、地区、版本号等信息，以方便更精确地下发，千万不能下发错。

6.Java在运行时加载对应的类是通过ClassLoader来实现的，ClassLoader本身是一个抽象来，Android中使用PathClassLoader类作为Android的默认的类加载器

7.我们的如果想做hotpatch，一定要保证我们的hotpacth dex文件出现在dexElements列表的前面。

二.常用的热更新技术框架:

基于QQ空间的HotFix →→ 要使用到android dex分包方案→拆分dex的项目的话，可以参考一下谷歌的multidex方案实现.

大众点评的NuWa←项目补丁自动化做的很完整
alibaba/AndFix

阿里巴巴的DexPosed
dalvik_patch实现multidex
使用React-Native实现app热部署的一次实践
alibaba/AndFix

三、常用的热更新技术框架比较

Advantage
disadavantage
NuWa
1，可以新增类和字段，
2，兼容到6.0系统
1，基本原理是classloader,类加载器
2，不能修改资源文件，如图片布局等（可通过动态布局实现）
AndFix
1， 支持Android2.3到6.0版本
2， 支持arm与x86系统架构
3， 支持dalvik和ART的runtime
4， 不需要重启App即可应用补丁
1，不能新增类和字段，
2，不能修改资源文件,
3，不能修改manifest文件
4，不能新增成员变量
5，不能使用加固后的apk制作pacth文件
四、github地址
百度的同学的实现 HotFix
点评的同学的实现 Nuwa
阿里的同学的实现 AndFix
另：AndFix对static的支持不太好，下面是试验的Demo:
添加了一个静态的字段addString：

通过AndFix来制作patch会直接报错：

介绍自己的一个Android插桩热修复框架项目QuickPatch

QuickPatch项目地址：

https://gitee.com/egg90/QuickPatch 和 https://github.com/eggfly/QuickPatch 同步更新

类似于美团的Robust插桩热修复，但是代码可读性比较强，还在继续完善，todo list在项目README里

QuickPatch项目介绍

年轻人的第一个Android插桩热修复框架

基于函数插桩，兼容性好（Android版本升级不需要做修改），支持热更新无需重启app，参考了美团的Robust插桩热修复框架，精简了很多实现细节，代码可读性高

一句话原理

简单地讲，就是通过编译时在每个函数的头部插入一个if判断和一个proxy代理，就可以在运行时动态替换实现，无需重启。代码如下：

protected void onCreate(Bundle savedInstanceState) {
    if (_QPatchStub != null) {
        // _QPatchStub.proxy() will check method existance and call it
        MethodProxyResult proxyResult = _QPatchStub.proxy(this, "onCreate", "(Landroid/os/Bundle;)V", new Object[]{savedInstanceState});
        if (proxyResult.isPatched) {
            return;
        }
    }
    // origin implementation below
    super.onCreate(savedInstanceState);
    // ...
}

设计思路

• QuickPatch和美团Robust的区别是，Robust的编译和dex阶段分别使用ASM和Smali做了处理，QuickPatch仅在gradle编译java到class阶段使用Javassist处理，逻辑简单
• 不支持自动生成dex补丁（复杂度高，代码可读性差），所以需要手动生成补丁，但是提供了补丁类模版，写起来很方便
• 对于super的处理使用native调用CallNonVirtual##TYPE##Method()系列方法实现
• 计划支持构造函数和增加成员函数的热修复
• 可能计划支持非Android的纯Java代码的热修复

DEMO

使用说明

• 打开app/build.gradle中的一行apply plugin: ‘quickpatch.gradleplugin‘
• 然后使用AndroidStudio或者./gradlew执行下面任务:

./gradlew gradleplugin:uploadArchives # 编译插桩插件
./gradlew app:installDebug # 使用插件编译app代码并插桩

• 为了方便点击app内的Enable Patch按钮可以模拟补丁加载效果，实际上是使用原本的ClassLoader加载了apk内打包好的的QPatch类
• 同包名下后缀是_QPatch的类是补丁类，如MainActivity类的补丁类对应名字是MainActivity_QPatch
• 接下来框架代码会使用一个新的ClassLoader加载dex，然后反射识别并查找相应的函数是否存在，如果存在则新的函数里面的逻辑会被调用
• 补丁文件名一般是patch.dex, 生成dex需要手动使用命令，比如dx --dex --output=patch.dex MainActivity_QPatch.class
• 补丁文件需要手动放置到sd卡下，比如adb push patch.dex /sdcard/
• 然后点击app内的Enable Patch按钮即可实时加载补丁，看到pid不会有变化

性能优化思路

1. 减少没有patch的时候所有函数调用损耗
2. 减少有patch时，但没有走到patch涉及到的类时的损耗
3. 减少有patch时，走到patch类，但是没走到patch函数时的损耗
4. 减少有patch时，走到patch类，并走到patch函数时的损耗
5. 优化patch函数内不包含反射，和包含native反射或java反射的这三种情况