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

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

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

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

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

引言

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

State 属于页面

无论是：

• React
• Vue
• Flutter
• ArkUI

底层思想都高度一致：

Page
 ↓

Component
 ↓

State
 ↓

Render

组件负责：

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

于是大家习惯于：

页面关闭
↓
状态销毁

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

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

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

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

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

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

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

而是：

Task

Context

Workspace

于是：

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

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

而是：

State 本身。

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

传统状态模型：

Page
 ↓

Component
 ↓

State
 ↓

Render

例如：

@Component
struct UserPanel {

    @State user: User

}

默认认为：

State
=
页面内部数据

生命周期：

Page Create
↓
State Create
↓
Page Destroy
↓
State Destroy

整个软件世界默认：

状态跟随页面

这也是：

• Redux
• Vuex
• MobX
• ArkUI @State

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

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

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

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

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

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

对于系统来说：

6 个 Window

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

开发审批流模块

用户感知的是：

Task

而不是：

Page

于是：

Task Boundary
>
Page Boundary

问题开始出现：

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

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

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

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

Page State

而是：

Task State

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

过去：

Page 生命周期
=
State 生命周期

但是未来：

Task 生命周期
>
Page 生命周期

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

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

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

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

于是，传统：

Page Destroy
↓
State Destroy

开始变成：

Page Destroy
↓
State Continue

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

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

这是 HarmonyOS PC 最重要的变化。

过去：

Window 属于 App

未来：

Window 属于 Workspace

例如，当前 Workspace：

AMS 工程

需求文档

设计稿

测试计划

企业微信

浏览器

这里真正持续存在的是：

Workspace

而不是：

Window

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

interface WorkspaceState {

    currentTask: string

    currentProject: string

    activeWindows: string[]

    activeFiles: string[]

    activeDevices: string[]

}

状态开始属于：

Workspace Runtime

而不是：

Page

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

传统软件，最重要的是：

UI State

例如：

selectedIndex

loading

showDialog

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

Context State

例如：

interface ContextState {

    currentTask: string

    selectedCode: string

    currentFile: string

    openedDocuments: string[]

    historySummary: string

}

AI 真正依赖的是：

Context

而不是：

Button State

因为 AI 需要理解：

用户正在做什么

而不是：

哪个按钮被点击了

因此，未来：

Context State
>
UI State

六、State 开始进入 Graph 时代

过去，状态是树：

Store
 ↓

State
 ↓

View

未来，状态越来越像：

State Graph

例如：

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

节点之间存在：

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

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

Knowledge Graph

而不是：

JSON Object

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

过去，状态消费者只有：

UI

例如：

State
↓
Render

未来，消费者变成：

State
↓
UI

+
Agent

+
Tool Runtime

AI 可以：

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

于是，整个模型变成：

State
 ↓

UI

Agent

Tool

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

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

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

Component State
       ↓

Page State
       ↓

Application State
       ↓

Workspace State
       ↓

Context State
       ↓

Runtime State

其中 Runtime State 管理：

Task

Context

Workspace

Device

Agent Session

Tool State

它不属于：

Page

也不属于：

App

而属于：

Runtime

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

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

Page Driven

而是：

Goal Driven

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

Goal

Task

Context

Workspace

Agent

这些对象都超过：

Page 生命周期

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

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

整个软件世界开始从：

UI State

进入：

Runtime State

时代。

总结

过去二十年：

State 属于页面。

未来十年：

State 属于 Runtime。

过去：

页面决定状态。

未来：

Task 决定状态。

过去：

UI 是状态消费者。

未来：

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

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

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

State Model

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

Page

而是：

Task

Workspace

Context

Agent

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

Page State

而是：

Runtime State