關於Android模組化你需要知道的

最近公司一個專案使用了模組化設計，本人蔘與其中的一個小模組開發，但是整體的設計並不是我架構設計的，開發半年有餘，在此記錄下來我的想法。

模組化場景

為什麼需要模組化？

當一個App使用者量增多，業務量增長以後，就會有很多開發工程師參與同一個專案，人員增加了，原先小團隊的開發方式已經不合適了。

原先的一份程式碼，現在需要多個人來維護，每個人的程式碼質量也不相同，在進行程式碼Review的時候，也是比較困難的，同時也容易會產生程式碼衝突的問題。

同時隨著業務的增多，程式碼變的越來越複雜，每個模組之間的程式碼耦合變得越來越嚴重，解耦問題急需解決，同時編譯時間也會越來越長。

人員增多，每個業務的元件各自實現一套，導致同一個App的UI風格不一樣，技術實現也不一樣，團隊技術無法得到沉澱。

架構演變

在剛剛開始的時候，專案架構使用的是MVP模式，這也是最近幾年很流行的一個架構方式，下面是專案的原始設計。

隨著業務的增多，我們新增了Domain的概念，Domain從Data中獲取資料，Data可能會是Net，File，Cache各種IO等，然後專案架構變成了這樣。

再然後隨著人員增多，各種基礎元件也變的越來越多，業務也很複雜，業務與業務之間還有很強的耦合，就變成了這樣的。

使用模組化技術以後，架構變成了這樣。

技術要點

這裡簡單介紹下Android專案實現模組化需要使用的技術以及技術難點。

Library module

在開始開始進行模組化之前，需要把各個業務單獨抽取成Android Library Module,這個是Android Studio自帶一個功能，可以把依賴較少的，作為基本元件的抽取成一個單獨模組。

如圖所示，我把各個模組單獨分為一個獨立的專案。

在主專案中使用gradle新增程式碼依賴。

Library module開發問題

在把程式碼抽取到各個單獨的Library Module中，會遇到各種問題。最常見的就是R檔案問題，Android開發中，各個資原始檔都是放在res目錄中，在編譯過程中，會生成R.java檔案。R檔案中包含有各個資原始檔對應的id，這個id是靜態常量，但是在Library Module中，這個id不是靜態常量，那麼在開發時候就要避開這樣的問題。

舉個常見的例子，同一個方法處理多個view的點選事件，有時候會使用switch(view.getId())這樣的方式，然後用case R.id.btnLogin這樣進行判斷，這時候就會出現問題，因為id不是經常常量，那麼這種方式就用不了。

同樣開發時候，用的最多的一個第三方庫就是ButterKnife，ButterKnife也是不可以用的，在使用ButterKnife的時候，需要用到註解配置一個id來找到對應view，或者繫結對應的各種事件處理，但是註解中的各個欄位的賦值也是需要靜態常量，那麼就不能夠使用ButterKnife了。

解決方案有下面幾種：

1.重新一個Gradle外掛，生成一個R2.java檔案，這個檔案中各個id都是靜態常量，這樣就可以正常使用了。

2.使用Android系統提供的最原始的方式，直接用findViewById以及setOnClickListener方式。

3.設定專案支援Databinding，然後使用Binding中的物件，但是會增加不少方法數，同時Databinding也會有編譯問題和學習成本，但是這些也是小問題，個人覺的問題不大。

上面是主流的解決方法，個人推薦的使用優先順序為 3 > 2 > 1。

當把個模組分開以後，每個人就可以單獨分組對應的模組就行了，不過會有資源衝突問題，個人建議是對各個模組的資源名字新增字首，比如user模組中的登入介面佈局為activity_login.xml，那麼可以寫成這樣us_activity_login.xml。這樣就可以避免資源衝突問題。同時Gradle也提供的一個欄位resourcePrefix，確保各個資源名字正確，具體用法可以參考官方文件。

依賴管理

當完成了Library module後，程式碼基本上已經很清晰了，跟我們上面的最終架構已經很相似了，有了最基本的骨架，但是還是沒有完成，因為還是多個人操作同一個git倉庫，各個開發小夥伴還是需要對同一個倉庫進行各種fork和pr。

隨著對程式碼的分割，但是主專案app的依賴變多了，如果修改了lib中的程式碼，那麼編譯時間是很恐怖的，大概統計了一下，原先在同一個模組的時候，編譯時間大概需要2-3min，但是分開以後大概需要5-6min，這個是絕對無法忍受的。

