HarmonyOS PC 为什么要重写整个 Component 模型？

子玥酱掘金 / 知乎 / CSDN / 简书 同名大家好我是子玥酱一名长期深耕在一线的前端程序媛 ‍。曾就职于多家知名互联网大厂目前在某国企负责前端软件研发相关工作主要聚焦于业务型系统的工程化建设与长期维护。我持续输出和沉淀前端领域的实战经验日常关注并分享的技术方向包括前端工程化、小程序、React / RN、Flutter、跨端方案在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。技术方向前端 / 跨端 / 小程序 / 移动端工程化内容平台掘金、知乎、CSDN、简书创作特点实战导向、源码拆解、少空谈多落地文章状态长期稳定更新大量原创输出我的内容主要围绕前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读展开。文章不会停留在“API 怎么用”而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍希望能帮你在实际工作中少走弯路。子玥酱 · 前端成长记录官 ✨ 如果你正在做前端或准备长期走前端这条路 关注我第一时间获取前端行业趋势与实践总结 可领取11 类前端进阶学习资源工程化 / 框架 / 跨端 / 面试 / 架构 一起把技术学“明白”也用“到位”持续写作持续进阶。愿我们都能在代码和生活里走得更稳一点 文章目录引言一、传统 Component 模型本质上解决的是页面问题二、AI Native 软件第一次打破了 Component 的生命周期三、真正的问题不是组件而是 State 放错了位置四、为什么 Component Tree 已经不够用了五、未来 Component 更像 Runtime 的观察者六、未来 HarmonyOS PC 为什么需要 Runtime Component总结引言过去十几年前端框架几乎都在解决同一个问题如何组织页面1、React 引入 Component2、Vue 引入 SFC3、Flutter 引入 Widget4、SwiftUI 引入 View。5、ArkUI 引入声明式 Component。虽然实现方式不同但它们都有一个共同假设Component 是整个软件系统最重要的运行单元。整个 Runtime 围绕 Component 构建Component ↓ State ↓ Render因此过去十几年我们讨论最多的是Component 如何拆分Component 如何通信Component 如何复用Component 如何管理 State几乎所有 UI 框架都在不断优化 Component。但是 AI Native 软件出现以后一个新的问题开始暴露真正持续运行的对象已经不是 Component。这也是为什么未来 HarmonyOS PC 很可能不仅要升级 ArkUI而是重新定义整个 Component Runtime。一、传统 Component 模型本质上解决的是页面问题先看 React一个典型组件function UserCard() { return Card / }FlutterclassUserCardextendsStatelessWidget{}ArkUIComponentstruct UserCard{}虽然语法不同但是 Runtime 做的事情完全一致创建 Component ↓ 建立 Component Tree ↓ 维护 Component State ↓ Diff ↓ Render整个生命周期始终围绕 Component 展开。因此传统 UI Runtime 可以抽象成Component Runtime它最大的职责只有两个管理状态 管理渲染这也是过去二十年 UI 框架不断演进的方向。二、AI Native 软件第一次打破了 Component 的生命周期真正的问题来了例如用户说帮我开发审批流模块Agent 开始分析需求 ↓ 设计数据库 ↓ 生成接口 ↓ 生成代码 ↓ 生成测试 ↓ 提交 Git整个过程可能持续2 小时 8 小时 2 天期间页面可能关闭窗口可能切换甚至设备可能改变但是任务不能结束也就是说Goal 生命周期 Component 生命周期第一次整个软件真正持续存在的对象已经不是Component而是Goal传统 Component Runtime 开始失效。三、真正的问题不是组件而是 State 放错了位置很多开发者认为未来 Component 最大的问题是渲染性能实际上不是真正的问题是State Ownership过去Componentstruct ChatPage{Statemessages:Message[]}State 属于Page页面关闭State 消失但是 AI Runtime 中真正需要保存的是Goal Task Context Execution这些对象根本不应该属于页面更合理的关系应该是Workspace Runtime ↓ State Runtime ↓ ComponentComponent 只是Projection也就是 Runtime 的一个投影State 真正属于 Runtime。四、为什么 Component Tree 已经不够用了所有现代 UI 都有Component Tree例如Page ├── Header ├── List └── Footer但是 AI Runtime 真正维护的是Goal Graph Task Graph Context Graph Execution Graph这些对象之间全部都是Graph而不是Tree例如一个 Task可能同时依赖多个 Goal 多个 Context 多个 ToolTree 根本无法表达这种关系。因此未来真正组织系统的已经不是Component Tree而是Runtime GraphComponent Tree 只是Runtime Graph 的一个渲染结果。五、未来 Component 更像 Runtime 的观察者传统State ↓ Component ↓ Render未来Runtime ↓ Execution Graph ↓ Component ↓ RenderComponent 不再拥有State而是Subscribe Runtime例如Componentstruct TaskPanel{ObservedexecutionGraph}真正更新的是Execution GraphComponent 只是Observer这意味着未来 Component Runtime 更接近Reactive Runtime而不是Page Runtime六、未来 HarmonyOS PC 为什么需要 Runtime Component未来的组件可能不再描述Button List Text而开始描述Goal Panel Task Timeline Execution Monitor Context Viewer Agent Console组件绑定的对象已经从State升级为Runtime Object例如Goal Runtime Task Runtime Execution Runtime Context Runtime真正运行的是 RuntimeComponent 只是 Runtime 的可视化终端。总结过去二十年整个 UI 世界都建立在一个默认前提之上Component 是运行时的中心。因此所有框架都在不断优化Component TreeStateDiffRender但是 AI Native 软件第一次打破了这一假设真正持续运行的对象已经变成Goal Task Context Execution而这些对象都拥有远远长于页面的生命周期也具有复杂的图结构关系。因此未来 HarmonyOS PC 真正需要重写的并不是Component这个语法也不是声明式 UI而是Component 与 Runtime 的关系。新的架构更可能演进为Workspace Runtime ↓ Goal Graph ↓ Task Graph ↓ Execution Graph ↓ State Runtime ↓ Component Runtime ↓ Render Engine在这套模型中Component 不再是系统的中心而是 Runtime 的观察者Observer和投影Projection。系统真正的核心从页面树Component Tree转向运行图Runtime Graph。这不仅是 UI 框架的一次升级更意味着 HarmonyOS PC 正在从页面驱动架构Page-Driven Architecture迈向运行时驱动架构Runtime-Driven Architecture。这也是 AI Native 操作系统与传统桌面系统最本质的架构差异。