從2017年只有幾個大廠在做組件化，到今天已經繁花似錦。

越來越多的團隊，越來越多的項目都做了組件化。

大叔相信即使你沒有做過組件化項目，但是，對組件化也早就聽爛了。

但是，組件化開發多少有些技術門檻。

有很多大神寫過相關文章，通俗易懂的不多。深入淺出的更不多。

不才，願意冒着不要臉的風險一試，通俗易懂、深深淺淺的來聊聊組件化開發，如果對你有一點點啟發，請記得回來給大叔點個贊。

一、單工程開發 -> 多module分層開發

這種分層架構，有什麼用呢？

分解成多module的項目結構，就是組件化開發了嗎？

當然不是，多module分層的項目結構，只是組件化開發的一部分。只是組件化開發的基礎。

大叔，搜索了很多資料，發現，對於組件化開發，並沒有很嚴格的定義。

當然，我們沒有必要，過於糾結 」組件化開發的定義「；

我們更關注這種開發思想對項目帶來的好處以及在團隊中如何運用。

二、組件化的思想&優勢

下面是我的理解，如有出入，歡迎提出來一起討論。

1、將一個大型項目分解成多個module，拆解的過程就是一個化繁為簡的過程。

尤其在大團隊，大項目上，組件化的優勢會更加凸顯。

大項目分解成一個個小型項目，相當於將一個複雜的問題拆解成一個個相對簡單的問題。

每個成員，可以專註在自己相關業務的module上。

2、分層的module結構，同一層的module間存在代碼隔離，這種隔離是編譯上的隔離。

同層的代碼不能相互調用。底層的代碼也不能調用上層。

這種編譯隔離，帶來了，模塊間的高度解耦。

讓模塊的依賴關係清晰。

3、更高的可重用性

（如果構建正確）組件化設計的系統，比傳統的整體設計具有更高的可重用性。

什麼是組件？什麼是模塊？

組件強調復用，模塊強調職責劃分。 他們沒有非常嚴格的劃分。

達到可復用要求的模塊，那麼這個模塊就是組件。

base層的module必須是可復用的，如果項目設計的好，business層都能被複用，每個module都能成為組件。

可重用性是組件化思想的核心。

如此架構，是否也適合技術中台的架構？

4、每個組件都具有可替代性（如果構建正確）

如果我們要為某個已經存在的組件，重新開發一個新組件，將變得非常可行。

組件內的重構也將變得非常可行。

新的組件的設計只要保證對外提供的接口，完全符合，舊組件對外提供的接口

5、組件的熱插拔，成為可能（如果構建正確）

我們想像下，在APP運行時，business中的組件可以動態加載，也可動態卸載。

那麼我們可以輕鬆實現組件的懶加載：用戶用到的組件，那麼就加載進來。用完之後便可以卸載。

6、組件的獨立編譯、測試，成為可能（如果構建正確）

大的android工程項目，build一次要到5分鐘左右，太浪費時間了。

拆成多個組件之後，如果每個組件都能單獨build，單獨測試，那麼將大大提升開發效率。

上面討論的這些優勢，並不是將簡單將 單工程 拆分成 分層的多module工程結構 就能獲得這些優勢。

想要獲得這些優勢，還任重道遠，我們還需要解決很多問題，才能讓我們的項目具備上面的說的優勢。

二、組件化後，將面臨哪些問題？如何解決？

1、module之間如何優雅的通信

通過ARouter通信。

ARouter是阿里開源的一個項目。github.com/alibaba/ARo…

通過ARouter跨module跳轉Activity

@Route(path = "/test/activity")//申明路由
public class YourActivity extend Activity {
    ...
}

//通過路由啟動Activity
ARouter.getInstance().build("/test/activity").withLong("key1", 666L).navigation();
複製代碼

通過ARouter在module間共享對象，實現module間通信。

比如：我們有一個賬號模塊 business:account ,提供了登錄、登出、用戶信息查詢等業務。

同級的其他模塊，如何跟賬號模塊通信？獲取用戶的登錄狀態以及用戶相關信息？

public class AccountBean {
    private String name;
    private int age;
    //....
}

public interface IAccountService extends IProvider {
    void login(Context context);//登錄
    void logout(Context context);//登出
    AccountBean getAccountBean();//獲取賬號信息
}
複製代碼

