摘要：馬蜂窩旅游歷經(jīng)幾十個(gè)版本的開發(fā)迭代，在啟動(dòng)流程上積累了一定的技術(shù)債務(wù)。我們定義啟動(dòng)廣告曝光率啟動(dòng)廣告曝光啟動(dòng)廣告加載。

增長、活躍、留存是移動(dòng) App 的常見核心指標(biāo)，直接反映一款 App 甚至一個(gè)互聯(lián)網(wǎng)公司運(yùn)行的健康程度和發(fā)展動(dòng)能。啟動(dòng)流程的體驗(yàn)決定了用戶的第一印象，在一定程度上影響了用戶活躍度和留存率。因此，確保啟動(dòng)流程的良好體驗(yàn)至關(guān)重要。

「馬蜂窩旅游」App 是馬蜂窩為用戶提供服務(wù)的主要陣地，其承載的業(yè)務(wù)模塊不斷豐富和完善，產(chǎn)品功能日趨復(fù)雜，已經(jīng)逐漸成長為一個(gè)集合旅行信息、出行決策、自由行產(chǎn)品及服務(wù)交易的一站式移動(dòng)平臺(tái)。

「馬蜂窩旅游」iOS App 歷經(jīng)幾十個(gè)版本的開發(fā)迭代，在啟動(dòng)流程上積累了一定的技術(shù)債務(wù)。為了帶給用戶更流暢的使用體驗(yàn)，我們團(tuán)隊(duì)實(shí)施了數(shù)月的專項(xiàng)治理，也總結(jié)出一些 iOS 啟動(dòng)治理方面的實(shí)踐經(jīng)驗(yàn)，借由本文和大家分享。

要分析和解決啟動(dòng)問題，我們首先需要界定啟動(dòng)的內(nèi)涵和邊界，從哪開始、到哪結(jié)束，中間經(jīng)歷了哪些階段和過程。以不同視角去觀察時(shí)，可以得出不同結(jié)論。

App 啟動(dòng)原本就是程序啟動(dòng)的技術(shù)過程。作為開發(fā)人員，我們很自然地更愿意從技術(shù)階段去看待和定義啟動(dòng)的流程。

App 啟動(dòng)的方式分為冷啟動(dòng)和熱啟動(dòng)兩種。簡單來說，冷啟動(dòng)發(fā)生時(shí)后臺(tái)是沒有這個(gè)應(yīng)用的進(jìn)程的，程序需要從頭開始，經(jīng)過漫長的準(zhǔn)備和加載過程，最終運(yùn)行起來。而熱啟動(dòng)則是在后臺(tái)已有該應(yīng)用進(jìn)程的情況下發(fā)生的，系統(tǒng)不需要重新創(chuàng)建和初始化。因此，從技術(shù)視角討論啟動(dòng)治理時(shí)，主要針對(duì)冷啟動(dòng)。

從技術(shù)視角出發(fā)，分析 iOS 的啟動(dòng)過程，主要分為兩個(gè)階段：

pre-main: main() 函數(shù)是程序執(zhí)行入口，從進(jìn)程創(chuàng)建到進(jìn)入 main 函數(shù)稱為 premain 階段, 主要包括了環(huán)境準(zhǔn)備、資源加載等操作；

post-main: main() 函數(shù)到-didFinishLaunchWithOptions:方法執(zhí)行結(jié)束。該階段已獲得代碼執(zhí)行控制權(quán)，是我們治理的主要部分。

??????????????????

??+----------------X------------------------------------X--------->

start?????????????main???????????????????-didFinishLaunchWithOptions:

iOS App 是面向終端用戶的產(chǎn)品，因此衡量啟動(dòng)的最終標(biāo)準(zhǔn)還是要從用戶視角出發(fā)。

從用戶視角定義啟動(dòng)，主要以用戶主觀視覺為依據(jù)，以頁面流程為標(biāo)準(zhǔn)。這樣看來，常見的 App 啟動(dòng)可以分為三個(gè)階段：

T1：閃屏頁

