Flutter二进制组件鸿蒙适配实战：字节流编解码与EventChannel优化

1. 为什么要把 Flutter 组件 b 搬到鸿蒙——适配背景与选型

先交代一下背景。我们团队原先有一整套基于 Flutter 的跨端业务组件，内部代号统一按字母排，组件 b 就是其中负责二进制数据处理与字节流编解码的那一块。它不承担 UI，不关心页面状态，唯一的使命是：把从设备端、服务端或本地文件里读到的原始字节流，按照既定协议拆包、校验、路由、解析，再反向组装成字节流回传出去。

过去这套逻辑在 Android 和 iOS 上跑得很稳，依赖的也是 Dart 标准库里的 dart:typed_data，几乎不碰平台原生代码。但到了鸿蒙适配这个节骨眼上，问题就不是“Dart 能不能写”这么简单了。鸿蒙的 Flutter 支持走的是 OpenHarmony 生态的 Flutter 适配分支，引擎、平台通道、插件机制都和官方主线有差异。组件 b 里凡是涉及平台通道传递原始字节、调用系统底层解析能力、或者依赖第三方原生插件的路径，全部要重新过一遍鸿蒙侧的实现方式。

如果你也是被“公司要求 Core 业务尽快跑通鸿蒙”推着走的人，应该能理解这种处境：往往不是 Flutter 代码本身要动刀子，而是你以前默认存在的东西——比如 MethodChannel 默认编码、二进制在通道里的类型映射、NDK 层的内存生命周期——在鸿蒙上可能完全是另一套规则。

所以这篇文章围绕组件 b 的适配实战展开，核心讲三件事：极简二进制数据处理的正确姿势是什么、字节流编解码怎么设计才算“治理架构”、以及鸿蒙适配时真正会卡住你的细节到底有哪些。内容偏工程向，适合已经在 Flutter 里写过一点数据解析、现在要往鸿蒙迁移的开发者；如果你刚接触 Flutter 但懂一些 Java/Kotlin 或 ArkTS，跟着思路走也完全能看懂。

2. 字节流的“第一性原理”——为什么二进制处理和 JSON 完全是两回事

在进入鸿蒙适配之前，我建议先把字节流本身想透。因为组件 b 做得越久，我越确认一件事：大多数二进制处理代码写得痛苦，不是 API 不熟，而是没分清“结构化数据”和“字节流”之间的本质区别。

2.1 字节是最终语言，任何协议都是“约定”

JSON 或 XML 这类文本格式自带结构标记，有括号、有逗号、有键名，人类和机器都能看出边界。但二进制流里什么都没有，一段 01 串能解释成什么，完全取决于编解码双方的事先约定。这个约定至少要回答四个问题：

• 字段从哪里开始、到哪里结束（长度）
• 整数是有符号还是无符号（符号）
• 多字节数值是按大端还是小端排放（端序）
• 一段消息从哪里断开算一条完整数据（定界）

这四个要素不弄清楚，后面全白干。组件 b 里所有解析代码的根，都建立在这套“协议名词表”之上。比如协议里说“前 2 字节是包体长度，无符号 16 位，大端序”，那 readUint16 就是基础操作；如果协议说“第 3 字节的 bit0 表示启用压缩”，那你需要的不只是读字节，还需要位运算。

2.2 常见的二进制协议字段类型

我整理了一下组件 b 里高频出现的二进制字段类型，每次新人对接手代码有困惑时我都会先甩这张表：

你可以把这四个问题想象成寄快递：长度是快递单上的重量，符号是“能不能是负数”，端序是“地址从上往下写还是从下往上写”，定界是“几个包裹打成一个袋子运”。 协议设计漏掉任何一个，就会出现“包裹收到但拆不开”的情况。

2.3 Flutter 里的二进制容器：Uint8List 与 ByteData 的分工

Dart 的标准库其实已经提供了足够底层的工具，很多人只是没分清 Uint8List 和 ByteData 的角色。

