iOS應用架構談 組件化方案：https://casatwy.com/iOS-Modulization.html
1.組件化有什麼好處？
- 業務分層、解耦，使代碼變得可維護；
- 有效的拆分、組織日益龐大的工程代碼，使工程目錄變得可維護；
- 便於各業務功能拆分、抽離，實現真正的功能複用；
- 業務隔離，跨團隊開發代碼控制和版本風險控制的實現；
- 模塊化對代碼的封裝性、合理性都有一定的要求，提升開發同學的設計能力；
- 在維護好各級組件的情況下，隨意組合滿嘴不同產品需求；（只需要將之前的多個業務組件模塊在新的主App中進行組裝即可快速迭代出下一個全新App）
2.你是如何組件化解耦的？
（a）分層：
- 基礎功能組件：按功能分庫，不涉及產品業務需求，跟系統庫類似，通過良好的接口供上層業務組件調用；不寫入產品定製邏輯，通過擴展接口完成定製；
- 基礎UI組件：各個業務模塊依賴使用，但需要保持好定製和擴展的設計；
- 業務組件：業務功能間相互獨立，相互間沒有model共享的依賴；業務之間的頁面調用只能通過UIBus進行跳轉；業務之間的邏輯Action調用只能通過服務提供；
（b）中間件：target-action，url-block，protocl-class
3.爲什麼CTMediator方案優於Router方案？
CTMediator的優點：
-
（1）調用時，區分了本地應用調用和遠程應用調用。本地應用調用爲遠程應用調用提供服務。
-
（2）組件僅通過Action暴露可調用接口，模塊與模塊之間的接口被固化在了Target-Action這一層，避免了實施組件化的改造過程中，對Business的侵入，同時也提高了組件化接口的可維護性。
-
（3）方便傳遞各種類型的參數。
Router的缺點：
-
（1）在組件化的實施過程中，註冊URL並不是充分必要條件。組件是不需要向組件管理器註冊URL的，註冊了URL之後，會造成不必要的內存常駐。註冊URL的目的其實是一個服務發現的過程，在iOS領域中，服務發現的方式是不需要通過主動註冊的，使用runtime就可以了。另外，註冊部分的代碼的維護是一個相對麻煩的事情，每一次支持新調用時，都要去維護一次註冊列表。如果有調用被棄用了，是經常會忘記刪項目的。runtime由於不存在註冊過程，那就也不會產生維護的操作，維護成本就降低了。 由於通過runtime做到了服務的自動發現，拓展調用接口的任務就僅在於各自的模塊，任何一次新接口添加，新業務添加，都不必去主工程做操作，十分透明。
-
（2）在iOS領域裏，一定是組件化的中間件爲openURL提供服務，而不是openURL方式爲組件化提供服務。如果在給App實施組件化方案的過程中是基於openURL的方案的話，有一個致命缺陷：非常規對象(不能被字符串化到URL中的對象，例如UIImage)無法參與本地組件間調度。 在本地調用中使用URL的方式其實是不必要的，如果業務工程師在本地間調度時需要給出URL，那麼就不可避免要提供params，在調用時要提供哪些params是業務工程師很容易懵逼的地方。
-
（3）爲了支持傳遞非常規參數，蘑菇街的方案採用了protocol，這個會侵入業務。由於業務中的某個對象需要被調用，因此必須要符合某個可被調用的protocol，然而這個protocol又不存在於當前業務領域，於是當前業務就不得不依賴public Protocol。這對於將來的業務遷移是有非常大的影響的。
4.基於CTMediator的組件化方案，有哪些核心組成？
（1）CTMediator中間件：集成就可以了；
（2）模塊Target_%@:模塊的實現以及提供對外的額方法，調用Action_methodName,需要傳參數時，都統一以NSDictionary *的方式傳入。
（3）CTMediator+%@類目擴展：類目裏聲明瞭模塊業務的對外接口，參數明確，這樣外部調用者可以 很容易理解如何調用接口。