HarmonyOS PC 为什么需要无状态组件（Stateless Component）？

网罗开发小红书、快手、视频号同名大家好我是展菲目前在上市企业从事人工智能项目研发管理工作平时热衷于分享各种编程领域的软硬技能知识以及前沿技术包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。图书作者《ESP32-C3 物联网工程开发实战》图书作者《SwiftUI 入门进阶与实战》超级个体COC上海社区主理人特约讲师大学讲师谷歌亚马逊分享嘉宾科技博主华为HDE/HDG我的博客内容涵盖广泛主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告同时也会提供产品优缺点分析、横向对比并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。展菲您的前沿技术领航员 大家好我是展菲 全网搜索“展菲”即可纵览我在各大平台的知识足迹。每周定时推送干货满满的技术长文从新兴框架的剖析到运维实战的复盘助您技术进阶之路畅通无阻。文章目录引言一、传统 Component 为什么必须拥有 State二、AI Native 软件第一次打破了 State 生命周期三、State 真正的归属应该是 Runtime四、为什么无状态组件更适合 AI Runtime五、无状态组件如何配合 Runtime 工作六、为什么无状态组件更适合多窗口与多设备七、真正需要无状态的不只是组件总结引言过去十几年几乎所有 UI 框架都在围绕一个核心问题不断演进如何管理组件状态StateReact 有useState useReducer Context ReduxFlutter 有StatefulWidget InheritedWidget Riverpod BlocSwiftUI 有State StateObject EnvironmentObjectArkUI 同样提供了丰富的状态管理能力StateLinkPropProvideConsume整个 UI Runtime 的设计几乎都建立在一个默认前提上State 属于 Component。组件创建、State 创建、组件销毁、State 销毁这一模型在移动互联网时代运行得非常成功。但是AI Native 软件的出现让这一假设第一次受到挑战。越来越多的软件开始围绕Goal Task Context Workspace持续运行。真正拥有生命周期的不再是页面而是 Runtime。因此一个新的问题出现了如果 State 不再属于页面那么 Component 是否还需要拥有 State这也是未来 HarmonyOS PC 为什么可能大量采用 Stateless Component 的真正原因。一、传统 Component 为什么必须拥有 State传统 UI 的运行方式非常简单用户点击按钮 │ ▼ 修改 State │ ▼ 重新 Render例如Componentstruct Counter{Statecount:number0}整个 Runtime 可以抽象成Component │ State │ RenderState 是组件生命周期的一部分。页面关闭Component Destroy │ State Destroy这种设计没有问题因为过去的软件生命周期很短打开页面 ↓ 完成操作 ↓ 关闭页面State 与页面保持一致。二、AI Native 软件第一次打破了 State 生命周期来看一个真实场景用户输入帮我完成审批流开发。Agent 开始持续执行分析需求 ↓ 生成数据库 ↓ 生成接口 ↓ 生成代码 ↓ 生成测试 ↓ 提交 Git整个过程可能持续数小时甚至几天。期间页面可能关闭窗口可能切换应用可能重启用户可能切换到另一台设备。但是Goal不能丢失。Task不能丢失。Context不能丢失。如果这些状态仍然保存在 Component 中那么Component Destroy │ State Lost整个 AI Runtime 就会中断。因此真正需要长期存在的 State不应该属于 Component。三、State 真正的归属应该是 RuntimeAI Native Runtime 中State 更合理的组织方式应该是Workspace Runtime │ Context Runtime │ Execution Runtime │ State Runtime │ ComponentState Runtime 负责维护Goal State Task State Execution State Workspace State Context StateComponent 不再保存业务状态它只是读取 Runtime 中的数据。例如Componentstruct TaskPanel{ObjectLinkexecutionState:ExecutionState}ExecutionState 来自 Runtime而不是组件自身State 与 Component 生命周期彻底解耦。四、为什么无状态组件更适合 AI Runtime无状态组件最大的特点是Input │ ▼ Render没有内部业务状态例如Componentstruct ProgressView{Propprogress:number}ProgressView 不关心数据来自哪里谁修改了数据生命周期如何管理。它只负责Render这样带来的好处是整个 Runtime 可以自由迁移状态。例如Workspace A │ ▼ Workspace B或者PC │ ▼ PadComponent 不需要感知任何变化。五、无状态组件如何配合 Runtime 工作未来 HarmonyOS PC 更可能形成如下架构Goal Graph │ Task Graph │ Execution Graph │ State Runtime │ Component Runtime │ Render Engine整个数据流变为Goal 更新 │ Execution Graph 更新 │ State Runtime 更新 │ 通知 Component │ 重新 Render可以发现真正变化的是 Runtime。Component 始终保持无状态它只是 Runtime 的观察者Observer。六、为什么无状态组件更适合多窗口与多设备HarmonyOS PC 的一个重要特点是同一个任务可能同时存在于多窗口多应用多设备。例如PC Pad Phone共同查看审批流开发任务如果每个 Component 都维护自己的 State就会出现三个 State同步成本极高而采用 Runtime State 后Runtime │ ├──── PC Component ├──── Pad Component └──── Phone Component所有组件共享同一个状态源整个系统真正实现Single Source of Truth七、真正需要无状态的不只是组件随着 Runtime 不断发展无状态思想可能扩展到整个系统。未来不仅 Component 无状态甚至Window Page View Widget都可能成为 Runtime 的投影真正维护生命周期的只有Goal Runtime Task Runtime Execution Runtime Context RuntimeUI 不再保存业务状态而只是Runtime Projection整个软件开始真正进入 Runtime Driven Architecture。总结过去二十年UI 框架一直默认State 属于 Component。因此State 与页面生命周期紧密绑定。但 AI Native 软件改变了这一前提。真正持续运行的对象已经变成Goal Task Context Execution它们的生命周期远远超过页面、窗口甚至应用本身。因此State 必须从 Component 中抽离交由 Runtime 统一管理。未来 HarmonyOS PC 所需要的无状态组件并不是为了减少几次渲染也不仅仅是为了提升性能而是为了适应一种全新的运行模型Goal Runtime │ Task Runtime │ Execution Runtime │ State Runtime │ Stateless Component │ Render Engine在这套架构中Component 不再拥有状态而是 Runtime 的观察者UI 不再驱动业务而是业务驱动 UI。从Stateful Component到Stateless Component看似只是组件设计理念的变化实际上反映的是 HarmonyOS PC 正在从页面驱动Page-Driven走向运行时驱动Runtime-Driven的软件架构演进。