如何進行iOS 容器化框架的基本思路分析

這期內容當中小編將會給大家帶來有關如何進行iOS 容器化框架的基本思路分析，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

前言

由本章節開始，我們將從支付寶客戶端的架構設計方案入手，細分拆解客戶端在“容器化框架設計”、“網絡優化”、“性能啟動優化”、“自動化日志收集”、“RPC 組件設計”、“移動應用監控、診斷、定位”等具體實現，帶領大家進一步了解支付寶在客戶端架構上的迭代與優化歷程。

下面將介紹支付寶 iOS 容器化框架設計的基本思路。

容器化實現概覽

在 mPaaS 開篇介紹中已經和大家分享過《模塊化與解耦式開發在螞蟻金服 mPaaS 中的實踐》：通過容器化開發框架將業務隔離成相對獨立的模塊，并著力追求模塊與模塊之間高內聚、低耦合，因此我們實現了靈活的插件式開發，并得以將業務劃分為上千個獨立工程。

mPaaS iOS 框架源自于支付寶客戶端，為了實現這種上千個工程之間的低耦合和相關依賴調用，mPaaS 框架直接接管了 App 的生命周期，負責整個 App 啟動托管、App 生命周期管理、處理與分發 UIApplication 的代理事件。

mPaaS 框架提供了容器化環境，業務開發人員在這個容器化環境中使用 微應用 和 服務 進行具體的業務需求開發。

微應用 和 服務 是 mPaaS 框架內定義的概念，主要是用來進行業務模塊間的劃分。按照是否有 UI 界面作為標準，mPaaS 框架將不同的業務模塊劃分為 微應用 和 服務。 微應用 是 APP 運行期間帶有用戶界面的業務模塊； 服務 是 APP 運行期由業務提供的輕量級抽象服務。在 mPaaS 框架中，通過 框架上下文Context 進行 微應用 與 服務 的生命周期管理。

應用生命周期管理

通過修改 main.m 函數的實現，mPaaS 框架使用ClientDelegate 類接管了 UIApplicationDelegate中各種 APP 生命周期。mPaaS 框架接入之后， ClientDelegate 完全替代了一般工程中的 AppDelegate 的角色，從而實現了整個應用的生命周期都是由框架進行管理。

為了方便用戶獲取 APP 生命周期來開發自定義功能，mPaaS 框架提供了 DTFrameworkInterface 類里面實現了 UIApplicationDelegate 中所有代理方法的等價接入方式。

只需要在 DTFrameworkInterface 的 Category 中覆蓋對應的方法即可。

例如下面常見的 UIApplicationDelegate 代理方法：

在 DTFrameworkInterface 中都提供了對應的方法：

由于 mPaaS 框架有一些自己的初始化邏輯需要實現，在 DTFrameworkInterface 中額外提供了 beforeDidFinishLaunchingWithOptions 和 afterDidFinishLaunchingWithOptions 方法，方便用戶在 APP 啟動時確定的時間執行自己的初始化代碼。

DTFrameworkInterface 在 afterDidFinis

LaunchingWithOptions 之前會啟動 BootLoader，執行 mPaaS 框架的初始化邏輯。在嵌入式操作系統中， BootLoader 的作用是初始化硬件設備，以便為最終調用操作系統內核準備好正確的環境。類似的在 mPaaS 框架中， BootLoader用來初始化整個 mPaaS 框架環境，默認實現為依次執行下面的流程：

• 創建 window

• 創建主 NavigationController

• 運行那些只運行一次就可以，并且需要率先啟動的服務

• 啟動其它所有非 lazyload 的服務

• 啟動在 ServicesMap 的 "[AUTOSTART]" 數組中指定需要自動啟動的服務分組

• 顯示主 Window

• 啟動 Launcher 微應用，顯示出首頁

這樣就完成了 mPaaS 框架的初始化和首頁的顯示。

后面將詳細介紹其中關鍵的3個概念： 微應用、 服務、 框架上下文Context。

微應用

微應用就是帶 UI 界面的獨立業務模塊，其中最特殊的一個微應用是 Launcher 微應用， Launcher 作為 APP 啟動之后第一個打開的微應用，一般用來創建 App 首頁。在 mPaaS 框架中，各個微應用之間是高度獨立、不相互依賴的。

微應用 通過 plist 配置來進行注冊。配置微應用時需要指定 delegate 對應的類名、微應用的描述 description 以及打開微應用時使用的 name。這樣 框架上下文Context 通過微應用的 name就可以打開指定的微應用。

為了方便業務開發，每個 微應用 也存在生命周期。微應用的生命周期，是模仿 iOS APP 的生命周期來做的。每個微應用需要實現自己的 DTMicroApplicationDelegate 代理，這個類似于 iOS App 中實現的 Appdelege 類。

對于具體業務開發而言 微應用 的開發和一個完整的 APP 一樣，每個 微應用 負責控制自己應用內的頁面堆棧，并根據 微應用 的生命周期執行相應的操作。在 mPaaS 框架中，所有的 微應用 都是運行在 mPaaS 框架提供的容器中，其不需要關注 APP 的生命周期。對于一些特殊的業務場景，mPaaS 支持創建微應用的多個實例。

服務

服務 與 微應用 不同地方在于其沒有 UI 界面，是在后臺執行。一旦服務啟動后，其在整個客戶端的生命周期中一直存在，因此服務一般用于給微應用提供通用服務，比如執行某個功能或者獲取數據等。

一個常見的服務是用戶登陸狀態服務，每個微應用可以通過這個服務來獲取到用戶的登錄狀態和用戶信息。

服務 也是通過 plist 配置來進行注冊。服務注冊時需要提供服務的唯一標識 name 和對應的實現類 class 類名。框架在創建 服務 時會利用 Objective-C 語言的運行時機制創建 服務 實現類的實例。 lazyLoading 用來控制是否延遲加載該類。如果是延遲加載，在框架啟動時該 服務 并不會實例化，只有在用到該 服務 時才會實例化并啟動。如果是非延遲加載，則在框架啟動時會啟動該服務。

由于服務的特殊性，在 mPaaS 中同時提供了 ServicesMap 來批量注冊類， ServicesMap 中的 [AUTOSTART] 用來說明哪些組的 服務需要在 App 啟動的時候最先啟動。

這種分級啟動服務的特點可以有效控制 APP 的啟動時間，從而提供很好的用戶體驗。

每個服務都需要實現 服務 接口:

在增加了 服務 之后，整個 App 的結構如下圖所示。后臺的服務成為各個 微應用 之間溝通的橋梁。

框架上下文 Context

通過前面的介紹，大家已經對 微應用 和 服務 有了深入的了解。在 mPaaS 框架中， 框架上下文Context 承擔了一個調度員的角色，負責各個 微應用 和 服務 的調度、通信管理，這樣就實現了每個 微應用 的打開、頁面推棧以及關閉不影響 APP 的其他 微應用 模塊。

通過 mPaaS 框架提供的 DTContext * DTContextGet() 函數可以獲取到框架上下文Context 對象 Context。

一個簡化的 Context 類實現如下：

對于業務開發人員，可以通過 框架上下文Context 獲取到主 window、啟動指定的 微應用、獲取一個 服務、動態注冊與反注冊 服務，從而實現業務之間的連接。

上述就是小編為大家分享的如何進行iOS 容器化框架的基本思路分析了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。