上面的第一問題，可以這樣解決，把各個子module分別使用單獨的一個git倉庫，這樣每個人也只需要關注自己需要的git倉庫即可，主倉庫使用git submodule的方式，分別依賴各個子模組。

但是這樣還是無法解決編譯時間過長的問題，我們把各個模組也單獨打包，每次子模組開發完成以後，釋出到maven倉庫中，然後在主專案中使用版本進行依賴。

舉個例子，比如進行某一版本迭代，這個版本叫1.0.0，那麼各個模組的版本也叫同樣的版本，當版本完成測試釋出後，對各個模組打對應版本的tag，然後就很清楚的瞭解各模組的程式碼分佈。

gradle依賴如下。

可能有人會問，既然各個模組已經分開開發，那麼如果進行開發聯調，別急，這個問題暫時保留，後面會對這個問題後面再表。

資料通訊

當一個大專案拆成若干小專案時候，呼叫的姿勢發生了少許改變。我這邊總結了App各個模組之間的資料通訊幾種方式。

頁面跳轉，比如在訂單頁面下單時候，需要判斷使用者是否登入，如果沒有則需要跳到登入介面。
主動獲取資料，比如在下單時候，使用者已經登入，下單需要傳遞使用者的基本資訊。
被動獲得資料，比如在切換使用者的時候，有時候需要更新資料，如訂單頁面，需要把原先使用者的購物車資料給清空。

再來看下App的架構。

第一個問題，原先的方式，直接指定某個頁面的ActivityClass，然後通過intent跳轉即可，但是在新的架構中，由於shopping模組不直接依賴user，那麼則不能使用原始的進行跳轉，我們解決方式使用Router路由跳轉。

第二個問題，原先的方式有個專門的業務單利，比如UserManager，直接可以呼叫即可，同樣由於依賴發生了改變，不能夠進行呼叫。解決方案是所有的需要的操作，定義成介面放在Service中。

第三個問題，原先的方式，可以針對事件變化提供回撥介面，當我需要監聽某個事件時候，設定回撥即可。

頁面路由跳轉

如上分析，原先方式程式碼如下。

但是使用Router後，呼叫方式改變了。

具體的原理是什麼，很簡單的，做一個簡單的對映匹配即可，把"app://user"與UserActivity.class配對，具體的就是定義一個Map，key是對應的Router字元，value是Activity的class。在跳轉時候從map中獲取對應的ActivityClass，然後在使用原始的方式。

可能有人的會問，要向另外一個頁面傳遞引數怎麼辦，沒事我們可以在router後面直接新增引數，如果是一個複雜的物件那麼可以把物件序列化成json字串，然後再從對應的頁面通過反序列化的方式，得到對應的物件。

例如：

注：上面的router中json字串是需要url編碼的，不然會有問題的，這裡只是做個示例。

除了使用Router進行跳轉外，我想了一下，可以參考Retrofit方式，直接定義跳轉Java介面，如果需要傳遞額外引數，則以函式引數的方式定義。

這個Java介面是沒有實現類的，可以使用動態代理方式，然後接下來的方式，和使用Router的方式一樣。

那麼這總兩種方式有什麼優缺點呢。

Router方式:

有點：不需要高難度的技術點，使用方便，直接使用字串定義跳轉，可以好的往後相容
缺點：因為使用的是字串配置，如果字元輸入字元，則很難發現bug，同時也很難知道某個引數對應的含義

仿Retrofit方式:

因為是Java介面定義，所以可以很簡單找到對應的跳轉方法，引數定義也很明確，可以直接寫在介面定義處，方便查閱。
同樣因為是Java介面定義，那麼如果需要擴充套件引數，只能重新定義新方法，這樣會出現多個方法過載，如果在原先介面上修改，對應的原先呼叫方也要做響應的修改，比較麻煩。

上面是兩種實現方式，如果有相應同學要實現模組化，可以根據實際情況做出選擇。

Interface和Implement

如上分析，如果需要從某個業務中獲取資料，我們分別需要定義介面以及實現類，然在獲取的時候在通過反射來例項化物件。

下面是簡單的程式碼示例

介面定義

實現類

反射生成物件

實際呼叫

本示例中每次呼叫都是用反射生成新的物件，實際應用中可能與IoC工具結合使用，比如Dagger2.

EventBus

針對上面的第三個問題，原先設計的使用方式也是可以的，只需要把回撥介面定義到對應的service介面中，然後呼叫方就可以使用。

