Flutter Rust Bridge 中 Ulid 类型的哈希一致性解决方案

问题背景

在使用 Flutter Rust Bridge 进行跨语言开发时，开发者遇到了一个关于 Ulid 类型的有趣问题。Ulid 是一种通用唯一标识符，类似于 UUID，但包含时间戳信息。当在 Dart 代码中获取 Rust 结构体中 Ulid 字段的哈希值时，发现每次调用都会返回不同的哈希码。

问题分析

这个问题源于 Flutter Rust Bridge 在处理外部类型时的默认行为。当 Ulid 类型从 Rust 传递到 Dart 时，系统会为每个实例生成一个新的 Dart 对象，即使底层数据相同，Dart 也会为这些对象分配不同的哈希码。

在 Rust 端，代码结构如下：

pub struct WorkoutDetails {
    pub id: Ulid,
    pub name: String,
    pub exercise_info: Vec<ExerciseInfo>,
}

在 Dart 端调用时：

var id = workout.id();
print(id.hashCode);  // 每次输出不同的值

解决方案探索

初步尝试：镜像类型

开发者首先尝试使用 Flutter Rust Bridge 的镜像功能，希望通过声明镜像类型来解决这个问题：

#[flutter_rust_bridge::frb(mirror(Ulid))]
pub struct _Ulid(pub u128);

然而，这种方法未能奏效，生成的类型仍然是完全不可见的(opaque)，无法访问其方法或属性。

有效解决方案：包装类型

最终有效的解决方案是创建一个包装类型，将 Ulid 转换为字节数组：

#[derive(Clone, Copy, PartialEq, PartialOrd, Debug)]
pub struct FlutterUlid(pub [u8; 16]);

impl From<Ulid> for FlutterUlid {
    fn from(value: Ulid) -> Self {
        Self(value.to_bytes())
    }
}

然后在 Dart 端使用自定义的哈希比较逻辑：

final HashMap<U8Array16, String?> selectedWeights = HashMap(
    equals: (key1, key2) {
        // 自定义比较逻辑
    },
    hashCode: Object.hashAll);

技术深入

哈希一致性的重要性

在编程中，哈希一致性是许多数据结构（如哈希表）正常工作的基础。当对象的哈希值在生命周期内发生变化时，会导致这些数据结构出现不可预测的行为。

Flutter Rust Bridge 的类型处理机制

Flutter Rust Bridge 在处理外部类型时有两种主要方式：

1. 透明类型：完全转换为 Dart 对应类型
2. 不透明类型：保持为 Rust 原生类型，通过 FFI 调用

对于外部 crate 的类型，默认会作为不透明类型处理，这就是为什么直接使用 Ulid 类型会导致方法不可访问的原因。

最佳实践建议

1. 对于简单值类型：考虑转换为基本类型（如字符串、字节数组）后再传递
2. 对于复杂类型：创建包装类型，实现必要的转换 trait
3. 哈希一致性：在 Dart 端实现自定义的 equals 和 hashCode 逻辑
4. 类型镜像：等待 Flutter Rust Bridge 未来版本对第三方 crate 类型的更好支持

未来展望

Flutter Rust Bridge 团队已经意识到这个问题，并在新版本中计划改进对第三方 crate 类型的支持。这包括：

• 允许为镜像类型指定方法签名
• 自动扫描第三方 crate 生成绑定代码

这些改进将大大简化外部类型的使用体验，减少开发者需要编写的样板代码。

总结

在跨语言开发中，类型系统的差异常常会带来各种挑战。通过创建适当的包装类型和实现必要的转换逻辑，开发者可以有效地解决这些问题。Flutter Rust Bridge 作为一个活跃的项目，正在不断改进其对复杂类型场景的支持，未来将提供更优雅的解决方案。