dim.red

开头

java上的AOP 框架比较出名的是AspectJ，比较可惜的是这个框架是在gradle上需要一些变换才能使用。

在使用这个框架之前,我们来看AspectJ 命令的几个比较重要的参数：
-classpath：class和source 的位置
-aspectpath： 定义了切面规则的class
-d：指定输出的目录
-outjar：指定输出的jar上
-inpath：需要处理的.class
classpath 的作用是在当解析一个类的时候，当这个类是不在inpath 中，会从classpath 中寻找。
在使用AspectJ的时候, 我们用以下几个方面来优化我们的速度。

一 多线程:

首先我们通过android plugin的Transform api ，收集所有的class文件。
然后用AspectJ处理所有的class.输出到对应的目录下。
这里我们为了保证transform灵活性，我们不将所有的class 合并成一个jar，而是每个输入对应一个输出。同时使用多线程来为这个过程加速。
在后续的使用我们发现单纯的直接用多线程来处理这个问题，会引发一个异常，异常如下：

通过分析可以发现问题是出现在CompilerAdapter 类下，具体是因为CompilerAdapter 会被注入到相关类中。而注入的是同一个实例，在多线程下操作中，一并发就会导致一些bug， 我们重新编写CompilerAdapter 类。在对应的field上用ThreadLocal 包裹，使在参数实例在多线程下隔离，这样就简单的解决问题。

这里有个比较有意思的点是：AspectJ AOP 框架对自身的代码进行了AOP编程。

二 指定精确的aspectpath

为了加速aspectJ的处理过程， 我们会将aspectpath对应的class 找出来，然后在AspectJ处理的时候将参数指向给aspectpath。 我们通过用ASM 框架解析类，查找所有被Lorg/aspectj/lang/annotation/Aspect 注释的类，收集到一个单独的文件夹中。这样可以为AspectJ处理提升速度。
同时为了加快查找aspectpath 的文件。
我们支持了对Android library 和Java Library 的aspectpath 文件进行标注。在主项目中查找aspectpath 文件的时候，可以根据这个标注更快的收集.

• Android Library 我们定义2个Transform ，一个针对Class，收集和分析class，一个针对资源，将上个Transform收集的结果写入Java Resource 中的NOTICE文件。
• Java Library 则是在jar task 后面分析生成的jar文件.同样把结果写入Java Resource 的 NOTICE文件。

这里之所以使用NOTICE ，而不使用别的，一是为了兼容Android Plugin 版本的变迁。二是因为 Android Plugin 的Java Resource 的合并是会忽略掉几个特定的文件，而NOTICE就在这几个特定文件中。
2.0 Android Plugin 忽略的文件：

2.3 Android Plugin 忽略的文件：

使用NOTICE 好处就是，你用插件处理的jar 包或者aar 在应用到不相干的项目中，在生成的APK不会多余令人困户的配置文件存在。

三 支持增量：

我们几乎所有的Transform 都支持了增量编译，意思是AspectJ 并不会每次都处理所有的class， 他只会处理有变更的class 文件。 除非是你的aspectpath文件出现了变更，即AOP规则变更了, 之前的处理结果已经不可靠了，就会触发一次全量的处理。
为了支持这个特性，我们必须手动的为AspectJ 新增一个参数 -infiles。为了这个特性我们必须去修改aspectJ 的源码。修改以下3个类 org.aspectj.ajdt.internal.core.builder.AjBuildManager和org.aspectj.ajdt.internal.core.builder.AjBuildConfig 和org.aspectj.ajdt.ajc.BuildArgParser， 这个特性在持续开发中对于节省时间特别有效。

因为在一些需求我们需要修改AspectJ的代码，因为AspectJ 的源码编译比较麻烦。我们这里使用修改后的java编译出的class 文件，然后直接覆盖AspectJ jar包中对应的文件上。

结尾:

我们将所有的代码放置在github 上 AspectJAOP。