如何進(jìn)行iOS容器化框架的基本思路分析

這期內(nèi)容當(dāng)中小編將會給大家?guī)碛嘘P(guān)如何進(jìn)行iOS 容器化框架的基本思路分析,文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述,閱讀完這篇文章希望大家可以有所收獲。

我們擁有十年網(wǎng)頁設(shè)計和網(wǎng)站建設(shè)經(jīng)驗,從網(wǎng)站策劃到網(wǎng)站制作,我們的網(wǎng)頁設(shè)計師為您提供的解決方案。為企業(yè)提供網(wǎng)站制作、成都網(wǎng)站建設(shè)、微信開發(fā)、微信小程序、手機(jī)網(wǎng)站制作設(shè)計HTML5建站、等業(yè)務(wù)。無論您有什么樣的網(wǎng)站設(shè)計或者設(shè)計方案要求,我們都將富于創(chuàng)造性的提供專業(yè)設(shè)計服務(wù)并滿足您的需求。

前言

由本章節(jié)開始,我們將從支付寶客戶端的架構(gòu)設(shè)計方案入手,細(xì)分拆解客戶端在“容器化框架設(shè)計”、“網(wǎng)絡(luò)優(yōu)化”、“性能啟動優(yōu)化”、“自動化日志收集”、“RPC 組件設(shè)計”、“移動應(yīng)用監(jiān)控、診斷、定位”等具體實現(xiàn),帶領(lǐng)大家進(jìn)一步了解支付寶在客戶端架構(gòu)上的迭代與優(yōu)化歷程。

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

容器化實現(xiàn)概覽

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

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

mPaaS 框架提供了容器化環(huán)境,業(yè)務(wù)開發(fā)人員在這個容器化環(huán)境中使用 微應(yīng)用 和 服務(wù) 進(jìn)行具體的業(yè)務(wù)需求開發(fā)。

如何進(jìn)行iOS 容器化框架的基本思路分析

微應(yīng)用 和 服務(wù) 是 mPaaS 框架內(nèi)定義的概念,主要是用來進(jìn)行業(yè)務(wù)模塊間的劃分。按照是否有 UI 界面作為標(biāo)準(zhǔn),mPaaS 框架將不同的業(yè)務(wù)模塊劃分為 微應(yīng)用 和 服務(wù)。 微應(yīng)用 是 APP 運(yùn)行期間帶有用戶界面的業(yè)務(wù)模塊; 服務(wù) 是 APP 運(yùn)行期由業(yè)務(wù)提供的輕量級抽象服務(wù)。在 mPaaS 框架中,通過 框架上下文Context 進(jìn)行 微應(yīng)用 與 服務(wù) 的生命周期管理。

應(yīng)用生命周期管理

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

如何進(jìn)行iOS 容器化框架的基本思路分析

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

只需要在 DTFrameworkInterface 的 Category 中覆蓋對應(yīng)的方法即可。

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

如何進(jìn)行iOS 容器化框架的基本思路分析

在 DTFrameworkInterface 中都提供了對應(yīng)的方法:

如何進(jìn)行iOS 容器化框架的基本思路分析

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

如何進(jìn)行iOS 容器化框架的基本思路分析

DTFrameworkInterface 在 afterDidFinis

LaunchingWithOptions 之前會啟動 BootLoader,執(zhí)行 mPaaS 框架的初始化邏輯。在嵌入式操作系統(tǒng)中, BootLoader 的作用是初始化硬件設(shè)備,以便為最終調(diào)用操作系統(tǒng)內(nèi)核準(zhǔn)備好正確的環(huán)境。類似的在 mPaaS 框架中, BootLoader用來初始化整個 mPaaS 框架環(huán)境,默認(rèn)實現(xiàn)為依次執(zhí)行下面的流程:

  • 創(chuàng)建 window

  • 創(chuàng)建主 NavigationController

  • 運(yùn)行那些只運(yùn)行一次就可以,并且需要率先啟動的服務(wù)

  • 啟動其它所有非 lazyload 的服務(wù)

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

  • 顯示主 Window

  • 啟動 Launcher 微應(yīng)用,顯示出首頁

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

后面將詳細(xì)介紹其中關(guān)鍵的3個概念: 微應(yīng)用、 服務(wù)、 框架上下文Context。

