歡迎光臨
每天分享高質量文章

一名一線開發對於App架構和組件化的思考

來自:Lobster-King

鏈接:https://github.com/Lobster-King/AppArticles/blob/master/Architecture/一名一線開發對於App架構和組件化的思考.md

寫在前面

關於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。這樣做有兩點好處:
    1.跟外部環境有效隔離,第三方庫發生問題,公司內部可控。
    2.公有庫太大,每次repo update耗時太長,國內的環境你懂的,沒有科學上網,至少一個小時過去repo也未必更新完畢。所以通用的方案是,若公司內部取用了第三方庫,按照依賴倒置的原則,建議封裝一層之後放到Basic Specs供業務方使用。

 

又來到了一年一度的QA環節。

 

Q:如何把握組件拆分粒度?

 

A:沒有一個可衡量的標準,需要結合具體業務場景,那些復用性高、功能相對獨立就可以考慮做拆分。還有需要註意的是,組件拆分不一定要抽離成pod庫,可以將有一定特性的一組通用組件打成一個pod庫(姑且定義成CommonUIKit)。我們知道pod庫最終都是生成靜態庫取用到主工程的,也就是最終都會經過鏈接的過程,pod庫過多會帶來一定的App啟動性能開銷,其次pod庫過多也會導致pod管理混亂的問題。

Q:比如一個很小的功能,就一個彈框我需要去做解耦麽,我抽成pod庫別人直接取用不就得了?

 

A:在回答之前,我們先思考兩個問題。彈框組件未來變動可能性有多大?你設計的Api是否合理,是否能夠滿足未來產品的需求?第二個問題,解耦帶來的益處能夠cover住這些可能的變動帶來的弊端?想清楚這兩個問題,我們就知道設計一個組件是否需要做解耦,是否需要用中間服務去除依賴了。

解決橫向依賴

  • 通用組件層的橫向依賴。

 

 

通過上圖可以發現,首頁組件實際只是獲取了登錄態,但登錄模塊沒有提供對應服務,則只能通過取用頭檔案的方式把該組件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:設計路由需要遵循幾個原則。

 

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

已同步到看一看
赞(0)

分享創造快樂