首先得聲明的是熱修復只能在國內市場使用。
而國外的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的限制。
插件化開發(fā)也是基于這種理念誕生的。
不同的dex由不同部門開發(fā)，然后由統(tǒng)一的apk進行加載。
這樣并行開發(fā)，互不干擾的模式，大大提高了開發(fā)效率，實現了APK模塊化區(qū)分。
而最近的Tinker，原理本質上是一樣的，但是基于這些采取了很多優(yōu)化，更加穩(wěn)定。
2.原理
基于android的dexClassLoader機制，將需要替換的dex放在dexElements數組最前面。
當系統(tǒng)遍歷方法的時候會優(yōu)先使用前面的方法（補丁方法），來替代原來的方法。
大概意思和插隊差不多，把最新的好的放在最前面，老舊的錯誤的將它淘汰。
如需詳細的解析介紹請移步參考中的[QQ空間熱修復實現]查看詳細實現原理。
后話
其實從熱修復里面可以看到一點：線上有bug更新一次是在是太麻煩了，不停打包和分發(fā)，實在是太繁瑣。熱修復這種折中的方式應運而生。
換句話來說，現在APP太重了。
每次迭代都要去用戶去應用市場下載，這對于用戶來說是個麻煩事，所以APP輕量化是一個以后發(fā)展的方向。
輕量化一個方向就是將APP功能拆分，模塊化開發(fā)。近似生活中，手機零件由不同工廠生產，然后再由一個工廠統(tǒng)一組裝，這樣大大提高了生產效率。
我認為模塊化必定是以后的發(fā)展方向，從google新的Android Instant Apps就可以看出來。今后可以通過Deep Link的方式，從一段url中可以鏈接到一個應用的某個模塊，迎來輕量化革命。
現在開發(fā)模式采用Native+Web混合模式歸根結底也是為了減輕APP重量，滿足快速迭代的要求。
Android Instant APP和Progressive Web App也是Google推出模糊Native和Web的界限，找到一個既有Native良好體驗，也有Web APP快速迭代的方案。
而且從筆者翻譯的【譯】Android 7.0 for Developers
里面的第16點來說，Google目前在持續(xù)性的迭代Chrome以及WebView，我猜測這些新的功能和Chrome的聯系將會非常密切，甚至可能會將Chrome抬到和Google Play相同的地位來成為Web端的控制者。這樣不但會提高chrome的市場份額，也變相壟斷了整個APP和Web。
這樣有幾點好處：
- 加強開發(fā)效率，模糊化Native和Web會給開發(fā)人員帶來便利。
- 方便用戶，提高整個Android端的用戶體驗。
- 壟斷市場，制定規(guī)則，站在整個Android流量的上游。
反正上面都是我猜的
至于一些缺點，比如技術實現啊什么的，反正還有苦逼的程序員來實現。
[手動滑稽]
參考
參考內容來自大腿們的詳細介紹，如有侵權請告知刪除