Uint8List 是一块连续的、按字节访问的数组，适合做“临时缓存”和“传输载体”。你在网络层读到的原始数据，几乎都以 Uint8List 形态出现。而 ByteData 是同一块内存之上的“结构化视图”，它允许你把这块内存解释成 int8、uint8、int16、float32 等更丰富的形态，并指定端序读写。

组件 b 的代码里有一个很核心的约定：所有需要按字段读写的路径，一律先把 Uint8List 包装成 ByteData，再基于视图去读写；所有用于传输和缓存的数据，一律保持 Uint8List 形态。 这样做的好处是可以避免频繁拷贝内存。ByteData 在创建时传入的是既有 buffer，它只是改变“看待同一块内存的方式”，并不会复制数据。

dart复制Uint8List rawBytes = Uint8List.fromList([0x00, 0x01, 0x02, 0x03]);
ByteData view = ByteData.sublistView(rawBytes);
// 读取前 2 字节，大端序无符号整数
int firstShort = view.getUint16(0, Endian.big);

声明宏详解：不少人喜欢用 ByteData(rawBytes.length) 再 setUint8List 拷贝一遍，这在数据量不大时无所谓，但组件 b 处理的音频采样数据动辄几十 KB，每次多拷贝一次数组，在鸿蒙这种内存敏感的设备上，性能和抖动差距就会显现。所以记住：能 sublistView 就不 copy，能用视图就不新建对象。

3. 极简二进制数据处理实现——BufferReader / BufferWriter 设计与踩坑

有了底层的“字节视角”，接下来就是组件 b 的核心部分：一个极简、好维护、方便鸿蒙侧复刻的读写缓冲区。

3.1 从零写一个 Dart 字节缓冲区

我不会一上来就丢一个重型的二进制解析框架。组件 b 的定位就是“极简”，所以 BufferReader 和 BufferWriter 两个类就足够了。设计思路很简单：

• BufferWriter 内部维护一个 BytesBuilder，提供按字段类型的 write 系列方法，写完后通过 toBytes() 输出完整 Uint8List。
• BufferReader 内部维护原始字节数组和当前读取偏移量，提供按字段类型的 read 系列方法，读完后可以检查 hasRemaining 或 remainingLength。

下面是一个极简的 Dart 实现片段，字段类型覆盖最常见的 uint8 / uint16 / uint32 / int32 / float32 / float64 / bytes / string：

dart复制import 'dart:typed_data';

class BufferWriter {
  final BytesBuilder _builder = BytesBuilder(copy: false);
  final Endian endian;

  BufferWriter({this.endian = Endian.big});

  void writeUint8(int value) {
    if (value < 0 || value > 0xff) {
      throw ArgumentError('value out of range: $value');
    }
    _builder.addByte(value);
  }

  void writeUint16(int value) {
    final data = ByteData(2)..setUint16(0, value, endian);
    _builder.add(data.buffer.asUint8List());
  }

  void writeUint32(int value) {
    final data = ByteData(4)..setUint32(0, value, endian);
    _builder.add(data.buffer.asUint8List());
  }

  void writeInt32(int value) {
    final data = ByteData(4)..setInt32(0, value, endian);
    _builder.add(data.buffer.asUint8List());
  }

  void writeFloat32(double value) {
    final data = ByteData(4)..setFloat32(0, value, endian);
    _builder.add(data.buffer.asUint8List());
  }

  void writeFloat64(double value) {
    final data = ByteData(8)..setFloat64(0, value, endian);
    _builder.add(data.buffer.asUint8List());
  }

  void writeBytes(Uint8List bytes) {
    _builder.add(bytes);
  }

  void writeString(String value, {int lengthBytes = 2}) {
    final encoded = Uint8List.fromList(value.codeUnits);
    if (lengthBytes == 2) {
      writeUint16(encoded.length);
    } else if (lengthBytes == 4) {
      writeUint32(encoded.length);
    }
    writeBytes(encoded);
  }

  Uint8List toBytes() => _builder.toBytes();
}

