应用优化最佳实践
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
下面的最佳实践有助于您在不牺牲质量的情况下优化应用。
使用基准配置文件
基准配置文件可以在应用首次启动后将代码执行速度提高 30%,还可让所有用户互动(例如启动应用、切换界面或滚动内容)从首次运行起就更顺畅。提升应用的速度和响应能力有助于提高日活跃用户数和平均回访率。
使用启动配置文件
启动配置文件与基准配置文件类似,但它会在编译时运行以优化 DEX 布局,进而加快应用启动速度。
使用 App Startup 库
借助 App Startup 库,您可以定义共用同一个 content provider 的组件初始化程序,而无需为需要初始化的每个组件定义单独的 content provider。这可以显著缩短应用启动时间。
延迟加载库或停用自动初始化功能
应用会使用许多库,其中一些在启动期间可能是必需的。不过,还有很多库的初始化可以延迟到第一帧绘制完毕之后。对于某些库,您可以选择在启动时停用自动初始化功能,或使用按需初始化模式。通过上述方法将初始化推迟到必要时进行,有助于提升性能。例如,您可以使用按需初始化模式,仅在需要 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 图片。
此外,您应尽量减少启动期间加载的图片的数量和大小。
适用于媒体播放的性能 API 可在 Android 12(API 级别 31)及更高版本上使用。您可以使用此 API 了解设备功能并相应地执行操作。
优先考量冷启动跟踪记录
冷启动是指应用从头开始启动。这意味着系统的进程尚未创建应用的进程。一般而言,如果您在设备启动或系统强制应用停止后初次启动应用,执行的就是冷启动。冷启动比其他类型的启动方式(例如温启动和热启动)要缓慢得多,因为应用和系统都必须执行更多工作。通过系统跟踪冷启动,您可以更好地了解应用性能。
为您推荐
本页面上的内容和代码示例受内容许可部分所述许可的限制。Java 和 OpenJDK 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):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"]],["最后更新时间 (UTC):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)"]]