框架是一個APP的骨骼，核心，一個項目的所有功能以及以后的迭代都是在此基礎(chǔ)上進(jìn)行的，它是開展一個項目的至關(guān)重要的一步。如果這一步做的不好，會導(dǎo)致結(jié)構(gòu)散亂、閱讀性和擴(kuò)展性差，影響開發(fā)效率甚至導(dǎo)致代碼重構(gòu)

APP主要做哪些事情

調(diào)用網(wǎng)絡(luò)API

頁面展示

數(shù)據(jù)的本地持久化

動態(tài)部署方案

收集用戶數(shù)據(jù)，給產(chǎn)品和運營提供參考

合理地組織各業(yè)務(wù)方開發(fā)的業(yè)務(wù)模塊，以及相關(guān)基礎(chǔ)模塊

每日app的自動打包，提供給QA工程師的測試工具

架構(gòu)原則：易讀性、易維護(hù)性、易擴(kuò)展性

常見的分層架構(gòu)：視圖層、業(yè)務(wù)層、網(wǎng)絡(luò)層、數(shù)據(jù)層

所謂好架構(gòu)

有嚴(yán)格的代碼規(guī)范，結(jié)構(gòu)目錄清晰，功能模塊分類明確

注釋統(tǒng)一明確，有一致規(guī)范

避免復(fù)雜的依賴關(guān)系，確保代碼的高封裝性和高復(fù)用性，減少冗余代碼

沒有橫向依賴，盡可能少的跨層訪問

對業(yè)務(wù)方該限制的地方有限制，該靈活的地方要給業(yè)務(wù)方創(chuàng)造靈活實現(xiàn)的條件

易測試，易拓展

接口少，接口參數(shù)少

低內(nèi)存，高性能

提高模塊化程度，增加組件粒度

項目目錄結(jié)構(gòu)

1. 應(yīng)用入口（AppDelegate）

AppDelegate是應(yīng)用的代理，應(yīng)用級的事件都委托它處理，包含啟動退出、推送等事件，以及IM、支付等第三方的回調(diào)，這使得AppDelegate內(nèi)代碼龐大，錯綜復(fù)雜，十分不利于閱讀和維護(hù),因此可以新增了一個AppDelegate+AppService類別，用來處理生命周期之外的業(yè)務(wù)，AppDelegate作為事件入口，具體實現(xiàn)直接調(diào)用類別里的方法，只為更清晰

2. 功能模塊（Modules）

Modules包含了應(yīng)用內(nèi)的功能模塊，一般根據(jù)底部Tab欄劃分并關(guān)聯(lián)實體文件夾,根據(jù)需求也可以增加Resource和Service文件夾，Service封裝數(shù)據(jù)請求，VC里調(diào)用拿數(shù)據(jù)即可;至于Resource為什么在這，我認(rèn)為當(dāng)功能模塊層級較多時，每個大功能模塊都對應(yīng)許多資源，對應(yīng)到模塊內(nèi)用起來方便;當(dāng)然也可以放到最外層的Resource文件夾里，建立對應(yīng)的模塊名稱，在這兒我是選擇把公共的放到最外層Resource里，功能相關(guān)的放到模塊里的Resource文件夾內(nèi)，只為更清晰;

3. 管理模塊（Manager）

Manager的定義是全局基礎(chǔ)服務(wù)，通常使用類方法或者單例來實現(xiàn)，主要包含對應(yīng)用、用戶的管理和服務(wù)，例如網(wǎng)絡(luò)狀態(tài)監(jiān)聽，廣告頁應(yīng)用介紹頁等；用戶快速登錄退出操作以及登錄狀態(tài)的獲取等

4. 工具類（Utils）

Utils文件夾內(nèi)主要包含全局通用工具，來源于對三方框架的二次封裝，或是自己寫的工具類。在這個項目里，我封裝了帶AES加密網(wǎng)絡(luò)請求工具，全局Toast提示，廣告頁等

5. 基類（Base）