dart复制class BufferReader {
  final Uint8List _bytes;
  final ByteData _view;
  final Endian endian;
  int _offset = 0;

  BufferReader(this._bytes, {this.endian = Endian.big})
      : _view = ByteData.sublistView(_bytes);

  int get remainingLength => _bytes.length - _offset;
  bool get hasRemaining => _offset < _bytes.length;

  int readUint8() {
    if (!hasRemaining) {
      throw const FormatException('Buffer underflow');
    }
    return _view.getUint8(_offset++);
  }

  int readUint16() {
    _checkReadable(2);
    final value = _view.getUint16(_offset, endian);
    _offset += 2;
    return value;
  }

  int readUint32() {
    _checkReadable(4);
    final value = _view.getUint32(_offset, endian);
    _offset += 4;
    return value;
  }

  int readInt32() {
    _checkReadable(4);
    final value = _view.getInt32(_offset, endian);
    _offset += 4;
    return value;
  }

  double readFloat32() {
    _checkReadable(4);
    final value = _view.getFloat32(_offset, endian);
    _offset += 4;
    return value;
  }

  double readFloat64() {
    _checkReadable(8);
    final value = _view.getFloat64(_offset, endian);
    _offset += 8;
    return value;
  }

  Uint8List readBytes(int length) {
    _checkReadable(length);
    final sub = _bytes.sublist(_offset, _offset + length);
    _offset += length;
    return sub;
  }

  String readString({int lengthBytes = 2}) {
    final length = lengthBytes == 2 ? readUint16() : readUint32();
    final sub = readBytes(length);
    return String.fromCharCodes(sub);
  }

  void _checkReadable(int need) {
    if (remainingLength < need) {
      throw FormatException(
          'Buffer underflow: need $need bytes, remaining $remainingLength');
    }
  }
}

这套代码在组件 b 里跑了两年，支撑了不下二十种业务协议。它真正的价值不在于“能读懂多少种类型”，而在于读写出错时能给出足够清晰的异常信息。比如 Buffer underflow: need 4 bytes, remaining 2，这种日志拿到手上，基本一眼就能定位是协议字段长度对不上，而不是猜来猜去。

3.2 读写浮点、变长整数时的隐性问题

写基础类型时踩过几个不算小坑，值得单列出来。

第一个坑：浮点数的端序与宽度必须一致。 组件 b 早期处理传感器数据时，协议规定传输 float64，但我在 BufferWriter 里粗心写了 writeFloat32，导致对方收到所有坐标全部错乱。这类错误不会抛异常，因为都是合法浮点数，但数值完全不对。后来我做了一个非常笨但有效的防护：在 BufferWriter 的每个 write 方法里都加了字段名断言检查，凡是写入的 String 注释与实际类型不符，直接在开发断言阶段提示。生产环境关闭断言，但开发期可以避免大量低级错误。

第二个坑：变长整数并不“天然存在”。 有些协议为了节省流量，会用 7-bit 分段编码，C 系语言里常见的 varint 是依靠每个字节的高位标识“后面还有字节”。Dart 没有内置 readVarint，所以组件 b 自己实现了一套。核心逻辑就是循环读取，每读一个字节，把低 7 位取出，按 7 位一组拼进结果：

dart复制int readVarint() {
  int result = 0;
  int shift = 0;
  while (true) {
    if (!hasRemaining) {
      throw const FormatException('Varint underflow');
    }
    final byte = readUint8();
    result |= (byte & 0x7f) << shift;
    if ((byte & 0x80) == 0) {
      break;
    }
    shift += 7;
    if (shift > 28) {
      throw const FormatException('Varint too long');
    }
  }
  return result;
}

注意这里的 shift 上限，如果不限制，恶意或损坏的数据流会让循环无限推进，最终抛出溢出异常。所有从外部拿到的字节流都应被视为不可信输入。

