启动速度

什么是 Android 的冷启动和热启动？

冷启动（Cold Start）和热启动（Warm Start）是指在 Android 应用启动过程中，应用所经历和执行的不同启动状态。

1）冷启动：冷启动是指应用从未在系统内存中运行过，或者说从完全关闭的状态启动。此时，系统需要完整地加载应用，包括创建新的进程、启动新进程所需的应用对象、执行应用程序的启动逻辑（比如Application类以及它的onCreate方法等）。这种启动通常耗时较长，因为需要进行更多的初始化操作。

2）热启动：热启动是指应用已经在后台运行并保留在系统内存中。当用户重新打开应用时，应用从后台切换到前台，通常只需要恢复活动等操作。因为大部分资源和初始化已经完成，所以相对来说启动时间较短。

扩展知识

1）启动模式(Start Mode)：对一个应用进行优化启动的方式有几种，比如增加启动图屏、减少应用启动时的动画过渡时间等，尤其应该注意避免在主线程中进行耗时操作。冷启动的优化是开发人员关注的重要点。

2）Android 应用的生命周期：了解冷启动和热启动必须理解 Android 应用的生命周期。比如，在冷启动时，应用会经历from scratch的创建所有组件的过程，而热启动则直接从暂停状态恢复来节省时间。

3）内存管理和进程优先级：Android对内存管理有自己的策略，如低内存状态下会进行进程杀掉。这直接影响了应用的启动状态，即应用在后台被杀掉重启就是冷启动，没有被杀掉就是热启动。这就涉及进程优先级和内存回收机制，Understanding memory management is key to optimizing your app for faster starts.

4）LaunchTime Measurement：如何测量冷启动和热启动时间？一般通过关键标记点，比如从系统调用"Activity.onCreate()"或者"Activity.onResume()"方法开始到绘制结束。Android Studio 提供了 Logcat Monitor 或 Profiler 工具，帮助开发者了解并优化启动时间。

如何优化 Android 的冷启动速度？

1）减少 Application 的初始化时间。比如，把一些可以延迟初始化的组件推迟到实际使用的时候再初始化。

2）缩短 onCreate 方法中的逻辑执行时间。 尽量避免在这个方法里面进行复杂计算或长时间的 IO 操作。

3）减少界面布局的过度嵌套和冗余布局。使用 ConstraintLayout 可以帮助减少层级。

4）优化资源加载。比如，提前加载一些重要资源，避免在冷启动时需要加载大体积的资源。

5）利用异步任务。当需要进行一些耗时操作时，可以考虑使用异步线程（如 AsyncTask 或 HandlerThread）来执行。

扩展知识

1）减少 Application 的初始化时间

  • 检查 Application 的 onCreate 方法，移除不必要的初始化操作。比如，数据库初始化可以推迟到第一次访问数据时，而不是立刻在 Application 启动时加载。
  • 使用 JobScheduler 或 WorkManager 将某些耗时任务推迟到适合的时间去执行。

2）优化 onCreate 方法

  • 重构代码确保 onCreate 方法中没有复杂逻辑或长时间阻塞的操作。
  • 如果当前的 onCreate 代码做了大量的网络请求或文件读写，可以考虑将这些操作放在后台线程执行，以免阻塞主线程。

3）优化界面布局

  • 使用 ConstraintLayout 这种扁平化的布局来代替包含大量层级嵌套的布局。
  • 使用 include 标签重用布局，减少复杂性和冗余。
  • 尽可能减少使用 wrap_content 和 match_parent 等属性，它们会引起多次测量和布局调整。

4）优化资源加载

  • 使用矢量图替代较大的 位图 可以减小 APK 大小，并加快加载速度。
  • 使用适当的资源压缩工具进行图片资源压缩，减少资源加载的时间。
  • 利用 LruCache 等缓存机制，缓存那些频繁使用的资源。

5）利用异步任务

  • 操作界面时尽量避免使用主线程做耗时操作，通过 AsyncTask, Executors, HandlerThread 等技术将耗时操作放在子线程中处理。
  • 使用 Handler 机制延迟某些非关键性任务，以释放 onCreate 方法的压力。

