Android適合組件化開發的路由架構：Launch

標籤：有一個   路由   merge   tac   為我   android開發   pil   cto   oca   

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中強大的快捷代碼塊
• 可愛的編譯時間註解。

本文的重點放在了編譯時間註解的架構實現，畢竟是要和時代接軌的啦！

百牛資訊技術bainiu.ltd整理髮佈於部落格園

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

五香魚cc
連結：http://www.jianshu.com/p/af2b83af02e1
來源：簡書
著作權歸作者所有。商業轉載請聯絡作者獲得授權，非商業轉載請註明出處。

Android適合組件化開發的路由架構：Launch