第三个坑：String.fromCharCodes 只能处理单字节或 UTF-16 码元的情况。 如果协议里塞的是 UTF-8 编码的中文文本，直接用 codeUnits 拼字符串会把多字节字符拆成一堆乱码。组件 b 的 writeString 默认用的是简单 codeUnits，只适合纯 ASCII；涉及中文或 Emoji 时，必须用 utf8 包编码后再写入。Emscripten 和 ArkTS 侧也存在同一个问题——我自己就在鸿蒙的 util.TextDecoder 上栽过一次，这个稍后在鸿蒙章节细说。

3.3 不要把 List 当字节数组用

这也是一个很容易踩的坑，尤其对从 Java 转过来的 Flutter 开发者。Java 的 byte[] 天然就是“无符号字节”的直觉，Dart 里没有 byte 类型，只有 int。于是许多人图省事，直接用 List<int> 存原始字节。

List<int> 在 Dart VM 里是一个对象数组，每个元素都是 64 位整数对象，内存开销远大于 Uint8List 的连续字节块。更要命的是，当你把 List<int> 传给 MethodChannel 或其他原生通道时，类型映射会变得非常含糊——Flutter 的标准 StandardMessageCodec 对 List<int> 和 Uint8List 的底层映射路径不同，某些原生端甚至会把 List<int> 当作对象数组逐元素反射处理，性能直接崩掉。

组件 b 有一条铁律：二进制数据的载体只允许 Uint8List，任何 List<int> 都要在入口处转换，任何从通道接收的二进制也要先断言为 Uint8List。 鸿蒙适配时，这条铁律省了非常多的事，因为 ArkTS 侧接收 Flutter 传来的数据时，底层映射期望的也是 Uint8List 对应的 Uint8Array，类型对不上就会出现“数据到了，但转换层抛异常”的诡异问题。

4. 字节流编解码治理架构——协议路由、缓冲池与异常闭环

单独一套 BufferReader/BufferWriter 只能解决“读写字节”的问题，但组件 b 面对的是一整条业务链路的解析与分发。当二进制消息不止一种协议类型、也不保证一次传完时，就需要一个“治理架构”来兜住全局。

4.1 基于协议号的注册路由中心

你要处理的字节流往往带一个“类型字段”。组件 b 的每一条消息第一个字段是 2 字节协议号（uint16），后面跟着具体负载。处理这类消息最怕的是 if else 满天飞——每加一种协议就改一次解析入口，代码最终会腐化成一个谁都动不了的巨石函数。

治理架构的第一步，是做一个按协议号注册的路由中心。核心数据结构就是一张 Map<int, CodecHandler>，Dart 侧极简实现如下：

dart复制abstract class CodecHandler {
  void onPacket(BufferReader reader, PacketContext context);
}

class CodecCenter {
  final Map<int, CodecHandler> _handlers = {};

  void register(int protocolType, CodecHandler handler) {
    if (_handlers.containsKey(protocolType)) {
      throw StateError('Protocol $protocolType already registered');
    }
    _handlers[protocolType] = handler;
  }

  void dispatch(Uint8List packet) {
    final reader = BufferReader(packet);
    if (reader.remainingLength < 2) {
      throw const FormatException('Packet too short, missing protocol type');
    }
    final protocolType = reader.readUint16();
    final handler = _handlers[protocolType];
    if (handler == null) {
      onUnknownProtocol(protocolType, packet);
      return;
    }
    handler.onPacket(reader, PacketContext(packet));
  }
}

这段代码看起来很简单，但真正让组件 b 的“治理”成立的是另外三件事：

• 注册是启动期完成的：每个业务协议模块在 init() 阶段把自己注册进 CodecCenter，模块与路由中心解耦，新增协议不必改动 dispatch。
• 未知协议有统一出口：onUnknownProtocol 里可以统一记录日志、上报监控、或者把原始包存到本地调试桶，而不是在某个解析函数里打印一堆临时代码。
• 协议号与版本绑定：协议升级时不要原地覆盖同一个协议号，组件 b 的做法是新增协议号并保留旧处理逻辑一段窗口期，这比向下兼容好维护得多。

