安卓插件化与热修复的选型（转）

Posted 2020-10-12 weizhxa

参考文章：

安卓插件化的过去现在和未来 张涛

http://kymjs.com/code/2016/05/04/01

安卓插件化从入门到放弃 包建强

http://www.infoq.com/cn/news/2016/04/baojianqiang-interview

安卓热补丁动态框架小结 鸿洋

http://blog.csdn.net/lmj623565791/article/details/49883661

专访罗迪：高二android大牛的成长之路

http://www.infoq.com/cn/news/2016/05/lody-interview/

DroidPlugin的原理

http://www.zhihu.com/question/35138070

 

插件化

安卓从三年前第一个插件化实现，到现在已经有很多种实现方法，主要目的为了减小模块耦合，方便在项目体量变大之后实现更好地团队协作。

实现了分进程之后，插件的崩溃也不会影响到主进程的使用。

AndroidDymnamicLoader

使用Activity作为外壳，里面包含fragment，通过fragment管理activity的生命周期，是最早的插件化方案。尽管比较古老，但在当时已经是先进的思路了。

dynamic-load-apk

简称DL，作者任玉刚，在百度。使用代理的方式执行被加载APK的activity中的方法，因为代理类拿不到基类的方法，所以有了that指针。算是最早的国产插件化框架了。

CJFrameForAndroid

作者张涛。根据DL得到启发，并在后续支持了Service以及Activity的launch mode。

android-pluginmgr

作者null，使用虚拟机字节码的方式生成插件类的子类。首次部署效率较低，后面速度快得多。

虽然有效率问题，但是此种方式的插件代码不必遵循任何限定。

不过作者现在已经改变实现方式，通过Instrument来进行加载。

direct-load-api

简称DLA，作者Lody，当时是一个中学生。也是代理的方式，只不过把插件activity伪装成调用者的样子（通过反射修改改插件Activity的部分成员变量为调用者的变量）。

这种实现也不需要遵循任何限定，也可以自由地使用插件中的资源，也不需要在主调（宿主）模块中声明Activity，当时还不支持Activity以外的组件。

后续，作者也在研究虚拟机挂钩的方式来实现插件化。在项目中看到的使用较少，坑量不明确。

现在Lody起了一个新框架叫VirtualApp，使用了新的实现方式。

DroidPlugin

作者张勇，来自360手机助手。这个算是比较靠谱的坑比较少的框架，可以较快地用于项目。框架主要用到了动态代理和hook机制，具体原理参考上面链接。

这个框架还有一个好处。一半插件在更新之后，只有重新启动才能更新为新的内容，而用户是不用去更新的，也不可能在用户用一半的时候重启app，不太现实。而这个框架的插件和宿主则是在不同的进程中，这也是第一个分进程的框架，可以单独重新加载插件而不影响整个APP的使用。

OpenAtlas

来自淘宝团队，也是比较靠谱的框架，暂时还没看透，后面慢慢看，易用性感觉不如DroidPlugin。

 

热修复

热修复的主要应用场景则是让用户无感知地修复线上问题，防止遇到问题后各部门措手不及。

热修复和插件化的根本都是利用classLoader来加载APK和dex，不同的是插件化大多加载的是APK，其中携带资源，而热修复主要用于修复代码，不包含资源，修复的单位也大多以dex为主，dex尽量小。

虽然根本都是利用classLoader，但是想用一个框架搞定两个功能还是不太现实的，虽然插件化或热修复也可以实现对方的部分需求，但是因为具体流派的原因，所使用的技术还是不同的，要分开处理。

市面上常见的热修复框架包括：

Andfix（阿里）

Exposed（阿里）

Nuwa（实现类似于QQ空间）

Tinker（微信）

其中前两中实现方式是通过把方法重定向到native方法，来实现在调用方法的前中后对方法进行修改和替换。前两种的缺点是重定向native后兼容性和适配性变差。

Nuwa根据DexClassLoader中的DexPathList的加载顺序，将补丁的方法优先加载。这种方法会遇到报错。在dalvik虚拟机情况下，可以使用插桩的方式解决，参考链接资料。art虚拟机的环境下，还没有看。这种方式的插桩带来了一定的性能损耗。

最后微信Tinker则是研究dex文件的格式，将补丁与前dex合并，性能较好，不过可能出现rom较大的情况。

几种框架对比：

 

鉴于每一个成熟的框架都有大量的适配工作，基于稳定性考虑最后初步选型：

插件化：DroidPlugin

热修复：Tinker