?

一般而言，大家把iOS冷啟動的過程定義為：從用戶點擊App圖標開始到appDelegate didFinishLaunching方法執行完成為止。這個過程主要分為兩個階段：

• T1：main()函數之前，即操作系統加載App可執行文件到內存，然后執行一系列的加載&鏈接等工作，最后執行至App的main()函數。
• T2：main()函數之后，即從main()開始，到appDelegate的didFinishLaunchingWithOptions方法執行完畢。

然而，當didFinishLaunchingWithOptions執行完成時，用戶還沒有看到App的主界面，也不能開始使用App。例如App還需要做一些初始化工作，然后經歷定位、首頁請求、首頁渲染等過程后，用戶才能真正看到數據內容并開始使用，我們認為這個時候冷啟動才算完成。我們把這個過程定義為T3。

pre-main time的過程

1 dylib loading time

載入動態庫，這個過程中，會去裝載app使用的動態庫，而每一個動態庫有它自己的依賴關系，所以會消耗時間去查找和讀取。對于Apple提供的的系統動態庫，做了高度的優化。而對于開發者定義導入的動態庫，則需要在花費更多的時間。

2 rebase/binding time

重構和綁定，rebase會修正調整處理圖像的指針，并且會設置指向綁定(binding)外部的圖像指針。所以為了加快rebase/binding，則需要更少的做指針修復。當你的app當中有太多的Objective-C的類，方法選擇器，和類別會增加這一部分的啟動時間。

3 ObjC setup time

在Objective-C的運行時(runtime)，需要對類(class)，類別(category)進行注冊，以及選擇器的分配。

4 initializer time

是執行+initialize方法的時間。

綜上，冷啟動過程定義為：從用戶點擊App圖標開始到用戶能看到App主界面內容為止這個過程，即T1+T2+T3。在App冷啟動過程當中，這三個階段中的每個階段都存在很多可以被優化的點。

?

?

從T1流程中，我們可以做優化的點主要有

?

1.是減少系統依賴庫
2.減少自己需要加入的各種三方庫(庫越少dyld加載的速度越快，就能越早的返回程序入口main函數的地址)
3.有一些自己加入的庫，能選擇靜態庫就選擇靜態庫，少用動態庫，因為動態庫的加載方式比靜態庫慢。如果必須依賴動態庫，則把多個非系統的動態庫合并成一個動態庫。
4.自己加入的各種framework庫根據情況設為optional和required，如果該framework在當前App支持的所有iOS系統版本中都存在，那么就設為required，否則就設為optional，因為optional會有些額外的檢查會導致加載變慢。
5.將不必須在+load方法中做的事情延遲到+initialize中，盡量不要用C++虛函數(創建虛函數表有開銷)。
6.減少項目文件中Category，靜態變量等的使用數量
7.檢查項目中，那些類和方法沒有使用到。?把沒有使用到的刪除
8.讓UI大佬盡量把給的資源壓縮到最小，因為在啟動加載時會加載資源圖片進行IO操作。所以圖片小加載速度也會響應提升。
9.內存上優化：類和方法名不要太長：iOS每個類和方法名都在__cstring段里都存了相應的字符串值，所以類和方法名的長短也是對可執行文件大小是有影響，及影響加載速度也消耗內存；因為OC的動態特性，都是加載后通過類/方法名反射找到這個類/方法進行調用，OC的對象模型會把類/方法名字符串都保存下來(壓縮算法TinyPNG)。

10使用更多的Swift代碼

?

?

從T2流程中，我們可以做優化的點主要有

1不使用xib，直接視用代碼加載首頁視圖。

2每次用NSLog方式打印會隱式的創建一個Calendar，因此需要刪減啟動時各業務方打的log，或者僅僅針對Debug版輸出log。

3將可以延時處理的SDK移到后面執行。

4將首頁viewDidLoad中網絡請求，數據解析，視圖渲染等耗時操作移到viewDidAppear中執行。

?

延展：插件式啟動項注冊,去中心化。

總結

以上是生活随笔為你收集整理的APP启动时间优化的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。