HarmonyOS 鸿蒙Next状态管理V1与V2

HarmonyOS 鸿蒙Next状态管理V1与V2 V2相对于V1有哪些突出的优点？官网资料说的太深奥了，有没有案例Demo来结合说明？比如对象状态更新结合全局状态更新或者结合数据库对象等常见场景。

14 回复

案例Demo可以参考：
基于状态管理V2-小场景案例https://developer.huawei.com/consumer/cn/codelabsPortal/carddetails/tutorials_NEXT-status-managementV2

简单的说：V2 的思想是可以通过单独的文件去管理数据和类型定义，而不是像 V1 那样大量的把 UI布局 和 状态变量 在一个文件下管理，这样便于后期的维护。

更多关于HarmonyOS 鸿蒙Next状态管理V1与V2的实战系列教程也可以访问 https://www.itying.com/category-93-b0.html


谢谢

学习了

纠结这个意义不大，迟早都要换成v2

找HarmonyOS工作还需要会Flutter的哦，有需要Flutter教程的可以学学大地老师的教程，很不错，B站免费学的哦：https://www.bilibili.com/video/BV1S4411E7LY/?p=17

现在老的更多还是V1和V2混用吧

混用有问题，基础类型没事，@State初始化的class类型的变量，传给子组件@Param修饰的变量，在api 18 上会崩

学到了，谢谢

如果你刚开始学习ArkTS，直接学V2就行了，如果你是从V1转V2，需要你对V1的认知比较深刻才能理解到变V2的意义。

举一个简单的点：V1的@State 只是说明这个变量会因变化而更新，而你不知道它是在哪里初始化的，有可能是本页面，也可能是父级页面。而V2的@Local 和@Param则是针对这一点做了区分，@Local是在本页面初始化，@Param则是通过传参。

然后是@Link转@Param+@Event，这个改动其实是在代码上改得更麻烦了，需要用回调来实现子组件向父组件传参，但有利于提升对代码的理解。

最主要的一点则是@ObjectLink改成@ObservedV2+@Trace，V1的嵌套类中的值观测起来很麻烦，V2的就简单多了。

谢谢您的解答

是的，不好理解，如果能兼容V1就好了。

鸿蒙Next状态管理V1与V2的核心区别在于架构与API设计。V1基于ArkTS的装饰器语法，如@State、@Prop，主要服务于UI组件内的状态管理。V2（即ArkUI应用状态管理）引入了更独立、中心化的状态管理方案，包括LocalStorage、AppStorage和PersistentStorage，支持跨组件、跨页面的状态共享与持久化。V2的API设计更强调状态与UI的松耦合，提供了更清晰的状态声明与更新机制。

HarmonyOS Next状态管理从V1演进到V2，核心在于架构统一、能力增强和开发简化。V2通过一套统一的响应式API覆盖了更广泛的场景，解决了V1中局部与全局状态管理模型割裂的问题。

主要优点对比：

  1. 统一响应式API：

    • V1：@State、@Provide/@Consume用于组件内/组件间，AppStorage/LocalStorage用于全局/局部UI状态，PersistentStorage用于持久化。模型多，选择复杂。
    • V2：引入 @Observable、@Track、@Computed 作为基础响应式装饰器，结合 @LocalStorageLink、@LocalStorageProp 等，形成统一心智模型。@Observable可装饰类，其属性变化自动触发UI更新，更符合现代前端开发习惯。

  2. 对象状态管理能力显著增强：

    • V1：深层嵌套对象的状态更新需要额外处理（如使用@Watch监听或重新赋值），不够直观。
    • V2：@Observable装饰的类，其嵌套属性、数组元素的变化都能被自动追踪并触发UI更新。这是V2最突出的改进之一，使得管理复杂数据模型（如从数据库映射的对象）变得非常直接。

  3. 全局状态管理更优雅：

    • V1：AppStorage是键值对形式，存储和读取类型化对象不够方便。
    • V2：可以将@Observable装饰的类实例直接绑定到AppStorage或LocalStorage。状态变更不仅在组件间同步，也能自动持久化到本地（若配置）。这实现了UI状态、应用全局状态与持久化存储的自然衔接。

场景示例说明：

场景：一个从数据库查询并编辑的“用户信息”对象

假设有一个User类，包含基本信息和地址对象。

// V2 方式
@Observable
class Address {
  city: string = '';
  street: string = '';
}

@Observable
class User {
  id: number = 0;
  name: string = '';
  age: number = 0;
  address: Address = new Address(); // 嵌套对象
}

  • 对象状态更新：

    // 在UI组件中
@State user: User = new User(); // @State 装饰，触发UI更新

// 更新深层属性，UI自动刷新
this.user.address.city = '上海';
// 更新数组（假设User有hobbies: string[]）同样自动触发
this.user.hobbies.push('篮球');

    在V1中，直接修改this.user.address.city无法触发UI更新，通常需要整体赋值。V2则直接、自动地完成了响应。

  • 结合全局状态/持久化：

    // 将User实例绑定到AppStorage，作为全局状态
AppStorage.setOrCreate<Object>('globalUser', new User());

// 在任意组件中链接使用
@StorageLink('globalUser') user: User = new User();

    此时，在任何组件中修改this.user.name或this.user.address.street，所有链接了'globalUser'的组件都会自动更新。如果配合PersistentStorage将'globalUser'键持久化，这些修改还会在应用重启后保留。

总结： V2状态管理的优势在于用**@Observable**这一核心概念，统一并简化了从组件内状态、组件间状态、应用全局状态到持久化状态的管理。对于嵌套对象、数组等复杂数据结构的响应式更新支持开箱即用，使得业务逻辑（尤其是涉及数据模型的操作）的代码更清晰、更易于维护。

官方SDK包中附带的**“Sample”示例应用**是学习V2状态管理的最佳Demo。其中“状态管理”（State Management）章节提供了大量完整代码示例，清晰展示了上述场景的具体实现。建议在DevEco Studio中直接创建并运行该Sample项目进行实践。

回到顶部