网罗开发 （小红书、快手、视频号同名）

  大家好，我是 展菲，目前在上市企业从事人工智能项目研发管理工作，平时热衷于分享各种编程领域的软硬技能知识以及前沿技术，包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。

图书作者：《ESP32-C3 物联网工程开发实战》
图书作者：《SwiftUI 入门，进阶与实战》
超级个体：COC上海社区主理人
特约讲师：大学讲师，谷歌亚马逊分享嘉宾
科技博主：华为HDE/HDG

我的博客内容涵盖广泛，主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告，同时也会提供产品优缺点分析、横向对比，并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。

展菲：您的前沿技术领航员
👋 大家好，我是展菲！
📱 全网搜索“展菲”，即可纵览我在各大平台的知识足迹。
每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。

引言

很多人第一次做鸿蒙 PC 时，都会有一种错觉：

PC 性能那么强
应该不会卡吧？

结果项目一上线，很快就会遇到这些问题：

• 多窗口切换掉帧
• ArkUI 滚动卡顿
• 输入延迟明显
• 状态更新越来越慢
• CPU 占用飙升
• AI Task 一跑整个 UI 卡死
• 内存越来越高
• Workspace 越切越重

最开始很多人会以为：

是不是 ArkUI 性能不行？

于是开始：

• 疯狂优化组件
• 到处加缓存
• 强行拆页面
• 拼命减少动画

但优化半天之后，你会慢慢发现：

真正的问题，往往根本不在 UI。

而在：

状态系统失控

因为在鸿蒙 PC 上：

性能问题，本质是“状态流问题”。

一、为什么鸿蒙 PC 的性能问题会越来越复杂

传统 App：

一个页面
一个状态
一次渲染

复杂度相对有限，但鸿蒙 PC：

多窗口
多 Workspace
多状态流
AI Runtime
分布式同步

意味着：

系统始终在“持续运行”。

也就是说：

性能问题不再是“瞬时”
而是“持续累积”

二、最大的性能误区：把问题归因于 UI

很多团队第一反应：

是不是组件太多？

于是开始：

• 减少节点
• 精简布局
• 减少动画

这些当然有用，但真正的大问题通常来自：

状态更新风暴

三、真正的性能黑洞：状态扩散

这是我踩过最大的坑之一，项目初期：

globalStore.user = user

看起来没问题，但后面：

• 多页面监听
• 多窗口监听
• AI Task 监听
• Workspace 同步

结果：

一次状态更新
触发几十次重渲染

最后：

整个系统开始持续卡顿

四、鸿蒙 PC 真正的优化核心：减少“状态传播”

后来我们才真正意识到：

性能优化的核心，不是“少渲染”。

而是：

减少状态扩散

这是本质区别。

五、第一个关键优化：状态分层

很多项目最大的问题：

所有状态都放 GlobalStore

例如：

globalStore.orders
globalStore.messages
globalStore.workspace

后果：

任何修改
整个系统都在刷新

后来我们改成：

GlobalState
 ↓
WorkspaceState
 ↓
UIState

之后性能直接稳定很多。

六、第二个关键优化：Workspace 隔离

这个优化收益极大，以前：

所有窗口共享同一状态树

结果：

• WindowA 更新
• WindowB 也刷新

CPU 直接飙升，后来：

workspaceA.state
workspaceB.state

完全隔离，之后：

窗口之间不再互相污染

性能提升非常明显。

七、第三个关键优化：Focus 独立运行

这个坑很多人会忽略，最开始我们的 Focus：

直接写在 UI State

结果：

• 鼠标移动
• 键盘切换
• Tab 切换

都会触发：

大量 UI 更新

后来单独做：

FocusCenter

并且：

Focus 不参与 UI Diff

输入延迟明显下降。

八、第四个关键优化：不要在 build 里做任何逻辑

这是 ArkUI 最容易踩的坑，很多人会写：

build() {
  this.loadData()
}

或者：

build() {
  calculate()
}

后面一定会出现：

重复执行风暴

因为：

build 不是生命周期
而是状态映射

后来我们定了死规则：

build 里只能“描述 UI”。

不能：

• 请求数据
• 修改状态
• 做计算

九、第五个关键优化：Task 异步化

这是 AI 场景里最重要的一步，以前：

await ai.run()

直接堵塞 UI，结果：

整个窗口卡死

后来彻底改成：

Task Runtime

例如：

taskCenter.dispatch()

UI 只监听：

Task State

之后：

• AI 不再卡 UI
• 多任务稳定很多
• Workspace 更流畅

十、第六个关键优化：避免“大状态对象”

很多人喜欢：

workspace = {
  user,
  orders,
  messages,
  tasks,
  layout
}

看起来方便，实际上：

任何字段变化
整个对象都变

导致：

Diff 成本暴涨

后来改成：

状态原子化

例如：

workspace.userState
workspace.taskState
workspace.layoutState

性能会明显稳定。

十一、第七个关键优化：长列表虚拟化

这个在 PC 上非常关键，很多人会觉得：

PC 性能高
直接渲染全部

结果：

• 内存暴涨
• 滚动掉帧
• Workspace 卡顿

后来统一：

虚拟列表

只渲染：

可见区域

滚动流畅度会提升非常明显。

十二、第八个关键优化：动画去状态化

这是一个很容易忽略的问题，很多项目：

动画驱动状态

例如：

@State offset

每一帧都改状态，结果：

ArkUI 持续重建

后来：

动画与业务状态彻底隔离

动画只存在：

Render Layer

性能提升很明显。

十三、第九个关键优化：AI 状态限流

这是 AI Native App 最大的坑，因为 AI：

特别喜欢连续更新状态

例如：

token 流式输出

最开始：

每个 token 都刷新 UI

后果：

CPU 飙升

后来统一：

批量状态提交

例如：

bufferedUpdate()

性能直接稳定。

十四、第十个关键优化：分布式状态分级同步

很多团队：

所有状态实时同步

后面：

网络与渲染双重爆炸

后来改成：

高频状态

本地优先：

focus
scroll
selection

中频状态

Workspace 同步：

task
layout

低频状态

全局同步：

user
settings

系统瞬间稳定很多。

十五、真正的性能优化：不是“优化 UI”

做到后面我们终于发现：

鸿蒙 PC 最大性能问题，从来不是“组件太多”。

真正的问题是：

状态流失控

因为：

• 多窗口
• AI
• 分布式
• Workspace

都会疯狂放大：

状态传播成本

十六、后来我们整个优化思路彻底变了

从：

优化页面

变成：

优化状态流

从：

减少组件

变成：

减少状态扩散

这是最关键的认知变化。

十七、总结

如果一句话总结鸿蒙 PC 性能优化：

性能问题，本质是“状态系统压力问题”。

包括：

• 卡顿
• 掉帧
• 输入延迟
• CPU 飙升
• Workspace 卡死

很多时候：

都不是 UI 的问题

而是：

状态流设计出了问题

后来我们终于意识到：

鸿蒙 PC 不是“页面应用”

而是：

持续运行的状态 Runtime

所以真正重要的优化，不是：

• 少几个组件
• 少几个动画

而是：

• 状态边界
• Workspace 隔离
• Task Runtime
• 状态传播控制
• Focus 独立化

最终你会发现：

当状态流稳定之后：

整个系统会突然变得“丝滑”

因为：

真正拖慢鸿蒙 PC 的，从来不是 UI。

而是：

失控的状态系统