閃屏頁是啟動(dòng)過程中的靜態(tài)展示頁。在冷啟動(dòng)的過程中，App 還沒有運(yùn)行起來，需要經(jīng)歷環(huán)境準(zhǔn)備和初始化的過程。這個(gè)過渡階段需要展示一些視圖，供阻塞等待中的用戶瀏覽。

iOS 系統(tǒng) (SpringBoard) 根據(jù) App Bundle 目錄下的 Info.plist 中"Launch screen interface file base name"字段的值，找到所指定的 xib 文件，加載渲染展示該視圖。

閃屏頁的展示是系統(tǒng)行為，因此無法控制；加載的是 xib 描述文件，無法定制動(dòng)態(tài)展示邏輯，因此是靜態(tài)展示。

對(duì)應(yīng)技術(shù)啟動(dòng)階段的 pre-main 階段

T2(可選)：歡迎頁（廣告）

App 運(yùn)行后根據(jù)特定的業(yè)務(wù)邏輯展示的第一個(gè)頁面。常見的有廣告頁和裝機(jī)引導(dǎo)流程。

歡迎頁是業(yè)務(wù)定制的，因此可根據(jù)業(yè)務(wù)需要優(yōu)化展示策略，該階段本身也是可選的。

T3：目標(biāo)頁?(落地頁)?

App 啟動(dòng)的目標(biāo)頁。

可以是首頁或特定的落地頁

目標(biāo)頁的加載渲染渲染完成標(biāo)志著 T3 階段的結(jié)束，也標(biāo)志著啟動(dòng)流程的結(jié)束。

啟動(dòng)治理的最終目標(biāo)是提升用戶體驗(yàn)，在這樣的思想下，本文關(guān)于啟動(dòng)流程的討論主要圍繞用戶視角進(jìn)行。

對(duì) iOS 啟動(dòng)的治理，本質(zhì)上是對(duì)應(yīng)用性能優(yōu)化 (App Performance Management) 的過程，其基本的方法論可以歸納為：

界定問題

準(zhǔn)確描述現(xiàn)象，確定問題的邊界

確定量化評(píng)價(jià)手段，明確關(guān)鍵指標(biāo)

分析問題

分析問題產(chǎn)生的主要原因，根本原因

確定問題的重要性，優(yōu)先級(jí)

性能問題可能是單點(diǎn)的短板，也可能是復(fù)雜的系統(tǒng)性問題，切忌「頭痛醫(yī)頭，腳痛醫(yī)腳」。要嚴(yán)謹(jǐn)全面地分析問題，找到主要原因、根本原因予以優(yōu)先解決

解決問題

確定解題的具體技術(shù)方案

根據(jù)關(guān)鍵指標(biāo)量化成果

對(duì)問題進(jìn)行總結(jié)，積累沉淀

持續(xù)監(jiān)控

性能問題是持續(xù)的，長期的

對(duì)關(guān)鍵技術(shù)指標(biāo)建立長效的監(jiān)控機(jī)制，確保增量能被及時(shí)反饋，予以處理

1. 啟動(dòng)耗時(shí)

啟動(dòng)耗時(shí)是衡量啟動(dòng)性能的核心指標(biāo)，因?yàn)樗苯佑绊懥擞脩趔w驗(yàn)并對(duì)用戶轉(zhuǎn)化率產(chǎn)生影響。

對(duì)啟動(dòng)耗時(shí)指標(biāo)的拆解有助于細(xì)粒度地監(jiān)控啟動(dòng)過程，幫助找到問題環(huán)節(jié)。具體可以拆解為：

技術(shù)啟動(dòng)耗時(shí)指標(biāo)

pre-main

core-postmain

主觀啟動(dòng)耗時(shí)指標(biāo)

T1_duration? ：從程序運(yùn)行起點(diǎn)到主視窗可見

T2_duration

T3_duration

total_duration

根據(jù)對(duì)馬蜂窩 App 用戶的行為數(shù)據(jù)分析確認(rèn)，我們得到以下結(jié)論：

