前言

當用戶按下home鍵的時候，iOS的App並不會馬上被kill掉，還會繼續存活若干時間。理想情況下，使用者點選App的圖示再次回來的時候，App幾乎不需要做什麼，就可以還原到退出前的狀態，繼續為使用者服務。這種持續存活的情況下啟動App，我們稱為熱啟動，相對而言冷啟動就是App被kill掉以後一切從頭開始啟動的過程。我們這裡只討論App冷啟動的情況。

對於冷啟動來說，啟動時間是指從使用者點選 APP 那一刻開始到使用者看到第一個介面這中間的時間。我們進行優化的時候，我們將啟動時間分為 pre-main 時間和 main 函式到第一個介面渲染完成時間這兩個部分。

因為 APP 的入口在 main 函式 ，在 main 函式之後我們的程式碼才會執行。

這裡有兩個階段

1. pre-main階段

1.1. 載入應用的可執行檔案

1.2. 載入動態連結庫載入器dyld（dynamic loader）

1.3. dyld遞迴載入應用所有依賴的dylib（dynamic library 動態連結庫）

2. main()階段

2.1. dyld呼叫main() 

2.2. 呼叫UIApplicationMain() 

2.3. 呼叫applicationWillFinishLaunching

2.4. 呼叫didFinishLaunchingWithOptions

我們把 pre-main階段稱為 t1，main()階段一直到首個頁面載入完成稱為 t2。

t1 時間的優化分析

t1部分主要參考自APP啟動優化的一次實踐

其中 t1蘋果提供了內建的測量方法, Xcode 中 Edit scheme -> Run -> Auguments 將環境變數 DYLD_PRINT_STATISTICS 設為 1

123456789

//結果為Total pre-main time: 1.4seconds (100.0%)dylib loading time: 1.3seconds (89.4%)rebase/binding time:  36.75milliseconds (2.5%)ObjC setup time:  35.65milliseconds (2.4%)initializer time:   80.97milliseconds (5.5%)slowest intializers :libSystem.B.dylib :  12.63milliseconds (0.8%)//解讀

1、main()函式之前總共使用了1.4s

2、在94.33ms中，載入動態庫用了1.3s，指標重定位使用了36.75ms，ObjC類初始化使用了35.65ms，各種初始化使用了80.97ms。

3、在初始化耗費的80.97ms中，用時最多的初始化是libSystem.B.dylib。

可以看到,我的 dylib loading time 花費了 1.3s時間，

其中各部分的作用是

載入dylib

分析每個dylib（大部分是iOS系統的），找到其Mach-O檔案，

開啟並讀取驗證有效性，找到程式碼簽名註冊到核心，

最後對dylib的每個segment呼叫mmap()。

rebase/bind

dylib載入完成之後，它們處於相互獨立的狀態，需要繫結起來。

在dylib的載入過程中，系統為了安全考慮，引入了ASLR（Address Space Layout Randomization）技術和程式碼簽名。

由於ASLR的存在，映象（Image，包括可執行檔案、dylib和bundle）會在隨機的地址上載入，和之前指標指向的地址（preferred_address）會有一個偏差（slide），dyld需要修正這個偏差，來指向正確的地址。

Rebase在前，Bind在後，Rebase做的是將映象讀入記憶體，修正映象內部的指標，效能消耗主要在IO。

Bind做的是查詢符號表，設定指向映象外部的指標，效能消耗主要在CPU計算。

OC setup

OC的runtime需要維護一張類名與類的方法列表的全域性表。

dyld做了如下操作：

對所有宣告過的OC類，將其註冊到這個全域性表中（class registration）

將category的方法插入到類的方法列表中（category registration）

檢查每個selector的唯一性（selector uniquing）

如果在各個 OC 類別的 ‘load’方法裡做了不少事情(如在裡面使用 Method swizzle),那麼這是pre-main階段最耗時的部分。dyld執行APP的初始化函式，呼叫每個OC類的+load方法，呼叫C++的構造器函式（attribute((constructor))修飾），建立非基本型別的C++靜態全域性變數，然後執行main函式。

優化思路是

1. 移除不需要用到的動態庫

2. 移除不需要用到的類

3. 合併功能類似的類和擴充套件

