1. 课程导入与工程全景
Flutter 用一套 Dart 代码同时构建 Android、iOS、Web、桌面等多端界面，但它的能力边界并不覆盖所有系统级功能。相机、蓝牙、NFC、生物识别、后台定位、系统通知、原生支付 SDK、厂商推送、文件选择器、传感器融合、原生地图与音视频硬解码等能力，最终都要落到各平台的原生 API 上。Flutter 原生插件与平台通道工程，解决的正是“Dart 世界”与“原生世界”之间的桥接问题：让 Dart 侧能以稳定、可测试、可维护的方式调用原生能力，并让原生侧能把事件、数据与错误回传给 Dart。
本课程不是零散地讲几个 API，而是围绕一条完整的工程链路展开：从 Dart 侧发起调用，经过平台通道编码，进入 Android 的 MethodChannel/EventChannel 或 iOS 的 FlutterMethodChannel/FlutterEventChannel，再由原生实现完成实际工作，最后把结果或流式事件回传。理解这条链路的每一段，才能写出不“卡死”、不“丢事件”、不“内存泄漏”的插件。
核心价值：为什么必须掌握平台通道
平台通道的价值可以归纳为三点。第一是能力扩展：Flutter 官方插件覆盖通用场景，但企业级应用常需要接入自研或第三方原生 SDK，此时必须自己写插件。第二是性能与体验：把重计算、大文件 IO、硬件编解码放到原生侧，可以避免 Dart 主 isolate 阻塞导致的掉帧。第三是工程可控：当插件由团队自己维护时，版本、线程模型、错误码、生命周期都能按项目规范统一，而不是被第三方插件的兼容性牵着走。
典型应用场景包括：调用系统相机并实时处理预览帧、接入厂商推送与消息透传、使用原生地图 SDK 做轨迹绘制、通过蓝牙与 IoT 设备通信、调用安全芯片做密钥签名、在后台持续采集定位并上报。这些场景的共同点是：Dart 侧只负责业务编排与 UI，真正的系统交互由原生实现承担。
平台通道的三种形态与选择依据
平台通道并非只有一种。最常用的是 MethodChannel，适合“一次调用、一次返回”的请求-响应模型，例如获取设备型号、触发一次原生支付、读取某个配置。它的返回值只有三种结果：成功携带结果、抛出 PlatformException、或返回 notImplemented。第二种是 EventChannel，适合持续产生的事件流，例如传感器数据、定位更新、蓝牙扫描结果。它把原生侧的 EventSink 包装成 Dart 的 Stream，Dart 侧通过 listen 订阅，取消订阅时要确保原生侧停止发送，否则会出现“页面已销毁但原生仍在推数据”的泄漏。第三种是 BasicMessageChannel，适合双向、对等的消息通信，例如原生侧主动向 Dart 发送指令，或需要自定义编解码器的场景。
选择依据可以这样判断：如果交互是“问一次答一次”，用 MethodChannel；如果是“持续推送”，用 EventChannel；如果是“双方都能主动发消息”，用 BasicMessageChannel。实际工程中三者常组合使用，例如一个相机插件用 MethodChannel 控制开始/停止，用 EventChannel 推送预览帧，用 BasicMessageChannel 传递自定义的帧元数据。
一次调用的完整生命周期
以“调用原生获取电池电量”为例，Dart 侧执行 channel.invokeMethod('getBatteryLevel')。这条调用会被 StandardMessageCodec 编码成二进制消息，通过 channel name 找到对应的原生 handler。Android 侧在 onMethodCall 中匹配 method 名，读取系统电量，再通过 result.success(level) 回传；iOS 侧在 handle 回调中调用 UIDevice.current.batteryLevel，再执行 result(level)。如果原生侧抛异常，应调用 result.error(code, message, details)，Dart 侧会收到 PlatformException，业务层据此区分“权限不足”“硬件不可用”“参数错误”等不同情况。
这里有一个容易被忽略的细节：线程模型。Android 的 MethodChannel 回调默认运行在平台主线程（UI 线程），如果原生实现里有耗时操作，必须切到工作线程，完成后再切回主线程调用 result，否则会阻塞 UI。iOS 的 FlutterMethodCallHandler 默认在平台线程执行，同样需要注意不要在主线程做重 IO。EventChannel 的 EventSink 也必须在正确的线程上调用，否则可能触发断言或丢事件。
工程化交付的检查清单
本课程最终要交付的不是“能跑通的 demo”，而是一个可维护的插件工程。以下清单可作为每个插件的验收依据：
| 维度 | 检查项 | 合格标准 |
|---|---|---|
| Dart API | 方法命名、参数类型、返回值 | 语义清晰，空安全，异常可区分 |
| Android | MethodCallHandler、ActivityAware、权限 | 线程正确，生命周期绑定，权限回调完整 |
| iOS | FlutterMethodCallHandler、Registrar、EventSink | 主线程安全，dealloc 时清理监听 |
| 事件流 | 订阅/取消订阅、错误传播 | 取消后原生停止发送，错误能到达 Dart |
| 测试 | 单元测试、集成测试、示例 App | 覆盖成功、失败、边界三类路径 |
| 发布 | pubspec、CHANGELOG、平台声明 | 版本语义化，平台最低版本明确 |
学习路径与最终目标
课程按“原理—实现—进阶—工程化”推进。先理解通道的编解码与线程模型，再分别完成 Android 与 iOS 的插件骨架，接着处理事件流、生命周期、权限与错误码，最后进入测试、性能与发布。每一章都会围绕一个可运行的最小对象展开，例如一个“设备信息插件”或“传感器事件插件”，逐步叠加能力，而不是孤立地讲概念。
完成本课程后，你应该能够独立设计并实现一个 Flutter 插件：Dart 侧 API 稳定易用，Android 与 iOS 双端行为一致，事件流在页面切换时不泄漏，错误码能被业务层准确识别，并且附带示例 App 与测试。这个交付物既是学习成果，也是后续接入企业原生 SDK 的工程模板。