在 Flutter 中集成原生本地模型，摆脱 JNI 地狱
Source: Dev.to
我是通过一次艰难的经历学到这课的，而不是从博客文章或会议演讲中得到的——那是一周里每一次成功构建后仍觉得不对劲的感受。
应用能够运行，模型能够工作，但每一次改动都显得十分脆弱，仿佛只要一次调用写错，就会破坏某个看不见的东西。这通常就是我知道自己已经踏入 JNI 地狱的标志。
在十五年以上紧贴移动运行时的工作经验中，我逐渐认同一个事实：
跨平台 UI 很容易。跨平台原生执行却不容易。
当在 Flutter 应用中引入设备端模型时，抽象边界不再温和，它开始要求精确无误。
在 mobile app development Charlotte 中，这个问题出现的频率往往超出团队的预期，尤其是在性能、内存控制和生命周期正确性真正重要的情况下。
为什么 Flutter 在原生机器学习周围感到不适
- Flutter 在渲染和状态管理方面表现出色。
- 它从未设计为掌控需要对线程、内存和生命周期顺序进行严格控制的原生执行路径。
在设备上的模型会立即暴露出这一差距：
- 模型初始化 对时机敏感。
- 推理 对线程亲和性敏感。
- 内存分配模式 很重要。
Flutter 的默认桥接并未隐藏这些细节；它以最糟糕的方式将其显现出来。
我反复看到的错误： 将原生机器学习视为 插件 问题，而不是 运行时 问题。
JNI 的真实成本并非语法
JNI 本身并不是敌人。真正的成本在于它隐藏的东西。
- 每一次 JNI 边界的跨越都会引入 线程上下文、对象生命周期 和 所有权 的不确定性。
- 当你加入分配大缓冲区并期望确定性销毁的模型运行时，这种不确定性会成倍增加。
我调试过只在热重启后出现的内存泄漏。
我追踪到帧率下降是由 JNI 调用导致的，这些调用在技术上是异步的，但仍然与 UI 线程竞争。
这些问题在 Dart 端并不明显。
JNI 不会大声报错。它会慢慢失效。
为什么平台通道在负载下会崩溃
- Flutter 的平台通道很方便，但它们也相当 coarse。
- 它们 serialize 消息，marshal 数据，并假设请求是简短且不频繁的。
- 模型推理违背了上述所有假设。
当我首次通过方法通道连接本地模型时，一切看起来都很正常——直到出现并发情况：
- 多个进行中的调用。
- 生命周期事件在推理过程中触发。
突然，调用顺序变得至关重要，而通道抽象层从未暴露这种情况。调试从 Dart 转向 Logcat 再回到 Dart，双方都无法完全了解对方的状态。
明确拥有本机运行时
- Flutter → 请求工作。
- Native code → 拥有执行。
这种思维转变简化了一切。本机层成为具有明确生命周期的服务；Flutter 成为客户端。一旦我不再尝试让模型感觉“Flutter‑native”，集成就稳定下来。
通过减少跨越而非消除跨越来避免 JNI
完全避免 JNI 不切实际；减少跨越是可实现的。
- 边界设计: Flutter 发送 intent，而不是数据。
- 配置: 只发生一次。
- 执行: 在本地进行。
- 结果: 以最小的信号或不透明的引用返回。
大型张量从不跨越边界。
中间状态从不跨越。
Flutter 不会轮询进度；它会收到完成通知。
大多数集成失败的根源在于线程
- 设备端推理必须在主线程之外——显而易见，却经常被违反。
- 不那么明显的是：与 Flutter 共享的线程池仍可能导致竞争。如果原生推理运行在引擎也使用的线程池上，你只是把问题搬了过去。
解决方案： 将模型执行隔离到专用的执行器或调度队列中。这种隔离是不可妥协的；它可以防止推理高峰导致渲染或输入处理被饿死。一旦实现了这种分离，帧的稳定性会立刻提升。
内存所有权必须明确
Flutter 的垃圾回收世界并不能直接映射到本地内存管理。
- 本地模型运行时通常要求 显式所有权。
- 必须在恰当的时机释放缓冲区。
- 必须确定性地销毁上下文。
最佳实践： 完全避免在边界之间传递所有权。
- 本地代码负责分配。
- 本地代码负责释放。
- Flutter 最多持有不透明句柄。
这种约束可以消除整类仅在高负载下才会出现的泄漏和崩溃。
生命周期是沉默的杀手
应用生命周期事件会在你是否准备好的情况下到来：
- 后台 / 前台
- 低内存信号
- 进程死亡
如果原生模型运行时没有明确绑定到这些事件，它最终会出现异常行为。我曾见过模型在后台后仍占用内存，以及恢复后出现重新初始化竞争。
解决方案： 将生命周期所有权交给原生代码。它必须直接订阅平台生命周期事件并相应地管理模型。Flutter 不应调解此责任。
热重载在这里不是你的朋友
热重载是生产力的礼物——但也是陷阱。
- 本机状态在重载后仍然存活，而 Dart 状态不会。
- 模型运行时会持久化。
- 线程继续运行。
- 引用会变得陈旧。
我的做法： 将热重载视为不支持本机模型集成的情况。在开发过程中，触及本机代码路径时强制完整重启。此约束可节省在仅存在于混合生命周期状态下的“幽灵”上追逐的数小时。
为什么 FFI 通常优于 JNI 用于设备端模型
在有条件的情况下，我更倾向于使用 基于 FFI 的集成 而不是 JNI 桥接，因为：
- 直接调用能够提供更清晰的所有权语义。
- FFI 避免了 JNI 那种额外的间接层和线程上下文的繁琐处理。
- 它与 Dart 的原生扩展配合得更好，性能也可能更高。
TL;DR
- 将原生机器学习视为运行时服务，而非 Flutter 插件。
- 尽量减少 JNI 跨越；发送意图，而不是数据本身。
- 在专用线程/执行器上隔离推理过程。
- 将内存所有权保留在原生端。
- 将原生生命周期绑定到平台事件，而不是 Flutter。
- 避免对原生代码进行热重载；使用完整重启。
- 在可能的情况下优先使用 FFI，以获得更清晰的语义和更低的开销。
遵循这些指南可以把脆弱的 “JNI‑地狱” 体验转变为 Flutter 与设备端机器学习模型之间的稳定、可维护的集成。
移除对象编组的层次
它去除了对象编组的层层包装，使性能特征更易预测。
在使用基于 C 或 C++ 的推理引擎时尤其如此。调用栈变得透明，调试也重新变得理智。
JNI 仍有其用武之地，但 FFI 在对机器学习工作负载重要的方面更贴近底层。
Handling Model Initialization Without Blocking Flutter
Initialization is heavy. It must not block Flutter’s startup.
I initialize models lazily but deliberately. Not at first frame. Not at first interaction. During an idle window after the UI has settled.
Native code controls this timing. Flutter is informed when readiness is reached.
This approach avoids cold‑start penalties while keeping inference responsive when needed.
跨边界的错误处理
错误必须干净地跨越边界，或者根本不跨越。
通过 JNI 抛出本机异常是错误的。会导致崩溃。相反，我将本机失败转换为明确的状态。
Flutter 对状态作出响应。本机代码处理原因。
这种分离使错误处理保持确定性且易于调试。
为什么当架构诚实时调试会更容易
以这种方式重构集成后，最显著的变化是心理层面的。
调试不再感觉像是对抗。日志变得有意义。线程追踪与预期相符。性能问题变得可复现。
这让我知道架构终于对它的行为诚实了。
让它看起来简单的陷阱
团队经常尝试在干净的 Dart API 后面隐藏复杂性。这种冲动可以理解，但也很危险。
原生机器学习本身就很复杂。假装相反只会把复杂性转移到故障模式中。
我学会了只暴露足够的现实，让未来的维护者了解他们正在触碰的内容。明确的边界。明确的所有权。明确的成本。
当 Flutter 仍然是正确选择时
尽管如此，Flutter 仍然是一个强有力的选择：渲染速度、开发者效率、跨平台覆盖。
关键是要尊重它抽象的边界。设备端模型存在于那条边界之外。
只要对这条边界保持尊重，集成就会变得可预测，而不是痛苦。
与经验相伴
经过十五年，我不再以牺牲正确性为代价去追求优雅。我追求的是在压力下表现与演示时相同的系统。
将本地设备模型集成到 Flutter 中而不陷入 JNI 地狱，并不是靠巧妙的技巧，而是要接受系统的某些部分需要显式控制。
当 Flutter 被允许发挥其最佳特长，而本地代码被信任来掌控执行时，结果并非魔法般的奇迹，而是更好的东西。
它很稳定。