HarmonyOS鸿蒙Next开发中复用native端结构较为繁琐，期望提供方法手动维护napi导出类的状态更新

HarmonyOS鸿蒙Next开发中复用native端结构较为繁琐，期望提供方法手动维护napi导出类的状态更新 【问题描述】：

目前在鸿蒙开发中复用native端结构较为繁琐，需要多维护2套类/结构体（用于生成 napi wrapper 和使用状态管理装饰器）。期望提供方法可以手动维护napi导出类的状态更新，这样就只需要在native侧多维护一套即可。

【版本信息】：rust 工具链最新版本，ohos.rs 1.1.6，鸿蒙 api22

10 回复

开发者您好，看您描述中是使用了rust，当前rust支持HarmonyOS是采用三方库，想跟您确认下，您是采用了哪一个三方库。

更多关于HarmonyOS鸿蒙Next开发中复用native端结构较为繁琐，期望提供方法手动维护napi导出类的状态更新的实战系列教程也可以访问 https://www.itying.com/category-93-b0.html


用的这个：https://github.com/ohos-rs/ohos-rs

开发者您好，这个库为三方维护的库，建议您直接联系三方库开发者，通过其官方渠道进行沟通。

可通过 NAPI 手动绑定 + 手动触发状态更新 实现，仅维护 Native 一套结构，ArkTS 侧不定义重复类。

实现方案

  1. Native 侧定义结构，手动封装 setter，并主动触发 ArkTS 状态更新。
  2. ArkTS 侧使用 observedV2 包裹对象，不重复定义结构。

Native 关键代码（Rust + ohos.rs）

// 只维护一套 Native 结构
#[derive(Default)]
pub struct UserData {
    pub name: String,
    pub age: u32,
}

// 导出类 + 手动触发更新
#[ohos_expand]
impl UserData {
    #[construct]
    pub fn new() -> Self {
        Self::default()
    }

    // setter 中主动 emit 通知更新
    pub fn set_name(&mut self, name: String) {
        self.name = name;
        self.emit("name", &name); // 触发状态刷新
    }

    pub fn set_age(&mut self, age: u32) {
        self.age = age;
        self.emit("age", &age);
    }
}

ArkTS 侧代码（无重复结构）

// 直接使用 native 导出类，ObservedV2 自动响应
@ObservedV2
export class UserData extends NativeUserData {}

// 页面使用
@State user: UserData = new UserData();

// 调用 native setter → UI 自动刷新
this.user.setName("Tom");

官方文档

不支持。ohos.rs 是三方维护库，状态管理是内部实现。而且无法集成

我觉得可以尝试对三方库ohos.rs进行改造操作，来达到目的

我不会支持，没有意义。这个跟arkts的状态管理强耦合了，以后有V3 V4都得改，你们可以fork一个自行处理。

ohos-rs解决的问题是N-API的重复工作，不是跟上层状态管理之间的维护。要保持其能力的最小化粒度和可维护性。

比如napi-rs不会支持 redux 是一个道理。

HarmonyOS的NAPI设计中，导出类实例默认由框架管理其生命周期与状态同步。若需手动维护，可使用napi_wrap将原生对象绑定到JS对象，并通过napi_set_property显式更新属性值，或利用napi_get_reference_value获取引用后操作。注意：手动管理需自行处理引用计数与内存释放，避免泄漏。

可以通过自定义 napi 绑定宏减少重复。在 Rust 侧仅维护一份结构体定义，利用过程宏自动生成 napi 导出的类（含 getter/setter），并在 setter 中调用 napi::Env::add_finalizer 或通过 ThreadsafeFunction 回调通知 ArkUI 状态变更。例如在宏生成代码时，为每个属性注入一个自定义的 Notify 函数，前端通过 @Observed 或手动 observer 接收更新。这样 Native 只需一套结构，状态同步逻辑完全由宏管理，避免手写两套 wrapper 和装饰器类。社区已有类似实现，可扩展 napi crate 的 derive 机制实现。

回到顶部