做 Flutter 应用迁移到 OpenHarmony 的时候，最容易被卡住的往往不是 UI 适配，而是一些看起来不起眼的基础能力。数据指纹校验就是一个典型场景：文件完整性检查、增量更新校验、分片去重、缓存 key 生成，全都依赖一个又快又稳定的哈希函数。我在实际项目里试过不少方案，最后锁定了 murmur3，并在鸿蒙侧完整做了一遍适配。这篇内容就把整个思路、实现细节和排坑过程整理出来，给正打算在 OpenHarmony 上用 Flutter 做类似事情的朋友一个可复用的参考。
1. 为什么是在鸿蒙上做数据指纹，为什么是 murmur3
1.1 数据指纹需求从哪来
做客户端开发的人对“数据指纹”这个概念应该不陌生。它本质上就是用哈希算法给一段数据算出一个固定长度的摘要，用这个摘要来代表数据本身。最常见的场景有这几个：
- 资源文件完整性校验：App 启动时检查若干关键资源文件的哈希值，防止资源被篡改或者下载过程出错。
- 增量更新：把一个大文件切成若干分片，每片单独算哈希，客户端只下载缺失的分片，服务端通过分片哈希确认内容正确。
- 缓存命中：用请求参数或者文件路径的哈希值作为缓存 key，快速定位缓存条目，避免用长字符串做 key 带来的内存和时间开销。
- 数据去重：上传场景中，先上传文件指纹，服务端发现已经有相同指纹的文件，就跳过内容传输。
这些场景对哈希算法有两个共同要求：计算要快、分布要均匀。md5 虽然也快，但已经被证明存在碰撞风险，而且很多安全策略上已经不建议用于完整性校验场景。sha256 很安全但性能开销大，在嵌入式设备或者移动端硬件上对大量分片做校验时，CPU 占用会明显偏高。这时候 murmur3 就很有优势了。
1.2 Murmur3 的核心价值
Murmur3 是 Austin Appleby 设计的非加密哈希算法，属于非加密哈希家族。所谓非加密哈希，是指它不追求对抗恶意碰撞的安全性，而是追求在正常数据分布下极高的计算效率和极低的碰撞率。它和加密哈希（比如 SHA 系列）的关系，就像日常门锁和保险柜锁的区别：门锁主要防止随机路过的人顺手推门，保险柜锁才需要防专业开锁。
具体到算法特性，murmur3 有几个关键指标：
| 指标 | 说明 | 实际意义 |
|---|---|---|
| 计算速度 | 比 md5 快 3 到 5 倍，比 sha256 快 8 到 20 倍 | 处理 GB 级文件时优势明显 |
| 分布均匀性 | 输出值近似均匀分布，雪崩效应好 | 做分片、负载均衡、哈希表分布均匀 |
| 碰撞率 | 32 位版本碰撞率约 1/2^32 | 指纹字段足够短但够用 |
| 实现复杂度 | C/C++ 实现几百行代码 | 前后端多端实现容易保持一致性 |
很多高性能开源项目都在用 murmur3，比如 Cassandra、Hadoop、Redis 的某些哈希场景、nginx 的一致性哈希等。把这套成熟算法移植到 OpenHarmony 生态，本质上就是让应用层能够低成本地拿到一个高性能指纹计算能力。
1.3 为什么不能直接拿 pub.dev 上的库用
这是这个项目最核心的痛点。Flutter 生态里确实有 murmur3 相关的库，比如murmur3这个包，但它是纯 Dart 实现的，算法层面没问题，性能却受限于 Dart AOT 后的执行效率。做少量字符串哈希没什么感觉，一旦进入文件分片、流式计算的场景，纯 Dart 版本的速度劣势就会被放大。
还有一类情况更麻烦：某些库虽然公开了源码，但内部依赖了 C++ 实现，需要通过 FFI 或原生插件编译调用。这类库在 Android/iOS 上能正常编译，到 OpenHarmony 上就不行了，因为鸿蒙的 Flutter 插件体系、原生库编译链和 Android 并不完全兼容。直接硬编往往遇到的是 NDK 路径找不到、so 库架构不支持、PlatformView 注册方式不一致这类问题。
所以最佳的适配路径是：把 murmur3 的核心算法用 C/C++ 实现好（或者复用公共领域实现），在鸿蒙侧用 NAPI 封装成原生接口，Flutter 侧通过鸿蒙 Flutter 插件的通道来调用。这套方案既能保证计算性能，又能让 Dart 层拿到同步返回值，避免异步通信的额外开销。
2. 三条适配路线怎么选：纯 Dart、NAPI 还是 ArkTS 重写
2.1 路线一：纯 Dart 实现
方案内容：在 Dart 层直接用Uint32List、位运算实现 murmur3 的 32 位和 128 位变体。
- 优点：跨端一致性最容易保证，写一次代码，Android、iOS、鸿蒙、桌面端都能跑；不需要处理任何平台通道和原生编译问题；调试起来非常简单。
- 缺点：性能天花板明显。Dart 虽然 AOT 编译后性能不错，但是面对大文件流式计算，位运算是热点路径，JIT/AOT 生成的代码在密集位运算场景下仍然明显慢于 C++ 原生实现。实测在 100MB 文件分片场景下，纯 Dart 实现耗时大约是 C++ 实现的 3 到 6 倍。
- 适用场景：数据量小（几百 KB 以内）、对性能不敏感、追求开发效率的工具类应用。
2.2 路线二：C/C++ 核心 + NAPI 封装
方案内容：写一个 C++ 版本的 murmur3 核心库（这是公共领域算法，实现稳定），在 OpenHarmony 侧用 NAPI（Node API，OpenHarmony 提供的原生模块接口）暴露为原生方法。Flutter 插件通过鸿蒙的通道机制调用该原生接口。
- 优点：性能最优，C++ 位运算效率和标准实现一致；算法核心可以复用服务端或者其他平台已有的代码，保证多端指纹一致；NAPI 在 OpenHarmony 上成熟度很高，文档和社区案例相对充足。
- 缺点：工程复杂度明显上升，需要配置完整的原生编译链、CMakeLists、构建配置文件；插件包体积增加几十 KB；遇到编译问题时的排查成本比纯 Dart 高。
- 适用场景：正式业务场景，特别是需要处理大文件、大量分片、高并发指纹计算的场景。
2.3 路线三：ArkTS 侧重写
方案内容：用 ArkTS（TypeScript 语法子集）在鸿蒙侧重写 murmur3 算法，以 ArkTS 原生模块方式暴露给 Flutter 调用。
- 优点：不需要处理 C++ 编译链，ArkTS 调用栈和 UI 层统一，调试体验比原生 NAPI 直观。
- 缺点：ArkTS 的性能在纯位运算场景下虽然优于 Dart，但相比 C++ 仍然有差距；而且 ArkTS 在严格模式下的类型约束比较严格，实现 128 位版本的中间变量处理会比 C++ 啰嗦很多；算法一致性测试需要额外做一遍。
- 适用场景：团队对 C++ 不熟、但又希望比纯 Dart 性能好一些的中间态方案。
三条路线对比下来，我的选择很明确：正式适配方案走路线二。原因不仅是性能，更重要的是算法实现可以和服务端现有接口保持完全一致——服务端在 OpenHarmony 之外还可能有 Linux、Android 环境，一套 C++ 核心库随处编译。对需要做数据指纹校验的系统来说，多端一致性比单端性能优先级更高，因为指纹算法如果不一致，会让整个校验体系直接失效。
3. 动手前的算法理解：murmur3 的几个关键参数
3.1 变体和输出长度
murmur3 主要有三个常见变体：
- MurmurHash3_x86_32：输出 32 位哈希，最常用，适合做缓存 key、布隆过滤器、分片标志。
- MurmurHash3_x86_128：输出 128 位哈希，基于 32 位平台优化，适合需要更长指纹的场景。
- MurmurHash3_x64_128：输出 128 位哈希，基于 64 位平台优化，x86_64 架构下性能最好。
在 OpenHarmony 环境里，芯片架构通常是 ARM64（部分设备可能是 x86_64），如果目标设备是 ARM64，murmur3 的 x64_128 变体其实在 64 位 ARM 上也能运行，但经典的优化路径还是按 x86_64 调参。为了简化多端一致性，我们通常先实现 x86_32 这个最通用的版本，再按需补 x64_128。32 位指纹短、计算快、网络传输省流量；128 位指纹碰撞概率极低，适合真正对标 sha 的场景。
3.2 种子（seed）
murmur3 支持传入一个 32 位种子。种子的作用不是加密密钥，而是让同样的输入在不同的上下文中产出不同的哈希。比如两个微服务各自维护一个缓存池，可以使用不同的 seed，避免互相之间缓存 key 碰撞。
实际项目中种子可以按业务模块做静态常量划分。例如：
class FingerprintSeed { static const int kDefault = 0; static const int kCacheKey = 0x1A2B3C4D; static const int kFileChunk = 0x51D4E8F9; }这等于给每个业务域一个独立的哈希空间，测试数据和线上数据天然隔离。
3.3 核心运算常量
实现时最核心的运算逻辑是这几步：
- 对每个 4 字节块，乘以常量 c1 = 0xcc9e2d51，循环左移 15 位，再乘以 c2 = 0x1b873593。
- 对剩余不足 4 字节的尾部做特殊处理。
- 最后做雪崩操作，让输出的每一位都尽可能受输入每一位影响：h1 异或自身右移 16 位，然后乘以 0x85ebca6b，再异或右移 13 位，再乘以 0xc2b2ae35，最后异或右移 16 位。
为什么要做雪崩？简单说，如果两个相似的输入在输出上只有 1 位差别，那这个哈希作为指纹就不太合格。雪崩操作保证了输入数据的任意一位变化，输出位都会有约一半的概率翻转，这样指纹分布才足够随机。
实现的时候要特别留意有符号右移和无符号右移的差异。Dart 里没有专门的无符号右移运算符，比较容易踩坑，后面在代码部分细说。
4. Flutter 鸿蒙插件的完整适配实战
4.1 建立插件工程
鸿蒙 Flutter 插件的工程结构，可以先用 Flutter 官方的方式创建基础插件，再在插件目录下增加鸿蒙侧的ohos目录。如果你用的是鸿蒙官方适配过的 Flutter SDK 版本，插件工程可以直接通过模板生成。
flutter create --template=plugin --platforms=ohos murmur3_ohos如果没有ohos这个平台选项，说明当前 Flutter SDK 还不支持鸿蒙导出，需要先确认使用的是鸿蒙官方或社区发布的 Flutter SDK 分支。生成后的目录大致如下：
murmur3_ohos/ ├── lib/ │ └── murmur3_ohos.dart ├── ohos/ │ ├── CMakeLists.txt │ └── src/ │ ├── murmur3.cpp │ ├── murmur3.h │ └── napi_init.cpp ├── example/ │ └── lib/ │ └── main.dart └── pubspec.yaml这个阶段最容易犯的错是在普通 Flutter 工程里直接在android目录旁边放一个ohos目录就以为能跑。实际上鸿蒙插件需要在ohos目录下有自己的构建配置和依赖声明，和 Android 目录完全隔离。更规范的做法是把原生代码独立组织成一个 OpenHarmony 模块，在工程配置文件里明确声明该模块。
4.2 C++ 核心实现
murmur3 的代码是公共领域实现，可以从开源社区拿到参考，但为了让大家理解结构，我把最核心的部分拆开说。
头文件声明：
// murmur3.h #ifndef MURMUR3_H #define MURMUR3_H #include <cstdint> #include <cstddef> void MurmurHash3_x86_32(const void *key, size_t len, uint32_t seed, void *out); void MurmurHash3_x64_128(const void *key, size_t len, uint32_t seed, void *out); #endif32 位版本的核心逻辑：
// murmur3.cpp #include "murmur3.h" void MurmurHash3_x86_32(const void *key, size_t len, uint32_t seed, void *out) { const uint8_t *data = static_cast<const uint8_t *>(key); const size_t nblocks = len / 4; uint32_t h1 = seed; uint32_t c1 = 0xcc9e2d51; uint32_t c2 = 0x1b873593; const uint32_t *blocks = reinterpret_cast<const uint32_t *>(data); for (size_t i = 0; i < nblocks; i++) { uint32_t k1 = blocks[i]; k1 *= c1; k1 = (k1 << 15) | (k1 >> (32 - 15)); k1 *= c2; h1 ^= k1; h1 = (h1 << 13) | (h1 >> (32 - 13)); h1 = h1 * 5 + 0xe6546b64; } const uint8_t *tail = data + nblocks * 4; uint32_t k1 = 0; switch (len & 3) { case 3: k1 ^= tail[2] << 16; [[fallthrough]]; case 2: k1 ^= tail[1] << 8; [[fallthrough]]; case 1: k1 ^= tail[0]; k1 *= c1; k1 = (k1 << 15) | (k1 >> (32 - 15)); k1 *= c2; h1 ^= k1; } h1 ^= len; h1 ^= h1 >> 16; h1 *= 0x85ebca6b; h1 ^= h1 >> 13; h1 *= 0xc2b2ae35; h1 ^= h1 >> 16; *static_cast<uint32_t *>(out) = h1; }注意几个容易写错的地方：
- 块循环里用的是 32 位平台假设，如果目标架构是大端，需要处理字节序，通常 OpenHarmony 设备都是小端，问题不大。
- C++ 里左移配合无符号右移做循环移位：
(k1 << 15) | (k1 >> (32 - 15))就是循环左移 15 位。 - 尾部处理里
fallthrough关键字是 C++17 引入的，如果你的编译标准是 C++11，需要改成手动顺序执行或者注释说明。
4.3 NAPI 封装层
核心算法是纯 C++，但鸿蒙侧需要让 Flutter 的 Dart 层能调用它，这里通过 NAPI 暴露一个封装函数。主要思路是：接收两个入参（字节数组和种子），调用 C++ 哈希函数，返回一个无符号整型值。
// napi_init.cpp #include <napi.h> #include "murmur3.h" static napi_value Hash32(napi_env env, napi_callback_info info) { size_t argc = 2; napi_value argv[2]; napi_get_cb_info(env, info, &argc, argv); // 取入参：第一个参数是 ArrayBuffer/Uint8Array，第二个参数是 number void *data = nullptr; size_t byte_length = 0; bool is_arraybuffer = false; napi_is_arraybuffer(env, argv[0], &is_arraybuffer); if (is_arraybuffer) { napi_get_arraybuffer_info(env, argv[0], &data, &byte_length); } else { napi_typedarray_type type; size_t length = 0; void *typed_data = nullptr; napi_get_typedarray_info(env, argv[0], &type, &length, &typed_data, nullptr, nullptr); data = typed_data; byte_length = length; } uint32_t seed = 0; napi_get_value_uint32(env, argv[1], &seed); uint32_t result = 0; MurmurHash3_x86_32(data, byte_length, seed, &result); napi_value out; napi_create_uint32(env, result, &out); return out; } static napi_value Init(napi_env env, napi_value exports) { napi_property_descriptor desc[] = { {"hash32", nullptr, Hash32, nullptr, nullptr, nullptr, napi_default, nullptr}, }; napi_define_properties(env, exports, 1, desc); return exports; } NAPI_MODULE(NODE_GYP_MODULE_NAME, Init)这里要注意的是：由于 Dart 侧调用原生方法时可能会传过来Uint8List，NAPI 层需要判断到底是 ArrayBuffer 还是 TypedArray，两种类型取数据的方式不同。不处理这个分支的话，有的调用报文会返回 undefined。
4.4 插件侧 Dart 接口设计
Dart 层提供给业务方的是简洁的同步接口。这里的关键是：通过EventChannel或者MethodChannel调用原生接口都有异步往返的成本，而数据指纹校验往往在校验代码里是高频调用，所以最好把一次哈希合并成一个方法调用，不要拆成“初始化 + 计算 + 释放”三步。
import 'dart:typed_data'; import 'dart:ffi'; import 'package:flutter/services.dart'; class Murmur3 { static const MethodChannel _channel = MethodChannel('com.example.murmur3_ohos/murmur'); /// 对 [data] 计算 32 位 murmur3 哈希，[seed] 为种子 static Future<int> hash32(Uint8List data, {int seed = 0}) async { final int result = await _channel.invokeMethod<int>('hash32', { 'data': data, 'seed': seed, }); return result; } /// 对字符串计算 32 位哈希 static Future<int> hashString32(String input, {int seed = 0}) async { final Uint8List bytes = Uint8List.fromList(input.codeUnits); return hash32(bytes, seed: seed); } }接口设计有几个心得：
- 入参类型统一用
Uint8List，不要接收String后自己在 Dart 层编码，因为编码方式（UTF-8、UTF-16）必须由调用方明确控制，原生层不做编码推断。 - seed 参数放到 named parameter 并给默认值，这样普通调用方不需要理解种子概念，高级用户可以自行指定。
- 返回值用
int，在 Dart 里直接对应无符号 32 位整数，没必要封装成对象。
4.5 插件注册与桥接代码
鸿蒙侧插件需要写一个继承自 FlutterPlugin 的类，在 OnAttach 时注册 method channel handler：
// 鸿蒙插件入口（此处为简化示例，实际鸿蒙插件使用 ArkTS 编写） // 实际工程写法是 ArkTS 类，这里给出逻辑结构层面的说明。 class Murmur3OhosPlugin : public flutter::Plugin { public: static void RegisterWithRegistrar(flutter::PluginRegistrar *registrar) { auto channel = std::make_unique<flutter::MethodChannel<flutter::EncodableValue>>( registrar->messenger(), "com.example.murmur3_ohos/murmur", &flutter::StandardMethodCodec::GetInstance()); auto plugin = std::make_unique<Murmur3OhosPlugin>(); channel->SetMethodCallHandler( [plugin_pointer = plugin.get()](const auto &call, auto result) { plugin_pointer->HandleMethodCall(call, std::move(result)); }); registrar->AddPlugin(std::move(plugin)); } void HandleMethodCall(const flutter::MethodCall<flutter::EncodableValue> &call, std::unique_ptr<flutter::MethodResult<flutter::EncodableValue>> result) { if (call.method_name() == "hash32") { // 从参数中解析 data 和 seed // 将 data 转为字节数组传给 NAPI 封装的 Hash32 // result->Success(value) } else { result->NotImplemented(); } } };如果你的 Flutter 鸿蒙 SDK 版本比较新，注册方式和这个略有差异，但整体思路一致：插件类注册 method channel，收到 Dart 侧调用后，将数据传给 NAPI 层。
4.6 构建配置文件
原生侧还需要配置 CMakeLists 和构建脚本。最小化的 CMakeLists 是这样的：
cmake_minimum_required(VERSION 3.16) project(murmur3_ohos) set(CMAKE_CXX_STANDARD 17) add_library(murmur3_ohos SHARED src/murmur3.cpp src/napi_init.cpp ) target_include_directories(murmur3_ohos PRIVATE ${CMAKE_CURRENT_SOURCE_DIR}/src ${OHOS_NDK_INCLUDE_DIR} ) target_link_libraries(murmur3_ohos PRIVATE libace_engine.so libnapi.so )构建配置里最容易踩的坑是libace_engine.so这个依赖：部分版本的 Flutter 鸿蒙插件需要链接它才能使用 Flutter API。如果你只做纯 NAPI 功能，不触达 Flutter API，其实可以去掉这行。
CMake 之外还需要检查工程里的oh-package.json5、build-profile.json5，确保模块名和依赖声明正确。如果缺少对外声明插件 ID，运行时 Flutter 引擎可能加载不到 so 文件。
4.7 一致性验证必须做
迁移之后的第一件事不是性能测试，而是一致性测试。因为指纹算法如果不一致，后续所有逻辑都白搭。
验证办法很简单：准备一批固定测试数据，分别用服务端（或者另一个已跑通的标准库）计算哈希值，和鸿蒙侧计算结果对比。比如对以下测试字符串：
"hello world" "" "The quick brown fox jumps over the lazy dog" "1234567890"标准 murmur3 库算出的MurmurHash3_x86_32(seed=0)结果分别是这些值（示例）：
| 输入 | seed=0 时的哈希值 |
|---|---|
| hello world | 0x5E928CB9 |
| 空字符串 | 0x00000000 |
| The quick brown fox jumps over the lazy dog | 0x6D92B453 |
| 1234567890 | 0x3C256D96 |
注意：这些样例值是示例用途，实际迁移时必须对照你选定标准库的输出。只要从服务端标准实现里导出一批黄金测试用例，在鸿蒙侧跑一遍，通过后再进入性能调优，就能避免“整个联调阶段都在排查指纹对不上”的惨剧。
5. 性能实测与调优记录
5.1 基准测试方法
我用的是 Flutter 侧Stopwatch计时，对三种方案做了对比：纯 Dart 实现、MethodChannel + NAPI 方案、以及直接用 ArkTS 侧本地实现（模拟数据）。
测试条件：
- 设备：OpenHarmony 4.0 开发板，ARM64 架构。
- 数据：随机生成 1MB、10MB、100MB 三组数据。
- 每组数据重复计算 10 次取平均值。
- SDK 版本：Flutter 4.x 对应鸿蒙分支（尽量使用较新版本）。
5.2 测试结果
| 数据量 | 纯 Dart 平均耗时 | MethodChannel + NAPI 平均耗时 | 性能比 |
|---|---|---|---|
| 1MB | 12ms | 3.1ms | 约 3.9x |
| 10MB | 118ms | 31.4ms | 约 3.8x |
| 100MB | 1250ms | 352ms | 约 3.6x |
MethodChannel 本身有编解码和调用栈切换开销，所以对于 1KB 以下的极小数据，纯 Dart 和 NAPI 方案差距不大，甚至 MethodChannel 有可能因为通道开销还慢一点。这从侧面说明接口设计要合理：对于大量小对象，应该批量传入，而不是一次次方法调用。
5.3 优化手段一：批量分片
使用场景是文件分片校验。一次校验 1000 个分片，如果每个分片单独走 method channel，就会出现 1000 次来回调用。优化方式是把分片先拼成一个大的二进制块，连同分片边界信息一起传给原生侧，在 C++ 侧循环计算，最后把结果数组一次返回。
这样调用次数从 N 次降低到 1 次，整体性能提升非常明显，实测将 1000 个 64KB 分片的校验时间从 260ms 降到了 40ms 左右。
5.4 优化手段二：纯内存计算避免 GC 压力
NAPI 调用过程中，Dart 层传入Uint8List会被转换成标准字节数据，这个过程如果不加控制会增加 GC 压力。实践中可以在 Dart 层使用Uint8List的复用池：预先分配一块大内存，分片数据写入其中，用完再复用，减少频繁创建大对象的开销。
不过这种优化要谨慎，因为 Flutter 的 GC 器对新生代内存的管理已经比较高效，盲目做内存池反而会增加代码复杂度。对于单次调用数据量小于几 MB 的场景，先不做这个优化，等 profile 明确显示内存分配是瓶颈时再动手。
6. 高频踩坑实录与排查清单
6.1 so 库没办法加载
现象：日志提示dlopen failed: library "libmurmur3_ohos.so" not found。
原因归纳：
- 构建产物没有正确打包到应用中。
- 插件注册时声明的 so 名称和实际构建产出的名称不一致。
- 鸿蒙侧未配置正确的
ohos模块加载路径。
排查顺序：
- 确认 build 产物目录里确实生成了
libmurmur3_ohos.so。 - 确认插件入口
NAPI_MODULE(NODE_GYP_MODULE_NAME, ...)中的名称和 so 文件名匹配。 - 确认
build-profile.json5中模块配置正确，且oh-package.json5中有依赖声明。
6.2 哈希结果和服务端对不上
现象：同一段内容，鸿蒙侧算出的值和 Linux 侧标准库算出的完全不同。
优先检查三个点：
- 字节序：murmur3 的标准实现基于小端字节序，如果你的设备端输入数据经过了 UTF-16 转换，结果必然不同。
- seed 不一致：最常见的是种子默认值没对齐。
- 尾部处理：少于 4 字节的最后一块，必须保证和标准实现相同的处理顺序。
建议从一开始就建立黄金测试用例：固定输入 + 固定 seed + 固定预期输出，自动化跑一遍。别信任何一个“看起来已经正确”的哈希结果。
6.3 MethodChannel 返回 Promise 没有 resolve
现象：Dart 侧invokeMethod一直挂起，或返回 null。
原因通常是 NAPI 回调中没有正确调用result->Success()，或者 channel 名字拼写不一致。有一个隐性坑是：两个插件注册了同名的 method channel，后注册的 handler 覆盖了前一个。建议给 channel 起名时带上插件名和用途，比如murmur3_ohos/hash32_async，避免和别的业务通道混淆。
6.4 大数据量计算导致 UI 卡顿
现象：主线程上调用 100MB 数据哈希，页面掉帧明显。
优化方式：
- 把大文件分片计算放到
compute或原生线程池去执行。 - 避免在 build 方法里触发哈希计算。
- 对于超大文件，采用增量分批计算模式，每批 4KB 到 8KB，轮询执行，配合异步接口返回进度。
murmur3 本身无法增量更新（不像 sha256 可以拆块调用），所以流式计算时要自己维护块累积的逻辑：将字节分批，每批单独计算后，把结果按顺序拼接再整体哈希一次。这种方案虽然会增加少量开销，但避免了一次性加载整个文件进内存。
7. 工程级建议：把指纹防线做成框架能力
做完这个适配之后，我最大的体会是：哈希计算本身只是一个工具，真正有价值的是把它嵌入到一个统一的指纹校验框架里。如果你有多个 Flutter 应用都要跑在 OpenHarmony 上，建议不要在每个应用里重复调用 method channel，而是抽一个公共的fingerprint_service模块，提供以下能力：
- 文件指纹：给定文件路径，输出文件内容的 murmur3 指纹。
- 分片指纹：按指定分片大小切文件，输出分片指纹列表。
- 多端一致性校验：对接服务端指纹库，返回校验结果。
- 指纹缓存：避免同一文件多次重复计算。
框架层面的设计要点是保持纯函数和可测试性。指纹计算不做 IO、不做网络请求、不做状态缓存，所有外部依赖通过参数注入。这样单元测试的时候可以直接传入字节数组，不依赖真实文件系统。
那为什么最终的方案我没有把 128 位版本也覆盖进去？因为在当前业务场景中，32 位指纹已经能满足完整性校验的碰撞概率要求。但如果你对接的是政企客户或对数据安全等级要求更高的场景，建议直接把x64_128变体也实现进去，128 位指纹的网络传输占用只有 16 字节，完全没有链路负担，却把碰撞风险降到可以忽略的量级。
最后分享一个调试技巧：在原生侧写一个自检方法，编译完成后直接在鸿蒙侧跑hash32自测，输出一个固定日志。这样每次改完核心代码后，就能在联调之前快速确认算法核心是否被意外改动。我遇到过好几次明明业务代码没变、指纹却变了的情况，最后都是因为重新编译过程中标准库版本被悄悄升级了。有了自检日志，这类问题十分钟内就能定位。
