1.概述
最近越来越不想写代码了，特别是一些重复性的代码，比如由于每次启动一个 Activity，我们都会很习惯的在 Activity 中写下：
public static void launch(Activity activity) {
Intent intent = new Intent();
intent.setClass(activity, xxxActivity.class);
activity.startActivity();
}
已经有两年Android开发经验的我掐指一算，好像有很多方法可以直接帮咱们生成这样类似的代码：
- 通过 Android Studio 中自定义Activity的Template，这样就可以在生成一个Activity class的时候，会自动帮咱们填充launch方法。大幅提高Android开发效率之Android项目模板化
- 通过 Android Studio 的快捷键方式 Live Templates，来定制 launch 代码块：你不一定知道的Android Studio中强大的快捷代码块
- 可爱的编译时注解。
本文的重点放在了编译时注解的框架实现，毕竟是要和时代接轨的啦！
2.需求剖析
我的需求很简单，就完成通过注解来代替Intent代码来启动 Activity，让注解来帮我们生成 launch 方法，而且还要能够在组件化开发中使用。
需求很明确，所以直接开始构思：
所有的 launch 方法其实很类似，不同的就是跳转的终点 xxxActivity ，那么我们就想办法来构造一个对应的关系：通过配置注解 LaunchAnn 来给每个 Activity 分配一个String别名，我通过找到这个别名，我就知道了这个对应的真实 Activity。这样在需要启动xxxActivity的地方，我通过调用别名来启动这个 xxxActivity 就可以了，这样启动就不会依赖 xxxActivity，而仅仅是一个别名字符串而已。
3.开发流程
创建三个 module：
-
iocAnnotation：java lib，里面只放了编译时注解 -
iocCompiler： 只能是 java lib，不能是 Android lib(生成aar的)，因为我们使用的 AbstractProcessor 在Android环境下是找不到的。 -
iocApi：Android lib，是给用户直接使用的，里面会用到一点点反射。
开发注解框架可以参考：Android 如何编写基于编译时注解的项目。注意的点：
- 为啥要三个 module：由于 iocCompiler 只是在编译的时候才使用的，所以在运行的时候是用不到的，这样我们就可以不用打包到正式apk中，所以在gradle文件中引入方式是：annotationProcessor。
- iocCompiler 对 AbstractProcessor 的注释有两种：1是直接在实现类中通过google提供的注解AutoService完成，2是自己在 resources 下 META-INF/services/javax.anotation.processing.processor中进行声明，如果有多个processor，直接逗号隔开。
定义注解：
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.CLASS)
public @interface LaunchAnn {
String value();
}
注解使用：
@LaunchAnn("RuntimeActivity")
public class RuntimeActivity extends Activity {
}
打开 activity：
public void onClick(View view) {
Launch.launch("RuntimeActivity", this);
}
iocCompiler 中的 CakeProcessor 中(AbstractProcessor实现类)，生成了一个固定的LaunchUtil工具类。通过遍历有哪些类使用了LaunchAnn注解，然后把 LaunchAnn 的 value 值(这里的“RuntimeActivity”)作为 key，类对应的全路径(包名+类名)作为 value 存入到 LaunchUtil 工具类的 map 中，这样我就可以直接通过注解 LaunchAnn 的 value 值可以获取到对应类的全路径。
iocApi 的作用就是提供给用户调用的接口(onClick中的内容调用)，LaunchUtil 中包含了注解对应的map信息，所以关键点就是能够解析LaunchUtil中的内容。
由于 iocApi 和 iocCompiler 没有半毛钱联系，所以怎么能够获取到 LaunchUtil 这个类？这点还是让我花费了一些时间的，最后通过在 iocApi 中定义一个 LaunchInjector 接口，实现通过key值获取Class的getPackageName的接口。当然我们的 LaunchUtil 工具也要实现与LaunchInject这个接口，这样通过反射LaunchUtil的，直接形成了一个 LaunchInjector 的对象，通过 getPackageName 方法就可以获取到需要跳转的 Activity 对应的 Class。
我感觉介绍的差不多了，不懂就自己看代码了。
4.适配组件化方案
其实最开始仅仅是想做一个懒人开发者，这样我就不用每次都写 launch 了，但是开发到最后才发现，前面还有好多要去学习的地方。
由于本身自己在学组件化开发，所以想把写的注解运用到组件化当中去。有4个 module：modulebase、moduleA、moduleB、app。命名中可以看出 modulebase 是基础包，moduleA 和 moduleB 都是功能模块包，最后总包 app module。
由于每个模块都是用了Launch，所以我们可以发现在编译注解的时候，每个 lib 下面都会有一个 LaunchUtil，在合并的时候就会冲突（提示类重复），所以我们需要针对不同的模块，定制不同的类名，我这边是根据模块绑定了，例如：LaunchUtil$$moduleA.java。这样多个 LauncUtil 类就可以共存了。
现在由于有多个 LauncUtil，我们怎么把所有的 LaunchUtil 里面的map信息进行汇总，得到一个总的 map 信息呢？这个东西我想了很久很久，过程中经历了两种实现，其中第一种最后证明不行，最后选择了第二种。为啥还要说第一种呢，因为我感觉还是有必要记录一下的：
- 第一种，为什么不可以对注解生成的 LaunchUtil 再进行加入注解，然后再把所有的 LaunchUtil 在编译时获取其中的map，最后生成一个新的LaunchUtilMerge类呢？我最开始的想法就是这样的，在生成的 LaunchUtil 中也实现了一个注解：MergeLaunch 注解，然后再生成一个 MergeProcessor 来查找 MergeLaunch 对应的 LaunchUtil 类，获取每个类中的 map，得到一个总的 map 放入到 LaunchUtilMerge 中去。
想象这很美好，但在开发过程中发现，由于编译的流程是：先编译 moduleA、moduleB 变成 aar 包，然后 app 依赖 aar 包后再进行编译，而 aar 中的类都是 .class 形式存在的，那么 moduleA.aar 中的 LaunchUtil 在 app module 看来就是一个 LauncUtil.class，即使你有 MergeLaunch 编译时注解，你也不可能找到 moduleA.arr 中的 LaunchUtil，因为他是一个 .class 文件，编译时注解只对 .java 文件有效。在组件化的时候，编译注解是对 java 类而言的，所以在 jar 包、aar 包中存在编译时注解，也是获取不到的。导致的后果就是，LaunchUtilMerge 最后也只找到了app module 中的 LaunchUtil，这样得到的 map 信息明显是不全的。分析到最后，我也是放弃了，很坚决的放弃！ - 第二种，在第一种无解的情况下，手贱把 apk 反编译看了看，其实发现打包后每个模块对应的 LaunchUtil 其实都是在 dex 中的，所以有没有一种方法，通过类名来找对应的 LaunchUtil 呢？为了好处理在生成 LaunchUtil 的时候，我都把他们放在了一个文件夹下面：”seu.com.util“，这样我只要找到这个文件夹下面的所有类就可以了，现在的问题就变成了通过指定的包名来找对应的所有类。
网上搜了搜，还真有在 Android 环境下，通过 DexFile 这个类来查找 dex 中对应的类名对应的全路径：Android中获取指定包名下的所有类，哈哈哈，这样我就找到了所有LaunchUtil对应的全路径名称，最后通过反射找到的所有类，获取每个类中的map，合并成一个汇总的 map，其中包括了所有 LaunchuAnn 注册过的 Activity 对应的类信息，在 iocApi 下的 Launch 类中。这样你就可以通过传入一个字符串的方式来启动 Activit y啦。
5.总结
前面的编译注解对老司机来说其实都是比较简单的，开发流程表比较固定。对于适配组件化开发的过程，其实还是一个比较新鲜的事情。因为看到了阿里的ARouter是适合组件化开发的，所以自己也是有点蠢蠢欲动的赶脚。最后有一个可以让人参考的 demo，希望大家多多交流和学习。对于还有更好的方法来获取所有的 LaunchUtil 的，欢迎交流。
存在的不足：
- 只是查找了一个dex中的所有类，一些apk有好多 dex 文件，那么要确保所有的 LaunchUtil 都被找到，需要查找所有的 dex，这一块是暂时还没有处理的。后续对 class 拆分成多个dex有了研究之后再回来研究这一块。
- 项目还是比较适合个人学习提升的：https://github.com/dndxxiangyu/AndroidLearn
