iOS開發系列之性能優化（中）

接上篇，本篇主要記錄我在程序啓動時間優化上的一些探索。

要談論時間優化，就要先了解程序啓動的過程和耗時的緣由，而後針對性的進行優化。

一、程序啓動過程

程序的啓動分爲冷啓動和熱啓動兩種模式，其中冷啓動是從程序被殺死後加載起來的過程，熱啓動是從後臺到前臺的過程。相比之下，熱啓動是包含在冷啓動裏，而且比冷啓動少了部分加載過程的，因此，咱們日常說的啓動優化，通常都是針對冷啓動的。

從點擊程序的圖標，到首頁渲染完成顯示到用戶眼前，主要有三個階段。

1.一、階段一：main 函數以前

該階段主要進行動態連接庫 (dylib) 和自身 App 可執行文件的加載。

其中動態連接庫包括：iOS 中用到的全部系統 framework，加載 OC runtime 方法的 libobjc，系統級別的 libSystem，例如 libdispatch(GCD) 和 libsystem_blocks (Block)。

1.二、階段二：main 函數到首頁加載以前

該階段主要執行 main 函數到 applicationWillFinishLaunching 方法結束。

1.三、階段三：首頁開始加載到渲染完成

該階段主要執行首頁界面 viewDidLoad 方法和 UITabBarController 第一個子控制器 viewWillAppear 裏的代碼。

二、耗時產生緣由

2.一、階段一里可能產生耗時的有：

• 加載大量動態連接庫；

• 註冊大量Objc類 、初始化類對象 (Objc 的 +load 方法)；

• 加載大量分類裏的方法；

• 加載大量 C++ 靜態對象；

• 執行大量聲明爲 attribute((constructor)) 的C函數。

2.二、階段二里可能產生耗時的有：

• 在 applicationWillFinishLaunching 執行了 UITabBarController 以及 子控制器的建立，並在 viewDidLoad 方法裏執行了大量的耗時操做；

• 大量第三方應用的配置和啓動項的累積；

2.三、階段三裏可能產生耗時的有：

• 在 UITabBarController 第一個子控制器的 viewWillAppear 方法裏執行了大量的耗時操做；

三、啓動時間優化

3.一、針對階段一的優化：

• 減小非系統庫的依賴、合併不是系統庫，蘋果最多支持6個非系統的動態庫合併爲一個；

• 按期清理項目裏不使用的類和方法，檢測工具可使用AppCode，關於AppCode的使用請參考這篇文章: AppCode使用介紹；

• 將沒必要須在+load方法中作的事情延遲到+initialize中，關於兩者的區別能夠參考這篇文章；

• 減小分類和分類裏方法的數量；

• 儘可能不要用 C++ 虛函數；

• 刪減一些無用的靜態變量。

3.二、針對階段二的優化：

• 對啓動項和第三方應用配置根據優先級區分，部分不須要在程序啓動就初始化的配置，進行延後處理；

• 減小在viewDidLoad 裏的耗時處理；

3.三、針對階段三的優化：

• UITabBarController 第一個子控制器裏的一些耗時操做能夠放到 viewDidAppear 方法中，先把界面加載出來，而後再拿到數據刷新界面；

• 增長廣告頁，在這個時間內準備好首屏頁面和數據；

四、耗時檢測工具

• Xcode自帶的Time Profiler，具體操做能夠參考這篇文章；

• 查詢main函數以前的耗時：菜單：Product->Scheme->Edit Scheme->Environment Variables，設置：key:DYLD_PRINT_STATISTICS ，value:1。

最後鄭重聲明，本篇裏只是記錄一下個人我的理解和代碼實踐，資料大量參考瞭如下文章：

今日頭條iOS客戶端啓動速度優化;

iOS App 啓動性能優化;

iOS App冷啓動治理：來自美團外賣的實踐;

iOS app啓動速度研究實踐;