iOS 如何優化 App 的啓動耗時

iOS 的 App 啓動時長大概能夠這樣計算：

• t(App 總啓動時間) = t1(main 調用以前的加載時間) + t2(main 調用以後的加載時間)
• t1 = 系統 dylib(動態連接庫)和自身 App 可執行文件的加載
• t2 = main方法執行以後到AppDelegate類中的application:didFinishLaunchingWithOptions:方法執行結束前這段時間，主要是構建第一個界面，並完成渲染展現

1. 在**t1**階段加快**App**啓動的建議：

• 儘可能使用靜態庫，減小動態庫的使用，動態連接比較耗時，若是要用動態庫，儘可能將多個dylib動態庫合併成一個
• 儘可能避免對系統庫使用optional linking，若是App用到的系統庫在你全部支持的系統版本上都有，就設置爲required，由於optional會有些額外的檢查
• 減小Objective-C Class、Selector、Category的數量，能夠合併或者刪減一些OC類
• 刪減一些無用的靜態變量，刪減沒有被調用到或者已經廢棄的方法
• 將沒必要須在+load中作的事情儘可能挪到+initialize中，+initialize是在第一次初始化這個類以前被調用，+load在加載類的時候就被調用。儘可能將+load裏的代碼延後調用
• 儘可能不要用C++虛函數，建立虛函數表有開銷
• 不要使用 __attribute__((constructor))將方法顯式標記爲初始化器，而是讓初始化方法調用時才執行。好比使用dispatch_once()，pthread_once()或 std::once()
• 在初始化方法中不調用dlopen()，dlopen()有性能和死鎖的可能性
• 在初始化方法中不建立線程

2. 在**t2**階段加快**App**啓動的建議：

• 儘可能不要使用xib/storyboard，而是用純代碼做爲首頁UI，若是要用xib/storyboard，不要在xib/storyboard中存放太多的視圖
• 對application:didFinishLaunchingWithOptions:裏的任務儘可能延遲加載或懶加載
• 不要在NSUserDefaults中存放太多的數據，NSUserDefaults是一個plist文件，plist文件會被反序列化一次
• 避免在啓動時打印過多的log，少用NSLog，由於每一次NSLog的調用都會建立一個新的NSCalendar實例
• 爲了防止使用GCD建立過多的線程，解決方法是建立串行隊列，或者使用帶有最大併發數限制的NSOperationQueue
• 不要在主線程執行磁盤、網絡、Lock或者dispatch_sync、發送消息給其餘線程等操做

推薦視頻詳解：

         iOS應用啓動優化