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

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

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

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

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

引言

很多人第一次做鸿蒙 PC 时，都会有一种非常强烈的错觉：

应用都已经装到本地了
启动应该很快吧？

结果真正上线之后，很快就会发现：

• 冷启动越来越慢
• 白屏时间越来越长
• Workspace 恢复卡顿
• 多窗口启动互相阻塞
• AI Runtime 初始化特别重
• 首页刚出现就开始掉帧

甚至很多时候：

不是“打开慢”
而是“打开之后整个系统像没醒”

最开始很多团队会怀疑：

• DevEco 打包有问题？
• ArkUI 初始化太重？
• PC Runtime 不成熟？

于是开始：

• 疯狂拆页面
• 拼命做懒加载
• 缩减资源
• 到处异步化

但做到后面你会发现：

鸿蒙 PC 启动慢，真正的问题通常不是“页面加载”。

而是：

状态系统启动失控

因为在鸿蒙 PC 上：

启动的从来不只是“一个页面”。

而是：

整个 Runtime 世界

一、传统 App 启动：本质是“页面初始化”

过去很多 App：

打开应用
 ↓
创建首页
 ↓
渲染 UI

启动核心就是：

把页面画出来

所以优化重点通常是：

• 图片
• 布局
• 首屏渲染
• 网络请求

二、鸿蒙 PC 启动：真正启动的是“状态系统”

但鸿蒙 PC 不一样，真正启动的是：

• Workspace Runtime
• Focus Runtime
• Task Runtime
• Store System
• 分布式状态
• AI Runtime
• 多窗口恢复

也就是说：

启动不是“页面创建”
而是“系统恢复”

这是本质区别。

三、为什么很多鸿蒙 PC 项目越做启动越慢

因为项目初期：

只有几个状态

所以：

启动非常快

但后面：

• Workspace 越来越多
• Store 越来越重
• AI Task 越来越复杂
• 分布式状态越来越大

最后：

启动变成“恢复整个世界”

四、最大的启动误区：把所有东西都放启动阶段

这是最典型的问题，很多项目：

Application.onCreate()

里面：

• 初始化 AI
• 初始化数据库
• 初始化 Workspace
• 初始化全部 Store
• 初始化全部 Service

结果：

主线程直接卡死

启动时间越来越夸张。

五、真正的启动原则：只有“当前状态”才能启动

后来我们整个架构改了一个核心原则：

启动阶段，只允许恢复“当前 Workspace”。

例如，错误模型

启动
 ↓
恢复全部窗口
 ↓
恢复全部状态
 ↓
恢复全部任务

正确模型

启动
 ↓
恢复当前 Workspace
 ↓
显示 UI
 ↓
后台渐进恢复

这个改动收益极大。

六、第一个关键优化：Workspace 延迟恢复

以前：

所有 Workspace 同时恢复

结果：

• CPU 飙升
• IO 爆炸
• UI 卡死

后来：

只恢复当前 Workspace

其他：

后台渐进恢复

之后：

首屏速度直接快很多

七、第二个关键优化：Store 分级初始化

很多项目：

所有 Store 启动即创建

例如：

• orderStore
• aiStore
• workspaceStore
• messageStore

全部初始化，问题是：

大部分启动时根本用不到

后来改成，核心 Store 立即初始化：

userStore
workspaceStore
focusStore

延迟 Store 按需加载：

messageStore
orderStore
aiStore

启动时间明显下降。

八、第三个关键优化：AI Runtime 后置

这是现在很多 AI Native App 最大的问题，很多团队：

启动即初始化 AI

包括：

• 模型加载
• Prompt Runtime
• Agent Registry
• Tool Runtime

后果：

启动直接变成“加载 AI”

后来彻底改成：

AI Runtime Lazy Boot

只有：

真正触发 AI Task

才启动 AI，这个优化极其明显。

九、第四个关键优化：不要在首页恢复全部状态

很多项目首页：

aboutToAppear()

里面：

• 拉订单
• 拉消息
• 拉 Workspace
• 拉历史记录

结果：

首页像“数据洪水”

后来改成首屏阶段，只恢复：

最小可见状态

例如：

• 用户
• 当前 Workspace
• 基础布局

后台阶段，渐进恢复：

• 消息
• AI
• 历史数据

之后：

白屏时间骤降

十、第五个关键优化：构建“启动快照”

这是后期最关键的优化之一，以前：

每次启动都重新构建状态树

结果：

恢复越来越慢

后来：

Workspace Snapshot

直接保存：

• Layout
• Focus
• UIState
• 当前 Task

启动时：

直接恢复快照

体验会非常接近：

系统级秒开

十一、第六个关键优化：Task Runtime 异步恢复

很多项目：

启动时恢复全部 Task

例如：

• 下载
• AI
• 同步
• 上传

结果：

启动阶段 CPU 爆炸

后来：

Task 分阶段恢复

前台任务

立即恢复：

用户当前任务

后台任务

延迟恢复：

同步任务
AI 分析任务

之后系统流畅很多。

十二、第七个关键优化：避免启动期状态风暴

这个问题特别容易被忽略，很多项目：

启动阶段疯狂 setState

例如：

userStore.update()
workspaceStore.update()
layoutStore.update()
taskStore.update()

后果：

ArkUI 连续重建

后来：

启动阶段统一批量提交状态

例如：

batchUpdate()

性能会稳定非常多。

十三、第八个关键优化：首屏 UI 必须“极简”

很多团队首页：

什么都想显示

包括：

• AI 面板
• Workspace 列表
• 消息
• 任务
• 推荐流

结果：

首页变成“大型 Runtime”

后来我们改成：

启动首页只负责“进入系统”

其他能力：

渐进加载

这是非常重要的一步。

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

很多项目：

启动即同步所有设备状态

结果：

• 网络阻塞
• Workspace 卡死
• 状态冲突

后来：

本地优先启动

之后：

后台渐进同步

用户体验会自然很多。

十五、为什么启动优化越来越像“操作系统优化”

做到后面你会发现：

鸿蒙 PC 的启动优化，已经不像“页面优化”。

而更像：

系统恢复优化

因为真正恢复的是：

• Runtime
• Workspace
• 状态树
• Task
• Focus
• AI Runtime

所以复杂度会越来越接近：

操作系统

而不是：

传统 App

十六、后来我们彻底改变了启动思路

从：

启动 App

变成：

恢复当前工作世界

这是一个非常关键的认知变化，因为鸿蒙 PC 真正核心不是：

页面

而是：

持续运行的 Workspace

十七、总结

如果一句话总结鸿蒙 PC 启动优化：

启动慢，本质不是“页面重”。

而是：

系统恢复失控

包括：

• Store 初始化
• Workspace 恢复
• Task 恢复
• AI Runtime
• 分布式同步

这些：

才是真正的启动成本

后来我们终于意识到：

鸿蒙 PC 启动
不是“打开一个页面”

而是：

恢复一个持续运行的状态系统

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

• 少几个组件
• 少几个图片

而是：

• Workspace 延迟恢复
• Runtime 分阶段启动
• 状态批量恢复
• Task 异步化
• AI Lazy Boot
• Snapshot 恢复

最终你会发现：

真正优秀的鸿蒙 PC 启动体验：

不是“快”
而是“像系统一样自然恢复”