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

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

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

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

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

引言

过去二十年，整个前端世界几乎都建立在一个共同假设之上：

Component = View

无论是：

• React
• Vue
• Flutter
• ArkUI

虽然实现方式不同，但核心思想其实高度一致：

Page
 ↓

Component
 ↓

State
 ↓

Render

组件负责：

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

这套模型在移动互联网时代几乎无往不利。

但越来越多团队开始发现：项目越复杂，Component 越像一个黑洞。

熟悉的问题开始出现：

• 组件越来越重；
• Store 越来越大；
• 状态同步越来越复杂；
• 多窗口开始失控；
• Workspace 无法恢复；
• AI 接入后逻辑爆炸；
• Context 到处传递；
• Agent 无法持续运行。

最后大家疯狂引入：

Redux

MVVM

DDD

状态机

EventBus

但效果往往有限，因为问题可能根本不在状态管理。

而在于：

整个 Component 模型正在遇到边界。

因为过去二十年，组件真正描述的是：

Page

而未来的软件真正持续存在的对象已经变成：

Workspace

Task

Context

Agent

这些对象根本不属于页面，于是：

Component 模型必须被重新定义。

一、React、Vue、ArkUI 的 Component 模型为什么越来越重？

传统组件生命周期：

Create
 ↓

Update
 ↓

Destroy

例如：

@Component
struct ChatPanel {

    @State messages: Message[] = []

}

默认认为：

State
属于组件

页面关闭：

State 消失

页面重新打开：

重新创建 State

这种模式在移动时代没有问题，因为：

打开 App
 ↓

完成任务
 ↓

退出 App

生命周期非常短，但是在 PC 上。真正持续运行的对象已经变了。

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

例如开发一个审批流系统，同时打开：

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

对于系统来说：

6 个窗口

但对于用户来说，只有一个东西：

开发审批流模块

用户感知的是：

Task

而不是：

Page

因此：

Task Boundary
>
Page Boundary

问题来了：

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

浏览器关闭了。Context 消失了吗？没有。

甚至，设备切换了，Workspace 还在。于是，真正持续存在的对象已经不是：

View Tree

而是：

Workspace Runtime

三、Component 生命周期已经小于 Task 生命周期

这是整个矛盾产生的根源，过去：

Component 生命周期
=
业务生命周期

现在：

Component 生命周期
<
Task 生命周期

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

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

用户切换到手机，任务应该丢失吗？显然不应该。

用户重启应用，Workspace 应该重置吗？也不应该。

这意味着，真正持续存在的是：

Task

Context

Workspace

而不是：

Page

于是，传统 Component 生命周期开始失效。

四、组件最大的错误：拥有状态

这是很多大型项目后期失控的根源，例如：

@Component
struct UserPanel {

    @State user: User

}

意味着：

State
属于组件

于是，多窗口同步困难、Workspace 恢复困难、AI 修改状态困难、分布式同步困难、Context 持久化困难。

因为，状态被困在：

Component

内部，但未来真正应该是：

State
属于 Runtime

组件只是：

Projection

即，状态投影器。因此，未来组件第一原则：

组件不拥有状态。

状态来自：

Store

Workspace Runtime

Agent Runtime

而不是组件自身。

五、未来真正持续存在的是 Workspace

这是鸿蒙 PC 最大的变化，过去：

Window
属于 App

未来：

Window
属于 Workspace

例如，当前 Workspace 包含：

AMS 工程

需求文档

设计稿

测试计划

企业微信

浏览器

无论：

• 打开多少窗口；
• 重启多少应用；
• 切换多少设备；

真正持续存在的是：

Workspace

于是，新的 Runtime 开始出现：

Workspace Runtime

负责维护：

interface Workspace {

    currentTask: string

    currentProject: string

    activeFiles: string[]

    activeWindows: string[]

}

此时，组件开始属于：

Workspace

而不是：

Page

六、未来 Component 会越来越像 Runtime Node

过去：

Component
 ↓

Render

未来：

Component
 ↓

Runtime Node
 ↓

Task
 ↓

Context
 ↓

Render

例如，AI Panel：

过去 ➡️ 只是聊天窗口；未来 ➡️ 内部维护。

• Memory；
• Context；
• Task；
• Tool；
• Agent Session。

关闭窗口后，AI 任务依然继续。这时候，组件已经不是：

View

而是：

Runtime Node

UI 只是最终输出。

七、AI Native 软件要求 Component 支持 Agent 调度

过去，事件来源只有：

User Event

例如：

Click

Input

Drag

未来，事件来源变成：

User Event

+

Agent Event

AI 自动：

• 创建窗口；
• 调整布局；
• 修改状态；
• 调用工具；
• 更新数据。

于是，组件需要支持：

Human + AI

双驱动模式，传统组件模型只考虑用户。新的 Component 模型必须同时支持：

Agent Runtime

八、组件开始从 View 演化为系统模块

过去：

Button

List

Dialog

未来，越来越多组件会变成：

AI Module

Memory Module

Task Module

Workspace Module

Agent Module

内部维护：

State Graph

Context Graph

Task Graph

Distributed Sync

Agent Hook

组件结构开始变成：

Component
      ↓

Runtime Node
      ↓

Workspace Module
      ↓

Agent Module

最终：

Component ≠ View

而是：

Component = Runtime Node

九、鸿蒙 PC 为什么必须重写整个 Component 模型？

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

Page Driven

而是：

Workspace Driven

更进一步：

Goal Driven

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

Goal

Task

Context

Workspace

Agent

这些对象已经超过：

Page 生命周期

于是，整个 Component 世界都必须发生变化：

View Component
        ↓

State Component
        ↓

Workspace Component
        ↓

Runtime Component

最终：

Component
=
Runtime Node

总结

过去二十年，整个 React、Vue、Flutter、ArkUI 世界都建立在：

Component = View

之上。但 AI Native 时代，真正持续运行的对象已经变成：

Task

Workspace

Context

Agent

它们不属于页面。因此，未来的软件组件可能会经历一次根本性的演化：

View Component
          ↓

State Component
          ↓

Workspace Component
          ↓

Runtime Component

最终：

Component
=
Runtime Node

也许。鸿蒙 PC 真正想重写的，并不是 Button、List、Dialog。而是整个软件世界沿用了二十多年的：

Component 模型。

因为未来软件竞争的核心，不再是谁拥有更多组件，而是谁能够让组件：

• 持续运行；
• 承载 Task；
• 维护 Context；
• 支持 Agent 调度；
• 支持跨设备迁移；
• 属于 Workspace Runtime。

这或许才是 AI Native 时代 Component 的真正形态。