Android 组件化，插件化，热更新/热修复

概要了解，先要明确这几个功能具体是做什么的，是为了解决什么问题

1.组件化

组件化首先要做的事是将app按功能模块进行拆分，降低各个模块间的耦合，并且可以将每个模块单独编译运行，也可以进行全量打包，可分可合。那说到这里，好处就显而易见了，在团队开发中可以让功能模块责任到人，各个模块开发同步进行，增强协作能力以及效率。全量或者拆分运行打包依靠的是gradle的灵活配置能力。

总结：组件化可拆分可全量打包，组件可单独测试，打包，提高开发效率。

2.插件化

插件化见名知意，像插件一样可插拔。但是需要提前预留插件的插槽，也就是对应插件的apk。实际开发中，会预先将一个插件打包成一个apk，放置到主module下的assets目录，而后在运行过程中，如果需要，先将assets目录下的apk复制到app的目录下，读取到插件apk，再通过反射(DexClassLoader)从对应的dex文件中读取到对应的类进行加载。但是该功能无法直接绕过Android的清单文件注册（并不绝对，比较麻烦），所以如果进行页面的加载是不能使用Activity的，只能加载Fragment。当然，预留的插件app也可以通过动态部署的方式去更新放置到app目录下，故可以变相的减少app的体积，提升用户体验。

总结：插件化可以通过动态部署的方式，减少apk体积，增强功能上的灵活性。

注意：插件化对插件的行为是已经预测到的有计划的。所以会预先留出加载的逻辑，只是相关的类文件首次打包不存在，这也是区别于热更新的地方。

3.热更新/热修复

热更新主要用于在线上环境，若线上出现bug或者需要更新一些功能，使用热更新适合的时候进行更新。该行为不需要像插件化一样预留“插槽”，哪里需要补哪里。

原理：干预（替换，或者增量更新）类加载器加载的dex数组。通过源码可知，类加载最终会将apk打包好的dex文件写入到一个“pathList”,这个pathList中包含的即为dex类型的元素。类加载过程中使用所谓的“双亲委派”机制，会优先从加载过的类的缓存中寻找，该pathList即为缓存。所以将需要修复的同名文件打包成dex（使用d8打包），放入到pathList的数组头部，加载过程中会从头至尾依次遍历，若找到则直接返回。

注意：1.补丁dex可以通过app内部动态部署下载到指定目录

2.修复完成或者移除补丁，需要重启app才可生效

3.该方案只是为大概原理，具体商业化使用远远不够。

4.除了以上说的，还有另外的方案。比如动态修改字节码文件。（未学习，不做讨论）

5.热更新是不需要预留插槽的，因为主要是为了修复已有的功能，缝补已有bug的同名文件。