首先得声明的是热修复只能在国内市场使用。
而国外的Google Play不允许任何APP有更改，被举报就准备好下架整改了。
An app downloaded from Google Play may not modify, replace, or update
itself using any method other than Google Play's update mechanism.
所以老老实实在国内用就好了。
市面上出现了许多热修复，从最早的Dexposed到后来的AndFix，到现在的Tinker各有千秋。
不过大概的分两种，一种是基于Dexposed和AndFix的Native流和基于Tinker的Dex流。
以下采取图片为主的方式介绍，更多详细原理以及代码实现请移步参考。
Native流派
1.简介
使用Nativie流主要有阿里的DexPosed和AndFix。主要是通过解析补丁中的方法，
将需要打补丁的地方在Native层使用C++中指针替换来达到修复bug的目的。
下面以AndFix作为例子简单介绍原理
2.流程
3.原理
<img src="http://upload-images.jianshu.io/upload_images/2241150-0d92931d7c0d3080?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240">
总的来说，Native流派是先获取补丁文件中的信息，通过信息进入Native层Hook需要修复Bug的方法，
然后将补丁中的内容打到需要替换的位置。通过这样的方式来实现热修复。
详细介绍以及代码分析请移步到参考[AndFix原理]
Dex流
1.简介
Dex流的原理其实和解决64k方法限制方法类似，主要还是在dex加载上面做文章。
分包的时候将不同方法分配到不同的dex中，这样解决了单个dex方法不能超过64k的限制。
插件化开发也是基于这种理念诞生的。
不同的dex由不同部门开发，然后由统一的apk进行加载。
这样并行开发，互不干扰的模式，大大提高了开发效率，实现了APK模块化区分。
而最近的Tinker，原理本质上是一样的，但是基于这些采取了很多优化，更加稳定。
2.原理
基于android的dexClassLoader机制，将需要替换的dex放在dexElements数组最前面。
当系统遍历方法的时候会优先使用前面的方法（补丁方法），来替代原来的方法。
大概意思和插队差不多，把最新的好的放在最前面，老旧的错误的将它淘汰。
如需详细的解析介绍请移步参考中的[QQ空间热修复实现]查看详细实现原理。
后话
其实从热修复里面可以看到一点：线上有bug更新一次是在是太麻烦了，不停打包和分发，实在是太繁琐。热修复这种折中的方式应运而生。
换句话来说，现在APP太重了。
每次迭代都要去用户去应用市场下载，这对于用户来说是个麻烦事，所以APP轻量化是一个以后发展的方向。
轻量化一个方向就是将APP功能拆分，模块化开发。近似生活中，手机零件由不同工厂生产，然后再由一个工厂统一组装，这样大大提高了生产效率。
我认为模块化必定是以后的发展方向，从google新的Android Instant Apps就可以看出来。今后可以通过Deep Link的方式，从一段url中可以链接到一个应用的某个模块，迎来轻量化革命。
现在开发模式采用Native+Web混合模式归根结底也是为了减轻APP重量，满足快速迭代的要求。
Android Instant APP和Progressive Web App也是Google推出模糊Native和Web的界限，找到一个既有Native良好体验，也有Web APP快速迭代的方案。
而且从笔者翻译的【译】Android 7.0 for Developers
里面的第16点来说，Google目前在持续性的迭代Chrome以及WebView，我猜测这些新的功能和Chrome的联系将会非常密切，甚至可能会将Chrome抬到和Google Play相同的地位来成为Web端的控制者。这样不但会提高chrome的市场份额，也变相垄断了整个APP和Web。
这样有几点好处：
- 加强开发效率，模糊化Native和Web会给开发人员带来便利。
- 方便用户，提高整个Android端的用户体验。
- 垄断市场，制定规则，站在整个Android流量的上游。
反正上面都是我猜的
至于一些缺点，比如技术实现啊什么的，反正还有苦逼的程序员来实现。
[手动滑稽]
参考
参考内容来自大腿们的详细介绍，如有侵权请告知删除