對外的數據結構和接口定義。

@Route(path = BusinessRoutePath.ModuleAccount.ACCOUNT)
public class AccountServiceImpl implements IAccountService {
    //.....
}
複製代碼

bussiness:account模塊中的實現。

IAccountService accountService = ARouter.getInstance().navigation(IAccountService.class);
accountService.login(activity);
AccountBean bean = accountService.getAccountBean();    
複製代碼

但是問題來了：

同層的其他模塊，如何，能拿到ARouter的path？

同層的其他模塊編譯時，如何，共享AccountBean類、IAccountService接口？

這就是模塊之間的編譯隔離，帶來的問題。

我們很自然的想到了framework模塊，或者base層的其他模塊。

我們只要將這些path定義、AccountBean類、IAccountService接口，下沉到base層,就可以實現編譯上的代碼共享。

如此一來，就帶來了，另一個問題：代碼的中心化問題。

2、代碼的中心化

簡單的path字符串定義，放在framework倒是還好。

如果所有business模塊對外提供的接口和數據結構，都定義到framework的話，問題就有點嚴峻。

將會破壞：組件的 可替代性、可重用性、組件間耦合度

因為framework是基礎模塊嘛，所有business模塊都依賴的模塊，如此，不管你的business1模塊是否依賴business2模塊的對外接口，都會存在這一層依賴。

模塊間的代碼邊界出現一些劣化。缺少了編譯上的隔離。許多模塊將會變得不夠「獨立」了。

可替代性、可重用性 越來越弱，想要替換或者復用某個business組件將變得越來越難。

將會導致，我們很難知道，哪些business對哪些business 接口有依賴。

同時，framework模塊隨着功能迭代，會不斷膨脹。

這就是，中心化的問題。

於是我們很自然的想到了一個解決方案：

實現了另一種接口暴露的形式——「.api化」。

將 business模塊 對外提供的接口單獨抽到 business-api 模塊中。其他依賴他的模塊只需要依賴他的business-api即可。

這個方案如何實踐下去呢？

微信的api化方案

微信團隊出了一個很巧妙的方案，這個方案對android的組件化開發，產生了非常深遠的影響。

後面很多做組件化開發的團隊，在解決中心化問題基本都會用到類似的方案。

以下為，微信官方博客的原文引用：

使用方式和思路都很簡單。對於java文件，將工程里想要暴露出去的接口類後綴名從「.java」改成「.api」，就可以了。

而且並不只是java文件，其他文件如果也想暴露，在文件名後增加”.api」，也一樣可以。

當然，要讓工程支持這樣的方式，gradle文件肯定會有一點改變。

它的實現原理也相當簡單：自動生成一個「SDK」工程，拷貝.api後綴文件到工程中就行了，後面其他工程依賴編譯的只是這個生成的工程。簡單好用。

api方案有點類似於android的AIDL的思路。

微信API方案的變種

gradle 根據src/api文件來，自動生成{moduleName}-api模塊。
如果，src/api文件不存在，將不會自動生成 {moduleName}-api 模塊。
複製代碼

通過API模塊來解決代碼中心化問題帶來的好處：

1. 讓各個business的之間的依賴明確
2. 讓business對外提供的接口明確。

從而加強了模塊的：可替代性。

只要兩個business對外提供的API一致，就可以相互替換。

3、單獨編譯、測試 business的單個模塊

模塊變多了，項目變大了，整個項目的編譯速度變慢了。

業內有兩種常用做法。

• 方案一：動態配置 build.gradle。只要讓單個的組建能編譯成APP就能單獨測試。
• 方案二：多殼APP方案來自，在聚美優品。這裡需要注意：假如，Demo1是business1的殼APP。那麼Demo1還需要依賴哪些businessXXX呢？剛好，前面做的api化，能排上用場。business1依賴的businessXXX-api模塊對應的businessXXX模塊，Demo1也需要依賴。為甚？因為，business1依賴的businessXXX-api模塊，意味着，business1需要依賴
  businessXXX提供的功能，比如要跳轉到businessXXX的activity？或者，要獲取businessXXX的對象。

4、模塊變多了，gradle代碼同比增長，gradle 代碼復用

