總結來看，pre-main 主要流程包括：
fork 進程
加載
加載 DYLD
分析依賴，迭代加載動態庫
耗時多
5. 準備環境
準備 OC 運行時
準備 C++環境
6. main 函數
2).優化建議
盡量編譯到靜態庫中，減少 ， 耗時
盡量合并動態庫，減輕依賴關系
嚴格控制 +load 方法使用
Swift 沒有運行時
Swift 沒有
Swift 沒有數據不對齊問題
3).性能監控：如何獲取啟動起點
啟動的結束時間相對來說是比較好確定的，但如何定位啟動的起點，是啟動監控的一個難點。
對于開發環境，可以通過 Xcode 配置啟動參數，獲得 pre-main 的啟動報告：
?DYLD_PRINT_STATICS?=?1
對于線上環境，根據 主要流程的分析，我們的解決方案是：
創建動態庫 .dylib
.dylib實現+load 方法，記錄啟動起點時間
將 .dylib 放在 動態庫依賴的頭部
通過上述方法，可以在線上環境盡量地模擬出最早的啟動時間點，從而更好地監測優化效果。
2.優化post-main
post-main 階段的技術優化主要針對兩個方法的執行耗時來進行：
- (BOOL):( *) :
- (void):( *);
為什么包含 2，需要我們對 iOS App 生命周期有一定理解。從操作系統的視角來看，iOS App 本質上是一個進程。對于 Mac OS/iOS 系統，進程的生命周期狀態包括了：
而對于 ，定義了生命周期狀態：
//??UIApplication.h
typedef?NS_ENUM(NSInteger,?UIApplicationState)?{
????UIApplicationStateActive,?????//?前臺，?UIApplication響應事件
????UIApplicationStateInactive,???//?前臺，?UIApplication不響應事件
????UIApplicationStateBackground??//?后臺，?UIApplication不在屏幕上顯示
}?NS_ENUM_AVAILABLE_IOS(4_0);
組合起來的狀態機如下圖：
通過上面的討論，我們可以分析出以下問題：
post-main優化思路和建議
二、精細化策略
1. 交互優化
通過技術的實現手段，我們可以從客觀上減少啟動的絕對耗時。而從用戶視角來看，對于啟動是否流暢會受到很多心理因素的主觀影響。因此從另一方面，我們可以從優化交互的角度提升用戶體驗。
避免阻塞等待
我們都希望用戶可以盡快地使用 App，不要出現流失。但在快消費的時代，用戶的耐心是極其有限的。
因此，如果有理由需要用戶進行等待，就應該注意盡量避免產品流程是阻塞的。即使有更充足的理由必須讓用戶在阻塞狀態原地等待，也應該給用戶提供可響應的交互。
例如，在 T2 歡迎/廣告頁階段，為了避免用戶阻塞等待，應該提供明顯的「跳過」按鈕，允許用戶進行跳過操作。
如果非要用戶在這個階段等待不可，也可以花一些小心思提供可響應的交互，比如點擊觸發視覺的變化等，不要讓用戶除了等待無事可做。
增加視覺信息量
增加屏幕上視圖的信息量提供給用戶消費，轉移其注意力，降低用戶對等待的感受。
例如，在 T1 閃屏頁階段，用戶處于阻塞等待的狀態，無法跳過。而且閃屏頁是系統渲染的靜態視圖，我們無法提供動態響應。那么，我們可以通過在靜態視圖上提供更多信息量，給等待中的用戶消費。
主觀感受對比如下圖：
合理的動態提示
事實上，早期在部分高性能 設備上，App 的啟動比同水平 要快。但由于 iOS 設計了符合神經認知學的交互動畫，使得主觀感受到的時間縮短。
動畫是否「合適」，關鍵在于對場景的選擇和數量的把握。一個常見的動畫耗時約為 0.25s，對于啟動流程來說，已經可以解決或掩蓋不少問題了。
好的交互體驗和產品流程，至少應該是符合用戶預期的。給以合適的動態提示，讓用戶知道此刻使用的 App 正在發生什么，可以極大地提升用戶體驗。
例如在 T2 廣告頁階段，廣告需要占時 3 秒鐘的時間。交互上建議給與廣告消失的倒計時提示：
2.基于場景的啟動會話
根據對啟動過程的定義，我們可以列舉出一些啟動的「起點」和「終點」，比如：
啟動觸發點：
啟動終點--目標頁：
可以看出，啟動的起點和終點多種多樣，而對于啟動流程的設定，很多都是和業務場景強相關的，比如：
如何才能維護這些復雜的啟動關系ios 上拉加載更多數據，提高業務承載能力呢？我們的優化思路是基于場景創建啟動會話：
3.啟動廣告曝光和緩存策略
廣告曝光主要流程為：請求廣告接口 —> 準備廣告素材 —> 展示廣告頁，進行曝光。
在準備廣告素材環節ios 上拉加載更多數據，我們會判斷廣告素材是否命中緩存。如果命中則直接使用緩存，這樣可以明顯縮短廣告加載的時間。如果沒有命中，則開始下載廣告素材。當廣告素材超過設定的準備時長，則此次曝光不顯示。
通過以往數據量化分析，我們發現通常情況下，廣告未曝光的主要原因是由于廣告素材準備超時，且素材體積和廣告曝光率是負相關的。為了保證廣告的曝光率，我們應該盡量減少廣告素材的體積，并且提高廣告素材緩存的命中率。
下面分別介紹下我們的啟動廣告預緩存策略和啟動廣告曝光策略。
啟動廣告預緩存策略
啟動廣告曝光策略
由于 App 之前已經啟動，此時大概率已經緩存了廣告素材
由于 App 一次生命周期存在多次切回前臺，曝光 PV 可以得到提升
三、合理利用平臺機制
iOS 經過多年的迭代，提供了很多智能的平臺機制。合理利用這些機制，可以強化 App 的功能和性能。
1.內存保活
我們已經討論了冷啟動和熱啟動的區別：
因此，我們應該盡量增加熱啟動概率，并且盡量減少 App 在后臺被系統回收的概率。
iOS App 生命周期中關于系統內回收策略如下：
優化思路：
2.后臺拉起
iOS 系統提供了一些機制，可以幫助我們實現在用戶不感知的情況下拉起 App。合適的拉起策略，可以優化 App 性能和功能表現，比如提升當日首啟熱啟動的概率；在后臺準備更新一些數據，如更新 PUSH token、準備啟動廣告素材等。
iOS 常見的后臺拉起機制包括：
使用后臺機制時，有以下幾點需要注意：
四、結構化定制
頁面棧/樹優化
App 通過頁面進行組織，在啟動過程中，我們需要構建根頁面棧。
由上分析我們知道，App 存在后臺拉起，我們建議在首次進入前臺時才進行頁面渲染操作。但另一方面，根頁面棧是 App 的基本結構，應該作為核心啟動流程。因此我們提出以下解決方案：
0x3
結語
經過團隊 3 個月的持續優化治理，馬蜂窩 iOS App 的啟動優化取得了一些成果：
ios App 的啟動治理乃至性能管理，是一個長期且艱巨的過程，需要各位開發同學具備良好的對平臺和對代碼性能的理解意識。其次，性能問題也常常是一個復雜的系統性問題，需要嚴謹地分析和推理，在此感謝支持以上工作的馬蜂窩數據分析師。最后，這項工作需要建立完善的性能監控機制，持續跟蹤，主動解決。
One
More Thing