冷启动是用户对一个应用的第一印象。很多团队做启动优化时习惯"东砍一刀西砍一刀"，删了几个初始化、加了个懒加载，数据却没什么变化。根本原因是：没有先拿到瀑布图，就没有关键路径，优化自然无的放矢。本文围绕 HarmonyOS 应用冷启动，讲清楚三件事：冷启动各阶段到底发生了什么、如何用 HiTrace / DevEco Profiler 拿到一张可信的瀑布图、以及如何据此裁剪关键路径并量化收益。
一、冷启动到底经历了哪些阶段
在 Stage 模型下，一次冷启动从用户点击图标到首帧可交互，大致经过以下阶段：
- 进程创建：AMS 调度、应用进程 fork、运行时初始化（ArkTS 运行时、字节码加载）；
- AbilityStage 初始化：
AbilityStage.onCreate()执行，通常承载全局初始化； - UIAbility 生命周期：
onCreate()→onWindowStageCreate()，窗口创建、loadContent加载首页； - 首页构建与渲染：ArkUI 组件树 build、measure/layout、首帧提交；
- 数据就绪与可交互：首屏数据返回、列表填充，达到 TTI（Time To Interactive）。
关键认知：只有位于"点击 → 首帧"这条串行链路上的耗时才是关键路径。一个在子线程里跑了 800ms 的初始化，如果不阻塞主线程和首帧，就不在关键路径上，砍掉它对启动时间毫无帮助。瀑布图的意义就是把"串行阻塞的部分"和"并行无害的部分"区分开。
二、拿到一张可信的瀑布图
2.1 用 HiTrace 打自定义 trace 点
系统 trace 只能看到框架级事件，业务初始化必须自己插桩。ArkTS 侧用 hiTraceMeter：
import {
hiTraceMeter } from '@kit.PerformanceAnalysisKit';
export class StartupTracer {
private static seq = 0;
static sync<T>(name: string, block: () => T): T {
const id = StartupTracer.seq++;
hiTraceMeter.startTrace(name, id);
try {
return block();
} finally {
hiTraceMeter.finishTrace(name, id);
}
}
static async async<T>(name: string, block: () => Promise<T>): Promise<T> {
const id = StartupTracer.seq++;
hiTraceMeter.startTrace(name, id);
try {
return await block();
} finally {
hiTraceMeter.finishTrace(name, id);
}
}
}
把它包在每一个启动期任务外面：
export default class MyAbilityStage extends AbilityStage {
onCreate(): void {
StartupTracer.sync('init_logger', () => Logger.init(this.context));
StartupTracer.sync('init_network', () => HttpClient.init());
StartupTracer.sync('init_db', () => Db.open(this.context)); // 嫌疑最大的通常在这
StartupTracer.sync('init_push', () => Push.register(this.context));
}
}
2.2 抓取与查看
用 DevEco Studio 的 Profiler（Launch 模板）或命令行抓 trace：
# 设备上抓 5 秒 trace，覆盖冷启动全过程
hdc shell hitrace -t 5 -b 20480 app ohos ability ace > startup.ftrace
抓取前先 hdc shell aa force-stop <bundleName> 杀掉进程保证是冷启动。把 trace 导入 Profiler 后，你会得到主线程时间轴：自定义 trace 点会和框架事件（Ability 生命周期、build、layout、首帧）排在同一条时间线上——这就是瀑布图。
2.3 读图：找三类问题
- 大块串行段：某个
init_xxx在主线程占了 200ms+，典型如同步开数据库、同步读文件、同步反序列化大 JSON； - 空转间隙：两个阶段之间有几十毫秒空白，常见原因是主线程在等某个子线程/IPC 结果；
- 首帧之前不该出现的东西：埋点上报、广告 SDK、非首屏模块的初始化。
我在一个中型项目上实测的首次瀑布图（模拟真机，冷启动，取 10 次中位数）：
| 阶段 | 耗时 | 是否关键路径 |
|---|---|---|
| 进程创建 + 运行时 | 210ms | 是 |
| AbilityStage.onCreate（4 个 init 串行） | 470ms | 是 |
| onWindowStageCreate + loadContent | 180ms | 是 |
| 首页 build + 首帧 | 320ms | 是 |
| 首屏数据请求（并行） | 380ms | 部分 |
| 点击到首帧 | 1180ms |
init_db（280ms，同步建表 + 迁移检查）和 init_push（110ms，同步 IPC）是最大的两块可裁剪项。
三、关键路径裁剪：四个手段按优先级来
3.1 延迟：不在首帧前做的事，一律推迟
推送注册、埋点上报、更新检查，全部挪到首帧之后。可以监听首帧完成再触发：
onWindowStageCreate(windowStage: window.WindowStage): void {
windowStage.loadContent('pages/Index', () => {
// 首帧提交后再做非关键初始化
setTimeout(() => {
StartupTracer.sync('init_push_deferred', () => Push.register(this.context));
StartupTracer.sync('init_report', () => Analytics.init());
}, 0);
});
}
3.2 并行：能下子线程的下子线程
数据库打开、配置文件解析这类 CPU/IO 任务用 taskpool 并行，主线程只在真正需要结果时 await：
import {
taskpool } from '@kit.ArkTS';
@Concurrent
function openDatabase(ctx: Context): void {
Db.open(ctx); // 建表、迁移都在子线程完成
}
export default class MyAbilityStage extends AbilityStage {
onCreate(): void {
// 不 await，让它和 UI 构建并行
AppState.dbReady = taskpool.execute(openDatabase, this.context);
}
}
首页真正读库时 await AppState.dbReady 即可。注意跨线程传递的数据要满足 Sendable 约束，Context 相关初始化需确认 API 支持在并发函数中调用，不支持的（如部分 UI 相关 API）留在主线程但延迟执行。
3.3 裁剪：首帧只画骨架
首页 build 的 320ms 里，有多少是首屏看不见的？常见问题：首页一次性 build 了 Tab 下所有子页面。用懒加载 + 条件渲染收敛：
Tabs() {
TabContent() {
HomePage() }.tabBar('首页')
TabContent() {
if (this.mineVisited) {
MinePage() } // 首帧不构建
}.tabBar('我的')
}
配合骨架屏：首帧渲染静态骨架（无数据依赖），数据到达后局部刷新，把"首帧时间"和"数据就绪时间"解耦。
3.4 预置：把串行 IO 变成预热
对必须在启动早期读取的配置（如上次登录态），用 Preferences 替代文件 + JSON 解析，并在上一次运行时就把数据写好，启动时只做一次轻量读取。
四、裁剪后的数据
同一设备、同一统计口径（10 次冷启动取中位数）：
| 指标 | 优化前 | 优化后 | 变化 |
|---|---|---|---|
| AbilityStage.onCreate | 470ms | 90ms | -380ms |
| 首页 build + 首帧 | 320ms | 210ms | -110ms |
| 点击到首帧 | 1180ms | 690ms | -41.5% |
| 点击到可交互（TTI） | 1620ms | 1080ms | -33.3% |
其中收益最大的三项：数据库初始化下子线程（-280ms）、推送注册延迟到首帧后（-110ms）、Tab 子页面懒构建（-90ms）。
五、方法论沉淀
- 先测量，后优化：没有瀑布图不动手。每次优化前后用同一口径抓 10 次取中位数，避免被抖动骗了。
- 只看关键路径：判断一个任务值不值得优化，唯一标准是它是否阻塞"点击 → 首帧 / TTI"这条串行链。
- 优先级：延迟 > 并行 > 裁剪 > 压缩：把任务挪出关键路径的收益，通常远大于把任务本身做快。
- 防劣化：把
StartupTracer的关键区间在发布版本降级为耗时统计上报，设阈值告警，防止后续迭代把启动时间又堆回去。
启动优化不是一次性冲刺，而是"瀑布图 → 裁剪 → 再测量"的循环。把插桩和统计口径固化到工程里，团队里任何人加的启动逻辑都逃不过下一张瀑布图。
