Android 元件化案例
前言
鑑於個人文筆有限,上篇博文Android元件化文章寫的太爛 Android元件化、模組化開發圖文以及解釋做的太過粗糙。
本篇咱們根據圖表對比,優缺點,講述具體的實現步驟以及gradle自動化指令碼的書寫等。
為什麼元件化
隨著移動網際網路的發展,或許中小型專案還可以用單工程+MVC/MVP/MVVM的架構來完成,但當專案到了一定程度之後,編譯時間 原來越長,測試或者開發任何一個模組功能都需要整個專案重啟執行。
常規單工程+MVC/MVP/MVVM專案:
乍一看,這樣的結構只要咱們模組分層明確,是不存在大問題的,但是隨著業務的快速迭代,面臨以下問題:
1.需求瘋狂變化,上週剛討論出一套方案,你花了兩天搞定,這個時候PM告訴你,這個咱們修改或者不要了,是否想抓狂呢。
2.所有業務都在一個專案,不管基於什麼原因,有時候咱們為了快速完成一個功能,或多或少存在耦合,任何改動都可能顯的比較吃力,解決了一個BUG又出現另外一個BUG。
3.團隊人數達到一定程度後,並行開發過程中,如果某個成員不小心犯錯並且提交了程式碼,可能導致專案暫時無法執行,不得不停下來協同查詢問題,嚴重影響開發效率
4.業務越來越多,專案越來越大,編譯執行一次要10秒…20秒…1分鐘…5分鐘…累計幾個月下來的時間說不得抽出來都可以去找個女朋友了…
基於以上問題,咱們的元件化應運而生。
元件化結構圖
對比上張圖,這裡的APP主要由業務元件構成,嚴格來說這5個業務元件也可以是5個App,當實現以上架構圖,看看元件化的優缺點:
元件化優點
業務元件可以單獨分配並行開發
單個元件業務可以由開發者自行決定採取MVC/MVP/MVVM架構而不影響整體大局
新人接手專案分配任務可單獨分配某一個模組任務,不必關心整個專案
開發效率提升,開發過程僅僅需要維護開發自己的元件內容
若公司有多個團隊,優秀程式碼元件可快速移植複用
積累個人的元件倉庫,擺脫貼上複製的“搬磚工”身份
測試可單獨測試某個模組
元件化的坑
元件與元件之間的呼叫,資料等互動
多個元件,在使用application的時候怎辦
多個元件資源命名重複
多個元件引用不同版本的相同的庫
瞭解了優缺點,咱們進入正式的元件化開發整合,後續將會描述如何解決元件化的一些坑。
前文說過,咱們的5個元件可以理解為5個app,下面開始整合。
先看看咱們的元件化效果,手機展示效果,
1:首先統一元件之間的版本以及第三方庫版本
利用Gradle統一版本號,可參考 android使用Gradle統一配置依賴版本
2:咱們的元件又是Lib,又是application,如何控制除錯,如何在主APP選擇
在config.build處新增一個布林isBuildApp作為標誌判斷依賴,true表示作為application存在,false表示lib存在
ext {
isBuildApp=false;//false:作為Lib元件存在, true:作為application存在
...
}
在每個元件的build根據isBuildApp來選擇依賴
if(rootProject.ext.isBuildApp){
apply plugin: "com.android.application"
}else{
apply plugin: 'com.android.library'
}
android{
...
defaultConfig {
if(rootProject.ext.isBuildApp){
applicationId "com.allure.shop"
}
...
}
}
ibrary與application執行時需要manifest,依然根據isBuildApp判斷
sourceSets {
main {
if (rootProject.ext.isBuildApp) {
manifest.srcFile 'src/main/debug/AndroidManifest.xml'
} else {
manifest.srcFile 'src/main/release/AndroidManifest.xml'
java {
exclude 'debug/**'
}
}
}
}
資源的命名為了避免重複,建議按照元件名開頭,如Login元件,命名login_xxx,BaiDuMap元件命bd_map_xxx
可用gradle進行強制檢測
resourcePrefix "login_"
主專案的引用
if (rootProject.ext.isBuildApp) {
compile project(':modulebase')
} else {
compile project(':modulecore:moduleLogin')
compile project(':modulecore:moduleShop')
}
解決元件與元件的互動:
方案1:可採用建立中介軟體的方式來統一管理元件之間的互動,如電影元件與首頁元件需要跳轉傳值等可採用開源的ActivityRouter,EventBus來完成
方案2:在主專案APP建立統一的入口類,針對元件與元件的互動建立方法,實現介面等,但此方式有一定溝通成本,元件與元件之間的互動維護可能需要一份文件來約束。
application的使用:
方案1:統一使用基礎庫的單例BaseApplication
方案2:反射ActivityThread
Lib與Application的切換
修改config.build裡的isBuildApp屬性並且重新sync
專案結構圖:
作為元件Lib
作為單獨的application
總結
元件化技術難度不大,難點在於業務的解耦。具體是否選擇元件化方式還是要根據專案大小來確定。 當然採取了元件化是極好的。
本身元件化是應用於複雜業務的場景,DEMO也不大好做,簡單的從專案抽取做了一份案例,後續考慮在此基礎上更新