微應(yīng)用

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

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

如何進(jìn)行iOS 容器化框架的基本思路分析

為了方便業(yè)務(wù)開發(fā),每個 微應(yīng)用 也存在生命周期。微應(yīng)用的生命周期,是模仿 iOS APP 的生命周期來做的。每個微應(yīng)用需要實現(xiàn)自己的 DTMicroApplicationDelegate 代理,這個類似于 iOS App 中實現(xiàn)的 Appdelege 類。

如何進(jìn)行iOS 容器化框架的基本思路分析

對于具體業(yè)務(wù)開發(fā)而言 微應(yīng)用 的開發(fā)和一個完整的 APP 一樣,每個 微應(yīng)用 負(fù)責(zé)控制自己應(yīng)用內(nèi)的頁面堆棧,并根據(jù) 微應(yīng)用 的生命周期執(zhí)行相應(yīng)的操作。在 mPaaS 框架中,所有的 微應(yīng)用 都是運(yùn)行在 mPaaS 框架提供的容器中,其不需要關(guān)注 APP 的生命周期。對于一些特殊的業(yè)務(wù)場景,mPaaS 支持創(chuàng)建微應(yīng)用的多個實例。

如何進(jìn)行iOS 容器化框架的基本思路分析

服務(wù)

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

一個常見的服務(wù)是用戶登陸狀態(tài)服務(wù),每個微應(yīng)用可以通過這個服務(wù)來獲取到用戶的登錄狀態(tài)和用戶信息。

服務(wù) 也是通過 plist 配置來進(jìn)行注冊。服務(wù)注冊時需要提供服務(wù)的唯一標(biāo)識 name 和對應(yīng)的實現(xiàn)類 class 類名??蚣茉趧?chuàng)建 服務(wù) 時會利用 Objective-C 語言的運(yùn)行時機(jī)制創(chuàng)建 服務(wù) 實現(xiàn)類的實例。 lazyLoading 用來控制是否延遲加載該類。如果是延遲加載,在框架啟動時該 服務(wù) 并不會實例化,只有在用到該 服務(wù) 時才會實例化并啟動。如果是非延遲加載,則在框架啟動時會啟動該服務(wù)。

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

如何進(jìn)行iOS 容器化框架的基本思路分析

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

每個服務(wù)都需要實現(xiàn) 服務(wù) 接口:

如何進(jìn)行iOS 容器化框架的基本思路分析

在增加了 服務(wù) 之后,整個 App 的結(jié)構(gòu)如下圖所示。后臺的服務(wù)成為各個 微應(yīng)用 之間溝通的橋梁。

如何進(jìn)行iOS 容器化框架的基本思路分析

框架上下文 Context

通過前面的介紹,大家已經(jīng)對 微應(yīng)用 和 服務(wù) 有了深入的了解。在 mPaaS 框架中, 框架上下文Context 承擔(dān)了一個調(diào)度員的角色,負(fù)責(zé)各個 微應(yīng)用 和 服務(wù) 的調(diào)度、通信管理,這樣就實現(xiàn)了每個 微應(yīng)用 的打開、頁面推棧以及關(guān)閉不影響 APP 的其他 微應(yīng)用 模塊。

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

一個簡化的 Context 類實現(xiàn)如下:

如何進(jìn)行iOS 容器化框架的基本思路分析

對于業(yè)務(wù)開發(fā)人員,可以通過 框架上下文Context 獲取到主 window、啟動指定的 微應(yīng)用、獲取一個 服務(wù)、動態(tài)注冊與反注冊 服務(wù),從而實現(xiàn)業(yè)務(wù)之間的連接。

上述就是小編為大家分享的如何進(jìn)行iOS 容器化框架的基本思路分析了,如果剛好有類似的疑惑,不妨參照上述分析進(jìn)行理解。如果想知道更多相關(guān)知識,歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。

網(wǎng)站名稱:如何進(jìn)行iOS容器化框架的基本思路分析
網(wǎng)頁鏈接:http://muchs.cn/article20/jehcco.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供網(wǎng)站改版、網(wǎng)站收錄、自適應(yīng)網(wǎng)站搜索引擎優(yōu)化、云服務(wù)器、網(wǎng)站導(dǎo)航

廣告

聲明:本網(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)

網(wǎng)站托管運(yùn)營