鸿蒙：@Provide 和@Consume原理

最新推荐文章于 2025-10-15 15:45:38 发布

原创最新推荐文章于 2025-10-15 15:45:38 发布 · 504 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#鸿蒙

@Provide:类似于@state可用于父组件向子组件或孙子组件传递数据

@Consume:类似于@link可用于数据的双向传递，需要注意的是不需要传递参数，可直接消费父组件@Provide修饰的数据变量

确定要放弃本次机会？

福利倒计时

: :

立减 ¥

普通VIP年卡可用

立即使用

S妖O风F

关注关注

2
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
分享

复制链接

分享到 QQ

分享到新浪微博

扫一扫
举报

举报

鸿蒙Harmony应用开发—ArkTS-@Provide装饰器和@Consume装饰器：与后代组件双向同步

m0_64420071的博客

03-22

1867

@Provide装饰器和@Consume装饰器：与后代组件双向同步

鸿蒙开发笔记(六):状态管理,组件状态管理 @Provide @Consume, @Observed @ObjectLink

Waruler的博客

01-16

2194

参与评论您还未登录，请先登录后发表或查看评论

浅谈@Provide、@Consume装饰器

最新发布

2501_93490614的博客

10-15

158

一般用于跨组件双向数据同步传值。相比@State、@Link装饰器，使用更加方便简洁，如果使用@Link，会传递多次，使用@Provide、@Consume，不需要我们做任何事（即不需要我们调用子组件手动传参），由系统内部自动帮我们做数据同步和传值。系统帮我们维护，会消耗系统一些资源，一般是在@Link装饰器不能满足使用需求时，会使用这个。父组件使用 @Provide 装饰属性，子组件/其它后代组件使用@Consume 装饰属性，注意属性名及类型和父组件保持一致，系统内部会自动帮我们做数据同步和传值。

鸿蒙进阶篇-状态管理之@Provide与@Consume

2401_88463044的博客

11-24

1684

嘿！大家还记得这张图吗？不记得也要记得哦，因为这张图里的东西，既是高频必考面试题，也是实际开发中，经常需要用到的玩意，大致上可以这么理解：下面Components框起来的部分，就是组件之间的状态变量的管理，也就是数据通讯，它会涉及到组件之间的关系，比如父子关系，比如祖孙关系或者其他跨级关系等等。昨天我们已经学习了左下角的@Prop和@Link，今天需要学的就在中间位置：@Provide/@Consume装饰的变量用于跨组件层级（多层组件）同步状态变量。

OpenHarmony后代组件双向同步，跨层级传递：@Provide装饰器和@Consume装饰器

OpenHarmony_dev的博客

10-08

640

可选，允许父组件中常规变量（常规变量对@Prop赋值，只是数值的初始化，常规变量的变化不会触发UI刷新，只有状态变量才能触发UI刷新）、@State、@Link、@Prop、@Provide、@Consume、@ObjectLink、@StorageLink、@StorageProp、@LocalStorageLink和@LocalStorageProp装饰的变量装饰变量初始化子组件@Provide。@Consume装饰的变量，在其父节点或者祖先节点上，必须有对应的属性和别名的@Provide装饰的变量。

HarmonyOS（十七）——状态管理之@Provide装饰器和@Consume装饰器（与后代组件双向同步）

hirezy

12-21

1409

HarmonyOS状态管理之@Provide和@Consume，应用于与后代组件的双向数据同步，应用于状态数据在多个层级之间传递的场景。

HarmonyOS4.0系列——05、状态管理之@Prop、@Link、@Provide、@Consume，以及@Watch装饰器

NanChen的博客

01-10

2178

看下面这张图Components部分的装饰器为组件级别的状态管理，部分为应用的状态管理。开发者可以通过@StorageLink/@LocalStorageLink 实现应用和组件状态的双向同步，通过@StorageProp/@LocalStorageProp 实现应用和组件状态的单向同步。

HarmonyOS鸿蒙开发组件状态管理详细说明（State、Prop、Link、Provide和Consume、Watch、ObjectLink和Observed）

qq_36255346的博客

03-25

4038

HarmonyOS鸿蒙开发组件状态管理详细说明（State、Prop、Link、Provide和Consume、Watch、ObjectLink和Observed）

@Provide装饰器和@Consume装饰器：与后代组件双向同步

2302_77228054的博客

06-09

609

@Provide和@Consume，应用于与后代组件的双向数据同步、状态数据在多个层级之间传递的场景。不同于上文提到的父子组件之间通过命名参数机制传递，@Provide和@Consume摆脱参数传递机制的束缚，实现跨层级传递。

@Provider装饰器和@Consumer装饰器：跨组件层级双向同步

2302_77228054的博客

06-11

920