啟動(dòng)耗時(shí)和啟動(dòng)流失率正相關(guān)

啟動(dòng)耗時(shí)和次日留存負(fù)相關(guān)

2.啟動(dòng)流失率

1). 如何定義啟動(dòng)流失

用戶視角的啟動(dòng)流程完成前（即目標(biāo)頁渲染完成前），用戶主動(dòng)離開 App(進(jìn)入后臺(tái)，殺死 App, 切換到其他 App 等)，記做一次啟動(dòng)流失。

啟動(dòng)流失率計(jì)算公式為：

啟動(dòng) PV 流失率：啟動(dòng)流失 PV / App 首次進(jìn)入前臺(tái) PV

啟動(dòng) UV 流失率：啟動(dòng)流失 UV / DAU

UV 絕對(duì)流失率：當(dāng)日僅進(jìn)入前臺(tái)一次且流失的 UV / DAU

2)?如何定義首次進(jìn)入前臺(tái)

我們先來區(qū)分下冷啟動(dòng)，熱啟動(dòng)和首次進(jìn)入前臺(tái)的概念：

iOS App 有后臺(tái)機(jī)制，App 可在某些條件下，在用戶不感知的情況下在后臺(tái)啟動(dòng)（如后臺(tái)刷新）。由于用戶不感知，如果當(dāng)日該用戶沒有主動(dòng)進(jìn)入前臺(tái)，則不會(huì)記作活躍用戶。因此，單純的后臺(tái)啟動(dòng)不是啟動(dòng)流失率的分母。

但是當(dāng) iOS App 從后臺(tái)啟動(dòng)，并留在內(nèi)存中沒有被操作系統(tǒng)清除，而一段時(shí)間后，用戶觸發(fā) App 進(jìn)入前臺(tái)，這種情況雖然是熱啟動(dòng)，但應(yīng)被看作「首次進(jìn)入前臺(tái)」。

3)?如何定位流失的時(shí)機(jī)

根據(jù)定義，用戶主動(dòng)離開 App 則記作一次流失。從技術(shù)角度可以找到兩個(gè)點(diǎn)：

applicationdidEnterBackground

applicaitonWillTerminate

但在實(shí)踐的典型場景中我們發(fā)現(xiàn)，從用戶點(diǎn)擊 Home 鍵到程序接收到-applicationdidEnterBackground 回調(diào)存在一定的時(shí)間差，該時(shí)間差會(huì)影響到流失率的判斷。

例如，用戶在時(shí)刻 0.0s 啟動(dòng) app，啟動(dòng)總時(shí)長為 4.0s。用戶在時(shí)刻 3.8s 點(diǎn)擊了 home 鍵離開 App，則應(yīng)該記作 launch_leave = true。而程序在時(shí)刻 4.3s 接收到了-applicationDidEnterBackground 回調(diào)，此時(shí)啟動(dòng)已經(jīng)結(jié)束，獲得了啟動(dòng)耗時(shí) 4.0s。通過比較 Tleave > Tlaunch_total，則錯(cuò)誤地記為?launch_leave = false。

由此推測(cè)，這里的 delay 是設(shè)置靈敏度阻尼，消除用戶決策的擺動(dòng)。這個(gè)延時(shí)大約在 0.5s 左右。

為了避免這個(gè)誤差，我們的解決方案是利用 inactive 狀態(tài)，找到準(zhǔn)確的用戶決策起點(diǎn):

用戶即將離開前臺(tái)時(shí)，會(huì)先進(jìn)入 inactive 狀態(tài)，通過-appWillResignActive：拿到?jīng)Q策起點(diǎn)的時(shí)間戳 Tdetermine

根據(jù)用戶最終決策行為，是否確實(shí)離開，再?zèng)Q定決策 Tdetermine 是否有效

最終根據(jù)有效的 Tdetermine 作為判斷流失行為的標(biāo)準(zhǔn)，而不是-applicationdidEnterBackground 的時(shí)間點(diǎn)

3.?啟動(dòng)廣告曝光率

