State 正在失效？HarmonyOS PC 新状态模型深度揭秘

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

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

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

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

展菲：您的前沿技术领航员

👋 大家好，我是展菲！

📱 全网搜索"展菲"，即可纵览我在各大平台的知识足迹。

每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。

文章目录

- 引言
- [一、过去二十年，State 一直属于页面](#一、过去二十年，State 一直属于页面)
- 二、用户真正运行的，其实不是页面
- [三、传统 State 最大的问题：生命周期太短](#三、传统 State 最大的问题：生命周期太短)
- [四、真正持续存在的是 Workspace State](#四、真正持续存在的是 Workspace State)
- [五、Context State 开始比 UI State 更重要](#五、Context State 开始比 UI State 更重要)
- [六、State 开始进入 Graph 时代](#六、State 开始进入 Graph 时代)
- [七、Agent 正在成为新的状态消费者](#七、Agent 正在成为新的状态消费者)
- [八、未来真正重要的是 Runtime State](#八、未来真正重要的是 Runtime State)
- [九、HarmonyOS PC 为什么需要新的 State 模型？](#九、HarmonyOS PC 为什么需要新的 State 模型？)
- 总结

引言

过去二十年，几乎所有软件架构都默认一个前提：

text 复制代码

State 属于页面

无论是：

React
Vue
Flutter
ArkUI

底层思想都高度一致：

text 复制代码

Page
 ↓

Component
 ↓

State
 ↓

Render

组件负责：

保存状态；
响应事件；
更新 UI；
跟随页面生命周期创建和销毁。

于是大家习惯于：

text 复制代码

页面关闭
↓
状态销毁

在移动互联网时代，这套模型运行得非常成功。

因为软件生命周期通常很短：

text 复制代码

打开 App
↓
完成任务
↓
退出 App

但 AI Native 时代，越来越多的软件开始出现新的特征：

多窗口；
Workspace；
Agent；
长任务；
跨设备协同；
持续运行。

这时候，一个问题开始暴露：

真正持续存在的对象，已经不是 Page。

而是：

text 复制代码

Task

Context

Workspace

于是：

整个 State 模型开始遇到边界。

也许，真正需要重写的，不是 Store。

而是：

text 复制代码

State 本身。

一、过去二十年，State 一直属于页面

传统状态模型：

text 复制代码

Page
 ↓

Component
 ↓

State
 ↓

Render

例如：

ts 复制代码

@Component
struct UserPanel {

    @State user: User

}

默认认为：

text 复制代码

State
=
页面内部数据

生命周期：

text 复制代码

Page Create
↓
State Create
↓
Page Destroy
↓
State Destroy

整个软件世界默认：

text 复制代码

状态跟随页面

这也是：

Redux
Vuex
MobX
ArkUI @State

共同遵循的思想，但是，这套模型有一个隐含假设：

text 复制代码

页面生命周期
=
业务生命周期

而今天，这个假设开始失效。

二、用户真正运行的，其实不是页面

假设开发审批流系统，桌面同时打开：

IDEA
浏览器
API 文档
企业微信
数据库客户端
AI 助手

对于系统来说：

text 复制代码

6 个 Window

对于用户来说，只有一个目标：

text 复制代码

开发审批流模块

用户感知的是：

text 复制代码

Task

而不是：

text 复制代码

Page

于是：

text 复制代码

Task Boundary
>
Page Boundary

问题开始出现：

关闭一个窗口，任务结束了吗？没有。

切换设备，Context 消失了吗？没有。

关闭应用，Workspace 消失了吗？也没有。

说明，真正持续存在的对象已经不是：

text 复制代码

Page State

而是：

text 复制代码

Task State

三、传统 State 最大的问题：生命周期太短

过去：

text 复制代码

Page 生命周期
=
State 生命周期

但是未来：

text 复制代码

Task 生命周期
>
Page 生命周期

例如，AI 正在生成测试方案。此时：

关闭窗口，应该停止吗？显然不应该。

切换手机继续工作，状态应该丢失吗？显然也不应该。

甚至，应用退出。Task 依然应该存在。

于是，传统：

text 复制代码

Page Destroy
↓
State Destroy

开始变成：

text 复制代码

Page Destroy
↓
State Continue

也就是说，State 已经开始脱离页面。

四、真正持续存在的是 Workspace State

这是 HarmonyOS PC 最重要的变化。

过去：

text 复制代码

Window 属于 App

未来：

text 复制代码

Window 属于 Workspace

例如，当前 Workspace：

text 复制代码

AMS 工程

需求文档

设计稿

测试计划

企业微信

浏览器

这里真正持续存在的是：

text 复制代码

Workspace

而不是：

text 复制代码

Window

因此新的状态模型开始出现：

ts 复制代码

interface WorkspaceState {

    currentTask: string

    currentProject: string

    activeWindows: string[]

    activeFiles: string[]

    activeDevices: string[]

}

状态开始属于：

text 复制代码

Workspace Runtime

而不是：

text 复制代码

Page

五、Context State 开始比 UI State 更重要

传统软件，最重要的是：

text 复制代码

UI State

例如：

text 复制代码

selectedIndex

loading

showDialog

未来 AI Native 软件，真正重要的是：

text 复制代码

Context State

例如：

ts 复制代码

interface ContextState {

    currentTask: string

    selectedCode: string

    currentFile: string

    openedDocuments: string[]

    historySummary: string

}

AI 真正依赖的是：

text 复制代码

Context

而不是：

text 复制代码

Button State

因为 AI 需要理解：

text 复制代码

用户正在做什么

而不是：

text 复制代码

哪个按钮被点击了

因此，未来：

text 复制代码

Context State
>
UI State

六、State 开始进入 Graph 时代

过去，状态是树：

text 复制代码

Store
 ↓

State
 ↓

View

未来，状态越来越像：

text 复制代码

State Graph

例如：

text 复制代码

Current Task
     ↓
Current Project
     ↓
Current File
     ↓
Current Window
     ↓
Agent Session

节点之间存在：

依赖关系；
Context 关系；
Workspace 关系；
Agent 关系。

因此，未来状态模型更像：

text 复制代码

Knowledge Graph

而不是：

text 复制代码

JSON Object

七、Agent 正在成为新的状态消费者

过去，状态消费者只有：

text 复制代码

UI

例如：

text 复制代码

State
↓
Render

未来，消费者变成：

text 复制代码

State
↓
UI

+
Agent

+
Tool Runtime

AI 可以：

修改状态；
创建状态；
合并状态；
同步状态。

于是，整个模型变成：

text 复制代码

State
 ↓

UI

Agent

Tool

状态不再只服务于页面，而是服务于整个 Runtime。

八、未来真正重要的是 Runtime State

未来状态模型很可能变成：

text 复制代码

Component State
       ↓

Page State
       ↓

Application State
       ↓

Workspace State
       ↓

Context State
       ↓

Runtime State

其中 Runtime State 管理：

text 复制代码

Task

Context

Workspace

Device

Agent Session

Tool State

它不属于：

text 复制代码

Page

也不属于：

text 复制代码

App

而属于：

text 复制代码

Runtime

九、HarmonyOS PC 为什么需要新的 State 模型？

因为未来的软件已经不再是：

text 复制代码

Page Driven

而是：

text 复制代码

Goal Driven

真正持续存在的对象变成：

text 复制代码

Goal

Task

Context

Workspace

Agent

这些对象都超过：

text 复制代码

Page 生命周期

于是，状态模型也开始演化：

text 复制代码

Page State
↓
App State
↓
Workspace State
↓
Context State
↓
Runtime State

整个软件世界开始从：

text 复制代码

UI State

进入：

text 复制代码

Runtime State

时代。

总结

过去二十年：

text 复制代码

State 属于页面。

未来十年：

text 复制代码

State 属于 Runtime。

过去：

text 复制代码

页面决定状态。

未来：

text 复制代码

Task 决定状态。

过去：

text 复制代码

UI 是状态消费者。

未来：

text 复制代码

UI、Agent、Tool 都是状态消费者。

也许 HarmonyOS PC 真正想重写的，并不是 Store。

而是整个软件世界沿用了二十多年的：

text 复制代码

State Model

因为 AI Native 时代真正持续运行的对象，已经不再是：

text 复制代码

Page

而是：

text 复制代码

Task

Workspace

Context

Agent

因此，未来最重要的状态，可能不再是：

text 复制代码

Page State

而是：

text 复制代码

Runtime State