今天先聊聊，啟動速度的那些事

應用啟動流程

冷啟動

從點擊應用圖標到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 其他功能，可以登錄 官方網站 去體驗。

原文鏈接：http://click.aliyun.com/m/1000293112/

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