@Provider和@Consumer用于跨组件层级数据双向同步，可以使得开发者不用拘泥于组件层级。 @Provider和@Consumer属于状态管理V2装饰器，所以只能在@ComponentV2中才能使用，在@Component中使用会编译报错。 @Provider和@Consumer提供了跨组件层级数据双向同步的能力。在阅读本文档前，建议提前阅读：@ComponentV2。

鸿蒙HarmonyOS开发：状态管理@State、@Prop、@Link、@Provide、@Consume @Watch详解

在这里，我乐于倾囊相授，分享我的技术心得、项目实战经验、技术技巧。希望能够惠及更多的开发者，助力大家在技术的海洋中扬帆远航。

05-17

5567

我们构建的页面多为静态界面。如果希望构建一个动态的、有交互的界面，就需要引入“状态”的概念。在声明式UI编程框架中，UI是程序状态的运行结果，用户构建了一个UI模型，其中应用的运行时的状态是参数。当参数改变时，UI作为返回结果，也将进行对应的改变。这些运行时的状态变化所带来的UI的重新渲染，在ArkUI中统称为状态管理机制。自定义组件拥有变量，变量必须被装饰器装饰才可以成为状态变量，状态变量的改变会引起UI的渲染刷新。如果不使用状态变量，UI只能在初始化时渲染，后续将不会再刷新。

Inject Provide @Inject @Provide

weixin_42274805的博客

11-08

615

一、Inject与Provide 作用：父级与子孙组件传递数据场景：由于vue有$parent属性可以让子组件访问父组件。但孙组件想要访问祖先组件就比较困难。通过provide/inject可以轻松实现跨级访问父组件的数据使用： // 父组件 <template> <div> <son></son> </div> </template> <script> export default { name

@Provide+@Inject组合使用

Jonn1124的博客

05-27

755

@Provide+@Inject组合使用 // 组件A export default { provide() { return { reload: this.reload; } } methods: { reload() { // 刷新页面的代码。。。 } } } // 组件BCDEFG都可以使用 export default { inject: ['rel

Dagger2 @Module @Provide 的简单使用

龙衣

12-17

891

Dagger2 简单入门三部曲（一）——是什么？ Dagger2 简单入门三部曲（二）——为什么使用？ Dagger2 简单入门三部曲（三）——怎么使用？ dagger2的使用在前面几篇文章已经介绍过了这篇文章主要介绍dagger2 的 @Module和@Provides的使用。先来回顾这两个注解的作用：@Module的出现是为了解决@Inject不是使用的场景，比如我们使用第三方库，或者...

HarmonyOS ArkTS学习-状态管理-@Provide和@Consume

weixin_43725192的博客

06-03

569

鸿蒙系统应用开发学习-状态管理-@Provide和@Consume双向同步

HarmonyOS NEXT应用开发之@Provide装饰器和\@Consume装饰器：与后代组件双向同步

maniuT的博客

04-03

1067

Provide/@Consume装饰的状态变量有以下特性：@Provide装饰的状态变量自动对其所有后代组件可用，即该变量被“provide”给他的后代组件。由此可见，@Provide的方便之处在于，开发者不需要多次在组件之间传递变量。后代通过使用@Consume去获取@Provide提供的变量，建立在@Provide和@Consume之间的双向数据同步，与@State/@Link不同的是，前者可以在多层级的父子组件之间传递。

鸿蒙 @State 的底层原理

07-24