廣告是 App 盈利的主要手段之一。廣告曝光率直接決定了廣告點(diǎn)擊消費(fèi)率；而廣告曝光 PV 和加載 PV 直接影響了廣告售價(jià)。

我們定義：啟動(dòng)廣告曝光率 = 啟動(dòng)廣告曝光 PV / 啟動(dòng)廣告加載 PV。

其中廣告素材需要下載，素材渲染需要一定耗時(shí)，這些都會(huì)對(duì)廣告曝光率產(chǎn)生影響。進(jìn)一步來說，啟動(dòng)廣告的曝光率會(huì)受到 App 啟動(dòng)性能的影響，但更主要的是受緩存和曝光策略的影響，詳細(xì)闡述在下文「精細(xì)化策略」部分介紹。

以上，我們對(duì) iOS App 啟動(dòng)治理的思路和關(guān)鍵指標(biāo)進(jìn)行了分析和拆解，下面來說一下從技術(shù)層面和業(yè)務(wù)層面，我們對(duì)啟動(dòng)性能的優(yōu)化和流程治理分別做了哪些事情。

1.?優(yōu)化pre-main

1). pre-main?主要流程分析

在進(jìn)行該階段的優(yōu)化前，我們需要對(duì) Pre-Main 階段的過程有所了解，網(wǎng)上的文章較多，這里主要推薦兩篇 WWDC 參考文章：

App Startup Time: Past, Present, and Future（https://developer.apple.com/v...）

Optimizing App Startup Time（https://developer.apple.com/v...）

總結(jié)來看，pre-main 主要流程包括：

????1. fork 進(jìn)程

????2. 加載 executable

????3. 加載 DYLD

? ? 4. 分析依賴，迭代加載動(dòng)態(tài)庫

????? ? a. rebase

????? ? b. rebind

????? ? c. 耗時(shí)多

? ? 5. 準(zhǔn)備環(huán)境

????? ? a. 準(zhǔn)備 OC 運(yùn)行時(shí)

????? ? b. 準(zhǔn)備 C++環(huán)境

? ? 6. main 函數(shù)

2).?優(yōu)化建議

盡量少使用動(dòng)態(tài)庫

????? ? a. 盡量編譯到靜態(tài)庫中，減少 rebase，rebind 耗時(shí)

????? ? b.盡量合并動(dòng)態(tài)庫，減輕依賴關(guān)系

控制 Class 類的數(shù)量規(guī)模

由于 selector 需要在初始化時(shí)做唯一性檢查，應(yīng)盡量減少使用

少用 initializers?

????? ? a. 嚴(yán)格控制 +load 方法使用

多用 Swift?

????? ? a. Swift 沒有運(yùn)行時(shí)

????? ? b. Swift 沒有 initializers

????? ? c. Swift 沒有數(shù)據(jù)不對(duì)齊問題

3).?性能監(jiān)控：如何獲取啟動(dòng)起點(diǎn)

啟動(dòng)的結(jié)束時(shí)間相對(duì)來說是比較好確定的，但如何定位啟動(dòng)的起點(diǎn)，是啟動(dòng)監(jiān)控的一個(gè)難點(diǎn)。

對(duì)于開發(fā)環(huán)境，可以通過 Xcode 配置啟動(dòng)參數(shù)，獲得 pre-main 的啟動(dòng)報(bào)告：

DYLD_PRINT_STATICS?=?1

對(duì)于線上環(huán)境，根據(jù) premain 主要流程的分析，我們的解決方案是：

創(chuàng)建動(dòng)態(tài)庫 ABootMonitor.dylib

ABootMonitor.dylib?實(shí)現(xiàn)+load 方法，記錄啟動(dòng)起點(diǎn)時(shí)間

將 ABootMonitor.dylib 放在 executable 動(dòng)態(tài)庫依賴的頭部

通過上述方法，可以在線上環(huán)境盡量地模擬出最早的啟動(dòng)時(shí)間點(diǎn)，從而更好地監(jiān)測(cè)優(yōu)化效果。

