如何進(jìn)行iOS容器化框架的基本思路分析-創(chuàng)新互聯(lián)

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

創(chuàng)新互聯(lián)堅(jiān)信：善待客戶，將會(huì)成為終身客戶。我們能堅(jiān)持多年，是因?yàn)槲覀円恢笨芍档眯刨?。我們從不忽悠初訪客戶，我們用心做好本職工作，不忘初心，方得始終。十載網(wǎng)站建設(shè)經(jīng)驗(yàn)創(chuàng)新互聯(lián)是成都老牌網(wǎng)站營(yíng)銷服務(wù)商,為您提供做網(wǎng)站、網(wǎng)站制作、網(wǎng)站設(shè)計(jì)、H5頁面制作、網(wǎng)站制作、品牌網(wǎng)站設(shè)計(jì)、微信小程序開發(fā)服務(wù),給眾多知名企業(yè)提供過好品質(zhì)的建站服務(wù)。

前言

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

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

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

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

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

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

微應(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ù)提供的輕量級(jí)抽象服務(wù)。在 mPaaS 框架中，通過 框架上下文Context 進(jìn)行 微應(yīng)用 與 服務(wù) 的生命周期管理。

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

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

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

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

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

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

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

DTFrameworkInterface 在 afterDidFinis

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

• 創(chuàng)建 window

• 創(chuàng)建主 NavigationController

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

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

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

• 顯示主 Window

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

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

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

微應(yīng)用

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

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

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

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

服務(wù)

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

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

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

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

這種分級(jí)啟動(dòng)服務(wù)的特點(diǎn)可以有效控制 APP 的啟動(dòng)時(shí)間，從而提供很好的用戶體驗(yàn)。

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

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

框架上下文 Context

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

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

一個(gè)簡(jiǎn)化的 Context 類實(shí)現(xiàn)如下：

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

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

當(dāng)前名稱：如何進(jìn)行iOS容器化框架的基本思路分析-創(chuàng)新互聯(lián)
瀏覽地址：http://bm7419.com/article46/igihg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站收錄、面包屑導(dǎo)航、企業(yè)網(wǎng)站制作、域名注冊(cè)、品牌網(wǎng)站制作、小程序開發(fā)

廣告

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