組件化這兩年聽得很多了，各大廠的團(tuán)隊(duì)也都在陸續(xù)的推出自己的組件方案，如美團(tuán)、阿里、蘑菇街啊等等。
盡管每個(gè)公司的目標(biāo)是一樣的，但是實(shí)現(xiàn)方式確是相去甚遠(yuǎn)，不論是依賴注入，SPI中間層機(jī)制，還是通知、runtime消息機(jī)制，都各有所長。最重要的是，合適自己的才是最好的。
一、組件化的必要性
為什么要做，適用于當(dāng)前的小團(tuán)隊(duì)么？
1、梳理APP的邏輯，使功能更清晰，透明
2、提高代碼復(fù)用率，減少重復(fù)造輪子 don't repeat yourself
3、APP模塊間解耦，業(yè)務(wù)隔離
4、對開發(fā)人員有更大的挑戰(zhàn)，提升自身
5、模塊化是趨勢，是功能越來越復(fù)雜時(shí)的必然結(jié)果
組件化在起步時(shí)，肯定是降低了開發(fā)效率的，需要把之前的代碼梳理清楚，所以我覺得反而小項(xiàng)目起步會(huì)比較容易，更容易上手。
二、涉及到的人員
1、通用層:
目標(biāo)：
可以直接移植到到任何APP，不做定制化內(nèi)容
允許上層業(yè)務(wù)強(qiáng)依賴
一般由業(yè)內(nèi)通用的第三方和團(tuán)隊(duì)內(nèi)部達(dá)成共識的基礎(chǔ)封裝組成，如Masonry、AFNetworking，和我們的FBDevelopKit，通用base
2、通用業(yè)務(wù)層：
APP的定制化封裝，如統(tǒng)計(jì)、crash收集、loading（一般來說每個(gè)APP的loading都有所差別）、無網(wǎng)UI等，AppInfo
3、業(yè)務(wù)模塊：
APP內(nèi)的主要模塊，卡片業(yè)務(wù)，IM，iVoice，登錄注冊等
4、中間層：
這一塊比較重要，我初步是構(gòu)想為業(yè)務(wù)模塊解耦服務(wù)
通用層和通用業(yè)務(wù)層可以被直接依賴，但是模塊之間不能耦合，只能通過中間層進(jìn)行消息的傳遞（組建通信）
三、實(shí)施步驟
1、抽離現(xiàn)有庫
項(xiàng)目中common和tool等工具類，進(jìn)行優(yōu)化再封裝
2、細(xì)?；K中的使用庫
平移、下沉、回接，內(nèi)部消化對齊
3、模塊分離
4、建設(shè)中間層（router、server、notification）
因?yàn)槊總€(gè)人都會(huì)參與進(jìn)來代碼的封裝，所以先達(dá)成以下共識：
1、盡量遵循幾大原則：
單一職責(zé)原則告訴我們實(shí)現(xiàn)類要職責(zé)單一；
里氏替換原則告訴我們不要破壞繼承體系；
依賴倒置原則告訴我們要面向接口編程；
接口隔離原則告訴我們在設(shè)計(jì)接口的時(shí)候要精簡單一；
迪米特法則告訴我們要降低耦合。
而開閉原則是總綱，他告訴我們要對擴(kuò)展開放，對修改關(guān)閉。
相關(guān)文檔
2、代碼規(guī)范化，Mogo iOS代碼規(guī)范
3、使用pod管理
？依賴注入，方便移植，遠(yuǎn)端管理...
4、復(fù)雜的封裝需要文檔輸出和demo
組件通信的幾種方案：
模塊間相互解耦，那么他們之間該如何回調(diào)（跨模塊、多層），通用Domin如何傳遞，如何調(diào)用其他模塊的API？
1、依賴注入
典型的如Objection框架，我大概看了一下，基于面向接口編程的思想，暴露出category
因?yàn)轫?xiàng)目中基本是基于MVC開發(fā)，所以這種方式暫不考慮
2、基于SPI機(jī)制（中間層）
大概看了下MGJRouter，是比較好理解的一種方式
3、通知中心
4、iOS消息機(jī)制
runtime方法直接調(diào)用，缺點(diǎn)很明顯，不好調(diào)試，代碼分散；但的確很強(qiáng)大
四、終極目標(biāo)
1、提高參與人員的規(guī)范、架構(gòu)意識
2、提高并行開發(fā)效率、維護(hù)效率
