移動端效能優化—啟動速度
本文出自於“「2021友盟+移動應用效能挑戰賽」”中的參賽作品，該文章表述了作者如何藉助友盟+ U-APM工具解決了啟動問題。
移動端效能對使用者體驗、留存有著至關重要的影響，作為開發者是不是被這樣吐槽過，“這個APP怎麼這麼大？”、“怎麼一直在APP封面圖轉悠，點不進去”、“進入詳情效果有些卡”、“用4G使用你們的APP，我的流量有點不夠啊”等等，這些問題都直觀反映出，一個體驗良好的應用，只有功能健全還不夠，以下是我在效能優化上總結的幾點：
- 啟動速度優化
- 流暢度優化
- 資源優化
- 記憶體優化
- APK體積優化
今天先聊聊，啟動速度的那些事
應用啟動流程
冷啟動
從點選應用圖示到UI介面完全顯示且使用者可操作的全部過程。
特點：耗時最多，衡量標準
啟動流程：Click Event -> IPC -> Process.start -> ActivityThread -> bindApplication -> LifeCycle -> ViewRootImpl
熱啟動
因為會從已有的應用程序啟動，所以不會再建立和初始化Application，只會重新建立並初始化Activity。
特點：耗時較少
啟動流程：LifeCycle -> ViewRootImpl
因此判斷應用啟動速度的的標準是冷啟動的速度，即殺掉應用後重新啟動的速度，此項主要是和你的競品對比。
不應在Application以及Activity的生命週期回撥中做任何費時操作，具體指標大概是你在onCreate，onResume，onStart等回撥中所花費的總時間最好不要超過400ms，否則使用者在桌面點選你的應用圖示後，將感覺到明顯的卡頓。
冷啟動分析及優化方向
冷啟動涉及的相關任務
冷啟動之前
- 首先，會啟動App
- 然後，載入空白Window
- 最後，建立程序
需要注意的是，這些都是系統的行為，一般情況下我們是無法直接干預的。
隨後任務
- 首先，建立Application
- 啟動主執行緒
- 建立MainActivity
- 載入佈局
- 佈置螢幕
- 首幀繪製
通常到了介面首幀繪製完成後，我們就可以認為啟動已經結束了。
下面是官方文件中的啟動過程流程圖，顯示系統程序和應用程序之間如何交接工作。實際上對啟動流程的簡要概括。
優化方向
我們的優化方向就是Application和Activity的生命週期這個階段，啟動中的系統任務我們無法干預，能干預的就是在建立應用和建立Activity的過程中可能會出現的效能問題。這一過程具體就是：
- Application的attachBaseContext
- Application的onCreate
- activity的onCreate
- activity的onStart
- activity的onResume
activity的onResume方法完成後才開始首幀的繪製。所以這些方法中的耗時操作我們是要極力避免的。並且，通常情況下，一個應用的主頁的資料是需要進行網路請求的，那麼使用者啟動應用是希望快速進入主頁以及看到主頁資料，這也是我們計算啟動結束時間的一個依據。
U-APM在啟動優化上的應用
以前使用友盟統計來分析App日活、埋點等資料，發現友盟推出的U-APM，趕緊來嚐嚐鮮。
U-APM是友盟+推出的App穩定性監控、效能監控和雲真機測試平臺。通過輕量級的整合接入即可擁有實時、可靠、全面的應用崩潰、ANR、自定義異常等捕獲能力，及卡頓、啟動分析等效能能力，支援多場景、多通道智慧告警監控，幫助開發者高效還原異常、卡頓使用者的訪問路徑和業務現場，縮短故障排查時間。就啟動分析這項能力來看看，U-APM都做了什麼。
U-APM支援啟動趨勢分析、慢啟動分析、啟動崩潰分析。
啟動趨勢分析
啟動趨勢較為直觀的展示應用啟動耗時的平均值、分位值、區間分佈等資料，以及啟動階段的效能分解資料，也能分析出，多版本迭代後，啟動時間的分佈狀況。
慢啟動分析
慢啟動分析，有助於開發者追根溯源，該功能展示慢啟動情況的佔比以及慢啟動裝置列表，您可以在啟動設定中自定義慢啟動的劃分，預設首次啟動/冷啟動超過3秒為慢啟動，熱啟動超過1秒為慢啟動。
冷啟動階段的慢啟動分析，直觀表現出慢啟動比例以及慢啟動平均耗時。
慢啟動分佈，直觀表現出，慢啟動分佈的裝置、系統、運營商、版本、渠道、地域。
啟動崩潰分析
歸納啟動階段中出現的崩潰資訊，支援劃分首次啟動、冷啟動、熱啟動狀態下的崩潰，預設啟動耗時上限為8秒，超出時間的崩潰不被劃分至啟動崩潰。
這對減少應用啟動時間，提供了巨大幫助，官方已提供Demo
總結
移動端效能優化環環相扣，啟動時間優化也是較為重要的一個環節，U-APM的出現，無疑是開發者的福利，幫助開發者及早發現問題，解決問題，至於U-APM其他功能，可以登入官方網站去體驗。