蓝牙 SDK 跨平台分层设计：Flutter 接入 Android & iOS 蓝牙 SDK 的方案设计

首先，本文介绍了跨平台分层设计的背景；然后，表达了当前正面临 Flutter 接入 SDK 这一困难；进一步地，提出了跨平台分层设计的思路，以及讨论了在 Flutter 上调用特定平台代码的方案选择；最后，用具体业务和代码论证了此方案的可行性。

Swuagg · 2026-02-27 20:32:38 发布

一、设计需要考虑的点

await sendCmd(CmdV2ConvInviteReq());
await waitAck();
if (isAccepted) {
  await sendCmd(CmdV2ConvActionReq());
}

问题是：

方案一：每个 SDK 都新建一个 Flutter Plugin 项目，最后引入到 Flutter 工程中：https://juejin.cn/post/7165732423534460965

dependencies:
  my_flutter_plugin:
    path: ../my_flutter_plugin

方案二：基于原有 Flutter 项目结构，在 Android 和 iOS 模块分别引入 SDK：

方案选择：对于一定会打包进应用的 SDK，可以直接在 Flutter 目录引入；对于不一定会打包进应用的 SDK，建议每个 SDK 新建一个 Plugin 方式去引入。

👉 建议使用方案一，虽然蓝牙 SDK 是应用核心模块，一定会打包进去，但为方便移植和解耦，还是建议新建 Plugin 的方案。

业务层——蓝牙组件层——平台兼容层——V1 / V2 协议分发层——蓝牙 SDK

业务层：不感知协议版本（V1 / V2），不感知平台（Android / iOS），只表达业务意图，比如：“我要发通知”，“我要获取 AR 眼镜设备信息”；
蓝牙组件层：BluetoothService 统一入口，把业务意图封装成 Command，与具体业务解耦；
平台兼容层：使用 Pigeon / MethodChannel，从 Flutter → Native 透传，不做协议判断；
V1 / V2 协议分发层：Native 层 Android / iOS 端决定使用哪个协议编码；
蓝牙 SDK：将 Byte 发给 AR 眼镜，Android → .aar，iOS → .xcframework。

场景	是否推荐 Pigeon	是否推荐 MethodChannel	说明
蓝牙 SDK 对外能力 (connect / send)	✅	❌	稳定性优先：SDK 接口需要严格的类型约束，防止版本断层。
业务级指令 (Notify / Call / Control)	✅	❌	业务契约：使用 Pigeon 定义协议，两端同步更新，减少沟通成本。
Flutter ↔ Native 数据模型	✅	❌	强类型：自动生成 Model 类，避免手动解析 Map 导致的字段错误。
设备状态回调 (连接状态、电量)	✅	❌	FlutterApi：利用 Pigeon 的反向调用机制，结构化下发状态更新。
少量、固定指令 (如：获取版本号)	✅	❌	工程规范：即便是小功能，使用 Pigeon 也能保持全局代码风格统一。
SDK 封装层 (三方地图、支付)	✅	❌	标准接入：插件开发标配，确保开发者调用时的 API 提示友好。
协议调试 / 临时命令	❌	✅	快速验证：无需运行脚本生成代码，随写随测，适合敏捷开发。
非结构化 Map 透传	❌	✅	灵活性：数据结构极其不固定或嵌套过深时，手动处理更直观。
高频、大数据流 (PCM / SCO)	❌	⚠️ (EventChannel)	性能瓶颈：Pigeon 的序列化开销不适合流式数据，应选 EventChannel。
动态协议 (灰度 / 远程配置)	❌	✅	动态性：Pigeon 依赖编译时生成，无法处理云端动态下发的字段。
C++ / JNI SDK 透传	❌	✅	透传层：Native 层只是个搬运工，没必要在中间层再做一次强类型定义。