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