• 版本號統一管理，依賴的統一管理方案一：Extra

  propertiesdeveloper.android.com/studio/buil…docs.gradle.org/current/use…在項目跟目錄的build.gradle文件中配置Extra屬性如此可以實現統一管理版本號，和依賴。但是，但是，但是，這個方案存在明顯的缺陷。不支持，自動補全不支持Find
  Usages，查找所有應用的地方使用時，不支持點擊跳轉嚴重影響開發體驗。方案二：buildSrc支持，自動補全支持，Find
  Usages支持，點擊跳轉更完美的語法高亮gradle文件復用版本和依賴做到了統一管理，但是每個module都有各自的build.gradle，重複的build.gradle代碼依然沒有復用。我們可以通過apply

  from:”xxx.gradle”的方式來複用gradle代碼。如下圖如上，我們可以在base.gradle中為每一個項目添加配置統一的編譯邏輯，如：kotlin的支持，java版本的修改，maven庫上場的邏輯等等

5、模塊間：string、drawable、value、layout等，資源名衝突問題

如何防止資源名衝突？

比如businessA 和 businessB都在drawable目錄下，都有一張同名的圖片。

這兩張圖片只有一張會被打包到apk中，被使用。

這樣就容易出現混亂。

這個問題比較好解決。讓每個模塊的資源名固定一個前綴。只要模塊之間的前綴不一樣就不會衝突。

gradle的resourcePrefix配置，剛好符合我們的需求。

如下配置，如果module中存在資源不以app_開頭，lint走查會報warnning。注意不會編譯失敗。

android {
    resourcePrefix 'app_'
}
複製代碼

如下截圖的warning：

6、由於多module分層的項目結構，導致 R.class 冗餘

可以通過booster的資源內聯工具解決，R類的冗餘。

詳細可以自己查看booster官網，booster是didi開源的一個插件。
booster.johnsonlee.io/feature/shr…

7、模塊間，公共資源string、drawable、layout等如何共享？

沒有找到很好的解決方案。

每個方案都有缺陷

比如說，business1和business2都要用到同一張圖片。

那麼這張圖片該放到哪裡呢？

• 1、把他放到api模塊里來共享資源這種，並非功能依賴，放到api模塊也不太合適。因為這樣可能造成business1和business2模塊原本沒有關聯也沒有依賴；但因為共用同一個資源，卻導致存在了依賴。
• 2、在business1和business2中都放一個圖片如此會增大包體
• 3、在business1和business2中都放文件名同名的圖片，讓編譯時資源合併的時候只使用同一張圖片。如此一來，放開各個模塊資源命名，也容易導致開發時發生衝突。自定義lint規則，讓存在common和{moduleName}兩種前綴？
• 4、將這張圖片下沉到base層，如：framework模塊，或者，單開一個lib-resource如此一來，將會出現資源中心化問題。

上面的方法多少都有些缺陷，大叔還沒有找到一個優雅的方式。如果你有什麼好想法，一定要留言告訴大叔，大叔在此謝過你了。

8、各個business 模塊 之間能不能有直接依賴？

千萬不能這麼操作。

假如：在 business/setting 中直接在gradle配置中依賴，business:account。

那麼編譯上的代碼隔離就徹底被毀。就跟不要談組件的可重用性、可替代性了。

implementation project(“:business:account”) 複製代碼

9、Application生命周期如何派發

各個組件如何獲得Application.attach()、Application.onCreate()、Application.onTerminate()等的回調。

未完待續

10、組件生命周期管理

未完待續，待踩過坑，實現了，再來寫。

11、組件實現熱插拔

未完待續，待踩過坑，實現了，再來寫。

12、等等，未完待續

待繼續探索

三、升華

最後我們再回到，組件化本身上來。

組件化開發不僅僅是一種多module分層的項目結構；他不僅僅是一種架構；他更是一種架構思想，一種追求模塊復用精神。

有人說小項目沒有必要做組件化開發。大叔不這麼認為，小項目依然適合做組件化，除非你們團隊只有一個項目，並且項目幾乎不需要迭代。組件跨項目的復用也是一件讓人十分興奮的優勢。

前幾年聽爛了的技術中台，跟組件化的架構也不謀而合。