前言
Andfix 算是热修复方案中，native流派的典范了。在讲解Andfix之前，我们首先了解一下Dexposed，Andfix 是在Dexposed的基础上演进的。
Dexposed介绍
阿里手淘团队基于 Xposed 研发出来的 AOP 框架，方法级粒度，可以进行 AOP 编程、插桩、热补丁、SDK hook 等功能。它的热补丁方案原理图大致如下：：
从上图中我们可以看出，它的主要原理是将 Java method 改变为 native, 并且将这个方法的实现链接到一个通用的 Native Dispatch 方法（即一个公共分发函数上）来修改方法加载逻辑以实现热补丁功能。
和 Xposed 不同的是，Xposed 通过劫持 zygote（须 root ），而 Dexposed 则是通过劫持 Java method (而非劫持 class loader）。我们可以用它来热替换某个导致崩溃的方法，此外手淘还用它作性能监控。这主要得益于无侵入式的方法调用 Befor 和 After 事件，能够让我们很好的记录和分析一个方法的调用时间。开源项目 promeG/XLog 就是基于 dexposed 实现的方法调用 logging。
但是它有个硬伤：不支持 art 平台。因此在Android L推出后，2015年起它就逐渐淡出了广大开发者的视线了。而 Andfix，则是在此基础上，进行了扩展和完善来替代它实现热修复功能。
AOP介绍
AOP（Aspect Oriented Programming），也就是面向方面编程，是通过预编译方式和运行期动态代理实现程序功能的统一维护的一种技术。利用 AOP 可以对业务逻辑的各个部分进行隔离，从而使得业务逻辑各部分之间的耦合度降低，提高程序的可重用性，同时提高了开发的效率。
AOP一般应用在日志记录，性能统计，安全控制，事务处理，异常处理等方面，它的主要意图是将日志记录，性能统计，安全控制，事务处理，异常处理等代码从业务逻辑代码中划分出来，通过对这些行为的分离，我们希望可以将它们独立到非业务逻辑的方法中，进而改变这些行为的时候不影响业务逻辑的代码。
Dexposed 示例
我们可以利用 Dexposed 在应用中所有的 Activity.onCreate(Bundle) 函数调用之前和之后增加一些处理：
详情细节就不过多阐述了，有兴趣的同学可以自行阅读dexposed的开源项目源码，GitHub地址是：https://github.com/alibaba/dexposed
下一篇是 Andfix 方案原理分析篇，后续整理好会发出来。