热更新

组件化

就是将app分成多个模板,每个模块都是一个组件(Model),开发的过程中我们可以让这些组件相互依赖或者单独调试部分组件等，但是最终发布的时候是将这些组件合并统一成一个apk，这就是组件化开发。

插件化

将整个app拆分成很多模块，这些模块包括一个宿主和多个插件，每个模块都是一个apk（组件化的每个模块是个lib），最终打包的时候将宿主apk和插件apk分开或者联合打包。开发中，往往会堆积很多的需求进项目，超过 65535 后(会报错,详细解决方案百度去)，插件化就是一个解决方案。

增量更新

与热更新区别最大的一个，其实这个大家应该很好理解，安卓上的有些很大的应用，特别是游戏，大则好几个G的多如牛毛，但是每次更新的时候却不是要去下载最新版，而只是下载一个几十兆的增量包就可以完成更新了，而这所使用的技术就是增量更新了。实现的过程大概是这个样子的：我们手机上安装着某个大应用，下载增量包之后，手机上的apk和增量包合并形成新的包，然后会再次安装，这个安装过程可能是可见的，或者应用本身有足够的权限直接在后台安装完成。

热更新

更新的类或者插件粒度较小的时候，我们会称之为热修复，一般用于修复bug！！比如更新一个bug方法或者紧急修改lib包，甚至一个类等。2016 Google 的 Android Studio 推出了Instant Run 功能 同时提出了3个名词；“热部署” – 方法内的简单修改，无需重启app和Activity。 “暖部署” – app无需重启，但是activity需要重启，比如资源的修改。 “冷部署” – app需要重启，比如继承关系的改变或方法的签名变化等。
所以站在app开发者角度的“热”是指在不发版的情况来实现更新，而Google提出的“热”是指值无需重新启动。 同时在开发插件化的时候也有两种情景，一种是插件与宿主apk没有交互，只是在用户使用到的时候进行一次吊起，还有一种是与宿主有很多的交互。

热修复框架分类

分类

Tinker原理

BaseApk就是我们的基准包，也就是渠道上线的包。
NewApk就是我们的hotfix包，包括修复的代码资源以及so文件。
Tinker做了对应的DexDiff、ResDiff、BsDiff来产出一个patch.apk,里面具体内容也是由lib、res和dex文件组成，assets中还有对应的dex、res和so信息

然后Tinker通过找到基准包data/app/packagename/base.apk通过DexPatch合成新的dex，并且合成一个tinker_classN.apk(其实就是包含了所有合成dex的zip包)接着在运行时通过反射把这个合成dex文件插入到PathClassLoader中的dexElements数组的前面，保证类加载时优先加载补丁dex中的class。

热修复原理

在for循环遍历dexElements中，首先遍历出来的是dex文件，然后再是从dex文件中获取class，所以，我们只要让修复好的class打包成一个dex文件，放于Element数组的第一个元素，这样就能保证获取到的class是最新修复好的class了（当然，有bug的class也是存在的，不过是放在了Element数组的最后一个元素中，所以没有机会被拿到而已）。