4.2 粘包/半包的环形缓存解法

字节流治理中绕不开“粘包与半包”的问题，这也是我一直坚持要单列出来的原因。组件 b 对接的硬件设备常常把多个协议包塞进一批网络包，或者一个完整包被拆成好几个 TCP 片段到达。

治本的方法是协议原本就设计良好——包头带完整长度字段。组件 b 采用的就是“2 字节长度前缀 + 协议号 + 负载”的格式。但即便协议再规范，接收侧也依然需要处理“当前缓冲区里可能只有半个包”的情况。

我用的方案非常朴素：维护一个累计缓冲区和已缓冲长度，每次收到新字节先追加，再循环检查缓冲区内是否有完整包。 伪代码如下：

dart复制class StreamPacketAssembler {
  final BytesBuilder _buffer = BytesBuilder(copy: false);

  void append(Uint8List chunk) {
    _buffer.add(chunk);
    _tryParse();
  }

  void _tryParse() {
    while (true) {
      final bytes = _buffer.toBytes();
      if (bytes.length < 2) {
        return; // 缓冲区连长度字段都不够
      }
      final lengthView = ByteData.sublistView(bytes);
      final packetLength = lengthView.getUint16(0, Endian.big);
      final totalLength = packetLength + 2;
      if (bytes.length < totalLength) {
        return; // 半包，继续等
      }
      final packet = Uint8List.sublistView(bytes, 2, totalLength);
      _consume(totalLength);
      CodecCenter.instance.dispatch(packet);
    }
  }
}

在这里要提醒一个非常关键的细节：BytesBuilder.toBytes() 会返回一份新的聚合内存，频繁调用会有不必要的分配。所以在 _tryParse 里不要每收到一个 chunk 就发行一次 toBytes，最好在合适的时机手动维护一段 Uint8List 作为“积累区”，满了再扩容。组件 b 最终实现引入了一个简单环形缓冲方案，其实质都一样，核心是**“能解析多少就解析多少，剩余部分留在缓冲区等下一次数据”**。

4.3 校验失败后的可观测性与降级

治理架构的最后一个维度是异常闭环。二进制数据的特点是：一旦错位，后续全糊。之前遇到过设备端偶发把一个 uint16 的协议号写成了 uint32，导致读取长度完全错乱，所有后续包全部 FormatException。

要是没有统一出口，每个业务模块自己 catch、自己打印，你很难在线上版本里快速定位到底是设备端问题还是组件 b 解析问题。所以我有一条经验：在 dispatch 入口处做整体性的包长度校验和 CRC 校验（如果协议有），校验不过绝不进入具体 handler。 具体的降级策略分三级：

• 轻度：CRC 校验不过但协议号可识别，丢弃该包、计数上报，不影响后续包解析。
• 中度：连续 N 个包校验失败，暂停该协议号解析 5 秒，并上报一次“协议风暴”。
• 重度：在某个协议的 handler 内部出现 FormatException，由 dispatch 统一 catch，记录日志并关闭该协议路由，防止单个坏包拖垮整个解析线程。

这套策略最朴素的一点是：字节流解析必须“坏一包，丢一包；不能坏一串，崩全线”。 把异常边界收拢在路由中心，是组件 b 能稳定支撑多种业务协议的关键。

5. 鸿蒙适配实录——EventChannel 传输二进制与端侧裁剪

现在来到最硬核的部分：把这些 Dart 侧的字节流设计真正落到鸿蒙设备上跑起来。组件 b 在鸿蒙适配过程中，最核心的场景是：Flutter 侧通过 EventChannel 接收从鸿蒙系统底层返回的原始二进制数据，或者反向把二进制负载发给鸿蒙侧的系统服务。

5.1 鸿蒙事件通道的二进制传输路径

Flutter 官方主线和鸿蒙分支的平台通道机制大体相似，但细节差异足够让你折腾大半天。组件 b 用的是 EventChannel，因为需要接收连续的二进制流（比如传感器数据、音频 PCM、文件块等），而不是一次一答式的 MethodChannel。