如何优化 Android 应用的启动速度？

1）精简应用启动代码：减少 Application 类中代码的执行量，拖延非必要初始化操作到应用的首次启动之后。

2）使用异步初始化：对于不需要在主线程上执行的初始化任务，使用线程或提高性能的第三方库（例如 Jetpack WorkManager）。

3）简化启动流程：优化和管理你的启动 Activity 中的布局，尽量减少布局的复杂性，这样可以减少绘制时间。

4）使用启动优化工具：使用 Android Profiler、Systrace、Perfetto等工具找出并优化启动瓶颈。

5）优化资源加载：提前加载静态资源，减少非必要资源的加载时间。

扩展知识

在优化 Android 应用启动速度时，有一些技术细节和工具的使用非常重要，下面来进一步扩展说明：

1）延迟初始化

  • 一些服务组件的初始化可以推迟到真正需要的时候，而不是在应用启动时。比如，起初不需要的第三方 SDK 初始化，可以在进入具体功能模块时进行初始化。

2）多进程优化

  • 考虑将一些重量级操作放在一个单独的进程中，这样即使这些操作比较耗时，也不会影响主进程的启动速度。例如，Service 可以在单独的进程运行。

3）预加载和预编译

  • 使用 Android App Bundle 和 Jetpack Compose 提高资源加载效率，优化启动速度。
  • 使用 AOT（Ahead-Of-Time）编译，减少 JIT（Just-In-Time）编译对启动时间的影响。

4）优化布局

  • 使用 ConstraintLayout 代替嵌套过多的 LinearLayout 和 RelativeLayout 减少布局绘制时间。
  • 尽量减少和优化 View 的数量，减少对 UI 布局的复杂操作。

5）减少应用体积

  • 使用 ProGuard 或 R8 工具优化代码结构，删除无用代码和资源，减少 APK 文件的体积，有助于减少启动时加载的时间。

6）使用 Android Profiler

  • Android Profiler 是 Android Studio 提供的一款性能分析工具，可以用于检测 CPU 使用率、内存占用等性能瓶颈。
  • 通过分析应用启动阶段的 CPU 和内存状况，找出需要优化的地方。

请问 Android 启动流程的四个阶段是什么？

Android 应用的启动流程基本可以分为四个主要阶段：

1）Zygote 进程启动

2）System Server 启动

3）Launcher 启动

4）Application 启动

这四个阶段环环相扣，共同构建了 Android 应用启动的整个流程。

扩展知识

以下是对每个阶段的详细解释，以及其中涉及的关键点和一些相关知识。

1）Zygote 进程启动： - Zygote 是 Android 系统中的一个非常特殊的进程，它的主要作用是负责孵化（fork）出新的应用进程。 - Zygote 进程使用预加载的类和资源来缩短应用启动时间。这减少了反复加载相同资源的开销，提升了启动性能。 - 当设备启动时，init 进程会启动 Zygote 进程，这个过程可以在 init.rc 脚本中找到相应配置。

2）System Server 启动： - System Server 是 Android 系统的核心服务进程，它运行一系列系统服务（如 Activity Manager、Window Manager 等），提供基本的系统功能。 - System Server 是由 Zygote 进程通过 fork 出来的，因此 zygote 需要首先完成初始化。 - System Server 的启动方式是在 Zygote 初始化完成后，通过 startSystemServer 方法启动。

3）Launcher 启动： - 当 System Server 启动后，接下来会通过 Activity Manager Service (AMS) 启动 Launcher 应用，也就是我们常看到的 Android 桌面。 - Launcher 作为标准的应用程序，其启动过程也遵循常规的 Android 应用启动流程。 - 它展示了主屏幕，并允许用户启动其它应用程序。

4）Application 启动： - 用户在 Launcher 上选择启动某个应用，这时会请求 Activity Manager Service (AMS) 来启动相应的应用。 - AMS 会首先检查应用是否已经在运行，如果没有则会请求 Zygote 进程 fork 出一个新的应用进程，然后通过反射调用应用的 ActivityThread.main 方法，最终启动应用的主 Activity。 - 这个过程包含了 Context 的创建、资源的加载、Activity 的启动等多个步骤。

