關于App架構、組件化，本文的內容不會涉及到具體代碼層面，也不會介紹怎樣使用Cocoapods去做組件化;而是站在軟件工程的角度上，結合自己多年一線開發經驗，去分析如何做App架構，如何通盤考慮什么樣的架構才是合理的，契合自身業務的，以及架構落地過程中應該規避哪些問題。

名詞解釋：本文中所提到的架構不是實際工程中代碼架構(MVC、MVVM、MVP)，確切的說是一種應用分層架構。而MVC、MVVM、MVP本質是一種軟件架構模式，是App實現過程中的一種編碼模式或者編碼規范。

iOS系統架構回顧

如上圖所示，經典的iOS系統架構分為四層，自下而上分為核心操作系統層、核心服務層、媒體層、用戶交互層。

Cocoa Touch：提供與用戶交互的相關能力，包括觸摸等，最常用的UIKit庫就在該層;除此之外還有MapKit、Address BookUI、PhotosUI等。

Media Layer：提供圖形與音視頻相關功能的接口，例如Core Animation、OpenGL ES等。

Core Services：最常用的有Core Foundation、Foundation、CFNetwork、CoreData等。提供最基礎的能力，比如數組、字典、HashMap、套接字等基礎數據結構。

Core OS：包含Mach、Kernel、BSD、Socket以及Sandbox等，它主要提供了底層操作的接口，對于應用開發來講直接用到的不是很多。

都說iOS系統牛逼，牛逼在哪?牛逼就牛逼在它有合理的架構分層，還有合理的Api設計，讓你能夠躺著就能做iOS開發，暢享絲滑!它牛逼的文件管理和文件隔離機制讓你不需要過多考慮iOS系統安全性問題，逆向開發除外，因為它總是Bug般的存在????。

Q：iOS系統架構這四層之間是如何進行通信和交互的，是否合理?

A：直接引用頭文件，調用下層提供的Api進行交互。關于是否合理，我想說的是只要Api設計的足夠合理，足夠能應對未來一段時間內SDK內部可能的變動，或者說SDK本身是一個很基礎的庫，比如Foundation庫等，我覺得直接引入頭文件無傷大雅，具體的我們稍后再討論。

設計一個合理的應用分層架構

麻雀雖小五臟俱全，要想展翅高飛，每個環節缺一不可。

關于如何設計一個合理的應用分層架構，這里我們拿蓋樓這件事做比喻，筆者干過建筑搬過磚，所以對于蓋樓流程相對來說比較熟悉。

第一步：打地基、支模板、澆灌水泥搭架子、搬磚壘墻，這是一切的基礎，高樓要屹立不倒，需要這些模塊的長久有力的支撐才行。抽象到應用架構里面，我們稱之為基礎模塊，其主要提供應用最基礎的能力。

第二步：鋪地面、造門，其中門在臥室、餐廳都可能會用到。抽象到應用架構里面，我們稱之為公共業務模塊，它主要提供了一些通用的業務模塊或者通用的組件。

第三步：給大樓賦能，臥室、餐廳、洗漱間等一應俱全，有了這些才能真正體現蓋大樓的意義。臥室等功能都要用到磚、墻、門等基礎模塊。在應用架構中，我們把臥室、廚房、洗漱等獨立功能抽象為普通業務模塊，每個業務模塊都代表一個具體的功能，業務模塊間沒有強關聯關系。

Q：除了以上的部分，是否還缺點什么東西?

A：樓層跟樓層之間需要電梯連接通信，臥室和廚房之間也需要通道進行連接。同樣對于應用來講，模塊間的通信也需要一個媒介連接起來，我們稱之為總線(Bus)。后續會詳細介紹如何實現一個總線，讓你的模塊各自分工，且模塊間的通信暢通無阻。

經過分析梳理，我們很容易能夠畫出如下的應用架構圖，圖中每層都標出了該層大致包含哪些內容。

圖中，我們按照“蓋大樓”的思路，進一步抽象羅列出了一個App應該包含哪些結構。

應用架構實施落地

在iOS平臺中，我們一般會通過Cocoapods去管理、集成自己的組件。按照工廠化生產App的理念，結合Cocoapods我畫出了如下的App集成圖。

基礎模塊：因模塊高度獨立，且高頻使用，若公司內部有多個App同時需要依賴，建議單獨創建私有庫Specs。

公共業務模塊：功能相對獨立，根據業務需求來決定是否單獨創建私有庫Specs。

Cocoapods公有庫：所有公司內部App，強烈建議不要直接引入公有Specs。這樣做有兩點好處：

跟外部環境有效隔離，第三方庫發生問題，公司內部可控。

公有庫太大，每次repo update耗時太長，國內的環境你懂的，沒有科學上網，至少一個小時過去repo也未必更新完畢。所以通用的方案是，若公司內部引用了第三方庫，按照依賴倒置的原則，建議封裝一層之后放到Basic Specs供業務方使用。在這里推薦一個科學上網工具，可自行搭建

通過上圖可以發現，首頁組件實際只是獲取了登錄態，但登錄模塊沒有提供對應服務，則只能通過引用頭文件的方式把該組件import進來，兩者耦合在一起。

利用中間件的概念，我們可以在兩個模塊之間建立一個服務層，專門用來進行模塊間的數據通信，或者非界面跳轉的小粒度組件的數據通信。這樣就很好的解決了兩個組件的橫向依賴問題。

業務模塊間的橫向依賴。

這里主要說的是那些業務功能獨立、業務線之間的橫向依賴。舉例說明，首頁模塊可能帶有業務A、業務B、業務C的入口，如果沒有做組件化，則首頁模塊連同A、B、C業務都耦合在一起。這里推薦幾個比較比較常用的路由解決方案。

• JLRoutes-URL routing library for iOS with a simple block-based API。
• BeeHive-iOS的App模塊化編程的框架實現方案，吸收了Spring框架Service的理念來實現模塊間的API耦合。
• CTMediator-基于Mediator模式和Target-Action模式。

Q：我該如何設計一個路由，用于模塊間的跳轉?

A：設計路由需要遵循幾個原則。

• 第一，便于集成，最小的改動即可實現一個路由。
• 第二，大限度把參數正確性校驗提前，能在編譯時校驗就不要在運行時校驗。
• 第三，盡可能的支持多種注冊方式，靜態注冊、動態注冊、服務配置等。

新聞名稱：一名一線開發對于App架構和組件化的思考
文章鏈接：http://www.js-pz168.com/news25/102325.html

成都網站建設公司_創新互聯，為您提供網站收錄、移動網站建設、動態網站、域名注冊、Google、搜索引擎優化

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