Dart 侧建立 EventChannel 的方式没什么特殊：

dart复制const EventChannel _binaryChannel = EventChannel(
    'com.team.binary/event',
    StandardMethodCodec());
_binaryChannel.receiveBroadcastStream().listen((event) {
  if (event is Uint8List) {
    onBinaryChunk(event);
  }
});

但这里有一个容易忽略的前提：EventChannel 的 Dart 端接收到的类型，完全取决于原生端 send 出去的对象类型。 在 Android 上你通常 send 一个 byte[]，走了标准消息编解码后 Dart 端拿到 Uint8List；在鸿蒙上对应的是 Uint8Array，理论上也能映射到 Uint8List。但如果你在鸿蒙侧图省事，直接把字节数组 Array 当参数 send，或者经过一层 JSON.stringify 序列化成字符串，到了 Dart 端就会收到 String 而不是 Uint8List，组件 b 统一的解析入口就会全部崩掉。

组件 b 的做法是在鸿蒙侧封装了一个 BinaryEventEmitter，对上游暴露的始终是 Uint8Array，并且内部做一层类型断言，任何非 Uint8Array 的返回都在源头拦下来。这一步极其重要，可以让你在 Flutter 端完全无感知，不需要为鸿蒙单独写分支。

5.2 通道传输的“三座大山”：对象类型、大包分片与内存拷贝

鸿蒙适配期间，组件 b 真正花时间解决的，是下面三个具体问题。

第一座：对象类型映射

上面已经说过 Uint8Array 与 Uint8List 的映射。这里要补充一个细节：鸿蒙侧如果是用 ArkTS 写的数据采集模块，很多系统 API 返回的是 ArrayBuffer，而不是 Uint8Array。ArrayBuffer 不能直接作为 EventChannel 的 send 参数，你需要先包一层 Uint8Array(arrayBuffer) 来显式指定视图。否则 ArkTS 运行时可能因为“参数类型不兼容”抛一个晦涩的类型错误，一旦报错你很难从堆栈里直观看到是“ArrayBuffer vs Uint8Array”的问题。

第二座：大包分片

EventChannel 本质上适合小数据量的流式推送，一次性 send 几百 KB 的二进制大块，在鸿蒙的适配分支上有概率触发底层信道的缓冲上限，表现为 Dart 端静默丢失后续事件或抛出 PlatformException、MalformedMessageException。

组件 b 没有依赖通道自动处理大包，而是自己做了一个非常克制的分片策略：超过 4KB 的二进制块，鸿蒙侧拆成多个 chunk，每个 chunk 带 2 字节的序列号头，Dart 端用 StreamPacketAssembler 重新拼装回完整包。本质就是上一节讲的半包拼装思路，只不过方向反过来了。这套机制让组件 b 在鸿蒙上可以直接传输 1MB 级别的原始文件块，基本上解决了“二进制通道不安全”的幻觉。

第三座：内存拷贝

鸿蒙侧生成一个 Uint8Array 并交给 EventChannel send 后，底层很可能对这个数组再拷贝一次。组件 b 早期在鸿蒙上处理 48kHz、双声道、16bit 的音频 PCM 流时，每秒钟约 192KB 数据，如果每次 send 都重复拷贝两三次，CPU 占用能明显看到上涨。

优化方案有两步：

• 复用鸿蒙侧的发送缓冲区：声明一个 Uint8Array，塞满数据后立即 send，send 完成后复用同一个 ArrayBuffer 继续填充新数据，底层有对应优化的设备可以直接减少 GC 压力。
• 如果鸿蒙系统侧 API 允许传递文件描述符或共享内存，优先走共享内存链路；EventChannel 只传“数据就绪”的通知信号。这个方案在组件 b 的音频场景里验证过，性能最好，但复杂度也最高，不一定每个团队都需要上。

我在适配时最深的感受是：鸿蒙上的二进制传输，在数据量小时“怎么传都行”，一旦数据量变大，通道本身的类型转换和内存布局就会成为最大瓶颈。

