前言：公司一年多的小專案，進行專案拆分，要求是每個業務模組都可以單獨打包。在開發過程中，如：酒店模組，只修改酒店單元，測試也只測試酒店部分。模組間相互不干擾，就有了，今天元件化之路。

一、元件化的目的。
說是元件化，其實更多的是模組化，對模組之間相互之間不干擾，可以單獨打包，測試，且相同模組不同專案之間的移植便利許多。和Android的外掛化大同小異，尤其是使用了cocoapods管理。

二、外掛化需要使用到哪些技術。
在考慮拆分時候，考慮使用的是類似攜程的主專案引用子專案的模式，但是考慮到嘗試使用cocoapods 管理未果，還有就是考慮到專案之間的引用比較混亂，就使用了類似百度或者阿里的外掛化方案。即將主專案變成殼工程，將其餘模組都變成私有pods的形式引用。
這時候我們就會考慮到使用什麼技術去讓模組間相互呼叫。git上有各自router ，可以考慮的也有有多，包括ct的，MGJ ,阿里的Been。這個著重談一下，CTMediator 和MGJRouter.

casatwy是通過CTMediator類實現元件化的，在此類中對外提供明確引數型別的介面，介面內部通過performTarget方法呼叫服務方元件的Target、Action。由於CTMediator類的呼叫是通過runtime主動發現服務的，所以服務方對此類是完全解耦的。但如果CTMediator類對外提供的方法都放在此類中，將會對CTMediator造成極大的負擔和程式碼量。解決方法就是對每個服務方元件建立一個CTMediator的Category，並將對服務方的performTarget呼叫放在對應的Category中，這些Category都屬於CTMediator中介軟體，從而實現了感官上的介面分離。但是實際過程中，還是通過CTMediator 物件，用runtime 建立對應的方法，然後當有這個對應方法時，之間執行實現方法。

蘑菇街的元件化方案，更像是一箇中間件，中介軟體的註冊用一個字典來保持，拿到url 將url 逐層拆分，然後將一個block 和url、回撥的block 對應儲存。當使用open url的時候，執行對應的Block 和回撥的block 。

元件化過程中如何管理。
因為MGJRouter 需要一個註冊的過程，並且需要知道註冊的Url 才能呼叫。所有需要有一個儲存的過程，這個建立一個文件用來儲存對應的名稱 url 用途，傳引數等。另外，專案中使用私有pods 可以很容易的區分版本，只要儲存podfile對應的私有pods 的版本號即可。即使私有私有pods 已經上傳至服務端。

三、專案的基本架構

每個BU相互獨立，但是唯一沒有解耦的是，相互的之間的呼叫需要註冊，如果使用的是CTMediator可剩下注冊這步，完全解耦。