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

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

iOS系統(tǒng)架構(gòu)回顧

如上圖所示，經(jīng)典的iOS系統(tǒng)架構(gòu)分為四層，自下而上分為核心操作系統(tǒng)層、核心服務(wù)層、媒體層、用戶交互層。

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

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

Core Services：最常用的有Core Foundation、Foundation、CFNetwork、CoreData等。提供最基礎(chǔ)的能力，比如數(shù)組、字典、HashMap、套接字等基礎(chǔ)數(shù)據(jù)結(jié)構(gòu)。

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

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

Q：iOS系統(tǒng)架構(gòu)這四層之間是如何進行通信和交互的，是否合理?

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

設(shè)計一個合理的應(yīng)用分層架構(gòu)

麻雀雖小五臟俱全，要想展翅高飛，每個環(huán)節(jié)缺一不可。

關(guān)于如何設(shè)計一個合理的應(yīng)用分層架構(gòu)，這里我們拿蓋樓這件事做比喻，筆者干過建筑搬過磚，所以對于蓋樓流程相對來說比較熟悉。

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

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

第三步：給大樓賦能，臥室、餐廳、洗漱間等一應(yīng)俱全，有了這些才能真正體現(xiàn)蓋大樓的意義。臥室等功能都要用到磚、墻、門等基礎(chǔ)模塊。在應(yīng)用架構(gòu)中，我們把臥室、廚房、洗漱等獨立功能抽象為普通業(yè)務(wù)模塊，每個業(yè)務(wù)模塊都代表一個具體的功能，業(yè)務(wù)模塊間沒有強關(guān)聯(lián)關(guān)系。

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

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

經(jīng)過分析梳理，我們很容易能夠畫出如下的應(yīng)用架構(gòu)圖，圖中每層都標出了該層大致包含哪些內(nèi)容。

圖中，我們按照“蓋大樓”的思路，進一步抽象羅列出了一個App應(yīng)該包含哪些結(jié)構(gòu)。

應(yīng)用架構(gòu)實施落地

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

基礎(chǔ)模塊：因模塊高度獨立，且高頻使用，若公司內(nèi)部有多個App同時需要依賴，建議單獨創(chuàng)建私有庫Specs。

公共業(yè)務(wù)模塊：功能相對獨立，根據(jù)業(yè)務(wù)需求來決定是否單獨創(chuàng)建私有庫Specs。

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

跟外部環(huán)境有效隔離，第三方庫發(fā)生問題，公司內(nèi)部可控。

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

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

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

業(yè)務(wù)模塊間的橫向依賴。

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

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

Q：我該如何設(shè)計一個路由，用于模塊間的跳轉(zhuǎn)?

A：設(shè)計路由需要遵循幾個原則。

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

新聞名稱：一名一線開發(fā)對于App架構(gòu)和組件化的思考
文章鏈接：http://redsoil1982.com.cn/news25/102325.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站收錄、移動網(wǎng)站建設(shè)、動態(tài)網(wǎng)站、域名注冊、Google、搜索引擎優(yōu)化

廣告

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