前言

作為程序猿來說，“性能優化”是我們都很熟悉的詞，也是我們需要不斷努以及持續進的事情；其實優化是個很嚴謹的課題，因為細分來說的話有種優化向 ，但是切忌在實際開發過程中不能盲目的為了優化而優化，這樣有時可能會造成適得其反的負效果，需要我們根據實際場景以及業務需求進合理優化。接下來進入正題，本文將會以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.2 Rebase/Bind

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

優化結論：

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()函數。

優化結論：

2、main()階段

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

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

場景補充：

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

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

這樣做的好處是

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

統計時

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

優化前啟動時：

優化后啟動時：

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

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

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

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