但是我建議可以使用另外一個方式——EventBus，EventBus也是利用觀察者模式，對事件進行監聽，是設定回撥更優雅方式的實現。

優點：不需要定義很多個回撥介面，只需要定義事件Class，然後通過Claas的唯一性來進行事件匹配。

缺點：需要定義很多額外的類來表示事件，同時也需要關注EventBus的生命週期，在不需要使用事件時候，需要登出事件繫結，不然容易發生記憶體洩漏。

對映匹配

上面的介紹的各個模組之間通訊，都運涉及到對映匹配問題，在此我總結了一下，主要涉及到一下三種方式。

Map register

Map register是這樣的，全域性定義一個Map，各個模組在初始化的時候，分別在初始化的時候註冊對映關係。

下面是簡單的程式碼示例，比如我們定義一個模組生命週期，用於初始化各個模組。

User模組初始化

在Application中完成初始化

APT

使用註解的方式配置對映資訊，然後生成一個類似Database一樣的檔案，然後Database檔案中包含一個Map欄位，Map中記錄各個對映資訊。

首先需要定義個Annotation。

如：

需要實現一個 Annotation Process Tool，來解析自己定義的Annotation。

程式碼略，此程式碼有點複雜，暫時不貼了。

編譯產生的檔案，大概如下所示。

然後利用反射找到Implement_$$_Database這個類，然後從方法中找到配對。

然後在需要配置的地方新增註解即可。

呼叫姿勢。

注意點：

有時候，在生成最終的配置檔案的時候，檔案的名字是固定的，比如上面的Implement_$$Database,最終的路徑是這樣的cn.mycommons.implements.database.Implement$$_Database.java，然後通過編譯到apk中或則是aar中。

但是有個問題，如果各個子模組都使用了這樣的外掛，那麼每個子模組的就會有這個Implement_$$_Database.class，那麼就會編譯出錯。

因為aar中包含的時候class檔案，不是java檔案，不能在使用APT做處理了。下面有2中解決方案。

子工程的外掛生成的檔案包含一定的規則，比如包含模組名字，如User_Implement_$$_Database.java，同時修改編譯過程，把java檔案也打包到aar中，主工程的外掛在編譯時候，提取aar中的檔案，然後合併子工程的所有的程式碼，這個思路是可行的，不過技術實現起來比較麻煩。
同一的方式類似，也是生成有一定規則的的檔案，或者在特地package下生成class，這些class再通過接下來的所講的Gradle Transform方式，生成一個新的Database.class檔案。

Gradle Transform

這是Android Gradle編譯提供的一個介面，可以供開發自定義一些功能，而我們就可以根據這個功能生成對映匹配，這種方式和APT類似，APT是執行在程式碼編譯時期，而且Transform是直接掃描class，然後再生成新的class，class中包含Map對映資訊。修改class檔案，使用的是javassist一個第三方庫。

下面簡單講述程式碼實現，後面有機會單獨寫一篇文章講解。

首先定義一個註解，這個註解用於標註一個實現類的介面。

一個測試用的介面以及實現類。

定義一個靜態方法，用於獲取某個介面的實現類。

如果不使用任何黑科技，直接使用Java技術，那麼在定義時候需要主動的往CONFIG這個map中新增配置，但是這裡我們利用transform，直接動態的新增。

定義一個ImplementsPlugin gradle外掛。

自定義的Transform實現。

程式碼省略。。地址為https://github.com/LiushuiXiaoxia/AndroidModular/tree/master/ImplementsTransformPlugin

對映匹配總結

優點:

Map:簡單明瞭，很容易入手，不會對編譯時間產生任何影響，不會隨著Gradle版本的升級而受影響，程式碼混淆時候不會有影響，無需配置混淆檔案。
APT：使用簡單，使用註解配置，程式碼優雅，原理是用程式碼生成的方式生成新的檔案。
Transform：使用簡單，使用註解配置，程式碼優雅，原理是用程式碼生成的方式生成新的檔案，不過生成的檔案的時期和APT不同，會編譯時間產生少許影響。

缺點:

Map：在需要新新增對映的時候，需要手動新增，不然不會生效，程式碼不優雅。
APT：在編譯時期生成檔案，會編譯時間產生少許影響，同時在不同的Gradle的版本中可能會產生錯誤或者相容問題。需要配置混淆設定，不然會丟失檔案。技術實現複雜，較難維護。
Transform：在編譯時期生成檔案，會編譯時間產生少許影響，同時在不同的Gradle的版本中可能會產生錯誤或者相容問題。需要配置混淆設定，不然會丟失檔案。技術實現複雜，較難維護。

