网罗开发小红书、快手、视频号同名大家好我是展菲目前在上市企业从事人工智能项目研发管理工作平时热衷于分享各种编程领域的软硬技能知识以及前沿技术包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。图书作者《ESP32-C3 物联网工程开发实战》图书作者《SwiftUI 入门进阶与实战》超级个体COC上海社区主理人特约讲师大学讲师谷歌亚马逊分享嘉宾科技博主华为HDE/HDG我的博客内容涵盖广泛主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告同时也会提供产品优缺点分析、横向对比并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。展菲您的前沿技术领航员 大家好我是展菲 全网搜索“展菲”即可纵览我在各大平台的知识足迹。每周定时推送干货满满的技术长文从新兴框架的剖析到运维实战的复盘助您技术进阶之路畅通无阻。文章目录引言一、过去二十年State 一直属于页面二、用户真正运行的其实不是页面三、传统 State 最大的问题生命周期太短四、真正持续存在的是 Workspace State五、Context State 开始比 UI State 更重要六、State 开始进入 Graph 时代七、Agent 正在成为新的状态消费者八、未来真正重要的是 Runtime State九、HarmonyOS PC 为什么需要新的 State 模型总结引言过去二十年几乎所有软件架构都默认一个前提State 属于页面无论是ReactVueFlutterArkUI底层思想都高度一致Page ↓ Component ↓ State ↓ Render组件负责保存状态响应事件更新 UI跟随页面生命周期创建和销毁。于是大家习惯于页面关闭 ↓ 状态销毁在移动互联网时代这套模型运行得非常成功。因为软件生命周期通常很短打开 App ↓ 完成任务 ↓ 退出 App但 AI Native 时代越来越多的软件开始出现新的特征多窗口WorkspaceAgent长任务跨设备协同持续运行。这时候一个问题开始暴露真正持续存在的对象已经不是 Page。而是Task Context Workspace于是整个 State 模型开始遇到边界。也许真正需要重写的不是 Store。而是State 本身。一、过去二十年State 一直属于页面传统状态模型Page ↓ Component ↓ State ↓ Render例如Componentstruct UserPanel{Stateuser:User}默认认为State 页面内部数据生命周期Page Create ↓ State Create ↓ Page Destroy ↓ State Destroy整个软件世界默认状态跟随页面这也是ReduxVuexMobXArkUI 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例如当前 WorkspaceAMS 工程 需求文档 设计稿 测试计划 企业微信 浏览器这里真正持续存在的是Workspace而不是Window因此新的状态模型开始出现interfaceWorkspaceState{currentTask:stringcurrentProject:stringactiveWindows:string[]activeFiles:string[]activeDevices:string[]}状态开始属于Workspace Runtime而不是Page五、Context State 开始比 UI State 更重要传统软件最重要的是UI State例如selectedIndex loading showDialog未来 AI Native 软件真正重要的是Context State例如interfaceContextState{currentTask:stringselectedCode:stringcurrentFile:stringopenedDocuments: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 RuntimeAI 可以修改状态创建状态合并状态同步状态。于是整个模型变成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