Android 应用启动方法耗时分析 ?

Android 启动耗时分析的核心逻辑是：先通过 Logcat/ADB 定位总耗时→用 Startup Profiler 拆解各阶段耗时→用 Systrace 深入系统层面→针对性优化→验证效果。重点关注冷启动的 Application 和首屏 Activity 初始化阶段，优先解决主线程阻塞问题，最终目标是让冷启动耗时控制在 Google 建议的基线内（低端机 < 3s，中高端机 < 1.5s）

Android 应用启动耗时分析是优化应用性能的核心环节，启动慢会直接影响用户体验（如 ANR、用户流失）。本文从启动类型、耗时指标定义、分析方法、优化方向 四个维度，全面讲解如何精准分析并优化启动耗时。

一、先明确：Android 应用启动类型

不同启动类型的耗时基线和优化重点不同，先区分场景：

启动类型定义典型场景耗时基线（参考）
冷启动（Cold Start）应用进程完全销毁后首次启动（最耗时）首次安装打开、后台被杀后打开低端机 < 3s，中高端机 < 1.5s（Google 建议）
温启动（Warm Start）应用进程仍在内存，但 Activity 需重建按返回键退出后快速打开、系统回收 Activity 但保留进程通常 < 冷启动 50%
热启动（Hot Start）应用进程和 Activity 均存活（仅恢复界面）多任务切换回到应用通常 < 500ms

核心分析对象：冷启动（用户感知最明显，优化价值最高）。

二、启动耗时的核心指标（怎么算 “耗时”）

冷启动的完整耗时分为三个阶段（Google 官方定义），需精准拆解：

  1. 应用进程创建阶段（系统层面）：
    • 系统接收启动请求 → 拉起 Zygote 进程 fork 应用进程 → 加载应用 APK、创建 Application 对象。
  2. Application 初始化阶段（应用层面）：
    • Application#attachBaseContext() → Application#onCreate()（最易产生耗时的阶段）。
  3. Activity 初始化阶段：
    • Activity 对象创建 → onCreate() → onStart() → onResume()（直到界面可交互）。

关键耗时指标：

  • 总启动耗时：从用户点击图标 → 界面完全可交互（首帧渲染完成）的时间。
  • 首帧时间（First Frame）：应用界面首次绘制完成的时间（Google Play 核心指标）。
  • Application onCreate 耗时：单独统计该方法的执行时间。
  • Activity 初始化耗时：onCreate到onResume的耗时。

三、耗时分析方法（从易到难，覆盖全场景）

方法 1：利用 Android Studio 自带工具（最便捷）

1.1 Startup Profiler（启动分析器，推荐）

Android Studio Arctic Fox 及以上版本内置，精准追踪冷启动全流程：

  • 操作步骤：
    1. 打开 Android Studio → 连接真机 / 模拟器（建议真机，更贴近真实场景）。
    2. 点击Run旁的Profile按钮 → 选择Startup → 勾选Cold start → 点击Start profiling。
    3. 应用启动后，工具自动生成启动耗时报告，包含：
      • 总耗时、各阶段（Application/Activity）耗时占比；
      • 方法执行时间线（可定位到具体耗时方法）；
      • 线程占用、CPU / 内存使用情况。
  • 核心看点：
    • 时间轴中红色块：耗时过长的方法；
    • Application.onCreate和Activity.onCreate的执行时长；
    • 是否有主线程阻塞（如 IO、网络、同步锁）。
1.2 Logcat 日志（快速定位基础耗时）

系统默认输出冷启动关键日志，无需额外配置：

  • 过滤日志关键词：Displayed，格式如下：

    I/ActivityTaskManager: Displayed com.xxx.xxx/.MainActivity: +1s854ms

    含义：从启动到 Activity 界面显示的耗时（1 秒 854 毫秒）。

  • 补充：若想统计Application初始化耗时，可在attachBaseContext和onCreate中埋点打印时间戳：

    // Application类中