4. 儘量避免在+load方法裡執行的操作，可以推遲到+initialize方法中。

t2 時間的優化分析

t2使用了來自NewPan大大 的打點計時器BLStopwatch

檢測耗時

可以看到，我的 APP 載入時間並沒有很慢，但是也想看一看有沒有優化的空間。

在 didFinishLaunchingWithOptions 方法裡我們一般都有以下的邏輯：

初始化第三方 SDK

配置 APP 執行需要的環境

自己的一些工具類的初始化

...

這裡主要參考[iOS]一次立竿見影的啟動時間優化

從優化圖可以看到，我的應用的跳轉邏輯是 開啟 -> 廣告頁 -> 首頁，首頁的UI 架構是:

UITabBarC管理一堆 UINavigationC

但是如果 UI 架構如上，並且在didFinishLaunchingWithOptions裡面設定了根檢視

123456789101112

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {NSLog(@"didFinishLaunchingWithOptions 開始執行");self.window = [[UIWindow alloc] initWithFrame:[UIScreen mainScreen].bounds];TestTabBarController *tabBarVc = [TestTabBarController new];self.window.rootViewController = tabBarVc;[self.window makeKeyAndVisible];NSLog(@"didFinishLaunchingWithOptions 跑完了");returnYES;}

然後我們來到 TestTabBarController 裡的 viewDidLoad方法裡進行它的 viewControllers 的設定，然後再進入到每個 viewController 的 viewDidLoad 方法裡進行更多的初始化操作。那麼你覺得從 didFinishLaunchingWithOptions 到最後顯示展示的 viewController 的 viewDidLoad 這些方法的執行順序是怎麼樣的呢？

didFinishLaunchingWithOptions 開始執行 

開始載入 TestTabBarController 的 viewDidLoad

didFinishLaunchingWithOptions 跑完了

開始載入 TestViewController 的 viewDidLoad, 然後執行一堆初始化的操作

在TestTabBarController 中操作了 TestViewController 的 view 的話，那麼呼叫順序將會是這樣：

didFinishLaunchingWithOptions 開始執行 

開始載入 TestTabBarController 的 viewDidLoad

開始載入 TestViewController 的 viewDidLoad, 然後執行一堆初始化的操作

didFinishLaunchingWithOptions 跑完了

這樣的問題就是當我們把介面的初始化、網路請求、資料解析、檢視渲染等操作放在了viewDidLoad 方法裡，這樣一來每次啟動 APP 的時候，在使用者看到第一個頁面之前，我們要把這些事件全部都處理完，才會進入到檢視渲染階段。

一般來說，我們放到didFinishLaunchingWithOptions執行的程式碼，有很多初始化操作，如日誌，統計，SDK配置等。儘量做到只放必需的，其他的可以延遲到MainViewController展示完成viewDidAppear以後。

* 日誌、統計等必須在 APP 一啟動就最先配置的事件

* 專案配置、環境配置、使用者資訊的初始化 、推送、IM等事件

* 其他 SDK 和配置事件

• 第一類，必須第一時間啟動，仍然把它留在 didFinishLaunchingWithOptions 裡啟動。

• 第二類，這些功能在使用者進入 APP 主體的之前是必須要載入完的，我把他放到廣告頁面的viewDidAppear啟動。

• 第三類，由於啟動時間不是必須的，所以我們可以放在第一個介面的 viewDidAppear 方法裡，這裡完全不會影響到啟動時間。

優化後

這是優化後的啟動時間

優化思路

梳理各個三方庫，找到可以延遲載入的庫，做延遲載入處理，比如放到首頁控制器的viewDidAppear方法裡。

梳理業務邏輯，把可以延遲執行的邏輯，做延遲執行處理。比如檢查新版本、註冊推送通知等邏輯。

避免複雜/多餘的計算。

避免在首頁控制器的viewDidLoad和viewWillAppear做太多事情，這2個方法執行完，首頁控制器才能顯示，部分可以延遲建立的檢視應做延遲建立/懶載入處理。

採用效能更好的API。

首頁控制器用純程式碼方式來構建。

另：[iOS]一次立竿見影的啟動時間優化 提到了使用一個工具類來管理的方法，可以比較方便的管理優化。

總結

相關推薦