每次系统版本更新，渲染和启动优化总是最先被拿出来说的。方舟引擎在底层做了不少事，API 26 也确实在 ArkUI 渲染和启动链路上带来了改进。但一个应用“感觉变快了”和“真的快了”，中间隔着一段很长的路。

对产品经理来说，这段路的关键词只有一个：先量化。

用户不关心毫秒，他关心“能不能马上用”

“启动时间”是一个容易被偷懒的概念。进程启动算启动，首帧算启动，可交互算启动，数据加载完也算启动——口径不同，结论可以完全相反。

用户真正在意的是这几件事：打开之后多久能点、列表会不会先白一下再猛跳、滑起来跟不跟手、切页面的时候会不会顿半秒。把这些体感翻译成可测的指标，优化才有靶子。

一个实用的做法是按场景拆指标，而不是追求一个笼统的“启动速度”：

启动慢，先看主线程被谁“堵”住了

冷启动是一条串行链：进程创建 → AbilityStage 初始化 → UIAbility 创建和页面加载 → 首帧渲染 → 数据就绪。只有卡在这条链上的耗时，才是真正拖慢打开的“关键路径”。子线程里跑了 800 毫秒的初始化，只要不挡首帧，对启动时间的影响就有限。

问题在于，很多团队把所有初始化都塞进了这条链里。同步打开数据库、同步解析大 JSON、在 aboutToAppear 里直接发网络请求——每一个都在替用户“等”。

可落地的第一步：给启动链路打上时间戳。 ArkTS 侧可以用 hiTraceMeter 给每个启动任务包一层，抓出来的 trace 导入 DevEco Studio 的 Profiler，就能看到主线程时间轴上每一段到底占了多少：

import { hiTraceMeter } from '@kit.PerformanceAnalysisKit';

class StartupTracer {
  static sync<T>(name: string, block: () => T): T {
    const id = Date.now();
    hiTraceMeter.startTrace(name, id);
    try {
      return block();
    } finally {
      hiTraceMeter.finishTrace(name, id);
    }
  }
}

// 在 AbilityStage.onCreate 中包住每一个初始化
StartupTracer.sync('init_logger', () => Logger.init(context));
StartupTracer.sync('init_db', () => Db.open(context));   // 如果这一段很长，它就是嫌疑人
StartupTracer.sync('init_push', () => Push.register(context));

读 trace 的时候重点找三类东西：大块串行段（某个 init 在主线程占了 200ms 以上）、空转间隙（主线程在等子线程或 IPC）、首帧之前不该出现的东西（广告 SDK、埋点上报、非首屏模块）。

找到之后，处理手段按优先级排列：能在首帧后做的，全部延后；能下子线程的 CPU/IO 任务，用 taskpool 并行；首屏只构建可见部分，其余用条件渲染收敛。API 26 还提供了 perfHint，可以在启动场景向系统申请调度资源倾斜，EntryAbility 创建后开启，首屏渲染完成后关闭，作为一个辅助手段配合使用。

列表卡顿，八成不是“渲染太慢”

长列表是体感问题最集中的地方。很多团队的第一反应是调大 cachedCount，但缓存参数解决不了结构性问题。

真正的原因通常是三个：一次性全量构建、缺少节点复用、状态作用域过大。用 ForEach 渲染几千条数据，组件挂载时就会创建全部子节点，首屏不白才奇怪。

正确的组合是 LazyForEach + @Reusable + 合理的 cachedCount。LazyForEach 只构建视口和缓存区内的项；@Reusable 让下屏的组件实例进入复用池，上屏时通过 aboutToReuse 更新数据，省掉 build() 重建；cachedCount 一般设在 3 到 5 之间，太小快速滑动会露白，太大内存和初始构建压力都会上去。

// 可复用项组件：局部状态下沉在内部
@Component
export struct ItemCard {
  @State isLiked: boolean = false;
  @State title: string = '';
  @State amount: string = '';

  aboutToReuse(params: Record<string, Object>): void {
    this.title = params.title as string;
    this.amount = params.amount as string;
    this.isLiked = params.isLiked as boolean;
  }

  build() {
    Row() {
      Column() {
        Text(this.title).fontSize(16)
        Text(this.amount).fontSize(20).fontColor('#FF6A00')
      }.alignItems(HorizontalAlign.Start)
      Image(this.isLiked ? $r('app.media.ic_liked') : $r('app.media.ic_like'))
        .width(24)
        .onClick(() => { this.isLiked = !this.isLiked; })
    }.padding(12)
  }
}

注意 isLiked 是放在 ItemCard 内部的 @State，而不是挂在父列表的数组上。如果整张列表的数据放在父组件的 @State 里，任何一条的点赞变化都会触发父组件 build，连带所有 item 重算。让该变的变，不该变的别动，这句话在列表性能上比任何参数调优都管用。

图片和首屏数据：把“等待”藏起来

列表里的图片如果按原图尺寸解码，一张 4K 图在手机屏幕上显示，解码耗时和内存占用都是不必要的浪费。ArkUI 的图片解码支持下采样：指定期望输出尺寸，解码器按最优采样率输出，JPEG、PNG、HEIF 格式在解码阶段就会降低分辨率，而不是先完整解一张大图再缩放。

async function downsampleDecode(imageSource: image.ImageSource) {
  const options: image.DecodingOptions = {
    desiredSize: { width: 512, height: 512 }  // 按显示区域给，不要给原图尺寸
  };
  return await imageSource.createPixelMap(options);
}

首屏数据也是同一个逻辑：不要等网络。先同步读本地缓存把页面渲染出来，网络返回后再静默更新。用户看到的是“秒开”，实际上是缓存先兜住了第一帧。配合骨架屏使用效果更好——数据没回来之前，先把页面的大致轮廓撑起来，比一个转圈加载更能让人感知到“内容正在来”。

量化不是写一份报告，是建一条回归门槛

DevEco Studio 的 Profiler 提供了两个对口的模板：Launch 用来拆启动阶段的耗时，Frame 用来定位卡顿丢帧。Frame 泳道里正常帧是绿色，卡顿帧是红色，一帧的期望耗时在 60fps 下是 16.6ms，超过这个时间就是体感风险的信号。

但工具本身不产生结论。有效的量化需要做到三件事：

固定条件。 同一台设备、同一网络、同一数据规模和操作步骤。冷启动要杀进程，不能拿“热启动”冒充。

看中位数和长尾，不看单次最好成绩。 每组至少采集 20 到 30 次，记录 P50 和 P95，P95 才是用户偶尔会撞上的“倒霉时刻”。

把结果变成门槛，而不是一次性报告。 关键页面的首屏时延设一个预算，启动和滚动场景的 P95 不超过某个阈值，版本迭代后如果回退超过 5% 或 30ms，就值得停下来查。这样性能才不是“这次优化完就结束”的运动，而是每次发版都在守的一条线。

最后一句

方舟引擎把系统级的底子铺好了，但应用侧的首屏构建、资源解码、同步 IO 和状态刷新，系统替不了。产品经理不需要自己去写 LazyForEach，但需要推动团队在做任何“快了 X%”的宣称之前，先回答一个问题：这个数字，是在什么设备、什么数据、什么口径下测出来的，能不能重复。

能重复的测量，才能变成下一轮优化决策的依据。先找到瓶颈，再决定动哪一层——这比任何一次演示视频都更接近真实的“快”。