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

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

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

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

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

引言

过去十几年，几乎所有 UI 框架都在围绕一个核心问题不断演进：

如何管理组件状态（State）？

React 有：

useState
useReducer
Context
Redux

Flutter 有：

StatefulWidget
InheritedWidget
Riverpod
Bloc

SwiftUI 有：

@State
@StateObject
@EnvironmentObject

ArkUI 同样提供了丰富的状态管理能力：

@State
@Link
@Prop
@Provide
@Consume

整个 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

例如：

@Component
struct Counter {

    @State
    count: number = 0

}

整个 Runtime 可以抽象成：

Component
        │
State
        │
Render

State 是组件生命周期的一部分。

页面关闭：

Component Destroy
        │
State Destroy

这种设计没有问题，因为过去的软件生命周期很短：

打开页面
↓

完成操作
↓

关闭页面

State 与页面保持一致。

二、AI Native 软件第一次打破了 State 生命周期

来看一个真实场景，用户输入：

帮我完成审批流开发。

Agent 开始持续执行：

分析需求
      ↓
生成数据库
      ↓
生成接口
      ↓
生成代码
      ↓
生成测试
      ↓
提交 Git

整个过程可能持续数小时，甚至几天。

期间：

• 页面可能关闭；
• 窗口可能切换；
• 应用可能重启；
• 用户可能切换到另一台设备。

但是：

Goal

不能丢失。

Task

不能丢失。

Context

不能丢失。

如果这些状态仍然保存在 Component 中，那么：

Component Destroy
        │
State Lost

整个 AI Runtime 就会中断。

因此真正需要长期存在的 State，不应该属于 Component。

三、State 真正的归属应该是 Runtime

AI Native Runtime 中，State 更合理的组织方式应该是：

Workspace Runtime
        │
Context Runtime
        │
Execution Runtime
        │
State Runtime
        │
Component

State Runtime 负责维护：

Goal State

Task State

Execution State

Workspace State

Context State

Component 不再保存业务状态，它只是读取 Runtime 中的数据。

例如：

@Component
struct TaskPanel {

    @ObjectLink
    executionState: ExecutionState

}

ExecutionState 来自 Runtime，而不是组件自身；State 与 Component 生命周期彻底解耦。

四、为什么无状态组件更适合 AI Runtime？

无状态组件最大的特点是：

Input
      │
      ▼
Render

没有内部业务状态，例如：

@Component
struct ProgressView {

    @Prop
    progress: number

}

ProgressView 不关心：

• 数据来自哪里；
• 谁修改了数据；
• 生命周期如何管理。

它只负责：

Render

这样带来的好处是，整个 Runtime 可以自由迁移状态。

例如：

Workspace A
      │
      ▼
Workspace B

或者：

PC
      │
      ▼
Pad

Component 不需要感知任何变化。

五、无状态组件如何配合 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 Runtime

UI 不再保存业务状态，而只是：

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） 的软件架构演进。