网罗开发小红书、快手、视频号同名大家好我是展菲目前在上市企业从事人工智能项目研发管理工作平时热衷于分享各种编程领域的软硬技能知识以及前沿技术包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。图书作者《ESP32-C3 物联网工程开发实战》图书作者《SwiftUI 入门进阶与实战》超级个体COC上海社区主理人特约讲师大学讲师谷歌亚马逊分享嘉宾科技博主华为HDE/HDG我的博客内容涵盖广泛主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告同时也会提供产品优缺点分析、横向对比并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。展菲您的前沿技术领航员 大家好我是展菲 全网搜索“展菲”即可纵览我在各大平台的知识足迹。每周定时推送干货满满的技术长文从新兴框架的剖析到运维实战的复盘助您技术进阶之路畅通无阻。文章目录引言一、为什么鸿蒙 PC 的性能问题会越来越复杂二、最大的性能误区把问题归因于 UI三、真正的性能黑洞状态扩散四、鸿蒙 PC 真正的优化核心减少“状态传播”五、第一个关键优化状态分层六、第二个关键优化Workspace 隔离七、第三个关键优化Focus 独立运行八、第四个关键优化不要在 build 里做任何逻辑九、第五个关键优化Task 异步化十、第六个关键优化避免“大状态对象”十一、第七个关键优化长列表虚拟化十二、第八个关键优化动画去状态化十三、第九个关键优化AI 状态限流十四、第十个关键优化分布式状态分级同步高频状态中频状态低频状态十五、真正的性能优化不是“优化 UI”十六、后来我们整个优化思路彻底变了十七、总结引言很多人第一次做鸿蒙 PC 时都会有一种错觉PC 性能那么强 应该不会卡吧结果项目一上线很快就会遇到这些问题多窗口切换掉帧ArkUI 滚动卡顿输入延迟明显状态更新越来越慢CPU 占用飙升AI Task 一跑整个 UI 卡死内存越来越高Workspace 越切越重最开始很多人会以为是不是 ArkUI 性能不行于是开始疯狂优化组件到处加缓存强行拆页面拼命减少动画但优化半天之后你会慢慢发现真正的问题往往根本不在 UI。而在状态系统失控因为在鸿蒙 PC 上性能问题本质是“状态流问题”。一、为什么鸿蒙 PC 的性能问题会越来越复杂传统 App一个页面 一个状态 一次渲染复杂度相对有限但鸿蒙 PC多窗口 多 Workspace 多状态流 AI Runtime 分布式同步意味着系统始终在“持续运行”。也就是说性能问题不再是“瞬时” 而是“持续累积”二、最大的性能误区把问题归因于 UI很多团队第一反应是不是组件太多于是开始减少节点精简布局减少动画这些当然有用但真正的大问题通常来自状态更新风暴三、真正的性能黑洞状态扩散这是我踩过最大的坑之一项目初期globalStore.useruser看起来没问题但后面多页面监听多窗口监听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 场景里最重要的一步以前awaitai.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 卡顿后来统一虚拟列表只渲染可见区域滚动流畅度会提升非常明显。十二、第八个关键优化动画去状态化这是一个很容易忽略的问题很多项目动画驱动状态例如Stateoffset每一帧都改状态结果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。而是失控的状态系统