摘要

在鸿蒙（HarmonyOS / OpenHarmony）应用开发中，很多开发者在功能完成后都会遇到一个问题：
页面不算复杂，但 CPU 使用率却一直偏高，真机一跑就发热、掉帧，Profiler 一看主线程红成一片。

实际开发中，CPU 占用过高往往不是某一行代码“算得慢”，而是：

• 线程模型不合理
• UI 刷新频率失控
• 任务调度方式不符合真实业务场景

本文结合真实开发过程，从 CPU 定位 → 代码调整 → 业务场景优化 三个层面，系统讲清楚鸿蒙应用中 CPU 使用率优化的核心思路，并给出可以直接运行的 ArkTS 示例。

引言

随着鸿蒙应用逐步从 Demo 走向真实业务，页面复杂度、动画数量、列表规模都会快速增长。
尤其是在资讯流、设备控制面板、数据看板这类页面中，CPU 压力会被无限放大。

在很多项目中我看到的现象是：

• 页面看起来没做什么，但 CPU 常年 30% 起步
• 一滑列表，CPU 直接冲到 70%
• 页面切后台后，CPU 还在跑

这些问题如果不在早期解决，后期基本只能靠“砍功能”止血。

先定位问题，而不是一上来就改代码

使用 DevEco Studio CPU Profiler

优化前，第一件事一定是确认 CPU 消耗在哪里。

在 DevEco Studio 中：

1. 打开 Profiler → CPU
2. 真机运行应用
3. 执行一次 CPU 明显偏高的操作（滑动、刷新、动画）
4. 停止录制，查看调用栈

重点关注三点：

• 主线程（UI Thread）是否长时间占用
• 是否有函数被高频调用
• 是否存在明显的循环或定时任务

很多时候你会发现：
CPU 高的根因并不在你以为的地方。

主线程是 CPU 的“高危区”

主线程直接计算的典型问题

在真实项目中，经常能看到类似的写法：

// ArkTS
onPageShow() {
  for (let i = 0; i < 10_000_000; i++) {
    Math.sqrt(i)
  }
}

这种代码在逻辑上没有任何问题，但问题在于：

• 页面刚显示就开始重计算
• UI 渲染和计算抢占同一个线程
• CPU 和卡顿一起出现

在 Profiler 中，这类问题非常明显：
主线程时间轴被完整占满。

使用 Worker 把“重活”挪走

鸿蒙提供了 Worker 机制，本质就是把耗时任务丢到子线程。

主线程代码

// main.ets
import worker from '@ohos.worker';

let calcWorker = new worker.Worker('workers/calcWorker.ets');

onPageShow() {
  calcWorker.postMessage({ count: 10_000_000 })
}

onPageHide() {
  calcWorker.terminate()
}

Worker 线程代码

// workers/calcWorker.ets
onmessage = (e) => {
  let count = e.data.count
  for (let i = 0; i < count; i++) {
    Math.sqrt(i)
  }
  postMessage('done')
}

这样处理之后：

• 主线程只负责 UI 和交互
• 计算任务完全不影响页面流畅度
• CPU 峰值明显下降

在真实业务中，只要你看到 大循环、数据批处理、解析逻辑，基本都应该第一时间考虑 Worker。

CPU 经常被“无意义刷新”拖垮

高频定时器刷新 UI 的问题

很多页面为了显示时间、状态、进度，会直接写定时器：

setInterval(() => {
  this.time = Date.now()
}, 10)

这种写法在功能上没问题，但代价是：

• 每 10ms 触发一次状态更新
• ArkUI 不断触发重建
• CPU 长时间维持高位

在真实设备上，这种代码会直接导致发热。

用“业务节奏”控制刷新频率

更合理的方式是：

setInterval(() => {
  this.time = Date.now()
}, 1000)

或者直接基于事件驱动：

if (newValue !== this.oldValue) {
  this.value = newValue
}

在实际项目中，UI 刷新频率永远不需要比人眼感知更快。
能用事件触发的地方，尽量别用定时轮询。

列表和组件重建是 CPU 隐形杀手

组件反复重建的问题

build() {
  Column() {
    if (this.showList) {
      ForEach(this.bigList, item => {
        HeavyItem({ data: item })
      })
    }
  }
}

这种写法在数据量稍大时，CPU 会明显偏高：

• 状态变化 → 整个列表重建
• 每个 Item 都重新创建
• 滑动时 CPU 波动明显

使用 LazyForEach 控制构建范围

build() {
  List() {
    LazyForEach(this.dataSource, (item) => {
      ListItem() {
        LightItem({ data: item })
      }
    })
  }
}

这种方式的核心优势在于：

• 只构建当前可见区域
• 滑动时不会触发全量重建
• CPU 和内存压力同步下降

在资讯流、电商列表、设备列表中，这是必须做的优化项。

动画和图片对 CPU 的影响经常被低估

动画不暂停，CPU 永远下不来

如果页面有动画，但没有在页面隐藏时处理：

onPageHide() {
  this.isAnimating = false
}

那么页面退后台后：

• 动画仍然在跑
• CPU 一直被占用
• 用户完全感知不到，但设备在发热

图片尺寸一定要贴合组件

Image($r('app.media.thumb'))
  .width(100)
  .height(100)

真实项目中经常出现的问题是：

• 使用超大原图
• 运行时再缩放
• 解码和缩放都消耗 CPU

图片资源本身就是性能优化的一部分。

几个真实应用场景的 CPU 优化案例

场景一：设备状态面板

问题

• 定时轮询设备状态
• 每 50ms 更新 UI

优化

• 改为设备事件上报
• 仅状态变化时刷新 UI

onDeviceStatusChange(status) {
  if (status !== this.lastStatus) {
    this.deviceStatus = status
  }
}

场景二：大数据列表页面

问题

• ForEach 全量渲染
• 滑动时 CPU 峰值过高

优化

• LazyForEach
• Item 组件轻量化

LazyForEach(this.dataSource, (item) => {
  SimpleItem({ data: item })
})

场景三：后台数据处理页面

问题

• 数据解析直接在主线程执行
• 页面操作明显卡顿

优化

• 使用 Worker 处理解析逻辑
• 主线程只接收结果

worker.postMessage(rawData)

QA：开发中最常见的几个问题

Q：CPU 高但页面不卡，还要不要优化？
A：要。长期高 CPU 会导致发热、耗电、系统降频。

Q：Worker 会不会增加复杂度？
A：合理封装后，复杂度远低于性能问题带来的维护成本。

Q：Profiler 一定要真机吗？
A：是的，模拟器的数据参考价值有限。

总结

鸿蒙应用中 CPU 优化的核心，不是让代码“算得更快”，
而是：

别在不该算的时候算，
别在主线程算，
别为了省事而持续刷新。

只要做到这三点，大多数 CPU 问题都会自然消失。