基於運行時組件化/模塊化的架構實踐
當前參與的項目歷史也很久遠，第一行代碼據說是寫於2014年的某一天，那時Android用的ide還是Eclipse、那時Android還沒有很好的架構指導（mvp、mvvm）、那時Android最新的版本是5.0、那時Android的Material Design還沒流行……
背景
隨著業務和產品發展，目前參與的項目apk有2~10個Android開發人員（註：開發人員數回浮動，不是因為離職，而是是因為當前項目團隊在承接多個項目的並行開發）在進行迭代和維護。當前技術部移動團隊有30+開發人員，有多個不同的項目在並行開發，但是卻沒有架構組（底層碼農管不了組織的事，只能埋頭敲代碼），沒有架構組的最直接的問題是沒有一個組織來統一各個項目的技術選型和技術方案。
今天帶來自己寫的一個組件化框架XModulable：
XModulable使用：
1. 添加依賴配置
android {
defaultConfig {
...
javaCompileOptions {
annotationProcessorOptions {
arguments= [ XModule : project.getName() ]
}
}
}
}
dependencies {
// gradle3.0以上建議使用implementation(或者api) "com.xpleemoon.xmodulable:XModulable-api:x.x.x"
compile"com.xpleemoon.xmodulable:XModulable-api:x.x.x"
annotationProcessor"com.xpleemoon.xmodulable:XModulable-compiler:x.x.x"
...
}
2. 實現組件
@XModule(name ="XX組件名")
publicclassXXModuleimplementsIModule{
}
3. 初始化sdk
if(isDebug) {
XModulable.openDebug();
}
XModulable.init(this);
4. 獲取組件
組件獲取有兩種方式：依賴注入和手動查詢獲取。
依賴注入：
publicclassTestActivityextendsBaseActivity{
@InjectXModule(name ="xxx")
XXModule mXXModule;
@Override
protected void onCreate(@NullableBundle savedInstanceState) {
super.onCreate(savedInstanceState);
XModulable.inject(this);
}
}
手動獲取：
XModulable.getInstance().getModule("XX組件名")
5. 添加混淆規則
原理介紹：
組件化/模塊化
組件：基於可重用的目的，對功能進行封裝，一個功能就是一個組件，例如網路、IO、圖片載入等等這些都是組件
模塊：基於業務獨立的目的，對一系列有內聚性的業務進行整理，將其與其他業務進行切割、拆分，從主工程或原所在位置抽離為一個相互獨立的部分
由於模塊是獨立、解耦、可重用的特性，在實施組件化/模塊化的過程中，我們需要解決三個主要問題：
1. 模塊通信——因為業務模塊是相互隔離的，它們完全不知道也無法感知其他業務模塊是否存在，所以需要一種盡最大可能的隔離、耦合度相對最低、代價相對最小的可行方案來實現通信
2. 模塊獨立運行——在後續迭代維護的過程中，各個業務線的人員能夠職責更加清晰
3. 模塊靈活組合運行——能夠適應產品需求，靈活拆分組合打包上線
NOTE：組件化/模塊化這一節將會以XModulable為例進行解釋它是如何進行組件化/模塊化：闡述和理解一個程序問題，最直接的方式是寫一個小的demo演示和show關鍵代碼。本文可能有些地方講的不夠詳細，強烈建議拉下XModulable運行看看。
解決拋出的三個問題之前，先過下[XModulable]的工程結構圖和架構圖，上圖中的module對應層級：
app殼層——依賴業務層，可靈活組合業務層模塊
業務層——im、live和main，面向common層實現業務層服務介面，向common註冊和查詢業務模塊
common層——依賴基礎組件層；承接業務層，暴露業務層服務介面，同時為業務層提供模塊路由服務
basic層——basicRes和basicLib
basicRes——包含通用資源和各UI組件
basicLib——包含網路組件、圖片載入組件、各種工具等功能組件
XModulable只是一個小的demo而已，而圖中展示的是我對於每一層的完整構想，所以當去源碼的時候發現有些是缺失的：common缺失了AOP代碼、basciRes缺失了UI組件，basicLib缺失了幾乎所有的組件。
XModulable-annoation、XModulable-api和XModulable -compiler屬於XModulable SDK。
XModulable SDK主要用於業務模塊的註冊（sdk在執行初始化的時候，會自動進行註冊）和獲取（依賴注入和手動獲取）。這裡對XModulable Sdk不做具體技術分析，對於依賴注入和註解的編譯期處理不了解或者感興趣的可移步我以前寫的編譯時（Compile time）處理，擼一個簡易版的ButterKnife
1. 模塊通信
模塊化的通信（UI跳轉和數據傳遞），需要抓住幾個基本點：隔離、解耦、代價小（易維護）、傳遞複雜數據（Fragment、View、File……）。實現獨立互不依賴模塊的通信，很容易能夠想到以下幾種方式：
Android傳統通信（比如aidl、廣播、自定義url……）
無法避免高度耦合、以及隨著項目擴張導致難以維護的問題
還有另外一關鍵個問題就是只能進行一些非常簡單的數據傳遞，像Fragment、View、File……這些數據（或者叫對象也行），完全無法通信傳遞，但是這些數據在實際的app中恰恰是組成一個app的關鍵節點。比如說app的主站中有一個MainActivity，它是一個ViewPager+TabLayout的結構，其中的每一個頁面都是來自於不同模塊的Fragment，這個時候我們的通信就完全無法滿足了。
第三方通信（比如EventBus、RxBus……）
容易陷入茫茫的event通知和接收中，增加調試和維護的成本
能夠傳遞一些複雜的數據，通過event事件來攜帶其它數據對象，但是代碼耦合性相應的會增加
第三方路由庫（比如ARouter、OkDeepLink、DeepLinkDispatch……）基本都能夠實現隔離、解耦、代價小（易維護）。至於數據傳遞的話默認只支持一些簡單數據，但是我們可以結合面向介面編程，公共層暴露介面，業務層面向公共層的介面去實現對應的介面方法（UI跳轉、數據讀寫……），最後當業務層使用的時候只需要通過路由到介面，就可以完成複雜數據的通信。以ARouter為例，可以在common層暴露業務模塊的服務介面（IProvider，ARouter提供的服務介面，只要實現了該介面的自定義服務，ARouter都能進行路由操作），然後交由對應的業務模塊去實現common層對應的服務介面，最後在業務模塊中使用ARouter進行路由其他業務模塊暴露的服務介面來實現。
從上面的分析來看，路由+面向介面編程是實現組件化/模塊化的不二之選，但是這裡又有一個問題——假設哪天抽風想要更換路由庫或者可能某種特殊需求不同的業務模塊使用了不容的路由庫，那怎麼辦呢？沒關係，我們這時候需要對路由庫做一層封裝，使業務模塊內的路由都相互隔離，也就是一個業務模塊內部的路由操作對其他業務模塊來說是一個黑箱操作。我的封裝思路是這樣的：加一個XModule（可以把它想像成一個容器）的概念，在common層暴露服務介面的同時暴露XModule（它的具體實現也是有對應的業務模塊決定的），每一業務模塊都對應一個XModule，用於承載common層暴露的服務介面，業務模塊之間的通信第一步必須先獲取XModule，然後再通過這個容器去拿到服務。
綜上所述，最終的組件化/模塊化採用的是封裝+路由+面向介面編程。以live業務模塊為例，從源碼的角度看下它們是實現這套思路的。在common層把live業務模塊想要暴露給其他業務模塊的服務LiveService進行了暴露，同時在common層暴露了一個LiveModule（live業務模塊的服務容器，承載了LiveService）,l，live業務模塊面向common層對應的介面進行實現（LiveModuleImpl和LiveServiceImpl）。這樣的話，上層業務就可以通過XModulable SDK獲取到LiveModule，然後通過LiveModule承載的服務進行調用。
2. 模塊獨立運行
業務模塊在Android Studio中其實就是一個module，從gradle的角度來說，module不是以application plugin方式運行，就是以library plugin方式運行，所以為了業務模塊也能夠獨立運行，就需要控制gradle能夠在application plugin和library plugin兩種形式下切換，同時還要提供單獨運行時的源碼。
首先在項目的build.gradle中創建業務模塊配置，isStandAlone表示業務模塊是否獨立運行：
然後設置對應業務模塊的build.gradle：
最後，在業務模塊中編寫build.gradle中sourceSets聲明單獨運行所需要的額外源碼文件，比如Application、SplashActivity和Manifest。
完成上面的過程後，就可以選擇對應的業務模塊live運行
3. 模塊靈活組合運行
模塊的靈活組合，其實也非常簡單，只需要更改業務模塊配置在項目build.gradle的isStandalone值，然後在app殼的build.gradle中通過業務模塊的isStandalone來決定是否依賴就行，關鍵代碼如下：
產品技術債
OK，現在已經把組件化/模塊化所面臨的問題消滅了，那就回過頭來整理現有產品的技術債：
代碼耦合、臃腫、混亂
模塊層級不合理
業務模塊相互依賴耦合
業務模塊拆分粒度不夠，某些模塊像個大雜燴
業務模塊無法單獨編譯運行，業務模塊之間無法靈活組合成apk
基礎組件無法快速提取，以供給其他工程使用
上述問題直接導致新來同事無法快速理清工程結構，以及無法快速進入開發。
若團隊後續擴張的話，勢必會按照業務功能模塊劃分獨立的業務小組，那麼會導致人員組織架構和工程組織架構上打架
對症下藥
(一)控制代碼質量
團隊內部人員需要有代碼質量意識，否則，容易出現有一波人在重構優化，而另一波人卻在寫bug、寫爛代碼，這樣就完全失去了重構的意義。所以，在進入重構之前務必要明確傳達控制代碼質量。
控制公共分支（master、develop和版本分支）許可權，將公共分支的許可權集中在少數人手裡，可避免代碼衝突、分支不可控
非項目負責人只有develop許可權——無法merge遠端倉庫的master、develop和版本分支
制定git flow和code review流程，提高團隊協作效率
項目負責人從master（或者develop分支，視自身的項目管理而定）遷出版本分支
開發人員從版本分支遷出個人的開發分支
開發人員在個人的開發分支上進行開發工作
開發人員在個人分支上開發完成後需要push到遠端，
開發人員在遠端（我們用的是gitlab）創建merge request（Source branch：個人分支，Target branch：版本分支），同時指派給項目負責人並@相關開發人人員
執行code review
review完成，由負責人進行遠端的分支合併
(二) 合理的模塊層級
首先來看下模塊層級架構圖：
在原有app的層級上，重新劃分模塊層級，這是很吃力的一件事情。因為一個項目經常是有多人並行的開發迭代的，當你已經切割或者規划出模塊層級了，但是其它成員卻在反其道而行之，必然會導致實施過程中進行代碼合併時有茫茫多的衝突需要解決和返工，所以我們在這裡還需要灌輸模塊層級思想和規劃。
劃分層級，從上到依次為：app殼層、業務層、common層、basic層，它們的職責如下
app殼層——直接依賴業務模塊
業務層——項目中各個獨立的業務功能的聚合，由多個業務模塊構成業務層
common層——承上啟下：承接上層業務，提供業務模塊路由服務；依賴底層basic，統一提供給上層使用
basic層——basicRes和basicLib
basicRes——包含通用資源和各UI組件
basicLib——包含網路組件、圖片載入組件、各種工具等功能組件
業務模塊提取通用代碼、組件、公共資源進行下沉
通用代碼下沉到common，可能涉及到BaseAplication、BaseActivity、廣播通知事件（也可能是EventBus相關事件，具體視自身而定）
ui組件和基礎資源下沉到basicRes
網路組件、圖片載入組件、各種工具等功能組件下沉到basicLib
大雜燴模塊拆分獨立。以主業務模塊為例，包含了推送、分享、更新、地圖、用戶中心、二手房、新房、租房……，如此臃腫的模塊不可能一次性拆分完成，所以必須制定一個計劃，有節奏的進行推進。我們的規劃是按照業務關聯性由低到高的原則依次拆分：
分享、更新下沉到basicLib
推送、地圖下沉到basicLib
用戶中心獨立成業務模塊
二手房、新房、租房獨立成業務模塊
業務模塊獨立運行；業務模塊之間靈活組合成apk
(三) 基礎組件內網maven依賴
基礎組件拆分完成後，如果直接進行module依賴的話，會導致重複編譯和無法靈活供給其它app使用的問題。所以我們需要將基礎組件上傳內網maven，然後通過maven進行依賴。
basicRes和basicLib作為基礎資源組件和基礎功能組件上傳到內網maven
對basicRes和basicLib根據組件細粒度拆分上傳內網maven，方便其他工程能夠根據實際需求靈活依賴
設定節奏和目標
制定重構節奏和流程如下，將規劃合理分配到各個版本中去，在保證產品迭代的同時，能夠穩步推進基於組件化/模塊化的重構探索實踐。
源碼：https://github.com/xpleemoon/XModulable
作者：xpleemoon。某互聯網房產公司高級工程師
TAG:開發者技術前線 |