從2017年只有幾個大廠在作組件化,到今天已經繁花似錦。html
愈來愈多的團隊,愈來愈多的項目都作了組件化。java
大叔相信即便你沒有作過組件化項目,可是,對組件化也早就聽爛了。android
可是,組件化開發多少有些技術門檻。git
有不少大神寫過相關文章,通俗易懂的很少。深刻淺出的更很少。github
大叔不才,願意冒着不要臉的風險一試,通俗易懂、深深淺淺的來聊聊組件化開發,若是對你有一點點啓發,請記得回來給大叔點個贊。api
這篇blog,大叔醞釀了很長長長長長長長長長長長長長長時間。微信
這種分層架構,有什麼用呢?markdown
分解成多module的項目結構,就是組件化開發了嗎?數據結構
固然不是,多module分層的項目結構,只是組件化開發的一部分。只是組件化開發的基礎。架構
大叔,搜索了不少資料,發現,對於組件化開發,並無很嚴格的定義。
固然,咱們沒有必要,過於糾結 」組件化開發的定義「;
咱們更關注這種開發思想對項目帶來的好處以及在團隊中如何運用。
下面是個人理解,若有出入,歡迎提出來一塊兒討論。
尤爲在大團隊,大項目上,組件化的優點會更加凸顯。
大項目分解成一個個小型項目,至關於將一個複雜的問題拆解成一個個相對簡單的問題。
每一個成員,能夠專一在本身相關業務的module上。
同層的代碼不能相互調用。底層的代碼也不能調用上層。
這種編譯隔離,帶來了,模塊間的高度解耦。
讓模塊的依賴關係清晰。
(若是構建正確)組件化設計的系統,比傳統的總體設計具備更高的可重用性。
什麼是組件?什麼是模塊?
組件強調複用,模塊強調職責劃分。 他們沒有很是嚴格的劃分。
達到可複用要求的模塊,那麼這個模塊就是組件。
base層的module必須是可複用的,若是項目設計的好,business層都能被複用,每一個module都能成爲組件。
可重用性是組件化思想的核心。
如此架構,是否也適合技術中臺的架構?
若是咱們要爲某個已經存在的組件,從新開發一個新組件,將變得很是可行。
組件內的重構也將變得很是可行。
新的組件的設計只要保證對外提供的接口,徹底符合,舊組件對外提供的接口
咱們想象下,在APP運行時,business中的組件能夠動態加載,也可動態卸載。
那麼咱們能夠輕鬆實現組件的懶加載:用戶用到的組件,那麼就加載進來。用完以後即可以卸載。
大的android工程項目,build一次要到5分鐘左右,太浪費時間了。
拆成多個組件以後,若是每一個組件都能單獨build,單獨測試,那麼將大大提高開發效率。
上面討論的這些優點,並非將簡單將 單工程 拆分紅 分層的多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層,就能夠實現編譯上的代碼共享。
如此一來,就帶來了,另外一個問題:代碼的中心化問題。
簡單的path字符串定義,放在framework卻是還好。
若是全部business模塊對外提供的接口和數據結構,都定義到framework的話,問題就有點嚴峻。
將會破壞:組件的 可替代性、可重用性、組件間耦合度
由於framework是基礎模塊嘛,全部business模塊都依賴的模塊,如此,無論你的business1模塊是否依賴business2模塊的對外接口,都會存在這一層依賴。
模塊間的代碼邊界出現一些劣化。缺乏了編譯上的隔離。許多模塊將會變得不夠「獨立」了。
可替代性、可重用性 愈來愈弱,想要替換或者複用某個business組件將變得愈來愈難。
將會致使,咱們很難知道,哪些business對哪些business 接口有依賴。
同時,framework模塊隨着功能迭代,會不斷膨脹。
這就是,中心化的問題。
因而咱們很天然的想到了一個解決方案:
實現了另外一種接口暴露的形式——「.api化」。
將 business模塊 對外提供的接口單獨抽到 business-api 模塊中。其餘依賴他的模塊只須要依賴他的business-api便可。
這個方案如何實踐下去呢?
微信團隊出了一個很巧妙的方案,這個方案對android的組件化開發,產生了很是深遠的影響。
後面不少作組件化開發的團隊,在解決中心化問題基本都會用到相似的方案。
如下爲,微信官方博客的原文引用:
使用方式和思路都很簡單。對於java文件,將工程裏想要暴露出去的接口類後綴名從「.java」改爲「.api」,就能夠了。
並且並不僅是java文件,其餘文件若是也想暴露,在文件名後增長".api」,也同樣能夠。
固然,要讓工程支持這樣的方式,gradle文件確定會有一點改變。
![]()
它的實現原理也至關簡單:自動生成一個「SDK」工程,拷貝.api後綴文件到工程中就好了,後面其餘工程依賴編譯的只是這個生成的工程。簡單好用。
api方案有點相似於android的AIDL的思路。
gradle 根據src/api文件來,自動生成{moduleName}-api模塊。
若是,src/api文件不存在,將不會自動生成 {moduleName}-api 模塊。
複製代碼
經過API模塊來解決代碼中心化問題帶來的好處:
從而增強了模塊的:可替代性。
只要兩個business對外提供的API一致,就能夠相互替換。
模塊變多了,項目變大了,整個項目的編譯速度變慢了。
業內有兩種經常使用作法。
方案一:動態配置 build.gradle。
只要讓單個的組建能編譯成APP就能單獨測試。
方案二:多殼APP
方案來自,在聚美優品。
這裏須要注意:假如,Demo1是business1的殼APP。那麼Demo1還須要依賴哪些businessXXX呢?
恰好,前面作的api化,能排上用場。
business1依賴的businessXXX-api模塊對應的businessXXX模塊,Demo1也須要依賴。
爲甚?由於,business1依賴的businessXXX-api模塊,意味着,business1須要依賴 businessXXX提供的功能,好比要跳轉到businessXXX的activity?或者,要獲取businessXXX的對象。
方案一:Extra properties
developer.android.com/studio/buil…
在項目跟目錄的build.gradle文件中配置Extra屬性
如此能夠實現統一管理版本號,和依賴。
可是,可是,可是,這個方案存在明顯的缺陷。
不支持,自動補全
不支持Find Usages,查找全部應用的地方
使用時,不支持點擊跳轉
嚴重影響開發體驗。
方案二:buildSrc
支持,Find Usages
更完美的語法高亮
gradle文件複用
版本和依賴作到了統一管理,可是每一個module都有各自的build.gradle,重複的build.gradle代碼依然沒有複用。
咱們能夠經過apply from:"xxx.gradle"的方式來複用gradle代碼。
以下圖
如上,咱們能夠在base.gradle中爲每個項目添加配置統一的編譯邏輯,如:kotlin的支持,java版本的修改,maven庫上場的邏輯等等
如何防止資源名衝突?
好比businessA 和 businessB都在drawable目錄下,都有一張同名的圖片。
這兩張圖片只有一張會被打包到apk中,被使用。
這樣就容易出現混亂。
這個問題比較好解決。讓每一個模塊的資源名固定一個前綴。只要模塊之間的前綴不同就不會衝突。
gradle的resourcePrefix配置,恰好符合咱們的需求。
以下配置,若是module中存在資源不以app_
開頭,**lint走查會報warnning。**注意不會編譯失敗。
android {
resourcePrefix 'app_'
}
複製代碼
以下截圖的warning:
能夠經過booster的資源內聯工具解決,R類的冗餘。
詳細能夠本身查看booster官網,booster是didi開源的一個插件。booster.johnsonlee.io/feature/shr…
沒有找到很好的解決方案。
每一個方案都有缺陷
好比說,business1和business2都要用到同一張圖片。
那麼這張圖片該放到哪裏呢?
一、把他放到api模塊裏來共享
資源這種,並不是功能依賴,放到api模塊也不太合適。
由於這樣可能形成business1和business2模塊本來沒有關聯也沒有依賴;
但由於共用同一個資源,卻致使存在了依賴。
二、在business1和business2中都放一個圖片
如此會增大包體
三、在business1和business2中都放文件名同名的圖片,讓編譯時資源合併的時候只使用同一張圖片。
如此一來,放開各個模塊資源命名,也容易致使開發時發生衝突。
自定義lint規則,讓存在common和{moduleName}兩種前綴?
四、將這張圖片下沉到base層,如:framework模塊,或者,單開一個lib-resource
如此一來,將會出現資源中心化問題。
上面的方法多少都有些缺陷,大叔尚未找到一個優雅的方式。若是你有什麼好想法,必定要留言告訴大叔,大叔在此謝過你了。
千萬不能這麼操做。
假如:在 business/setting 中直接在gradle配置中依賴,business:account。
那麼編譯上的代碼隔離就完全被毀。就跟不要談組件的可重用性、可替代性了。
implementation project(":business:account") 複製代碼
各個組件如何得到Application.attach()、Application.onCreate()、Application.onTerminate()等的回調。
未完待續
未完待續,待大叔踩過坑,實現了,再來寫。
未完待續,待大叔踩過坑,實現了,再來寫。
待大叔繼續探索
最後咱們再回到,組件化自己上來。
組件化開發不只僅是一種多module分層的項目結構;他不只僅是一種架構;他更是一種架構思想,一種追求模塊複用精神。
有人說小項目沒有必要作組件化開發。大叔不這麼認爲,小項目依然適合作組件化,除非大家團隊只有一個項目,而且項目幾乎不須要迭代。組件跨項目的複用也是一件讓人十分興奮的優點。
前幾年聽爛了的技術中臺,跟組件化的架構也不謀而合。
最後,十分感謝,前輩們將他們的組件化經驗分享到互聯網,爲咱們這些組件化的後來者提供了寶貴的資料。
感謝!感謝!感謝!感謝!感謝!大叔給大家一個麼麼噠
Is there a difference between a component and a module
最後的最後,若是這篇文章對你有一點點啓發,請必定要點個贊再走。這對一個草根原創技術博主很重要……