簡介：?作為程序猿來說，“性能優化”是我們都很熟悉的詞，也是我們需要不斷努?以及持續進?的事情；其實優化是?個很?的課題，因為細分來說的話有??????種優化?向 ，但是切忌在實際開發過程中不能盲?的 為了優化?優化，這樣有時可能會造成適得其反的負效果，需要我們根據實際場景以及業務需求進?合理優 化。接下來進?正題，本?將會以iOS App的啟動優化為展開點進?探討。

前言

作為程序猿來說，“性能優化”是我們都很熟悉的詞，也是我們需要不斷努?以及持續進?的事情；其實優化是?個很?的課題，因為細分來說的話有??????種優化?向 ，但是切忌在實際開發過程中不能盲?的 為了優化?優化，這樣有時可能會造成適得其反的負效果，需要我們根據實際場景以及業務需求進?合理優?化。接下來進?正題，本?將會以iOS App的啟動優化為展開點進?探討。

啟動流程：

iOS App 的啟動我們都知道分為 ?為pre-main 和 ?main() 兩個階段，并且在這兩個階段中，系統會進 ??系列的加載操作，過程如下：

1、pre-main階段

1. ?加載應?的可執??件

2. ?加載dyld動態連接器

3. ?dyld遞歸加載應?所有依賴的動態鏈接庫dylib

2、main()階段

1. ?dyld調? ?main()

2. ?調?UIApplicationMain()

3. ?調?applicationWillFinishLaunching

4. ?調?didFinishLaunchingWithOptions

階段優化項

1、pre-main階段

針對 ?pre-main 階段做優化時，我們需要先詳細了解其加載過程，這個可以在2016年WWDC 的 ?Optimizing App Startup Time 中詳細了解到， ? 相關材料

1.1 Load dylibs

這?階段dyld會分析應?依賴的 ?dylib （xcode7以后.dylib已改為名.tbd），找到其 ?mach-o ?件，打開和讀取這些?件并驗證其有效性，接著會找到代碼簽名注冊到內核，最后對 ?dylib 的每?個 ?segment 調? mmap()。不過這?的 ?dylib ?部分都是系統庫，不需要我們去做額外的優化。

優化結論：

1、盡量不使?內嵌的dylib，從?避免增加?`Load?dylibs`開銷 2、合并已有的dylib和使?靜態庫（static?archives），減少dylib的使?個數 3、懶加載dylib，但是要注意dlopen()可能造成?些問題，且實際上懶加載做的?作會更多

1.2 Rebase/Bind

在dylib的加載過程中，系統為了安全考慮，引?了ASLR （Address Space Layout Randomization）技術和 ? ?代碼簽名。由于ASLR的存在，鏡像（Image，包括可執??件、 ?dylib和bundle）會在隨機的地址上加載，和 之前指針指向的地址（preferred_address）會有?個偏差（slide）， dyld需要修正這個偏差，來指向正確的?地址。 ? Rebase在前， ? Bind在后， ?Rebase做的是將鏡像讀?內存，修正鏡像內部的指針，性能消耗主要在 ? ? IO。 Bind做的是查詢符號表，設置指向鏡像外部的指針，性能消耗主要在CPU計算。

優化結論：

在此過程中，我們需要注意的是盡量減少指針數量，?如： 1.?減少ObjC類（class）、?法（selector）、分類（category）的數量 2.?減少C++虛函數的的數量（創建虛函數表有開銷） 3.?使??Swift?struct?（內部做了優化，符號數量更少）

1.3 Objc setup

?部分ObjC初始化?作已經在Rebase/Bind階段做完了，這?步dyld會注冊所有聲明過的ObjC類，將分類插 ?到類的?法列表?，再檢查每個selector的唯?性。

在這?步倒沒什么優化可做的， ?Rebase/Bind階段優化好了，這?步的耗時也會減少。

1.4 Initializers

在這?階段， ? dyld開始運?程序的初始化函數，調?每個Objc類和分類的+load?法，調?C/C++ 中的構造器 函數（?attribute((constructor))修飾的函數），和創建?基本類型的C++靜態全局變量。 ?Initializers階段執? ?完后， ?dyld開始調?main()函數。

優化結論：

1.?少在類的+load?法?做事情，盡量把這些事情推遲到+initiailize 2.?減少構造器函數個數，在構造器函數?少做些事情 3.?減少構造器函數個數，在構造器函數?少做些事情

2、main()階段

在這?階段?，主要優化重點放在 SDK初始化、業務?具注冊、整體