Base文件夾用來存放項目的基類，基類作用包含一些定制化的內(nèi)容，例如頁面樣式，空數(shù)據(jù)頁面等，使用基類來實現(xiàn)，可以統(tǒng)一控制，利于維護(hù)，減少冗余

6. 分類（Category）

對系統(tǒng)類、自定義類增加的類別都放在這里

7. 宏定義、頭文件（Define）

全局宏顧名思義是定義了一些全局通用宏、枚舉

一般是這幾種：工具宏定義（UtilsMacros）：比如獲取屏幕寬高，系統(tǒng)版本，顏色賦值，數(shù)據(jù)類型驗證等

接口宏定義（URLMacros）：定義服務(wù)器接口地址以及環(huán)境開關(guān)

枚舉（Enumerate）：全局的枚舉

8. 第三方庫（ThridParty）

第三方文件夾放一些第三方的類庫和對第三方封裝，比如第三方登錄、支付、IM等(靜態(tài)庫)

9. 資源文件（Resource）

主要是各種文件，json、xml、dat、圖片,視頻，聲音等

10. 支持文件（Supporting Files）

主要放 PCH，Assets.xcassets，LaunchScreen.storyboard，Info.plist，main.m等系統(tǒng)文件

11. Pods（管理第三方庫）

CocoaPods是iOS項目的依賴管理工具，開發(fā)iOS項目不可避免地要使用第三方開源庫，CocoaPods的出現(xiàn)使得我們可以節(jié)省設(shè)置和第三方開源庫的時間

模塊化

就是將一個現(xiàn)有的工程，拆分成一個個可獨立編譯的子模塊的過程,同時，需要提供一種機制，讓各個模塊間可以相互調(diào)用通信

各模塊間通過中介者M(jìn)ediator通信，使得各個模塊間沒有直接的引用。而這，也就是模塊化思想的核心,這也延伸出了一個問題,Mediator 必須知道每一個模塊的存在，這就在模塊和Mediator間產(chǎn)生了強耦合

業(yè)界給出了兩種方式：

1. 運用OC特有的語言機制，就是runtime反射調(diào)用。

2. 設(shè)計注冊機制，每一個模塊主動向Mediator注冊自己，在Mediator中統(tǒng)一通過抽象的Class類型來管理這些模塊。用戶通過模塊對應(yīng)的key向Mediator索要對應(yīng)的模塊，然后在Mediator外部自行調(diào)用模塊的功能

這兩種方式，都可以使得Mediator不再關(guān)心具體的模塊類型，使得Mediator的實現(xiàn)與模塊解耦

CTMediator的核心思路

1.CTMediator核心，負(fù)責(zé)runtime反射的核心實現(xiàn)，不需要引入其他模塊任何內(nèi)容

2,CTMediator的Category們，這些分類是跟模塊走的，有幾個模塊，就應(yīng)該有幾個Category。Category用于告訴調(diào)用者該模塊可以提供哪些功能，在CTMediator庫中，所提供的這些功能被稱為action。Category會調(diào)用CTMediator核心的runtime接口，將任務(wù)發(fā)送到對應(yīng)的target;為了能夠讓CTMediator Category中能夠真正調(diào)用到對應(yīng)模塊的功能，每個模塊還會提供一個對應(yīng)的target。target和模塊是強耦合的，target會直接引用模塊中的類型和接口

所謂基于注冊的模塊化方案，核心思想是：在Mediator中，維護(hù)一個key-vaule形式的字典。模塊所提供的所有服務(wù)（或稱功能），作為key，而其真正提供服務(wù)的模塊對象，則作為vaule。當(dāng)客戶需要特定服務(wù)時，只需要向Mediator輸入對應(yīng)的key，便可以得到其對應(yīng)的服務(wù)對象;Service則表示該模塊能夠?qū)ν馓峁┑姆?wù),Service應(yīng)該是從屬與Module的

基于注冊的方案也有其優(yōu)點：因為所有的模塊都被注冊到Mediator中，因此對于一些模塊關(guān)心的系統(tǒng)或自定義事件，在Mediator中可以很方便的傳遞給每個模塊。