Android 热补丁和热修复

参考：

各大热补丁方案分析和比较

1. Xposed

Github地址：https://github.com/rovo89/Xposed

项目描述：Xposed框架使用起来很确实很好用。可是就是有一个巨大的缺点，就是需要Root权限。

2. Dexposed

Github地址：https://github.com/alibaba/dexposed

阿里巴巴（淘宝团队），基于ROOT社区著名开源项目Xposed改造剥离了ROOT部分，实现的一个Android平台上功能强大的无侵入式运行时AOP框架。（基于Xposed改造剥离了ROOT部分）

支持从Android2.3到4.4（除了3.0）的所有dalvid运行时arm架构的设备，暂不支持5.0系统，可以针对5.0以上版本进行修复。

3. AndFix

Github地址：https://github.com/alibaba/AndFix

项目描述：阿里巴巴（支付宝团队）开源的 Android 应用热修复工具，帮助 Anroid 开发者修复应用的线上问题。

AndFix 支持 Android 2.3 - 6.0，ARM 和 x86 架构，完美支持dalvik 运行时和 art 运行时。AndFix 的分支是 .apatch 文件。

4. AndroidPatchUpdate

Github地址：https://github.com/JackCho/AndroidPatchUpdate

项目描述：类似Google I/O 上提及的 Smart App update，应用增量更新机制，利用了Linux上的Patch打补丁的方法，将旧项目和新项目进行差别对比(使用bsdiff或者Courgette工具)生成patch文件，然后使用bspatch将旧项目与Patch进行合并

5. HotFix

Github地址：https://github.com/dodola/HotFix

项目描述：该项目是基于QQ空间终端开发团队的技术文章：安卓App热补丁动态修复技术介绍实现的一个动态打补丁的框架。

该框架完成了作者所描述的基本功能。

项目部分代码从 dalvik_patch 项目中修改而来，这个项目本来是用来实现multidex加载的，修改后可以用来实现热补丁的效果。

6. ClassLoader

Github地址：

项目描述：腾讯空间Android工程师，陈钟发明的热补丁方案，是他在看源码的时候偶然发现的切入点。

我们知道，multidex方案的实现，其实就是把多个dex放进app的classloader之中，从而使得所有dex的类都能被找到。

而实际上findClass的过程中，如果出现了重复的类，参照下面的类加载的实现，是会使用第一个找到的类的。

该热补丁方案就是从这一点出发，只要把有问题的类修复后，放到一个单独的dex，通过反射插入到dexElements数组的最前面，不就可以让虚拟机加载到打完补丁的class了吗。

说到此处，似乎已经是一个完整的方案了。

但在实践中，会发现运行加载类的时候报preverified错。

原来在DexPrepare.cpp，将dex转化成odex的过程中，会在DexVerify.cpp进行校验，验证如果直接引用到的类和clazz是否在同一个dex，如果是，则会打上CLASS_ISPREVERIFIED标志。

通过在所有类（Application除外，当时还没加载自定义类的代码）的构造函数插入一个对在单独的dex的类的引用，就可以解决这个问题。空间使用了javaassist进行编译时字节码插入。

注意：ClassLoader方案支持2.3-6.0，会对启动速度略微有影响，只能在下一次应用启动时生效，在空间中已经有了较长时间的线上应用，如果可以接受在下次启动才应用补丁，是很好的选择。

6. 基于Proxy/Delegate 实现bug热修复

地址：Android 基于Proxy/Delegate 实现bug热修复