讓應用程式更臻完善的最佳做法
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
只要採用下列最佳做法,即可在不犧牲品質的前提下,充分提升應用程式效能。
使用基準設定檔
基準設定檔可以在首次啟用後讓程式碼執行速度提高 30%,也能讓所有使用者互動從首次執行起就更順暢,例如啟動應用程式、切換不同畫面或捲動內容等互動。提升應用程式的速度和回應能力,也有助於增加每日活躍使用人數,並提高平均回訪率。
使用啟動設定檔
啟動設定檔與基準設定檔類似,但會在編譯期間執行,將 DEX 版面配置最佳化,進而加快應用程式啟動速度。
使用 App Startup 程式庫
使用 App Startup 程式庫時,您可以定義共用單一內容供應器的元件初始化器,不必為每個需要初始化的元件定義不同的內容供應器。這麼做可大幅縮短應用程式啟動時間。
延遲載入程式庫或停用自動初始化
應用程式使用的程式庫不計其數,有些或許必須在啟動時使用,但不少程式庫也能延後到第一個影格繪製後才初始化。對於某些程式庫,您可以選擇停止在啟動時自動執行初始化,或依需求執行初始化。這樣一來,即可將初始化作業延後到有需要時再執行,協助增進效能。舉例來說,您可以使用隨選初始化,只在需要 WorkManager 時叫用此元件。
使用 ViewStub
ViewStub
是大小為零的隱藏 View
,可用於在執行階段延後加載版面配置資源,方便您延後加載不須用於應用程式啟動程序的檢視畫面。
使用 Jetpack Compose 時,您可以使用狀態來延遲載入部分元件,執行與 ViewStub
類似的行為:
var shouldLoad by remember {mutableStateOf(false)}
if (shouldLoad) {
MyComposable()
}
修改 shouldLoad
,在條件式區塊中載入可組合函式:
LaunchedEffect(Unit) {
shouldLoad = true
}
這會觸發重組,其中包含第一個程式碼片段中條件式區塊內的程式碼。
最佳化啟動畫面
啟動畫面是應用程式啟動程序的重要部分,使用精心設計的啟動畫面有助於提升應用程式的整體啟動體驗。Android 12 (API 級別 31) 以上版本包含可提升效能的啟動畫面。詳情請參閱「啟動畫面」。
使用可擴充的圖片類型
我們建議優先使用向量可繪項目這種格式的圖片,如果不可行,再使用 WebP 圖片。WebP 是一種圖片格式,可對網路圖片提供效果卓越的有損和無損壓縮檔案。您可以使用 Android Studio,將現有的 BMP、JPG、PNG 或靜態 GIF 圖片轉換為 WebP 格式。詳情請參閱「建立 WebP 圖片」。
此外,請盡量減少啟動期間載入的圖片,並避免載入大型圖片。
Android 12 (API 級別 31) 以上版本支援媒體播放用的效能 API。您可以運用這個 API 掌握裝置性能,據此執行相應作業。
優先考量冷啟動追蹤記錄
冷啟動是指應用程式從頭開始啟動,也就是從系統程序尚未建立應用程式程序時開始啟動。一般而言,若是在裝置開機或系統強制停止後首次啟動應用程式,就會執行冷啟動。比起暖啟動和熱啟動等其他啟動類型,冷啟動的速度緩慢許多,因為應用程式和系統需要執行更多作業。您可以利用系統追蹤冷啟動,更有效監控應用程式效能。
為您推薦
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。Java 與 OpenJDK 是 Oracle 和/或其關係企業的商標或註冊商標。
上次更新時間:2025-07-27 (世界標準時間)。
[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["缺少我需要的資訊","missingTheInformationINeed","thumb-down"],["過於複雜/步驟過多","tooComplicatedTooManySteps","thumb-down"],["過時","outOfDate","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["示例/程式碼問題","samplesCodeIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間:2025-07-27 (世界標準時間)。"],[],[],null,["# Best practices for app optimization\n\nThe following best practices help optimize your app without sacrificing quality.\n\nUse Baseline Profiles\n---------------------\n\n[Baseline Profiles](/topic/performance/baselineprofiles/overview) can improve\ncode execution speed by 30% from the first launch, and can make all user\ninteractions---such as app startup, navigating between screens, or scrolling\nthrough content---smoother from the first time they run. Increasing the speed and\nresponsiveness of an app leads to more daily active users and a higher average\nreturn visit rate.\n\nUse a startup profile\n---------------------\n\nA\n[startup profile](/topic/performance/baselineprofiles/dex-layout-optimizations#startup-profiless)\nis similar to a Baseline Profile, but it is run at compile time to optimize the\nDEX layout for faster app startup.\n\nUse the App Startup library\n---------------------------\n\nThe [App Startup library](/topic/libraries/app-startup) lets you define\ncomponent initializers that share a single content provider, instead of defining\nseparate content providers for each component you need to initialize. This can\nsignificantly improve app startup time.\n\nLazily load libraries or disable auto-initialization\n----------------------------------------------------\n\nApps consume many libraries, some of which might be mandatory for startup.\nHowever, there can be many libraries where initialization can be delayed until\nafter the first frame is drawn. Some libraries have an option to disable\nauto-initialization on startup or have an on-demand initialization. Use this\noption to postpone initialization until necessary to help boost performance. For\nexample, you can use\n[on-demand initialization](/topic/libraries/architecture/workmanager/advanced/custom-configuration)\nto only invoke WorkManager when the component is required.\n\nUse ViewStubs\n-------------\n\nA [`ViewStub`](/reference/android/view/ViewStub) is an invisible, zero-sized\n`View` that you can use to lazily inflate layout resources at runtime. This\nlets you delay inflating views that aren't necessary at startup until a later\ntime.\n\nIf you are using Jetpack Compose, you can get similar behavior to `ViewStub`\nusing state to defer loading some components: \n\n var shouldLoad by remember {mutableStateOf(false)}\n\n if (shouldLoad) {\n MyComposable()\n }\n\nLoad the composeables inside the conditional block by modifying `shouldLoad`: \n\n LaunchedEffect(Unit) {\n shouldLoad = true\n }\n\nThis triggers a recomposition that includes the code inside the conditional\nblock in the first snippet.\n\nOptimize your splash screen\n---------------------------\n\nSplash screens are a major part of app startup, and using a well-designed\nsplash screen can help improve the overall app startup experience. Android\n12 (API level 31) and later includes a splash screen designed to improve\nperformance. For more information, see [Splash\nscreen](/about/versions/12/features/splash-screen).\n\nUse scalable image types\n------------------------\n\nWe recommend using [vector\ndrawables](/develop/ui/views/graphics/vector-drawable-resources) for images.\nWhere it's not possible, use [WebP\nimages](https://developers.google.com/speed/webp/). WebP is a image format\nthat provides superior lossless and lossy compression for images on the web. You\ncan convert existing BMP, JPG, PNG or static GIF images to WebP format using\nAndroid Studio. For more information, see [Create WebP\nimages](/studio/write/convert-webp).\n\nAdditionally, minimize the number and size of images loaded during startup.\n\nUse Performance APIs\n--------------------\n\nThe [performance API for media\nplayback](/about/versions/12/features/performance-class) is available on Android\n12 (API level 31) and later. You can use this API to understand device\ncapabilities and perform operations accordingly.\n\nPrioritize cold startup traces\n------------------------------\n\nA [cold start](/topic/performance/vitals/launch-time#cold) refers to an app\nstarting from scratch. Meaning, the system's process doesn't yet create the\napp's process. Your app typically starts cold if you launch it for the first\ntime since the device booted or since the system force-stopped the app. Cold\nstarts are much slower because the app and system must perform more work that\nisn't required on other startup types---like warm and hot starts. System tracing\ncold startups gives you better oversight into app performance.\n\nRecommended for you\n-------------------\n\n- Note: link text is displayed when JavaScript is off\n- [App startup analysis and optimization {:#app-startup-analysis-optimization}](/topic/performance/appstartup/analysis-optimization)\n- [App startup time](/topic/performance/vitals/launch-time)\n- [Frozen frames](/topic/performance/vitals/frozen)"]]