三国杀武将|手游三国杀边锋版

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

suiling 2019-04-28 10:59:03 5563
本文來自 一線搬磚工人 ,作者 suiling

寫在前面

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

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

iOS系統架構回顧

image.png

如上圖所示,經典的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)。后續會詳細介紹如何實現一個總線,讓你的模塊各自分工,且模塊間的通信暢通無阻。

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

image.png

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

應用架構實施落地

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

image.png

  • 基礎模塊:因模塊高度獨立,且高頻使用,若公司內部有多個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住這些可能的變動帶來的弊端?想清楚這兩個問題,我們就知道設計一個組件是否需要做解耦,是否需要用中間服務去除依賴了。

解決橫向依賴

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

image.png

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

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

  • 業務模塊間的橫向依賴。

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

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

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

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

未完待續  
文章首發GitHub

作者:一線搬磚工人
鏈接:https://www.jianshu.com/p/ba08804ce056

三国杀武将