@Override
protected void attachBaseContext(Context base) {
    super.attachBaseContext(base);
    Log.d("Startup", "Application attachBaseContext start: " + System.currentTimeMillis());
}

@Override
public void onCreate() {
    long start = System.currentTimeMillis();
    super.onCreate();
    // 初始化代码...
    Log.d("Startup", "Application onCreate耗时: " + (System.currentTimeMillis() - start) + "ms");
}

方法 2：ADB 命令（精准无侵入）

通过 ADB 命令获取系统级启动耗时，避免应用埋点误差：

# 1. 重置启动耗时统计
adb shell am force-stop com.xxx.xxx

# 2. 启动应用并记录耗时（冷启动）
adb shell am start -W com.xxx.xxx/.MainActivity

Starting: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] cmp=com.xxx.xxx/.MainActivity }
Status: ok
LaunchState: COLD
Activity: com.xxx.xxx/.MainActivity
TotalTime: 1854  # 总耗时（毫秒），核心指标
WaitTime: 1900    # 系统等待应用启动的时间（略大于TotalTime）
Complete: true

方法 3：Systrace（深入系统层面）

若启动慢是因系统资源（如 CPU、IO、线程调度）导致，需用 Systrace 分析：

  • 操作步骤：

    1. 打开终端，执行命令（指定跟踪时间 10 秒）：

      python $ANDROID_HOME/platform-tools/systrace/systrace.py -t 10 -o startup_trace.html sched freq idle am wm app

    2. 立即点击应用图标启动应用，等待 10 秒后停止跟踪。

    3. 用 Chrome 打开startup_trace.html（地址栏输入chrome://tracing → 加载文件）。

  • 核心看点：

    • 主线程（main）是否有长时间阻塞（红色长条）；
    • 是否有大量 IO 操作（如读取本地文件、SP）占用主线程；
    • 是否有跨进程调用（如 AMS/WMS）耗时过长。

方法 4：第三方工具（线上监控）

以上方法适用于线下分析，线上需接入监控平台：

  • Firebase Performance：Google 官方，自动统计启动耗时、首帧时间；
  • 友盟 / 极光统计：支持启动耗时上报，可按设备 / 系统版本维度分析；
  • 字节跳动 ARouter / 美团 MTLeaks：可集成启动耗时监控模块。

四、常见耗时原因及优化方向（分析后落地）

分析出耗时点后，针对性优化：

常见耗时点优化方案
Application.onCreate 中初始化过多（如 SDK、数据库）1. 延迟初始化：非启动必需的 SDK（如统计、推送）放到首屏加载完成后；2. 异步初始化：用线程池 / 协程异步执行（注意线程安全）；3. 懒加载：用到时再初始化（如工具类、第三方 SDK）。
主线程 IO 操作（如读取 SP、本地文件、数据库）1. 将 IO 操作移到子线程；2. 优化 SP：减少 SP 键值对数量，避免getAll()；3. 数据库优化：提前创建索引，避免启动时全表查询。
首屏布局复杂（XML 解析耗时）1. 布局优化：减少层级（用 ConstraintLayout）、延迟加载非首屏 View（ViewStub）；2. 启动页简化：用 SplashScreen（Android 12+）替代复杂布局；3. 预加载布局：提前解析常用布局。
类加载 / 反射耗时（如插件化、路由框架）1. 减少启动时反射：提前预编译（如 ARouter 的 APT）；2. 优化类加载：减少无用依赖，混淆时保留核心类；3. 延迟加载插件：非启动必需的插件延后加载。
系统资源竞争（如 CPU / 内存不足）1. 避免启动时创建大量线程（控制线程池大小）；2. 减少启动时内存分配（如避免大对象创建）；3. 适配低配置设备：针对性降级策略。

五、验证优化效果

优化后需通过以下方式验证：

  1. 重复执行 ADB 冷启动命令，对比 TotalTime 是否下降；
  2. 用 Startup Profiler 确认耗时方法的执行时间减少；
  3. 线上监控（如 Firebase）观察启动耗时均值是否达标；
  4. 多设备测试（低端机 / 高端机、不同 Android 版本），确保优化效果一致。
最近更新：:
Contributors: luokaiwen