從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模塊來解決代碼中心化問題帶來的好處：
- 讓各個business的之間的依賴明確
- 讓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 properties
developer.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分層的專案結構；他不僅僅是一種架構；他更是一種架構思想，一種追求模塊復用精神，
有人說小專案沒有必要做組件化開發，大叔不這么認為，小專案依然適合做組件化，除非你們團隊只有一個專案，并且專案幾乎不需要迭代，組件跨專案的復用也是一件讓人十分興奮的優勢，
前幾年聽爛了的技術中臺，跟組件化的架構也不謀而合，
最后，十分感謝，前輩們將他們的組件化經驗分享到互聯網，為我們這些組件化的后來者提供了寶貴的資料，這也是我寫這篇文章的原因，也算是反哺吧，最后的話分享一些組件化的學習筆記給大家，有需要的可以在我的github自取！
Android-Architecture-Guide
轉載請註明出處，本文鏈接：https://www.uj5u.com/yidong/287768.html
標籤：其他