5.3 端侧裁剪：一次典型的踩坑复盘

最后讲一个非常典型的踩坑过程。组件 b 在鸿蒙真机调试时突然出现偶发崩溃，崩溃栈指向 ari 层的 ByteArray 访问越界，但组件 b 的 Dart 侧没有任何异常输出。

当时我第一次排查方向完全是错的：我以为是 Flutter 端解析器的问题，加了大量日志，却发现崩溃发生在 Dart 代码运行之前。于是我把注意力放到鸿蒙侧的采集代码，才发现上游系统服务返回的 Uint8Array 实际长度为 0，但代码里还是按“期望长度”去读取了字节。原因是系统服务在启动后有个冷启动窗口，第一次回调返回的是一个空包。

这个问题的通用解法是：鸿蒙侧的每个二进制发送方，在 send 之前必须显式检查缓冲区长度；如果长度为 0，要么跳过本次发送，要么发送一个带明确“空包标识”的特殊协议包。 不要在“空数据”和“完整数据”之间留下含糊地带。

另外，组件 b 在鸿蒙上还踩过一个和 Flutter 3.x 的 Impeller 渲染引擎有关的小坑。鸿蒙适配分支如果使用了较新的 Flutter 引擎，开启 Impeller 后部分设备的热度抬高，EventChannel 的数据交付延迟会有轻微抖动。这不影响字节流本身，但对实时音频解析类业务影响明显。如果你在鸿蒙上做实时数据采集，务必在设备上实测一波 Impeller 开/关的延迟差异，再决定要不要引擎层做特殊配置。

dart复制// 组件 b 在鸿蒙侧发送二进制块的分片伪实现
// 假设 data 是鸿蒙侧采集到的 Uint8Array
final int maxChunkSize = 4096;
int sequence = 0;
for (int offset = 0; offset < data.length; offset += maxChunkSize) {
  int end = min(offset + maxChunkSize, data.length);
  // 拼一个分片包头：2 字节序列号 + 2 字节负载长度 + 字节负载
  ByteBuffer chunkHeader = ByteArray(4);
  chunkHeader.setUint16(0, sequence++);
  chunkHeader.setUint16(2, end - offset);
  // 把 header 与 data 子区间拼接后 send
  binaryEventEmitter.send(concatChunk(chunkHeader, data, offset, end));
}

这段伪代码把“分片、带序列号、接收端重组”的逻辑表达得很直观，也是组件 b 在鸿蒙侧二进制发送路径上的标准姿势。关键是序列号，接收端虽然不一定用到它，但一旦出现乱序或丢包，你能靠它快速定位是网络层、通道层还是设备端的问题。

尾声：一点个人的适配心得

组件 b 这次鸿蒙适配，真正改的 Dart 核心逻辑其实很少——BufferReader/BufferWriter 原封不动，协议路由中心原封不动，只有平台通道收发二进制的那一层，花了大量精力去调类型映射、分片大小、内存复用和空包防护。这让我越发确认一个判断：跨端组件要适配一个新平台，真正的成本不在业务逻辑，而在你过去默认“不需要关心”的底层边界。

如果你手头也有一套类似的 Flutter 二进制处理组件要迁往鸿蒙，我会建议从三条线同时推进：先看一眼你的 Uint8List 在通道里的映射链路，再实测一次大包传输稳定性，最后把空包、坏包、半包这一整条异常链路统一收口。这三点做完，大概率能绕开我踩过的大半坑。

最后分享一个小技巧：在鸿蒙真机上调试二进制通道时，不要只看 Dart 侧的日志，鸿蒙侧 hilog 里有关 event_channel 的底层输出往往能比 Flutter 端更早暴露问题。我就是靠它在一次大包静默丢失的问题里，直接把定位范围缩小到了“send 后、Dart 收到前”的那几百毫秒。把两端的日志放到同一时间轴上去看，比单端死磕高效得多。