資訊專欄INFORMATION COLUMN
摘要：一背景業務組件化或者叫模塊化作為移動端應用架構的主流方式之一，近年來一直是業界積極探索和實踐的方向。有贊移動團隊自年起也在不斷嘗試各種組件化方案，在有贊微商城，有贊零售，有贊美業等多個應用中進行了實踐。相比組件，個人感覺稱之為模塊更為合適。
一、背景
業務組件化（或者叫模塊化）作為移動端應用架構的主流方式之一，近年來一直是業界積極探索和實踐的方向。有贊移動團隊自16年起也在不斷嘗試各種組件化方案，在有贊微商城，有贊零售，有贊美業等多個應用中進行了實踐。我們踩過一些坑，也收獲了很多寶貴的經驗，并沉淀出 iOS 相關框架 Bifrost (雷神里的彩虹橋)。在過程中我們深刻體會到“沒有絕對正確的架構，只有最合適的架構”這句話的意義。很多通用方案只是組件化的冰山一角，實際落地過程中還有相當多的東西需要考量。
本文并不準備對組件化架構設計方案給出一份標準答案，而是希望通過我們的實踐經驗和思考分析，提供一種思路，對遇到類似問題的同學能有所啟發。
注：
區別于功能模塊/組件（比如圖片庫，網絡庫），本文討論的是業務模塊/組件（比如訂單模塊，商品模塊）相關的架構設計。
相比組件（Component），個人感覺稱之為模塊（Module）更為合適。組件強調物理拆分，以便復用；模塊強調邏輯拆分，以便解耦。而且如果用過 Android Studio, 會發現它創建的子系統都叫 Module. 但介于業界習慣稱之為組件化，所以我們繼續使用這個術語。本文下面所用名詞，“模塊”等同于“組件”。
二、什么是業務模塊化（組件化）傳統的 App 架構設計更多強調的是分層，基于設計模式六大原則之一的單一職責原則，將系統劃分為基礎層，網絡層，UI層等等，以便于維護和擴展。但隨著業務的發展，系統變得越來越復雜，只做分層就不夠了。App 內各子系統之間耦合嚴重, 邊界越來越模糊，經常發生你中有我我中有你的情況（圖一）。這對代碼質量，功能擴展，以及開發效率都會造成很大的影響。此時，一般會將各個子系統劃分為相對獨立的模塊，通過中介者模式收斂交互代碼，把模塊間交互部分進行集中封裝, 所有模塊間調用均通過中介者來做（圖二）。這時架構邏輯會清晰很多，但因為中介者仍然需要反向依賴業務模塊，這并沒有從根本上解除循壞依賴等問題。時不時發生一個模塊進行改動，多個模塊受影響編譯不過的情況。進一步的，通過技術手段，消除中介者對業務模塊依賴，即形成了業務模塊化架構設計（圖三）。
業務模塊化設計通過對各業務模塊的解耦改造，避免循環雙向依賴，達到提升開發效率和質量的目的。但業務需求的依賴是無法消除的，所以模塊化方案首先要解決的是如何在無代碼依賴的情況下實現跨模塊通信的問題。iOS 因為其強大的運行時特性，無論是基于 NSInvocation 還是基于 peformSelector 方法, 都可以很很容易做到這一點。但不能為了解耦而解耦，提升質量與效率才是我們的目的。直接基于 hardcode 字符串 + 反射的代碼明顯會極大損害開發質量與效率，與目標背道而馳。所以，模塊化解耦需求的更準確的描述應該是“如何在保證開發質量和效率的前提下做到無代碼依賴的跨模塊通信”。
目前業界常見的模塊間通訊方案大致如下幾種：
基于路由 URL 的 UI 頁面統跳管理。
基于反射的遠程接口調用封裝。
基于面向協議思想的服務注冊方案。
基于通知的廣播方案。
根據具體業務和需求的不同，大部分公司會采用以上一種或者某幾種的組合。
3.1 路由 URL 統跳方案統跳路由是頁面解耦的最常見方式，大量應用于前端頁面。通過把一個 URL 與一個頁面綁定，需要時通過 URL 可以方便的打開相應頁面。
//通過路由URL跳轉到商品列表頁面
//kRouteGoodsList = @"http://goods/goods_list"
UIViewController *vc = [Router handleURL:kRouteGoodsList];
if(vc) {
[self.navigationController pushViewController:vc animated:YES];
}
當然有些場景會比這個復雜，比如有些頁面需要更多參數。
基本類型的參數，URL 協議天然支持：
//kRouteGoodsDetails = @“//goods/goods_detail?goods_id=%d”
NSString *urlStr = [NSString stringWithFormat:@"kRouteGoodsDetails", 123];
UIViewController *vc = [Router handleURL:urlStr];
if(vc) {
[self.navigationController pushViewController:vc animated:YES];
}
復雜類型的參數，可以提供一個額外的字典參數 complexParams, 將復雜參數放到字典中即可：
+ (nullable id)handleURL:(nonnull NSString *)urlStr
complexParams:(nullable NSDictionary*)complexParams
completion:(nullable RouteCompletion)completion;
上面方法里的 completion 參數，是一個回調 block, 處理打開某個頁面需要有回調功能的場景。比如打開會員選擇頁面，搜索會員，搜到之后點擊確定，回傳會員數據：
//kRouteMemberSearch = @“//member/member_search”
UIViewController *vc = [Router handleURL:urlStr complexParams:nil completion:^(id _Nullable result) {
//code to handle the result
...
}];
if(vc) {
[self.navigationController pushViewController:vc animated:YES];
}
考慮到實現的靈活性，提供路由服務的頁面，會將 URL 與一個 block 相綁定。block 中放入所需的初始化代碼。可以在合適的地方將初始化 block 與路由 URL 綁定，比如在 +load 方法里：
+ (void)load {
[Router bindURL:kRouteGoodsList
toHandler:^id _Nullable(NSDictionary * _Nullable parameters) {
return [[GoodsListViewController alloc] init];
}];
}
更多路由 URL 相關例子，可以參考 Bifrost 項目中的 Demo.
URL 本身是一種跨多端的通用協議。使用路由URL統跳方案的優勢是動態性及多端統一 (H5, iOS，Android，Weex/RN); 缺點是能處理的交互場景偏簡單。所以一般更適用于簡單 UI 頁面跳轉。一些復雜操作和數據傳輸，雖然也可以通過此方式實現，但都不是很效率。
目前天貓和蘑菇街都有使用路由 URL 作為自己的頁面統跳方案，達到解耦的目的。
當無法 import 某個類的頭文件但仍需調用其方法時，最常想到的就是基于反射來實現了。例：
Class manager = NSClassFromString(@"YZGoodsManager"); NSArray *list = [manager performSelector:@selector(getGoodsList)]; //code to handle the list ...
但這種方式存在大量的 hardcode 字符串。無法觸發代碼自動補全，容易出現拼寫錯誤，而且這類錯誤只能在運行時觸發相關方法后才能發現。無論是開發效率還是開發質量都有較大的影響。
如何進行優化呢？這其實是各端遠程調用都需要解決的問題。移動端最常見的遠程調用就是向后端接口發網絡請求。針對這類問題，我們很容易想到創建一個網絡層，將這類“危險代碼”封裝到里面。上層業務調用時網絡層接口時，不需要 hardcode 字符串，也不需要理解內部麻煩的邏輯。
類似的，我可以將模塊間通訊也封裝到一個“網絡層”中（或者叫消息轉發層）。這樣危險代碼只存在某幾個文件里，可以特別地進行 code review 和聯調測試。后期還可以通過單元測試來保障質量。模塊化方案中，我們可以稱這類“轉發層”為 Mediator (當然你也可以起個別的名字)。同時因為 performSelector 方法附帶參數數量有限，也沒有返回值，所以更適合使用 NSInvocation 來實現。
//Mediator提供基于NSInvocation的遠程接口調用方法的統一封裝
- (id)performTarget:(NSString *)targetName
action:(NSString *)actionName
params:(NSDictionary *)params;
//Goods模塊所有對外提供的方法封裝在一個Category中
@interface Mediator(Goods)
- (NSArray*)goods_getGoodsList;
- (NSInteger)goods_getGoodsCount;
...
@end
@impletation Mediator(Goods)
- (NSArray*)goods_getGoodsList {
return [self performTarget:@“GoodsModule” action:@"getGoodsList" params:nil];
}
- (NSInteger)goods_getGoodsCount {
return [self performTarget:@“GoodsModule” action:@"getGoodsCount" params:nil];
}
...
@end
然后各個業務模塊依賴Mediator, 就可以直接調用這些方法了。
//業務方依賴Mediator模塊，可以直接調用相關方法 ... NSArray *list = [[Mediator sharedInstance] goods_getGoodsList]; ...
這種方案的優勢是調用簡單方便，代碼自動補全和編譯時檢查都仍然有效。
劣勢是 category 存在重名覆蓋的風險，需要通過開發規范以及一些檢查機制來規避。同時 Mediator 只是收斂了 hardcode, 并未消除 hardcode, 仍然對開發效率有一定影響。
業界的 CTMediator 開源庫，以及美團都是采用類似方案。
3.3 服務注冊方案有沒有辦法絕對的避免 hardcode 呢？如果接觸過后端的服務化改造，會發現和移動端的業務模塊化很相似。Dubbo 就是服務化的經典框架之一。它是通過服務注冊的方式來實現遠程接口調用的。即每個模塊提供自己對外服務的協議聲明，然后將此聲明注冊到中間層。調用方能從中間層看到存在哪些服務接口，然后直接調用即可。例：
//Goods模塊提供的所有對外服務都放在GoodsModuleService中 @protocol GoodsModuleService - (NSArray*)getGoodsList; - (NSInteger)getGoodsCount; ... @end //Goods模塊提供實現GoodsModuleService的對象, //并在+load方法中注冊 @interface GoodsModule : NSObject@end @implementation GoodsModule + (void)load { //注冊服務 [ServiceManager registerService:@protocol(service_protocol) withModule:self.class] } //提供具體實現 - (NSArray*)getGoodsList {...} - (NSInteger)getGoodsCount {...} @end //將GoodsModuleService放在某個公共模塊中，對所有業務模塊可見 //業務模塊可以直接調用相關接口 ... id module = [ServiceManager objByService:@protocol(GoodsModuleService)]; NSArray *list = [module getGoodsList]; ...
這種方式的優勢也包括調用簡單方便。代碼自動補全和編譯時檢查都有效。實現起來也簡單，協議的所有實現仍然在模塊內部，所以不需要寫反射代碼了。同時對外暴露的只有協議，符合團隊協作的“面向協議編程”的思想。劣勢是如果服務提供方和使用方依賴的是公共模塊中的同一份協議（protocol）, 當協議內容改變時，會存在所有服務依賴模塊編譯失敗的風險。同時需要一個注冊過程，將 Protocol 協議與具體實現綁定起來。
業界里，蘑菇街的 ServiceManager 和阿里的 BeeHive 都是采用的這個方案。
3.4 通知廣播方案基于通知的模塊間通訊方案，實現思路非常簡單, 直接基于系統的 NSNotificationCenter 即可。
優勢是實現簡單，非常適合處理一對多的通訊場景。
劣勢是僅適用于簡單通訊場景。復雜數據傳輸，同步調用等方式都不太方便。
模塊化通訊方案中，更多的是把通知方案作為以上幾種方案的補充。
除了模塊間通訊的實現，業務模塊化架構還需要考慮每個模塊內部的設計，比如其生命周期控制，復雜對象傳輸，重復資源的處理等。可能因為每個公司都有自己的實際場景，業界方案里對這些問題描述的并不是很多。但實際上他們非常重要，有贊在模塊化過程中做了很多相關思考和嘗試，會在后面環節進行介紹。
四、有贊的模塊化實踐有贊移動自 16 年起開始實踐業務模塊化架構方式，大致經歷了 2016 年的嘗試+摸索，2017 年的思考+優化以及 2018 年的成熟+沉淀幾個階段。期間有過對已有 App 的模塊化改造，也試過直接應用于新起項目。模塊化方案經歷過幾次改版，踩過一些坑，也收獲了很多寶貴的經驗。
4.1 v1.0: 嘗試+摸索16 年，有贊微商城、有贊收銀等 App 經歷了初期的功能快速迭代，內部依賴混亂，耦合嚴重，急需優化重構。傳統的 MVVM、MVP 等優化方式無法從全局層面解決這些問題。后來在 InfoQ 的"移動開發前線"微信群里聽了蘑菇街的組件化方案分享，非常受啟發。不過當時還是有一些顧慮，比如微商城和收銀當時都屬于中小型項目，每端開發人員都只有 4-6 人。業務模塊化改造后會形成一定的開發門檻，帶來一定的開發效率下降。小項目適合模塊化改造嗎？其收益是否能匹配付出呢？但考慮到當時 App 各模塊邊界已經穩定，即使模塊化改造出現問題，也可以用很小的代價將其降級到傳統的中介者模式，所以改造開始了。
4.1.1 模塊間通信方式設計首先是梳理我們的模塊間通信需求，主要包括以下三種：
UI 頁面跳轉。比如IM模塊點擊用戶頭像打開會員模塊的用戶詳情頁。
動作執行及復雜數據傳輸。比如商品模塊向開單模塊傳遞商品數據模型并進行價格計算。
一對多的通知廣播。比如 logout 時賬號模塊發出廣播，各業務模塊進行 cache 清理及其它相應操作。
我們選擇了路由 URL + 遠程接口調用封裝 + 廣播相結合的方式。
對于遠程接口調用的封裝方式，我們沒有完全照抄 Mediator 方案。當時非常期望保留模塊化的編譯隔離屬性。比如當 A 模塊對外提供的某個接口發生變化時，不會引發依賴這個接口的模塊的編譯錯誤。這樣可以避免依賴模塊被迫中斷手頭的工作先去解決編譯問題。當時也沒有采用Beehive的服務注冊方式，也是因為同樣的原因。 經過討論，當時選擇參考網絡層封裝方式，在每個模塊中設計一個對外的“網絡層” ModuleService。將對其它模塊的接口的反射調用，放入各個模塊的 ModuleService 中。
同時，我們希望各業務模塊不需要去理解所依賴模塊的內部復雜實現。比如 A 模塊依賴 D 模塊的 class D1 的接口 method1， class D2 的接口method2, class D3 的接口 method3. A 需要了解 D 模塊的這些內部信息才能完成反射功能的實現。如果 D 模塊中這些命名有所變化，還會出現調用失敗。所以我們對各個模塊使用外觀（Facade）模式進行重構。D 模塊創建一個外觀層 FacadeD. 通過 FacadeD 對象對外提供所有服務，同時隱藏內部復雜實現。調用方也只需要理解 FacadeD 的頭文件 包含哪些接口即可。
外觀（Facade）模式: 為子系統中的一組接口提供一個一致的界面， Facade 模式定義了一個高層接口，這個接口使得這一子系統更加容易使用。引入外觀角色之后，用戶只需要直接與外觀角色交互，用戶與子系統之間的復雜關系由外觀角色來實現，從而降低了系統的耦合度。
另外，為什么還需要路由 URL 呢？
其實從功能角度，遠程接口的網絡層，完全可以取代路由 URL 實現頁面跳轉，而且沒有路由 URL 的一些 hardcode 的問題。而且路由 URL 和
遠程接口存在一定的功能重合，還會造成后續實現新功能時，分不清應選擇路由 URL 還是選擇遠程接口的困惑。這里選擇支持路由 URL 的主要原因是我們存在動態化且多端統一的需求。比如消息模塊下發的各種消息數據模型完全是動態的。后端配好展示內容以及跳轉需求后，客戶端不需要理解具體需求，只需要通過統一的路由跳轉協議執行跳轉動作即可。
每個模塊除了 Facade 模式改造之外，還需要考慮以下問題：
合適的注冊及初始化方式。
接收并處理全局事件。
App 層和 Common 層設計。
模塊編譯產出以及集成到 App 中的方式。
因為考慮到每個 App 中業務模塊數量不會很多（我們幾個 App 內大多是20個左右），所以我們為每個模塊創建了一個 Module 對象并令其為單例。在 +load 方法中將自身注冊給模塊化 SDK Bifrost. 經測試，這里因為單例造成的內存占用以及 +load 方法引起的啟動速度影響都微乎其微。模塊需要監聽的全局事件主要為 UIApplicationDelegate 中的那些方法。所以我們定義了一個繼承 UIApplicationDelegate 的協議 BifrostModuleProtocol，令每個模塊的 Module 對象都服從這個協議。App 的 AppDelegate對象，會輪詢所有注冊了的業務模塊并進行必要的調用。
