項目發展到一定階段，業務線增多，團隊龐大，需求變更加速，組件化變成一種“剛需”。
組件化最早在一些大廠被提出，如淘寶、蘑菇街、滴滴等，都有各自的組件化實踐，
這些實踐滿足了各個平臺的業務發展需要，同時也讓組件化的定義越發模糊，本文從實踐角度，梳理一下組件化過程，供在組件化道路上迷茫的開發者參考。
本文討論以下三個主題：
- 通信方案的選擇
- 組件的劃分方式，定義組件包含的內容
- 最後給出一個Demo，演示組件的集成和消息傳遞。
本文主要從iOS技術角度出發，兼顧跨平臺實踐，其它平臺可以對應參考，其思想是貫通的。
通信方案的選擇
由於組件對通信庫有直接的依賴關係，通信方案決定着組件封裝形式，討論組件化的實踐，就需要先確定組件的通信方式，常見的通信方式有下面三種：
通信方式1: 協議
將方法調用抽象爲協議，調用者依賴抽象協議，從而避免與實際被調用者緊耦合，是面向對象的傳統方法。
協議的缺點是：維護時需要同時維護Protocol、接口類兩部分，影響開發效率。
通信方式2: Target-Action
Target-Action方式，說白了，就是利用了OC的分類特性，在中間件中“聲明”了每個組件各自的方法，優點是參數傳遞和返回值直觀，可以強控制參數類型，以至於在很多組件方案中都是優先選擇。
強方法會造成一些問題，舉例來說，設想在手機淘寶中，搜索“保溫杯”後顯示一個商品列表，其中的商品可能來自天貓也有可能來自C鋪，點擊後分別打開天貓詳情頁和C鋪詳情頁，這兩個商品頁面差別較大，業務流程也有差異，應該分爲兩個組件，這就需要根據跳轉的商品，區分不同平臺，並調用不同分類方法，這部分代碼無論由調用者還是中間件來處理，都導致硬編碼，有悖組件化的初衷。
通信方式3: Route
在 RESTful 系統中，URL 都已經不陌生，Route 方式是這種思路在APP內的自然選擇，Route 方式在傳值上有限制，不過在一個已經適配了 RESTful 的項目中，遇到的不便實際很少，畢竟如果一個項目已經能 Web 化，必要的模型都已經 json 化，能通過 URL 傳輸。
在前面“保溫杯”的例子中，來自天貓的詳情頁URL可以是：
/tmall/detail/:itemid
來自C鋪的詳情頁URL可以是：
/taobao/detail/:itemid
直接在 URL 上就區分了兩個組件，中間件可以直接跳轉，不需要額外的編碼。
小結
通信方案是組件化的基礎，基於 URL 的 Route 方式，形式統一，自然區分了不同組件，成爲組件化的首選。