2.?優(yōu)化post-main

post-main 階段的技術(shù)優(yōu)化主要針對(duì)兩個(gè)方法的執(zhí)行耗時(shí)來進(jìn)行：

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:

- (void)applicationDidBecomeActive:(UIApplication *)application;

為什么包含 2，需要我們對(duì) iOS App 生命周期有一定理解。從操作系統(tǒng)的視角來看，iOS App 本質(zhì)上是一個(gè)進(jìn)程。對(duì)于 Mac OS/iOS 系統(tǒng)，進(jìn)程的生命周期狀態(tài)包括了：

not-running

running?

進(jìn)程激活，可以運(yùn)行的狀態(tài)

suspend?

進(jìn)程被掛起，不可以執(zhí)行代碼，通常在 UIApplication 進(jìn)入后臺(tái)后一段時(shí)間被系統(tǒng)掛起

zombie?

進(jìn)程回收前的臨時(shí)狀態(tài)，很短暫

terminated?

進(jìn)程終止，并被清理

而對(duì)于 UIApplication，定義了生命周期狀態(tài)：

//??UIApplication.h

typedef?NS_ENUM(NSInteger,?UIApplicationState)?{
????UIApplicationStateActive,?????//?前臺(tái)，?UIApplication響應(yīng)事件
????UIApplicationStateInactive,???//?前臺(tái)，?UIApplication不響應(yīng)事件
????UIApplicationStateBackground??//?后臺(tái)，?UIApplication不在屏幕上顯示
}?NS_ENUM_AVAILABLE_IOS(4_0);

組合起來的狀態(tài)機(jī)如下圖：

通過上面的討論，我們可以分析出以下問題：

UIApplication 會(huì)因?yàn)槟撤N原因，在用戶不感知的情況下被喚起，進(jìn)程進(jìn)入 running 狀態(tài)，但停留在 iOS 的 background 狀態(tài)

每次冷啟動(dòng)都會(huì)執(zhí)行- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:，但未必進(jìn)入前臺(tái)

在 didFinishLaunchingWithOptions 中進(jìn)行大量 UI 和網(wǎng)絡(luò)請(qǐng)求等操作是不合理

post-main?優(yōu)化思路和建議

整理拆分啟動(dòng)項(xiàng)，以啟動(dòng)項(xiàng)為粒度進(jìn)行測(cè)量

啟動(dòng)項(xiàng)執(zhí)行盡量在背景線程

啟動(dòng)的過程 CPU 占用較高，占用主線程會(huì)導(dǎo)致卡頓，耗時(shí)延長，用戶體驗(yàn)不佳

啟動(dòng)項(xiàng)并發(fā)執(zhí)行

啟動(dòng)項(xiàng)延遲執(zhí)行

當(dāng) CPU 時(shí)間片跑滿時(shí)，使用多線程并發(fā)不能提高性能，反而會(huì)因?yàn)轭l繁的線程上下文切換，造成 overhead 耗時(shí)增長

盡可能將啟動(dòng)項(xiàng)延遲執(zhí)行，在時(shí)間軸上平滑，降低 CPU 利用率峰值

啟動(dòng)項(xiàng)分組

-didFinishLaunchingWithOptions 只執(zhí)行必要的核心啟動(dòng)項(xiàng)

其他啟動(dòng)項(xiàng)，在首次調(diào)用-applicationDidBecomeActive:后執(zhí)行

1. 交互優(yōu)化

通過技術(shù)的實(shí)現(xiàn)手段，我們可以從客觀上減少啟動(dòng)的絕對(duì)耗時(shí)。而從用戶視角來看，對(duì)于啟動(dòng)是否流暢會(huì)受到很多心理因素的主觀影響。因此從另一方面，我們可以從優(yōu)化交互的角度提升用戶體驗(yàn)。

避免阻塞等待

我們都希望用戶可以盡快地使用 App，不要出現(xiàn)流失。但在快消費(fèi)的時(shí)代，用戶的耐心是極其有限的。

