//聯絡人:石虎 QQ:1224614774 暱稱:嗡嘛呢叭咪哄

一、概念

1.為什麼要元件化？

  * 元件和元件之間沒有明確的約束；

  * 元件單獨開發、單獨測試，不能揉入主專案中開發，測試也可以針對性的測試；

  * 解決人多（更好的協作）、需求多（更好的功能模組劃分）的問題；

  * 解決專案模組間的程式碼耦合問題；（堅決抵制業務元件間程式碼直接引用）

2.如何拆分元件？

  基礎功能元件：（類似於效能統計、Networking、Patch、網路診斷等）

  按功能分庫，不涉及產品業務需求，跟庫Library類似

  通過良好的介面拱上層業務元件呼叫；

  不寫入產品定製邏輯，通過擴充套件介面完成定製；

  基礎UI元件：（例如下拉重新整理元件、iCausel類似的元件）

  產品內通用UI元件；（各個業務模組依賴使用，但需要保持好定製擴充套件的設計）

  公共通用UI元件；（不涉及具體產品的視覺設計， 目前較少）

  產品業務元件：（例如圈子、1元購、登入、客服MM等）

  業務功能間相對獨立，相互間沒有Model共享的依賴；

  業務之間的頁面呼叫只能通過UIBus進行跳轉；

  業務之間的邏輯Action呼叫只能通過服務提供；

二、方案

方案一、url-block

   這是蘑菇街中應用的一種頁面間呼叫的方式，通過在啟動時註冊元件提供的服務，把呼叫元件使用的url和元件提供的服務block對應起來，儲存到記憶體中。在使用元件的服務時，通過url找到對應的block，然後獲取服務

下圖是url-block的架構圖：

方案二、target-action

   casa的方案是通過給元件包裝一層wrapper來給外界提供服務，然後呼叫者通過依賴中介軟體來使用服務；其中，中介軟體是通過runtime來呼叫元件的服務，是真正意義上的解耦，也是該方案最核心的地方。具體實施過程是給元件封裝一層target物件來對外提供服務，不會對原來元件造成入侵；然後，通過實現中介軟體的category來提供服務給呼叫者，這樣使用者只需要依賴中介軟體，而元件則不需要依賴中介軟體。

下圖是casa的元件化方案架構圖：

方案三、protocol-class

    針對方案一的問題，蘑菇街又提出了另一種元件化的方案，就是通過protocol定義服務介面，元件通過實現該介面來提供介面定義的服務，具體實現就是把protocol和class做一個對映，同時在記憶體中儲存一張對映表，使用的時候，就通過protocol找到對應的class來獲取需要的服務。

謝謝!!!