使用者希望應用程式可以快速載入及回應網頁。啟動時間緩慢的應用程式 不符合這項預期，可能會讓使用者感到失望。此類不佳體驗可能會導致使用者在 Play 商店中對您的應用程式給予負評，或甚至解除安裝應用程式。
本頁面提供有助於最佳化應用程式啟動時間的資訊，包括發布程序內部總覽、如何分析啟動效能，以及一些常見的啟動時間問題和排解提示。
瞭解不同的應用程式啟動狀態
應用程式啟動可能有三種狀態：冷啟動、暖啟動或熱啟動。每種狀態都會影響顯示應用程式所需的時間長度。冷啟動就表示應用程式從頭開始啟動。在其他狀態中，系統需要將執行中的應用程式從背景移至前景。
建議您一律以冷啟動為假設狀態來進行最佳化。這麼做也可以改善暖啟動和熱啟動的效能。
如要最佳化應用程式快速啟動程序，建議您瞭解各系統和應用程式層級所發生的情況，以及各狀態如何互動。
決定應用程式啟動的兩項重要指標為初始顯示時間 (TTID) 和完整繪製時間 (TTFD)。TTID 是 顯示第一個影格，而 TTFD 是啟動應用程式所需的時間 完全互動。兩者一樣重要，因為 TTID 能讓使用者知道 系統載入的是應用程式的內容和 TTFD。如果有 使用者可能在應用程式載入完畢前就退出應用程式。
冷啟動
冷啟動是指應用程式從頭開始啟動，這表示系統程序會在冷啟動開始後才建立應用程式程序。冷啟動是指在裝置啟動後首次次啟動應用程式，或是系統終止應用程式後首次啟動應用程式。
這種啟動方式很難將啟動時間縮減到最少，因為相較於其他啟動狀態，系統和應用程式需要執行更多工作。
在冷啟動開始時，系統會執行以下三項工作：
- 載入並啟動應用程式。
- 啟動後立即顯示應用程式的空白起始視窗。
- 建立應用程式程序。
系統建立應用程式程序後，應用程式程序就會負責進行後續階段：
- 建立應用程式物件。
- 啟動主執行緒。
- 建立主要活動。
- 加載檢視畫面。
- 對畫面建立版面配置。
- 執行初始繪圖。
應用程式程序完成第一個繪圖後，系統程序會關閉目前顯示的背景視窗，並以主要活動取代。此時使用者就可以開始使用應用程式。
圖 1 顯示系統和應用程式程序如何交互處理。
應用程式建立和活動建立期間可能會出現的效能問題。
應用程式建立
應用程式啟動時，畫面中會持續顯示空白的啟動視窗，直到系統完成應用程式繪圖作業為止。此時，系統程序會切換應用程式的啟動視窗，讓使用者能與應用程式互動。
如果在應用程式中覆寫 Application.onCreate()，系統會
對應用程式物件叫用 onCreate() 方法。之後，應用程式就會產生
主執行緒 (也稱為 UI 執行緒)，以及用來建立
主要活動。
此時，系統層級和應用程式層級的程序會根據應用程式生命週期階段進行。
活動建立
應用程式程序建立活動後，該活動會執行下列作業：
- 初始化值。
- 呼叫建構函式。
- 依照目前的活動生命週期狀態呼叫回呼方法，例如：
Activity.onCreate()。
一般來說，onCreate() 方法對載入時間會造成最大的影響。
因為這會執行負載最高的工作：載入和加載
以及初始化執行活動所需的物件。
暖啟動
暖啟動包含冷啟動期間的部分作業，而且負載比熱啟動高。有許多潛在狀態可視為暖啟動，例如以下情況：
使用者先退出再重新啟動應用程式。此時程序可能仍會繼續執行，但應用程式必須呼叫
onCreate()，才能從頭開始重新建立活動。系統從記憶體中清除應用程式，然後使用者再重新啟動應用程式。 和活動需要重新啟動，不過任務可以帶來些許好處 儲存的例項狀態組合 (儲存在
onCreate()中)。
熱啟動
相較於冷啟動，應用程式熱啟動作業耗用的資源較少。進行熱啟動程序時，系統會將活動移至前景。如果應用程式的所有活動仍留在記憶體中，應用程式就不需要重複初始化物件、版面配置加載和轉譯。
不過，如果有些記憶體已因回應記憶體修整事件 (例如 onTrimMemory()) 而遭到清除，就需要重新建立這些物件才能回應熱啟動事件。
熱啟動顯示的畫面行為與冷啟動的情況相同，系統程序會顯示空白畫面，直到應用程式完成活動轉譯為止。
如何在 Perfetto 中查看應用程式啟動作業
如要對應用程式啟動問題偵錯，建議您先判斷應用程式啟動階段涉及哪些作業。如要在 Perfetto 中查看應用程式的所有啟動階段，請按照下列步驟操作：
在 Perfetto 中，找出「Android App Startups 」衍生指標列。如果 如果不支援模擬功能，請嘗試使用裝置端系統追蹤記錄擷取追蹤記錄 app。
圖 3：Perfetto 中的「Android App Startups」衍生指標片段。 按一下相關聯的片段，然後按下 m 鍵選取片段。系統會將片段以括弧括起，表示所費時間。「Current selection」分頁中也會顯示時間長度。
將滑鼠游標懸停在資料列上，點選出現的圖釘圖示，即可固定「Android App Startups」列。
捲動至含有所需應用程式的資料列，然後按一下第一個儲存格，即可展開內容 。
按下 W 鍵放大主要執行緒，通常位於頂端 (按下 s, a, D 鍵即可縮小、向左移動、向右移動， )。
圖 4.「Android App Startups」衍生指標片段，位於應用程式的主要執行緒旁。 衍生指標片段可讓您更輕鬆地查看應用程式啟動階段中的作業，以便進一步偵錯。
依據指標檢查及改善啟動作業
為了正確診斷開始時間的效能，您可以追蹤顯示應用程式啟動所需時間的指標。Android 提供多種可以讓您得知應用程式出現問題的方法，還能幫助您診斷問題原因。Android Vitals 會提醒您發生問題，診斷工具則可協助您診斷問題。
使用啟動指標的優點
Android 會使用「初始顯示時間 (TTID)」和「完整顯示時間」 (TTFD) 指標，用於最佳化冷啟動和暖啟動應用程式。Android 執行階段 (ART) 使用這些指標的資料，以有效率的方式預先編譯程式碼，進行最佳化 未來新創公司的成功經驗
啟動速度越快，就越能吸引使用者持續與應用程式互動，進而減少提前結束、重新啟動執行個體或離開並前往其他應用程式的情形。
Android Vitals
Android Vitals 會透過 Play 管理中心。
Android Vitals 會將以下的應用程式啟動時間視為過長：
Android Vitals 會使用「初始顯示時間 (TTID)」指標。適用對象 如要瞭解 Google Play 如何收集 Android Vitals 資料，請參閱 Google Play 控制台說明文件。
初始顯示時間
初始顯示時間 (TTID) 是指顯示第一個影格所需的時間
應用程式 UI 的功能這個指標可測量應用程式的製作時間
第一個畫面，包括冷啟動期間的程序初始化、活動
顯示第一個影格保留中
應用程式的 TTID 偏低，有助於改善使用者體驗，
迅速啟動應用程式Android 會自動回報每個應用程式的 TTID
架構。針對應用程式啟動進行最佳化時，建議實作
reportFullyDrawn 來取得 TTFD 的資訊。
TTID 測量結果為時間值，代表 包含下列事件序列：
- 啟動程序。
- 初始化物件。
- 建立並初始化活動。
- 加載版面配置。
- 首次繪製應用程式。
擷取 TTID
如要找出 TTID，請在 Logcat 指令列工具中搜尋輸出行
內含名為 Displayed 的值。這個值是 TTID，看起來很類似
在以下範例中，TTID 為 3s534 毫秒：
ActivityManager: Displayed com.android.myexample/.StartupTiming: +3s534ms
如要在 Android Studio 中找出 TTID，請停用 Logcat 檢視畫面中的篩選器，方法是：
然後找出 Displayed 時間，如圖 5 所示。
由於系統伺服器 (非應用程式) 必須停用篩選器
就會提供這項記錄
Displayed
值。Logcat 輸出內容中的 Displayed 指標不一定能擷取
要經過多少時間才會載入並顯示所有資源如果資源沒有在版面配置檔案中加入參照，或是屬於應用程式為物件初始化而建立的資源，則不會計算在內。由於這些資源會以內嵌程序載入，而且不會封鎖應用程式的初始顯示，因此會予以排除。
有時 Logcat 輸出內容的 Displayed 行中會包含額外欄位
總共投入了大量時間例如：
ActivityManager: Displayed com.android.myexample/.StartupTiming: +3s534ms (total +1m22s643ms)
在這種情況下，首次測量僅適用於首次繪製的活動。total 時間測量從應用程式處理程序開始，而且可能包含首次開始，但未在螢幕上顯示的任何活動。只有在單一活動和總啟動時間出現差異時，系統才會顯示 total 時間測量結果。
建議您在 Android Studio 中使用 Logcat，但如果您不使用 Android
您也可以使用 adb 殼層執行應用程式，以評估 TTID
活動管理員指令。範例如下：
adb [-d|-e|-s <serialNumber>] shell am start -S -W
com.example.app/.MainActivity
-c android.intent.category.LAUNCHER
-a android.intent.action.MAIN
Displayed 指標會像先前一樣顯示在 Logcat 輸出內容中。終端機視窗會顯示以下內容：
Starting: Intent
Activity: com.example.app/.MainActivity
ThisTime: 2044
TotalTime: 2044
WaitTime: 2054
Complete
-c 和 -a 是選用引數，可讓您指定 <category>
和 <action>。
完整顯示時間
完整顯示時間 (TTFD) 是指應用程式上線所需的時間 與使用者互動報表中顯示 應用程式使用者介面的第一個影格，以及非同步載入的內容 初始影格顯示完畢。一般來說，這是主要內容 應用程式回報的內容換句話說， TTFD 包括 TTID，以及啟用應用程式所花的時間。維持應用程式的 TTFD 低廉，能讓使用者與您 快速部署應用程式
系統會在 Choreographer 呼叫活動的
onDraw() 方法，且知道這個方法第一次呼叫時。
但因為每個應用程式，系統都不知道何時該決定 TTFD
行為會有所不同應用程式必須向系統發出訊號，才能判斷 TTFD
直到達到完全繪製狀態
擷取 TTFD
如要找出 TTFD，請呼叫
ComponentActivity 的 reportFullyDrawn() 方法。
reportFullyDrawn 方法會回報應用程式繪製完成且可供使用的時間
時間。TTFD 是指系統收到應用程式啟動後經過的時間
目標在呼叫 reportFullyDrawn() 時的意圖。如果不來電
reportFullyDrawn()，系統不會回報任何 TTFD 值。
如要測量 TTFD，請在完整繪製 UI 並呼叫 reportFullyDrawn() 後，
所有資料請勿在第一個活動開始前呼叫 reportFullyDrawn()
系統會依照測量值先繪製並顯示視窗，
系統會回報測量時間。也就是說，
系統偵測到 TTID 前 reportFullyDrawn()，系統會同時回報兩者
TTID 和 TTFD 相同，這個值就是 TTID 值。
使用 reportFullyDrawn() 時，Logcat 會顯示如下所示的輸出內容
例如， TTFD 為 1s54 毫秒：
system_process I/ActivityManager: Fully drawn {package}/.MainActivity: +1s54ms
Logcat 輸出內容有時會包含 total 時間，如「時間：
初始畫面。
如果顯示時間比平常慢，可以試著找出 啟動程序中的瓶頸。
在基本情況下，您可以使用 reportFullyDrawn() 指出已繪製完成的狀態
您就會知道已繪製完成的狀態不過在某些情況下
背景執行緒必須完成背景工作，才能完整繪製
則需要延遲 reportFullyDrawn()，才能獲得更準確的結果
TTFD 測量。如要瞭解如何延遲 reportFullyDrawn()，請參閱以下資源
專區。
提高啟動時間準確度
如果您的應用程式執行延遲載入，且初始顯示資料未包括
所有資源 (例如應用程式從網路擷取圖片時)
您可能會想延遲呼叫 reportFullyDrawn，直到應用程式變成
這樣您就能將名單填入納入基準
時間。
舉例來說，如果 UI 包含動態清單，例如 RecyclerView
可能是在
清單會先繪製，因此 UI 標示為已完成繪製後。
在這類情況下，基準測試就不會納入名單填入資料。
如要將名單填入納入基準時間，請取得
FullyDrawnReporter，方法是使用 getFullyDrawnReporter()，然後新增
新增到應用程式的程式碼中在背景工作完成後釋出回報器
系統正在填入清單。
FullyDrawnReporter 不會呼叫 reportFullyDrawn() 方法，直到全部
發布更多記者。在背景程序前新增回報器
完成時，時間也會包括填入
列出。這麼做並不會改變應用程式的
但啟動時間資料就會包含填入作業所需的時間
在這個範例中就是「花」
以及排在前端的其他字詞系統會等到所有工作都完成時，才會呼叫 reportFullyDrawn()
完成所有程序。
以下範例說明如何在每項背景工作都各自註冊回報器的情況下，同時執行多項這類工作：
Kotlin
class MainActivity : ComponentActivity() { sealed interface ActivityState { data object LOADING : ActivityState data object LOADED : ActivityState } override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContent { var activityState by remember { mutableStateOf(ActivityState.LOADING as ActivityState) } fullyDrawnReporter.addOnReportDrawnListener { activityState = ActivityState.LOADED } ReportFullyDrawnTheme { when(activityState) { is ActivityState.LOADING -> { // Display the loading UI. } is ActivityState.LOADED -> { // Display the full UI. } } } SideEffect { lifecycleScope.launch(Dispatchers.IO) { fullyDrawnReporter.addReporter() // Perform the background operation. fullyDrawnReporter.removeReporter() } lifecycleScope.launch(Dispatchers.IO) { fullyDrawnReporter.addReporter() // Perform the background operation. fullyDrawnReporter.removeReporter() } } } } }
Java
public class MainActivity extends ComponentActivity { private FullyDrawnReporter fullyDrawnReporter; @Override protected void onCreate(@Nullable Bundle savedInstanceState) { super.onCreate(savedInstanceState); fullyDrawnReporter = getFullyDrawnReporter(); fullyDrawnReporter.addOnReportDrawnListener(() -> { // Trigger the UI update. return Unit.INSTANCE; }); new Thread(new Runnable() { @Override public void run() { fullyDrawnReporter.addReporter(); // Do the background work. fullyDrawnReporter.removeReporter(); } }).start(); new Thread(new Runnable() { @Override public void run() { fullyDrawnReporter.addReporter(); // Do the background work. fullyDrawnReporter.removeReporter(); } }).start(); } }
如果應用程式使用 Jetpack Compose，您可以使用下列 API 表示 完整繪製狀態：
ReportDrawn：表示可組合項可立即準備好 互動。ReportDrawnWhen：使用述詞 (例如list.count > 0) 來 表示可組合函式已準備好互動的時間。ReportDrawnAfter：採用暫停方法，完成後 表示可組合函式已準備好互動。
找出瓶頸
如要尋找瓶頸，可以使用 Android Studio CPU 分析器。如要 詳情請參閱「使用 CPU 分析器查看 CPU 活動」。
此外，您也可以透過應用程式和活動 onCreate() 方法中的內嵌追蹤記錄，深入瞭解潛在瓶頸。瞭解內嵌
追蹤記錄，請參閱 Trace 函式的說明文件和總覽
系統追蹤。
解決常見問題
本節說明會影響應用程式啟動效能的幾個問題。這些問題主要與初始化應用程式、活動物件，以及載入畫面有關。
大量應用程式初始化
當程式碼覆寫 Application 物件，並在初始化該物件的過程中執行大量工作或複雜邏輯時，可能會影響啟動效能。如果 Application 子類別會執行當下還不需完成的初始化作業，應用程式就可能會在啟動過程中浪費時間。
某些初始化作業可能完全沒必要執行，例如當應用程式為了回應意圖，而實際上已啟動時，將主要活動的狀態資訊初始化就是一項非必要的作業。如果使用意圖，應用程式只會使用先前初始化狀態資料的子集。
應用程式初始化期間的其他挑戰包括具影響力或多餘的垃圾收集事件，或與初始化同時進行磁碟 I/O，進一步封鎖初始化程序。使用 Dalvik 執行階段時，垃圾收集是特別需要考量的部分；Android 執行階段 (ART) 會同時執行垃圾收集，將作業的影響降到最低。
診斷問題
您可以利用方法追蹤記錄或內嵌追蹤記錄，嘗試診斷問題所在。
方法追蹤記錄
執行 CPU 分析器會顯示 callApplicationOnCreate()
方法最終會呼叫 com.example.customApplication.onCreate 方法。如果工具顯示這些方法需要很長的時間才能完成執行，請深入瞭解當下進行中的作業為何。
內嵌追蹤記錄
使用內嵌追蹤記錄調查可能的問題情況，包括：
- 應用程式的初始
onCreate()函式。 - 應用程式初始化的任何全域單例模式物件。
- 瓶頸期間可能會發生的任何磁碟 I/O、去序列化或密集迴圈。
問題解決方案
不論問題原因是非必要初始化作業還是磁碟 I/O，解決方案都是延遲初始化。換句話說，請只初始化立即需要的物件。請採用單例模式，不要建立全域靜態物件，讓應用程式僅在首次需要物件的時候初始化該物件。
此外，請考慮使用 Hilt 等依附元件插入架構 會在第一次插入物件時建立物件和依附元件。
如果應用程式會使用內容供應器，在啟動程序初始化應用程式元件，建議您改用 App Startup 程式庫。
大量活動初始化
活動製作通常需要大量的高負載工作。通常這種工作都可以進行最佳化以提升效能。這類常見問題包括：
- 加載大型或複雜的版面配置。
- 禁止在磁碟或網路 I/O 上繪圖。
- 載入和解碼點陣圖。
- 光柵處理
VectorDrawable物件。 - 活動的其他子系統初始化。
診斷問題
在這種情況下，方法追蹤記錄和內嵌追蹤記錄也非常實用。
方法追蹤記錄
使用 CPU 分析器時，請留意應用程式的 Application
子類別建構函式和 com.example.customApplication.onCreate() 方法
如果工具顯示這些方法需要很長的時間才能完成執行，請深入瞭解當下進行中的作業為何。
內嵌追蹤記錄
使用內嵌追蹤記錄調查可能的問題情況，包括：
- 應用程式的初始
onCreate()函式。 - 應用程式初始化的任何全域單例模式物件。
- 瓶頸期間可能會發生的任何磁碟 I/O、去序列化或密集迴圈。
問題解決方案
潛在瓶頸有很多，以下是其中兩個常見的問題及補救方式：
- 檢視區塊階層越大，應用程式就需要越多時間加載。兩條
如要解決這個問題，請按照下列步驟操作：
- 減少多餘或巢狀版面配置，簡化您的檢視區塊階層。
- 請勿加載無須在啟動期間顯示的使用者介面部分，
請改用
ViewStub物件做為子階層的預留位置 讓應用程式可在更合適的時間加載
- 在主執行緒完成所有資源初始化作業也可能會降低啟動速度。您可以按照下列步驟解決這個問題：
- 移動所有資源初始化作業，讓應用程式可在 不同的討論串
- 允許應用程式載入及顯示檢視畫面，然後再更新視覺介面 相依於點陣圖和其他資源的屬性
自訂啟動畫面
如果您之前曾使用以下其中一種方法，在 Android 11 (API 級別 30) 以下版本中實作自訂啟動畫面，可能會發現啟動時需要更多時間：
- 使用
windowDisablePreview主題屬性關閉初始值 系統啟動的空白畫面。 - 使用專屬
Activity。
自 Android 12 起，必須遷移至 SplashScreen API。
此 API 可加快啟動時間，並可讓您針對
方法如下：
- 設定主題以變更啟動畫面外觀
- 使用
windowSplashScreenAnimationDuration控制啟動畫面的顯示時間長度 - 自訂啟動畫面動畫，然後妥善處理 用於關閉啟動畫面的動畫。
此外，compat 程式庫向後移植 SplashScreen API，以啟用
回溯相容，並打造與潑水效果一致的外觀和風格
顯示完整資訊
詳情請參閱「啟動畫面遷移指南」。
為您推薦
- 注意：系統會在 JavaScript 關閉時顯示連結文字
- 轉譯速度緩慢
- 擷取 Macrobenchmark 指標
- 建立基準設定檔{:#create-profile-rules}