Android客户端插件化热修复各种方案对比和最全总结

原文链接:Android客户端插件化热修复各种方案对比和最全总结

2016年不能扯几句热修复和插件化都不好意思说自己是做 Android 的，虽然我对这个技术不怎么感兴趣，奈何业务需要也得深入的研究一下，本文记录我对热修复的插件化的学习和研究。

技术背景

插件化解决的问题

1. 减小主包大小

2. 不发版上新功能

3. 独立开发加载 A/B TEST 模块

4. bug 修复工具

个人态度

学习这项技术是关心技术后的本质，在项目中能不用就不用，因为本身这种做法是 Google 不推荐的，RN才是今后的发展方向。但是RN性能方面的优化也很重要，这方面没深入了解。

在项目中引入新技术

在项目中使用新技术，哪怕是引入一个第三方库也要小心谨慎，确定是否确实需要。但是还是要对不了解的新的东西要积极学习、积极研究，这样在引入实际生产环境后也能快速踩坑出坑。

个人认为开发不能脱离业务，不能脱离实际场景为了技术而技术，也不能害怕引入新技术，风险和效率等优点是并存的，但是要合理的控制风险。

介绍名词

1. 插件化 – apk 分为宿主和插件部分，插件在需要的时候才加载进来

2. 热修复 – 更新的类或者插件粒度较小的时候，我们会称之为热修复，一般用于修复bug

3. 热更新 – 2016 Google 的 Android Studio 推出了Instant Run 功能 同时提出了3个名词

   “热部署” – 方法内的简单修改，无需重启app和Activity。 “暖部署” – app无需重启，但是activity需要重启，比如资源的修改。 “冷部署” – app需要重启，比如继承关系的改变或方法的签名变化等。

所以站在app开发者角度的“热”是指在不发版的情况来实现更新，而Google提出的“热”是指值是否需要重新启动。 同时在开发插件化的时候也有两种情景，一种是插件与宿主apk没有交互，只是在用户使用到的时候进行一次吊起，还有一种是与宿主有很多的交互。

从MulitiDex开始

当 Android 系统安装一个应用的时候，有一步是对 Dex 进行优化，这个过程有一个专门的工具来处理，叫 DexOpt 。DexOpt 的执行过程是在第一次加载Dex文件的时候执行的。这个过程会生成一个 ODEX 文件，即 Optimised Dex。执行 ODex 的效率会比直接执行 Dex 文件的效率要高很多。

但是在早期的 Android 系统中，DexOpt 有一个问题，DexOpt 会把每一个类的方法 id 检索起来，存在一个链表结 构里面。但是这个链表的长度是用一个 short 类型来保存的，导致了方法 id 的数目不能够超过65536个。当一个项目足够大的时候，显然这个方法数的上限是不够的。尽管在新版本的 Android 系统中，DexOpt 修复了这个问题，但是我们仍然需要对低版本的 Android 系统做兼容。

为了解决方法数超限的问题，需要将该dex文件拆成两个或多个，为此谷歌官方推出了 multidex 兼容包，配合 AndroidStudio 实现了一个 APK 包含多