前言
本文将从另一个角度讲解 AOP，从宏观的实现原理和设计本质入手。大部分讲 AOP 的博文都是一上来就罗列语法，然后敲个应用 demo就完了 。但学习不能知其然，不知其所以然。
对 AOP 我提出了几点思考：AspectJ 为什么会大热？AspectJ 是怎样工作的？和 Spring AOP 有什么区别？什么场景下适用？我们能不能自己实现一个 AOP 方法？
在熟悉原理前，如果想先掌握 AOP 的使用方法可以看：
一、引入
敲一个小 Demo 来引入主题，假设我想不依赖任何 AOP 方法，在特定方法的执行前后加上日志打印。
第一种方式：写死代码
定义一个目标类接口
把 before() 和 after() 方法写死在 execute() 方法体中，非常不优雅，我们改进一下。
第二种方式：静态代理
但是存在一个问题，随着打印日志的需求增多，Proxy 类越来越多，我们能不能保持只有一个代理呢？这时候我们就需要用到 JDK 动态代理了。
第三种方式：动态代理
新建动态代理类
客户端调用
这又引出一个问题，日志打印和业务逻辑耦合在一起，我们希望把前置和后置抽离出来，作为单独的增强类。
第四种方式：动态代理 + 分离增强类
新建增强类接口和实现类
用反射代替写死方法，解耦代理和操作者
客户端调用
但是用了反射性能太差了，而且动态代理用起来也不方便，有没有更好的办法？
我们发现 Demo 存在种种问题
- 静态代理每次都要自己新建个代理类，太繁琐，重用性又差，一个代理不能同时代理多种类；
- 动态代理可以重用，但性能太差；
- 代理类耦合进被代理类的调用阶段，万一我需要改下 before、after 的方法名，可能会点燃一个炸弹；
- 代理拦截了一个类，就会拦截这个类的所有方法，难道我还要在代理类里加个 if-else 判断特定方法过滤拦截？我们可以不可以只拦截特定的方法？
- 如果我既要打印日志，又要计算方法执行用时，每次都要去改增强类吗？
我们的诉求很简单：1. 性能高；2. 松耦合；3. 步骤方便；4. 灵活性高。
那主流的 AOP 框架是怎么解决这个问题的呢？我们赶紧来看看！
二、AOP 方法
不同的 AOP 方法原理略微有些不同，我们先看下 AOP 实现方式有哪些：
| AOP方式 | 机制 | 说明 |
|---|---|---|
| 静态织入 | 静态代理 | 直接修改原类，比如编译期生成代理类的 APT |
| 静态织入 | 自定义类加载器 | 使用类加载器启动自定义的类加载器，并加一个类加载监听器，监听器发现目标类被加载时就织入切入逻辑，以 Javassist 为代表 |
| 动态织入 | 动态代理 | 字节码加载后，为接口动态生成代理类，将切面植入到代理类中，以 JDK Proxy 为代表 |
| 动态织入 | 动态字节码生成 | 字节码加载后，通过字节码技术为一个类创建子类，并在子类中采用方法拦截的技术拦截所有父类方法的调用织入逻辑。属于子类代理，以 CGLIB 为代表 |
所有 AOP 方法本质就是：拦截、代理、反射（动态情况下），实现原理可以看作是代理 / 装饰设计模式的泛化，为什么这么说？我们来详细分析一下。
三、静态织入原理，以 AspectJ 为例
静态织入原理就是静态代理，我们以 AspectJ 为例。
1. AspectJ 设计思路
前面说到 Demo 存在的种种问题，AspectJ 是怎么解决的呢？AspectJ 提供了两套强大的机制：
（1）切面语法 | 解决业务和切面的耦合
AspectJ 中的切面，就解决了这个问题。
@Before("execution(* android.view.View.OnClickListener.onClick(..))")
我们可以通过切面，将增强类与拦截匹配条件（切点）组合在一起，从而生成代理。这把是否要使用切面的决定权利还给了切面，我们在写切面时就可以决定哪些类的哪些方法会被代理，从而逻辑上不需要侵入业务代码。
而普通的代理模式并没有做到切面与业务代码的解耦，虽然将切面的逻辑独立进了代理类，但是决定是否使用切面的权利仍然在业务代码中。这才导致了 Demo 中种种的麻烦。
AspectJ 提供了两套对切面的描述方法：
- 我们常用的基于 java 注解切面描述的方法，写起来十分方便，兼容 Java 语法；
@Aspect
public class AnnoAspect {
@Pointcut("execution(...)")
public void jointPoint() {
}
@Before("jointPoint()")
public void before() {
//...
}
@After("jointPoint()")
public void after() {
//...
}
}
- 基于 aspect 文件的切面描述方法，这种语法不兼容 Java 语法。
public aspect AnnoAspect {
pointcut XX():
execution(...);
before(): XX() {
//...
}
after(): XX() {
//...
}
}
（2）织入工具 | 解决代理手动调用的繁琐
那么切面语法让切面从逻辑上与业务代码解耦，但是我要怎么找到特定的业务代码织入切面呢？
两种解决思路：一种就是提供注册机制，通过额外的配置文件指明哪些类受到切面的影响，不过这还是需要干涉对象创建的过程；另外一种解决思路就是在编译期或类加载期先扫描切面，并将切面代码通过某种形式插入到业务代码中。
那 AspectJ 织入方式有两种：一种是 ajc 编译，可以在编译期将切面织入到业务代码中。另一种就是 aspectjweaver.jar 的 agent 代理，提供了一个 Java agent 用于在类加载期间织入切面。
2. 通过 class 反推 AspectJ 实现机制
（1）@Before 机制
国际惯例写个 Demo
- 自定义 AutoLog 注解
- 编写 LogAspect 切面
- 在切入点中加上注解
反编译后（请点开大图查看）
发现 AspectJ 会把调用切面的方法插入到切入点中，且封装了切入点所在的方法名、所在类、入参名、入参值、返回值等等信息，传递给切面，这样就建立了切面和业务代码的关联。
我们跟进 LogAspect.aspectOf().aroundJoinPoint(localJoinPoint); 一探究竟。
我们发现了什么？其实 Before 和 After 的插入就是在匹配到的 JoinPoint 调用前后插入 Advise 方法，以此来达到拦截目标 JoinPoint 的作用。 如下图所示：
（2）@Around 机制
- 自定义 SingleClick 注解
- 编写 SingleClickAspect 切面
- 业务方加上注解
打开编译后的 class 文件（请点开大图查看）
我们发现和 Before、After 织入不一样了！前者的织入只是在匹配的 JoinPoint 前后插入 Advise 方法，仅仅是插入。而 Around 拆分了业务代码和 Advise 方法，把业务代码迁移到新函数中，通过一个单独的闭包拆分来执行，相当于对目标 JoinPoint 进行了一个代理，所以 Around 情况下我们除了编写切面逻辑，还需要手动调用 joinPoint.proceed() 来调用闭包执行原方法。
我们看下 proceed() 都做了些什么
那这个 arc 是什么？什么时候拿到的呢？
继续回溯
在 AroundClosure 闭包中，会把运行时对象和当前连接点 joinPoint 对象传入，调用 linkClosureAndJoinPoint() 绑定两端，这样在 Around 中就可以通过 ProceedingJoinPoint.proceed() 调用 AroundClosure，进而调用到目标方法了。
那么一图总结 Around 机制：
我们从 AspectJ 编译后的 class 文件可以明显看出执行的逻辑，proceed 方法就是回调执行被代理类中的方法。
所以 AspectJ 做的事情如下：
首先从文件列表里取出所有的文件名，读取文件，进行分析；
扫描含有 aspect 的切面文件；
根据切面中定义规则，拦截匹配的 JoinPoint ；
继续读取切面定义的规则，根据 around 或 before ，采用不同策略织入切面。
（3）@Before @After 机制与 @Around 机制区别
- Before、After 仅仅是织入了 Advise 方法
- Around 使用了代理 + 闭包的方式进行替换
3. AspectJ 底层技术总结
分析完 class 你会发现，AspectJ 实际上就是用一种特定语言编写切面，通过自己的语法编译工具 ajc 编译器来编译，生成一个新的代理类，该代理类增强了业务类。
-
AspectJ 就是一个代码生成工具；
编写一段通用的代码，然后根据 AspectJ 语法定义一套代码生成规则，AspectJ 就会帮你把这段代码插入到对应的位置去。
-
AspectJ 语法就是用来定义代码生成规则的语法。
扩展编译器，引入特定的语法来创建 Advise，从而在编译期间就织入了Advise 的代码。
如果使用过 Java Compiler Compiler (JavaCC)，你会发现两者的代码生成规则的理念惊人相似。JavaCC 允许你在语法定义规则文件中，加入你自己的 Java 代码，用来处理读入的各种语法元素。
四、动态织入原理，以 Spring AOP 为例
动态织入原理就是动态代理。
1. Spring AOP 执行原理
Spring AOP 利用截取的方式，对被代理类进行装饰，以取代原有对象行为的执行，不会生成新类。
2. Spring AOP VS AspectJ
可能有的小伙伴会困惑了，Spring AOP 使用了 AspectJ，怎么是动态代理呢？
那是因为 Spring 只是使用了与 AspectJ 一样的注解，没有使用 AspectJ 的编译器，转向采用动态代理技术的实现原理来构建 Spring AOP 的内部机制（动态织入），这是与 AspectJ（静态织入）最根本的区别。
Spring 底层的动态代理分为两种 JDK 动态代理和 CGLib：
JDK 动态代理用于对接口的代理，动态产生一个实现指定接口的类，注意动态代理有个约束：目标对象一定是要有接口的，没有接口就不能实现动态代理，只能为接口创建动态代理实例，而不能对类创建动态代理。
CGLIB 用于对类的代理，把被代理对象类的 class 文件加载进来，修改其字节码生成一个继承了被代理类的子类。使用 cglib 就是为了弥补动态代理的不足。
3. JDK 动态代理的原理
我们前面的 Demo 第三种方式使用了动态代理，我们不禁有了疑问，动态代理类及其对象实例是如何生成的？调用动态代理对象方法为什么可以调用到目标对象方法？
我们通过 Proxy.newProxyInstance 可以动态生成指定接口的代理类的实例。我们来看下newProxyInstance内部实现机制。
代理对象会实现接口的所有方法，实现的方法交由我们自定义的 handler 来处理。
我们看下 getProxyClass0 方法，只凭一个类加载器、一个接口，是怎么创建代理类的？
注意一下：Android 中动态代理类是直接生成，而 Java 是生成代理类的字节码，再根据字节码生成代理类。
那么客户端就可以 getProxy() 拿到生成的代理类 com.sun.proxy.$Proxy0
这个代理类继承自 Proxy 并实现了我们被代理类的所有接口，在各个接口方法的内部，通过反射调用了 InvocationHandlerImpl 的 invoke 方法。
总结下步骤：
- 获得被代理类的接口信息，生成一个实现了代理接口的动态代理类；
- 通过反射获得代理类的构造函数；
- 利用构造函数生成动态代理类的实例对象，在调用具体方法前调用 invokeHandler 方法来处理。
后记
1. 设计模式不能脱离业务场景
不知不觉我们复习了一下代理模式，设计模式必须依赖大量的业务场景，脱离业务去看设计模式是没有意义的。
因为脱离了应用场景，即使理解了模式的内容和结构，也学不会在合适的时候应用。
2. 敢于追求优雅的代码
首先你要敢于追求优雅的代码，就像我们开头的打印日志的需求，不断提出问题，不断追求更好的解决方案，在新的方案上挖掘新的问题……如果你完全不追求设计，那自然是不会想到去研究设计模式的。
本篇完成耗时 26 个番茄钟（650 分钟）
我是 FeelsChaotic，一个写得了代码 p 得了图，剪得了视频画得了画的程序媛，致力于追求代码优雅、架构设计和 T 型成长。
欢迎关注 FeelsChaotic 的简书和掘金，如果我的文章对你哪怕有一点点帮助，欢迎 ❤️！你的鼓励是我写作的最大动力！
最最重要的，请给出你的建议或意见，有错误请多多指正！