從技術複雜性以及維護性來看，Map > APT = Transform

從使用複雜性以及程式碼優雅性來看，Transform > APT > Map

開發除錯技巧

Debug

上面介紹了很多關於模組化的概念以及技術難題，當模組化完成以後，再進行完成開發時候還是會遇到不少問題。不如原先程式碼在一起的時候很方便的進行程式碼除錯。但是進行模組化以後，直接使用的是aar依賴，不能直接修改程式碼，可以使用下面技巧，可以直接進行程式碼除錯。

在根目錄下面建立一個module目錄以及module.gradle檔案，這個目錄和檔案是git ignore的，然後把對應的模組程式碼clone到裡面，根目錄的setting.gradlew apply module.gradle檔案，如下所示，如果需要原始碼除錯，則在module中新增對應的模組。然後在app的依賴中去掉aar依賴，同時新增專案依賴即可。當不需要原始碼除錯好，再修改為到原先程式碼即可。

module.gradle

比如除錯shopping模組

當然還有個更具技術挑戰性方案，使用gradle外掛的形式，如果發現root專案中包含的模組化的原始碼，則不適用aar依賴，直接使用原始碼依賴，當然這個想法是不錯的，不過具有技術挑戰性，同時有可能隨著Gradle版本的升級，編寫的gradle外掛也要做相對於的相容風險，這是隻是簡單提示一下。

容器設計

上面講到的如果要除錯程式碼時候，需要完整的執行的整個專案，隨著專案的增大，編譯時間可能變得很長。

我們可以做一個簡單的，類似與主app模組一樣，比如我是負責user模組的開發者，那麼我只要除錯我這個模組就行了，如果需要其他的模組，我可以簡單的做一個mock，不是把其他的模組直接依賴過來，這樣可以做到除錯作用。等到再需要完整專案除錯時候，我們在使用上面介紹的方式，這樣可以節省不少開發時間。

還有一種實現除錯的方式，比如上面的user模組，目錄下面的build.gradle檔案是這樣的

我們可以在gradle.properties中設定編譯變引數isLibModule，當需要完整除錯好，設定為isLibModule=false，這樣我這個子模組就是一個apply plugin: 'com.android.application'這樣的模組，是可以單獨執行的一個專案

可能有時候還是需要單獨的執行環境，android編譯方式有2中，一種是debug，一種是release。當打包成aar的時候，使用的是release方式，我們可以把需要除錯的程式碼全部放到debug中，這樣打包的時候就不會把除錯的檔案釋出到aar中。不過這種實現方式，需要對Android專案的目錄有較高的認識，才可以熟練使用。

CI

上面介紹的各個模組需要單獨到獨立的git倉庫，同時打包到單獨的maven倉庫，當開發完成後，這時候就需要進行打包，但這個是一個簡單和重複的事情，所以我們需要一個工具來完成這些事情，我們可以利用CI系統來搞定這件事情，這裡我推薦Jenkins，主流廠商使用jenkins作為CI伺服器這個方案。

具體的步驟就是，需要對每個模組的git倉庫做web hook，我們公司使用的是git lab，可以對git的各種操作做hook，比如push，merge，tag等。

當程式碼傳送了變化了，我們可以傳送事件到CI伺服器，CI伺服器再對各個事件做處理，比如user模組develop分支有程式碼變化，這個變化可能是merge，也有可能是push。我們可以把主專案程式碼和user專案的程式碼單獨clone下拉，然後編譯一下，確認是否有編譯問題，如果有編譯通過，那麼在使用相關gradle命令釋出到maven倉庫中。

不管每次編譯結果怎樣，是成功還是失敗，我們都應該把結果回饋給開發者，常見的方式是郵件，不過這個資訊郵件方式可能很頻繁，我們建議使用slack。

總結

模組化架構主要思路就是分而治之，把依賴整理清楚，減少程式碼冗餘和耦合，在把程式碼抽取到各自的模組後，瞭解各個模組的通訊方式，以及可能發生的問題，規避問題或者解決問題。最後為了開發和除錯方便，開發一些周邊工具，幫助開發更好的完成任務。

作者：流水不腐小夏

地址：http://www.jianshu.com/p/910911172243