Uniffi-rs 项目中外部 crate 自定义类型在导出函数中的绑定签名问题解析

在 uniffi-rs 0.26.1 版本中，开发者发现了一个关于跨 crate 使用自定义类型时的绑定生成问题。这个问题主要影响 Swift 绑定生成器，但也可能影响其他语言绑定。

问题现象

当在一个 crate 中定义自定义类型并通过 uniffi::custom_new_type 声明后，在另一个 crate 中使用该类型时，生成的绑定函数签名会出现不一致的情况。

具体表现为：

• 在定义该类型的原始 crate 中，绑定函数会正确生成基于底层类型（如 u64）的签名
• 在使用该类型的外部 crate 中，绑定函数却生成了使用 RustBuffer 的签名

技术背景

Uniffi 的自定义类型机制允许开发者创建基于基础类型（如 u64、String 等）的新类型。这些类型在 Rust 内部有明确的语义，但在 FFI 边界会被转换为对应的基础类型。

正常情况下，当自定义类型在其定义的 crate 中使用时，uniffi 能够正确识别其底层表示并生成相应的绑定代码。但当这些类型被其他 crate 导入使用时，类型信息在元数据处理过程中出现了丢失或转换。

问题根源

经过分析，这个问题与 uniffi 的元数据处理机制有关：

1. 当前 ExternalKind 枚举没有包含对基础类型的支持，导致外部 crate 无法正确识别自定义类型的基础表示
2. 类型信息在跨 crate 边界传递时，缺少必要的上下文来保持其原始语义
3. 对于复杂类型（如基于 String 的自定义类型），由于它们本来就使用 RustBuffer 传递，所以不会表现出这个问题

解决方案探讨

要彻底解决这个问题，可能需要：

1. 扩展 ExternalKind 枚举以包含基础类型支持
2. 确保类型信息在跨 crate 使用时能保持完整的语义
3. 可能需要引入新的声明方式来显式指定外部类型的基础表示

不过，这种修改需要考虑向后兼容性和使用复杂性。目前，开发者可以通过以下临时解决方案：

• 在导出函数中直接使用基础类型
• 在函数内部进行类型转换
• 对于复杂类型，由于它们使用 RustBuffer 传递，可以继续正常使用

总结

这个问题揭示了 uniffi 在处理跨 crate 自定义类型时的一些局限性。虽然对于简单类型目前存在工作区，但长期来看需要改进元数据处理机制来提供更一致的类型处理体验。开发者在使用跨 crate 自定义类型时应当注意这个问题，特别是在性能敏感的场合，因为错误的绑定签名可能导致不必要的序列化开销。