因此，如果有理由需要用戶進(jìn)行等待，就應(yīng)該注意盡量避免產(chǎn)品流程是阻塞的。即使有更充足的理由必須讓用戶在阻塞狀態(tài)原地等待，也應(yīng)該給用戶提供可響應(yīng)的交互。

例如，在 T2 歡迎/廣告頁階段，為了避免用戶阻塞等待，應(yīng)該提供明顯的「跳過」按鈕，允許用戶進(jìn)行跳過操作。

如果非要用戶在這個(gè)階段等待不可，也可以花一些小心思提供可響應(yīng)的交互，比如點(diǎn)擊觸發(fā)視覺的變化等，不要讓用戶除了等待無事可做。

增加視覺信息量

增加屏幕上視圖的信息量提供給用戶消費(fèi)，轉(zhuǎn)移其注意力，降低用戶對(duì)等待的感受。

例如，在 T1 閃屏頁階段，用戶處于阻塞等待的狀態(tài)，無法跳過。而且閃屏頁是系統(tǒng)渲染的靜態(tài)視圖，我們無法提供動(dòng)態(tài)響應(yīng)。那么，我們可以通過在靜態(tài)視圖上提供更多信息量，給等待中的用戶消費(fèi)。

主觀感受對(duì)比如下圖：

合理的動(dòng)態(tài)提示

合適的動(dòng)畫

事實(shí)上，早期在部分高性能 Android 設(shè)備上，App 的啟動(dòng)比同水平 iDevice 要快。但由于 iOS 設(shè)計(jì)了符合神經(jīng)認(rèn)知學(xué)的交互動(dòng)畫，使得主觀感受到的時(shí)間縮短。

動(dòng)畫是否「合適」，關(guān)鍵在于對(duì)場景的選擇和數(shù)量的把握。一個(gè)常見的動(dòng)畫耗時(shí)約為 0.25s，對(duì)于啟動(dòng)流程來說，已經(jīng)可以解決或掩蓋不少問題了。

合適的提示信息

好的交互體驗(yàn)和產(chǎn)品流程，至少應(yīng)該是符合用戶預(yù)期的。給以合適的動(dòng)態(tài)提示，讓用戶知道此刻使用的 App 正在發(fā)生什么，可以極大地提升用戶體驗(yàn)。

例如在 T2 廣告頁階段，廣告需要占時(shí) 3 秒鐘的時(shí)間。交互上建議給與廣告消失的倒計(jì)時(shí)提示：

一方面，倒計(jì)時(shí)提示可以有動(dòng)態(tài) loading 的視覺效果，展現(xiàn) App 的良好運(yùn)行；

另一方面，倒計(jì)時(shí)可以讓用戶安心，主觀上耗時(shí)減少，情緒上不至于焦慮和退出。

2.?基于場景的啟動(dòng)會(huì)話

根據(jù)對(duì)啟動(dòng)過程的定義，我們可以列舉出一些啟動(dòng)的「起點(diǎn)」和「終點(diǎn)」，比如：

啟動(dòng)觸發(fā)點(diǎn)：

點(diǎn)擊 App 圖標(biāo)正常啟動(dòng)

初次安裝

點(diǎn)擊 PUSH 進(jìn)入

應(yīng)用間跳轉(zhuǎn)

3DTouch

Siri 喚起

其他

啟動(dòng)終點(diǎn)--目標(biāo)頁：

應(yīng)用首頁

指定的落地頁

可以看出，啟動(dòng)的起點(diǎn)和終點(diǎn)多種多樣，而對(duì)于啟動(dòng)流程的設(shè)定，很多都是和業(yè)務(wù)場景強(qiáng)相關(guān)的，比如：

初次安裝需要進(jìn)入裝機(jī)引導(dǎo)流程

正常啟動(dòng)需要展示廣告

PUSH 進(jìn)入可以不展示廣告，直達(dá)落地頁

其他

如何才能維護(hù)這些復(fù)雜的啟動(dòng)關(guān)系，提高業(yè)務(wù)承載能力呢？我們的優(yōu)化思路是基于場景創(chuàng)建啟動(dòng)會(huì)話：