didFinishLaunchingWithOptions ?法中，因為我們的?些第三? ? ?app ?格配置、啟動引導?顯示狀態邏輯、版本更新邏輯等等基本?都會在這?進?，如果這部分邏輯沒有做好優化梳理，隨著業務不斷拓展，臃腫的業務邏輯會直接導致啟動時 間加?。

在滿?業務需求的前提下，盡量減少??didFinishLaunchingWithOptions??法在主線程中的事件處理邏輯，??如： 1.?根據實際業務狀況，梳理各個??/三?庫，找到可以延遲加載的庫，做延遲加載處理，?如放到??控制器?的viewDidAppear?法?。 2.?梳理業務邏輯，把可以延遲執?的邏輯，做延遲執?處理。?如檢查新版本、注冊推送通知等邏輯 3.?避免進??些復雜/多余的計算邏輯，這類邏輯盡量進?異步延遲處理 4.?避免在??控制器的viewDidLoad和viewWillAppear做太多容易阻塞主線程的事情，這2個?法執?完，???控制器才能顯示

場景補充：

另外，在我們實際開發過程中，很多項?的??控制器都會有?些后臺可配、較為豐富的結構或者推薦數據 ?進?展示，?且我們的??展示速度通常也會被納?啟動優化的?部分，其實對于這種類型的優化，如果我 ?們還只是?傳統的 ?api -> data -> UI ?式進?的話，就很難有明顯的改善空間，因為?戶的?絡狀態 并不是可控項，如果不做其他處理的話，那在很多場景下對?戶來說，即使我們放上?些占位圖，展示的樣式也是很不友好的，畢竟??控制器對?戶的第?視覺沖擊影響還是?較?的。

對于這種場景下的優化來說，?般我們可以采取 ?Local + Network + Update 的?式在?定程度上優化 ??加載速度： ? ?即：

1、?app更新過程中，?先進?本地內嵌處理邏輯，內嵌??數據結構（?localDataBase）、內嵌??樣式所需?資源（?localStorage） 2、在安裝啟動之后，對本地與線上數據更新記錄進?對?，檢測是否需要更新本地內嵌數據結構 3、檢測到有需要更新的數據時，才會對指定結構進?靜默更新，并且同步更新本地數據結構

這樣做的好處是：

1、??數據直接從本地加載，減少?絡數據等待時間 2、僅檢測數據key值變化，?數據量對?定向更新結構，減少api數據交互頻次及數據包體積 3、能夠保證??對于?戶來說會?直處于?個友好的展示狀態

當然這種也并不是唯?的應對?式，?且也并?對所有場景都適?，只是提供?種思路?已，還是需要根據 項?的實際場景選擇適合的優化?案。

統計時?

另外如果在開發過程中，我們想直觀的查看 ?app 啟動期間，各階段的耗時情況，也可以在Xcode，的 ?edit scheme 設置添加 ? DYLD_PRINT_STATISTICS 為1 ，打印啟動時?，例如

優化前啟動時?：

優化后啟動時?：

當然，這些log我們僅僅只能在開發調試階段查看打印，那么在實際項?中，我們需要對線上項?的啟動數據 進?監控，以便及時的定位和優化那些影響 ?app 啟動時?的環節，這時我們應該怎樣更好的處理呢？

當然我們可以通過服務器埋點上報的?式??統計分析，不過這樣?來會發現我們的統計成本就會??增 ? ? ?加，?且結果分析也會變得不那么靈活。所以這?推薦?種簡單的監控?式，那就是友盟的 ?U-APM 應能性 能監控SDK ，只需要我們進?簡單的pod集成之后，便可根據我們的實際需要進??動或者?動監控啟動數 ?據，詳情可以參考 U-APM，?并且為了?便我們對數據進?分析，友盟后臺已經根據這些數據幫我們繪制出?了對應的分布圖，我們可以??了然的得出啟動耗時分布、啟動類型占?等等，如圖：

除此之外，我們還可以通過SDK進?崩潰分析、 ?ANR分析、監控告警、卡頓分析、內存分析等等諸多功能， 有了 ?U-APM 這個監控平臺，其實在實際開發過程中很?程度的提升了我們對線上 ?app 的優化分析效率。

當然本?的介紹也只是?較淺顯的優化項，僅供參考以及思路引導，優化之路任重?道遠，還需要我們不斷 的去探索、發現、提?。不過最后還是要提醒?句：在實際項?開發過程中，不要為了優化?優化，要根據 項?情況有針對性的進?優化。

參考：

探秘?Mach-O??件

iOS底層?- 從頭梳理?dyld 加載流程

iOSapp啟動?- dyld加載App流程

wwdc2016optimizingappstartuptime.pdf

作者：武玉寶

原文鏈接
本文為阿里云原創內容，未經允許不得轉載。?

總結

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

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