浅析热修复以及思考
首先得声明的是热修复只能在国内市场使用。
而国外的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数组最前面。
当系统遍历方法的时候会优先使用前面的方法（补丁方法），来替代原来的方法。
[手动滑稽]
参考
参考内容来自大腿们的详细介绍，如有侵权请告知删除