由啟動(dòng)參數(shù)和其他條件確定啟動(dòng)場景

根據(jù)啟動(dòng)場景創(chuàng)建具體的啟動(dòng)會(huì)話

啟動(dòng)會(huì)話接管之后的啟動(dòng)流程

3.?啟動(dòng)廣告曝光和緩存策略

廣告曝光主要流程為：請(qǐng)求廣告接口 —> 準(zhǔn)備廣告素材 —> 展示廣告頁，進(jìn)行曝光。

在準(zhǔn)備廣告素材環(huán)節(jié)，我們會(huì)判斷廣告素材是否命中緩存。如果命中則直接使用緩存，這樣可以明顯縮短廣告加載的時(shí)間。如果沒有命中，則開始下載廣告素材。當(dāng)廣告素材超過設(shè)定的準(zhǔn)備時(shí)長，則此次曝光不顯示。

通過以往數(shù)據(jù)量化分析，我們發(fā)現(xiàn)通常情況下，廣告未曝光的主要原因是由于廣告素材準(zhǔn)備超時(shí)，且素材體積和廣告曝光率是負(fù)相關(guān)的。為了保證廣告的曝光率，我們應(yīng)該盡量減少廣告素材的體積，并且提高廣告素材緩存的命中率。

下面分別介紹下我們的啟動(dòng)廣告預(yù)緩存策略和啟動(dòng)廣告曝光策略。

啟動(dòng)廣告預(yù)緩存策略

廣告素材接口和廣告曝光接口分離

在可能的合適時(shí)機(jī)，下載廣告素材

??????例如后臺(tái)啟動(dòng)，后臺(tái)刷新等

盡可能地提前下發(fā)廣告素材

拉長廣告素材投放的時(shí)間窗口

常見地可提前半月下發(fā)廣告素材

對(duì)于「雙十一等大促活動(dòng)，應(yīng)盡早地下發(fā)素材

啟動(dòng)廣告曝光策略

分級(jí)的廣告曝光QoS策略

???????若業(yè)務(wù)許可，可對(duì)廣告優(yōu)先級(jí)進(jìn)行分級(jí)

對(duì)于低優(yōu)先級(jí)，應(yīng)用 cache-only 的曝光策略

對(duì)于普通優(yōu)先級(jí)，應(yīng)用 max-wait 的曝光策略

對(duì)于高優(yōu)先級(jí)，應(yīng)用 max-retry 的曝光策略

靈活的曝光時(shí)機(jī)選擇

通常我們僅在首次進(jìn)入前臺(tái)時(shí)，進(jìn)行廣告曝光，但這有一定的缺陷：

啟動(dòng)耗時(shí)長了，用戶體驗(yàn)差，啟動(dòng)流失率高

對(duì)于當(dāng)日只有一次啟動(dòng)且啟動(dòng)流失的用戶，丟了這個(gè) DAU

我們可以在 App 首次進(jìn)入前臺(tái)，和熱啟動(dòng)切回前臺(tái)時(shí)選擇時(shí)機(jī)，進(jìn)行有策略的曝光

可依據(jù)策略，在首啟時(shí)不展示廣告頁，提升用戶體驗(yàn)，DAU，減少啟動(dòng)流失

可在 App 切回時(shí)展示，提升廣告曝光 PV，和曝光率。

由于 App 之前已經(jīng)啟動(dòng)，此時(shí)大概率已經(jīng)緩存了廣告素材

由于 App 一次生命周期存在多次切回前臺(tái)，曝光 PV 可以得到提升

根據(jù)馬蜂窩 App 的統(tǒng)計(jì)分析，在激進(jìn)策略下可提升曝光 PV 約 4 倍

iOS 經(jīng)過多年的迭代，提供了很多智能的平臺(tái)機(jī)制。合理利用這些機(jī)制，可以強(qiáng)化 App 的功能和性能。

1.?內(nèi)存?；?/strong>