巧用友盟+U-APM 實現App啟動速度最佳化

本文出自於“「

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，否則使用者在桌面點選你的應用圖示後，將感覺到明顯的卡頓。

冷啟動分析及最佳化方向

冷啟動涉及的相關任務

冷啟動之前

1、首先，會啟動 App

2、然後，載入空白 Window

3、最後，建立程序

需要注意的是，這些都是系統的行為，一般情況下我們是無法直接干預的。

隨後任務

1、首先，建立 Application

2、啟動主執行緒

3、建立 MainActivity

4、載入佈局

5、佈置螢幕

6、首幀繪製

通常到了介面首幀繪製完成後，我們就可以認為啟動已經結束了。

下面是

官方文件

中的啟動過程流程圖，顯示系統程序和應用程序之間如何交接工作。實際上對啟動流程的簡要概括。

最佳化方向

我們的最佳化方向就是 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 支援啟動趨勢分析、慢啟動分析、啟動崩潰分析。

啟動趨勢分析

啟動趨勢較為直觀的展示應用啟動耗時的平均值、分位值、區間分佈等資料，以及啟動階段的效能分解資料，也能分析出，多版本迭代後，啟動時間的分佈狀況。