啟動速度優化背景：
我們的專案在專案為一個開發迭代多年的老專案，之前對專案的啟動效能沒有太多的關注，導致APP的啟動速度比較慢，啟動有時要耗時3、4s鍾，整體啟動效能堪憂。我們主管安排我負責優化，全力優化APP啟動速度。
遇到挑戰：
最大挑戰有2個，一是程式碼歷史程式碼效能消耗沒有把控，很多地方存在不合理的程式碼；二是做為入職不久的新人需要在1個月完成左右優化，時間緊任務重；
優化步驟：
首先我們梳理好目標，iOS啟動可以分為冷啟動和熱啟動。冷啟動是指APP本身不在後臺系統，從使用者點選應用icon到appDelegate didFinishLaunching方法執行完成使用者看到APP首頁為止；熱啟動是APP本身在系統後臺執行，從後到點選到進入APP場景。我們重點是優化冷啟動的速度，啟動速度時間目標由3s降到1.2s;
有了明確目標後接下來是對目標進行拆解，要進行冷啟動優化我們需要知道冷啟動過程具體做了什麼，具體哪部分執行節點耗時較多。APP冷啟動可以大概分為三個階段，第一階段是main函式之前，系統執行一系列載入和連結工作；第二階段是main函式之後，從main函式開始到AppDelegate的didFinishLaunchingWithOptions執行完畢；第三階段是從didFinishLaunchingWithOptions執行到APP渲染出APP的首頁；我們需要從這三個階段來進行優化，首先我們需要分析這三個階段的耗時情況。
測算main函式之前的耗時，我們可以通過配置xcode來進行，在xcode的editScheme中Run→ Environment Variables 新增name為DYLD_PRINT_STATISTICS為1，這樣就可以在xcode控制檯中一份輸出報告示例如下：
從上圖中我們可以清晰瞭解main函式前的耗時，以及過程中載入動態庫耗時、oc類初始化耗時、指標重定義耗時。對於main函式後我們可以通過加入計時程式碼來統計，這塊統計比較簡單；
main函式前核心優化：主要包括優化動態載入庫、Rebase/Binding優化和優化初始化階段
動態庫載入優化：
我們主要進行2方面的優化，
1.消滅內嵌的動態庫，因為系統載入內嵌動態庫會消耗比較大的效能；
2.減少動態庫的數量，可以通過合併已有的動態庫來達到目的，動態庫越多效能開銷越多；
Rebase/Binding優化：
主要進行了2類優化，
1.減少oc類、減少方法、減少分類數量；
2.使用Swift structs可以大幅減少符號數量；
Initializers階段優化：最核心是減少load方法使用，load執行程式碼越多啟動會越慢，我們可以把load的實現程式碼延遲放到initiailize方法中，在initiailize方法不會影響APP的啟動速度；
main函式後階段優化：這個階段核心優化思路是減少主執行緒的效能消耗，對於基礎元件的初始化做到能延後的延後，能放到子執行緒初始化的放到子執行緒初始化。
通過以上優化後我們APP的啟動速度有了很大的提升，由原來的3s出頭優化到了1.2s左右。
接入總結和建議：整體接入還是比較簡單，官網在整體的說明文件方面比較清晰。整個apm在崩潰做的比較好，對比之前用的聽雲和bugly還是不錯的，在資訊收集的全面性方面特別好，另外對於崩潰日誌解析和準確性方面比較好，崩潰的堆疊相對其他產品更易懂。
對產品的建議：在使用過程中發現以下問題建議參考優化
（1） 從u-apm註冊後，在之後的主頁就找不到關於u-apm的內容了，註冊完後註冊了一個APP發現是接入友盟基礎SDK，不是我想要的，只能通過返回到活動也才找到u-apm。
（2） 想接入一個沒有idfa的版本，沒找到，看接入注意是強制收集了idfa，定位和idfa國家對我們這個行業有限制，特別是位置許可權不允許用；
（3） 官網上播放視訊和下面的介紹疊在一起，無法全屏看（Safari瀏覽器）
（4） 概覽中，崩潰率、ANR描述使用專門名詞，現在都使用“錯誤“統稱，並不符合開發的認知，比如崩潰就是崩潰率，anr就說是anr，而不是統稱為崩潰；
（5） 實時概覽更希望看的是一些總的資料表，比如崩潰Android崩潰希望看java和原生底層加起來的總崩潰，另外建議實時概覽增加卡頓率、網路錯誤率、啟動速度等一些關鍵指標的總覽圖；二級頁面再增加卡頓、崩潰等詳情；
作者：盛夏
從事iOS開發5年，做過社交和教育APP研發