<think>嗯，用户想深入了解鸿蒙系统中@State注解的实现机制，特别是源代码层面的分析。这属于系统级框架设计的深度技术问题，用户可能是HarmonyOS应用开发者或系统架构师，需要理解底层实现来优化应用性能。从技术角度看，@State作为ArkUI的核心响应式机制，涉及编译时注解处理、运行时状态管理和UI渲染管道的协同。用户可能遇到状态更新延迟或性能问题，才需要深挖源码。不过鸿蒙作为闭源系统，直接查看完整源码受限，但可以通过开发者文档和公开的SDK代码片段分析。用户引用的两段文献其实与问题无关，可能是误粘贴。第一段讲CNN模型实现，第二段讨论论文审稿GPT的训练方案，都涉及AI模型微调技术。这提示用户可能有跨领域的技术背景，但当前应聚焦在ArkUI框架分析上。关于@State的实现机制，需要从三个层面展开： 1. 编译时处理：分析@State注解如何被ArkCompiler识别并生成状态管理代码 2. 运行时机制：解释StateManager如何追踪依赖和触发UI更新 3. 跨设备同步：说明分布式软总线如何传递状态变更特别注意要强调闭源码的限制，避免给出未经证实的实现细节。可以引用官方文档说明设计思想，比如状态与UI组件的绑定关系。对于实际开发，更值得关注的是@State的最佳实践和常见陷阱。相关问题设计应覆盖： - 原理层：响应式机制与Vue/React的差异 - 应用层：性能优化和状态设计模式 - 扩展层：与其他状态管理方案的集成这能帮助用户建立系统化认知，而不仅是碎片化代码分析。</think>理解鸿蒙系统（HarmonyOS）中 `@State` 注解的实现机制需要从 **ArkUI 框架**（鸿蒙的声明式UI开发框架）和 **ArkCompiler**（鸿蒙的运行时）层面分析。虽然无法直接查看完整的闭源源码，但基于官方文档、技术解析和公开的SDK代码片段，其核心机制可概括如下： --- ### 一、`@State` 的核心作用 `@State` 是 **组件内部状态** 的注解，用于标记一个变量： 1. **响应式更新**：当被 `@State` 标记的变量值改变时，**自动触发关联UI的重新渲染**。 2. **作用域限定**：状态仅对当前组件及其子组件可见（通过 `@Link` 或 `@Prop` 传递时）。 3. **数据驱动UI**：是实现声明式UI编程的核心机制之一。 --- ### 二、实现机制分析（源码级逻辑推断） #### 1. **编译时：注解处理与代码生成** - **注解扫描**：ArkCompiler 在编译组件代码时，识别 `@State` 注解。 - **生成代理类**：编译器为含 `@State` 的类生成**代理类**（Proxy Class），例如： ```java // 原始代码 @Component struct MyComponent { @State count: number = 0 } // 编译器生成（伪代码） class MyComponent_Proxy { private __count: ObservedProperty<number> = new ObservedProperty(0); get count(): number { return this.__count.get(); } set count(value: number) { this.__count.set(value); // 触发更新逻辑 } } ``` - **状态包装**：将原始变量（如 `count`）包装为 `ObservedProperty` 对象，实现**值变更的监听**。 #### 2. **运行时：状态管理与依赖追踪** - **状态对象 (`ObservedProperty`)**： - 内部封装 `value` 和 `listeners`（监听该状态的UI组件列表）。 - 提供 `get()`/`set()` 方法，其中 `set()` 会触发更新流程： ```typescript class ObservedProperty<T> { private value_: T; private listeners: Component[] = []; set(value: T) { if (this.value_ !== value) { this.value_ = value; this.notifyListeners(); // 通知所有依赖此状态的组件 } } notifyListeners() { listeners.forEach(comp => comp.updateUI()); } } ``` - **依赖收集**： - 当UI组件（如 `Text`）在 `build` 方法中读取 `this.count` 时，触发 `get()` 方法。 - 运行时将该组件注册为 `count` 的监听者（添加到 `listeners` 列表）。 #### 3. **UI更新：渲染管线触发** - 状态变更后，`notifyListeners()` 调用监听组件的 `updateUI()` 方法。 - ArkUI 框架通过 **差异比对（Diffing）** 计算最小化UI变更： - 仅重绘受影响的组件子树（非整树刷新）。 - 使用 **虚拟DOM** 或 **更轻量的UI描述树** 优化性能[^1]。 --- ### 三、关键设计亮点 1. **细粒度更新** 仅更新依赖变更状态的组件，避免全局刷新（对比传统 `setState` 的粗粒度更新）。 2. **编译优化** ArkCompiler 的 AOT（Ahead-of-Time）编译将状态管理逻辑提前生成，减少运行时开销。 3. **跨设备状态同步** 在分布式场景下，`@State` 可通过 `@Provide`/`@Consume` 跨设备同步，底层由 **分布式数据管理模块** 实现[^2]。 --- ### 四、与类似框架对比 | 机制 | HarmonyOS `@State` | React `useState` | Flutter `StatefulWidget` | |-------------|-------------------------|------------------------|---------------------------| | **更新粒度** | 组件级 | 组件级 | 组件级 | | **依赖追踪** | 自动（编译时生成） | 手动声明依赖数组 | 手动调用 `setState` | | **编译优化** | AOT 生成代理类 | JIT 运行时追踪 | AOT 编译 | | **跨平台能力** | 原生支持分布式设备同步 | 需第三方库（如 Redux） | 不支持 | --- ### 相关问题 1. `@State` 与 `@Link`、`@Prop` 在状态传递机制上有何本质区别？ 2. ArkUI 如何通过 `@State` 实现比传统命令式UI更高的渲染性能？ 3. 在分布式场景下，`@State` 的状态同步如何保证数据一致性？ 4. `@State` 能否用于管理复杂对象（如嵌套数组）？会有什么性能陷阱？ > 注：由于 HarmonyOS 部分源码未完全开源，上述分析基于公开文档及SDK行为反推。实际实现可能涉及更多底层优化（如状态压缩、增量更新等）。 [^1]: 差异比对与轻量UI树是声明式框架通用优化手段，见 ArkUI 设计文档。 [^2]: 分布式状态同步依赖 HarmonyOS 的分布式软总线与数据管理服务。