热修复（本篇主要说一下什么是热修复以及几大主流热修复框架的介绍）
什么是热修复
热修复技术在近年来飞速发展，尤其是在Instant Run方案推出之后，各种热修复技术竞相涌现。国内大部分成熟的主流APP都拥有自己的热修复技术，像手淘、支付宝、QQ、饿了么、美团等等。
对于广大的移动开发者而言，发版更新是最为寻常不过的事了。然而，如果你发现刚发出去的包有紧急的BUG需要修复，那你就必须需要经过下面这样的流程：
这就是传统的更新流程，步骤十分繁琐，用户需要点击进入应用商店，下载完整新版本安装包，花费大量时间等待安装完成，才能重新打开使用修复完BUG的APP。如果有些用户可能会对你失去耐心而直接卸载，你就再也没有更新修复的机会了。
因此，传统流程存在这几大弊端：
· 重新发布版本代价太大
· 用户下载安装成本太高
· BUG修复不及时，用户体验太差
相应的，许多开发者找到了比较合适的解决方案。其中一种方法，就是采用Hybrid方案。也就是需要变更的业务逻辑以H5的方法独立出来。而这种方案，需要传统的java开发者学习前端语言，不仅增加了学习成本，而且，对于无法转为H5形式的代码仍旧是无法修复的。
还会有人会选择插件化方案来解决问题，像Atlas或者DroidPlugin方案。而这类方式，移植成本非常高，且不说先学习整套插件化工具，对原先老代码的修改也不是短时间能够完成的。对于中小型APP而言，明显太过笨重
于是，热修复技术应运而生了。
采用热修复技术，你可以把更新补丁上传到云端，此时APP就可以直接从云端下拉补丁直接生效。因此，更新流程就变成了这样：
可见，热修复开发流程显得更加灵活，它有以下这几个优势：
. 无需重新发版， 实时高效热修复
. 用户无感知修复，无需下载新的应用， 代价小
. 修复成功率高， 把损失降到最低
几种主流的热修复比较
一、Dexposed
项目地址：https://github.com/alibaba/dexposed
Dexposed是一个阿里巴巴手机淘宝基于Xposed进行的改进，产生了针对Android Dalvik 虚拟机运行 时的Java Method Hook 技术－－Dexposed。
这个方案由于对底层Dalvik结构的过于依赖，最终无法兼容Android 5.0以后的ART虚拟机，所以现在也没什么用。
二、Andfix
项目地址：https://github.com/alibaba/AndFix
Andfix 是支付宝提出的一种底层结构替换的方案，也达到了运行时即时生效的效果，并且重要的是，做到了Dalvik和ART环境的全版本兼容。
实现原理：
AndFix的原理就是方法的替换，把有bug的方法替换成补丁文件中的方法。
对于实现方法的替换，需要在Native层操作，经过三个步骤：
优点：
1.BUG修复的即时性
2.补丁包同样采用差量技术，生成的PATCH体积小
3.对应用无侵入，几乎无性能损耗
不足：
1.不支持新增字段，以及修改方法，也不支持对资源的替换。
2.由于厂商的自定义ROM，对少数机型暂不支持。兼容性差。
三、Hotfix
阿里百川Hotfix其实是阿里手机淘宝根据对Andfix的使用，对相关业务解偶后推出的，所以Andfix的缺点它也有。而且阿里已经在此基础上推出了更好的替代方案Sophix。所以这个这个以后基本上用不上了。
四、Sophix
这个是阿里最新的一个解决方案，下面这个是官网。
https://www.aliyun.com/product/hotfix
这个是挂在github上的Demo。
https://github.com/aliyun/alicloud-android-demo/tree/master/hotfix_android_demo?spm=5176.doc53241.2.1.B9j904
阿里推出这个方案的同时出了本关于热修复的书，想要的可以下面留言私聊我。
下面是阿里系的热修复方案的对比。
五、QQ空间超级补丁技术
参考博文：
https://mp.weixin.qq.com/s?__biz=MzI1MTA1MzM2Nw==&mid=400118620&idx=1&sn=b4fdd5055731290eef12ad0d17f39d4a
六、 Tinker
项目官网：http://www.tinkerpatch.com/
Tinker 是开源项目Github的地址：https://github.com/Tencent/tinker
参考：http://www.cnblogs.com/yyangblog/p/6268818.html
微信针对QQ空间超级补丁技术的不足提出了一个提供DEX差量包，整体替换DEX的方案。主要的原理是与QQ空间超级补丁技术基本相同，区别在于不再将patch.dex增加到elements数组中，而是差量的方式给出patch.dex，然后将patch.dex与应用的classes.dex合并，然后整体替换掉旧的DEX，达到修复的目的。
优势：
1.合成整包，不用在构造函数插入代码，防止verify，verify和opt在编译期间就已经完成，不会在运行期间进行。
2.性能提高。兼容性和稳定性比较高。
3.开发者透明，不需要对包进行额外处理。
不足：
1.与超级补丁技术一样，不支持即时生效，必须通过重启应用的方式才能生效。
2.需要给应用开启新的进程才能进行合并，并且很容易因为内存消耗等原因合并失败。
3.合并时占用额外磁盘空间，对于多DEX的应用来说，如果修改了多个DEX文件，就需要下发多个patch.dex与对应的classes.dex进行合并操作时这种情况会更严重，因此合并过程的失败率也会更高。
七、Amigo
库地址：https://github.com/eleme/Amigo
Amigo 是来自饿了么团队的 JackCho 所写
八、Robust
Robust插件对每个产品代码的每个函数都在编译打包阶段自动的插入了一段代码，插入过程对业务开发是完全透明。在Application中通过DexClassLoader，将补丁class文件事先加载，然后之后会调用新的class以替换旧apk中的bug class文件，通过反射进行新代码的调用，以达到热修复目的。
优点：
1、高兼容和适配性，由于是java代码层面的替换调用，基本不涉及各个版本的适配和虚拟机的适配。
缺点：
1、由于对包体中的文件进行了代码侵入，对运行效率、方法数、包体积都有影响，文件方法数变多，企业级应用可能会涉及到65535的问题。
2、项目不够成熟，文档不够健全。
下面从几个热修复最重要的唯独，把Sophix和另外两个主要商业化热修复方案进行比较：
可以看到，Sophix在各个指标上全面占优。而其中唯一不支持的地方就试四大组件的修复，这是因为如果修复四大组件，必须在AndroidManifest里面预先插入代理组件，并且尽可能声明所有权限，而这么做会给原先的App添加很多臃肿的代码，对App运行流程侵入性很强。
目前已知热修复存在的问题
- AndroidManifest出现的BUG是无法修复的，因为它是由系统进行解析的，系统会直接获取安装包里唯一的AndroidManifest文件，在解析过程中不会访问补丁包信息。
- Sophix 如果想要增加四大组件，通常需要预先在安装包的AndroidManifest里边埋入代理的组件，在每次新增组件时，进行偷梁换柱，通过预埋的代理组件实现与系统进程间的通信。否则四大组件是不支持补丁修复的。
- Tinker需要提前配置好才可以新增四大组件。
- Sophix 测试新增音频资源 播放本地新增资源无效 ，官方给的解释是MediaPlayer不会找补丁中资源，换成网络音频地址可以正常替换，亲测可以。