浅析热修复以及思考

首先得声明的是热修复只能在国内市场使用。

而国外的Google Play不允许任何APP有更改，被举报就准备好下架整改了。

An app downloaded from Google Play may not modify, replace, or updateitself 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.原理

总的来说，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流量的上游。

反正上面都是我猜的

至于一些缺点，比如技术实现啊什么的，反正还有苦逼的程序员来实现。

[手动滑稽]

参考

参考内容来自大腿们的详细介绍，如有侵权请告知删除

1. QQ空间热修复实现

2. AndFix原理

3. 干货干货