Dart Isolate、compute() 与无共享多核并发

回到总览：并发与运行时底座
回到 Dart 并发总览：Dart 并发总览：Future / event loop / isolate
相关模块：Dart EventLoop、Microtask Queue 与 Event Queue 机制 · Dart Isolate 消息传递：SendPort / ReceivePort / 可发送对象 · Native 原生线程与 Dart Isolate 桥接 (FFI 零拷贝与 NativePort)

一句话定义

Dart Isolate 是 Dart 语言实现多核 CPU 并行计算的核心机制；与传统线程不同，每个 Isolate 拥有完全独立的堆内存空间 (Isolated Memory Heap) 与独立的 EventLoop，多 Isolate 之间遵循**“无共享内存 (Share-Nothing)”**原则，仅通过 Port 端口进行消息传递。

代码索引

对应 Lab：dart-event-loop-isolate

为什么需要

• 为什么在 Flutter 中执行耗时的 JSON 大解析（如 10MB JSON 字符串）会导致界面丢帧？
  • 一句话答：Dart UI 运行在单线程的 Main Isolate 中；任何超过 16.6ms 的 CPU 密集计算（如大 JSON 解析）都会占用 Main Isolate 的 EventLoop，导致下一帧渲染无法被及时处理而产生丢帧。
• compute() 和普通 Future 有什么本质区别？
  • 一句话答：普通 Future 默认仍在当前 isolate 调度，只是改变执行时机；compute() 会把单次重计算任务搬到后台 isolate 跑完再把结果回传。
• compute() 为什么常被说“有成本、有边界，不是越多越好”？
  • 一句话答：因为它会创建/调度后台 isolate，并且参数与返回值需要跨 isolate 传输；小任务、高频碎任务或复杂多轮协作场景，compute() 往往不划算。
• Dart Isolate 和 Java 传统 Thread 有何本质区别？
  • 一句话答：Java 线程共享同一个堆内存，并发访问共享变量需要加锁（如 synchronized / ReentrantLock）；而 Dart Isolate 内存完全隔离，天然不存在多线程锁竞争与死锁难题。

底层机制

1. Dart Isolate 无共享架构模型

图注补充：Background Isolate (工作隔离体)"；消息传递 / 内存深拷贝 (或 TransferableTypedData 零拷贝)。

2. compute() 简易高阶函数脱糖

compute(fn, message) 是 Flutter 提供的轻量级封装：

1. 自动调用 Isolate.spawn() 创建后台子 Isolate。
2. 将入参 message 发给子 Isolate 执行 fn。
3. 获取子 Isolate 返回的结果后自动销毁子 Isolate。

什么时候优先用 compute()

compute() 最适合这类任务：

• 单次 CPU 重活
• 值进值出（输入一份数据，返回一份结果）
• Flutter UI 场景下已经明显影响主 isolate 响应
• 不需要长期后台 worker，也不需要多轮双向通信

典型例子：

• 大 JSON 解析
• 图片字节处理 / JPEG 编码 / 压缩
• 大列表排序、分组、聚合
• 文本解析、加解密、哈希计算

compute() 的限制与成本

限制主要有两类：

1. 函数与数据边界

   • 传给 compute() 的函数应为顶层函数或静态函数。
   • 参数和返回值必须适合跨 isolate 传输，更适合 String、Uint8List、List、Map 这类纯数据。
   • BuildContext、Widget、文件句柄、Socket、复杂宿主对象都不适合直接传。

2. 调度与消息传递成本

   • isolate 启动/调度有固定成本。
   • 参数越大、结果越大，消息传输成本越高。
   • 高频碎任务、小任务、连续触发任务，往往不值得上 compute()。

工程上更实用的判断是：

• compute() 的第一价值是避免主 isolate 卡 UI，不是保证绝对更快。
• 如果任务很小，可能主线程直接做更省。
• 如果任务要长期驻留、多轮协作、持续回传进度，就该升级到 Isolate.spawn。

真实工程例子：拍照后把图像处理搬到后台 isolate

在真实 Flutter 项目里，compute() 很常见的用途不是“教科书里的大 JSON”，而是相机拍照后的图像后处理。例如：

• 从相机流拿到 CameraImage
• 在后台 isolate 中完成 YUV / BGRA 转 JPEG
• 对前置摄像头照片做镜像翻转
• 按目标大小压缩到指定 KB
• 最后把处理结果或保存结果返回主 isolate

这类任务有两个共同点：

• 在主 isolate 上做会明显卡 UI、掉帧、影响拍照交互
• 它们基本都是“一次输入 → 一次输出”的 CPU 密集型处理，非常适合 compute()

真实项目参考（v2 应用中的相机图像链路）：

• washine_v2_app/lib/core/interview/video/ctrl/camera_image_to_jpeg.dart
• washine_v2_app/lib/core/interview/video/ctrl/video_camera_ctrl.dart

关键逻辑可以摘成下面这两段理解：

static Future<Uint8List> convert(
  CameraImage image, {
  required CameraLensDirection cameraLensDirection,
}) async {
  final payload = _serializeCameraImage(
    image, targetWidth, targetHeight, quality, cameraLensDirection,
  );
  final Uint8List jpg = await compute<_CameraImagePayload, Uint8List>(
    _isolateConvert,
    payload,
  );
  return jpg;
}

final result = await compute(_processImageData, {
  'imageBytes': jpegImageBytes,
  'savePath': imageFullPath,
  'maxSizeKB': maxSizeKB,
  'cameraLensDirection': _currentCameraDirection.index,
});

这个例子里，为什么要这么做：

• CameraImage 先序列化：相机插件返回的是运行时图像对象，不能直接把控制器上下文或底层资源对象丢进 compute()；所以先抽成 _CameraImagePayload / Map 这种可发送纯数据。
• 在 compute() 中完成 JPEG 编码 / 前置镜像翻转 / 压缩：这些都是典型 CPU 重活，放主 isolate 会影响拍照流畅度、预览刷新和点击响应。
• 最后返回 Uint8List 或保存结果：如果后续还要继续上传或加工，就回传 Uint8List；如果只是落盘，则可以在后台 isolate 中处理后返回保存状态或目标路径。

为什么这个相机案例现在适合 compute()：

• 它是典型的单次任务：拿一帧图像进来，处理完立刻返回结果。
• 它是典型的值进值出：输入是可发送的纯数据，输出也是字节或保存结果。
• 它虽然重，但还没有复杂到需要长期常驻 worker：当前需求不是“持续后台服务”，而是“某一帧来了就处理一次”。

什么情况下它会进一步升级成 Isolate.spawn + TransferableTypedData：

• 图像帧持续高频进入，需要一个长期驻留的后台 worker，而不是每次都重新调度单次任务。
• 帧数据非常大、传输非常频繁，Uint8List 深拷贝已经成为瓶颈。
• 需要多轮消息通信，例如“主 isolate 发任务 -> worker 回传阶段进度 -> 主 isolate 再下发下一步参数”。

也就是说：

• 当前是“偶发 / 周期性单次处理” → compute() 很合适。
• 未来如果变成“持续高吞吐图像流水线” → 再升级到 Isolate.spawn + TransferableTypedData。

这个案例还顺带说明了一个常见边界：

• 直接传文件路径字符串、Uint8List、普通 Map 参数是合理的。
• 直接传 BuildContext、相机控制器、文件句柄这类运行时对象则不合适。

传文件路径 vs 传大字节数组 vs TransferableTypedData

工程上可以先这样选：

• 传文件路径字符串：最稳妥，适合“后台 isolate 自己读文件 -> 处理 -> 写回文件 / 返回摘要”。当输入已经落盘、结果也准备落盘时，这通常比来回传大对象更省心。
• 传 Uint8List / 大字节数组：适合数据已经在内存里，且是一次性处理后立刻返回结果的场景；但字节越大，跨 isolate 传输成本越高。
• 传 TransferableTypedData：适合超大二进制块（图片帧、视频帧、解码缓冲区）需要跨 isolate 高频移动时，用来减少深拷贝成本；但复杂度更高，一般在普通 compute() + Uint8List 已经成为瓶颈时再上。

一个实用判断：

• 输入输出已经是文件 → 优先考虑“传路径”。
• 数据已经在内存里，且单次处理就结束 → 可以先用 Uint8List。
• 大二进制频繁跨 isolate 流动 → 再考虑 TransferableTypedData。

compute()、Isolate.run、Isolate.spawn 如何分工

方式	更适合什么
compute()	Flutter UI 场景下的单次 CPU 重活
Isolate.run()	纯 Dart 通用的一次性后台计算
Isolate.spawn()	长生命周期 worker、多轮消息通信、持续后台服务

如果你现在的问题是“主 isolate 为什么会卡、事件循环怎么调度”，回看 Dart EventLoop、Microtask Queue 与 Event Queue 机制。如果你要深入长期端口通信和可发送对象限制，继续看 Dart Isolate 消息传递：SendPort / ReceivePort / 可发送对象。

Android / Flutter / Web / Backend 对照

并发维度	Dart Isolate	Java / Android Thread	Go Goroutine
内存模型	Share-Nothing (内存堆隔离)	Shared Memory (共享堆内存)	Shared Memory (通过 Channel 通信)
并发锁需求	不需要加锁	需要锁 (ReentrantLock/Mutex)	需要锁 (sync.Mutex)
多核利用	显式 spawn 创建 Isolate	由系统 OS 调度到不同 CPU 核心	由 M:N 调度器自动调度到多核

常见场景

1. 使用 compute() 在后台 Isolate 解析大 JSON

// 耗时解析顶层函数 (必须是静态函数或顶层函数!)
List<User> parseUsers(String jsonStr) {
  final List<dynamic> parsed = jsonDecode(jsonStr);
  return parsed.map((json) => User.fromJson(json)).toList();
}

// 在 UI 线程调用
Future<List<User>> loadUsersAsync(String jsonStr) async {
  // 将耗时解析搬到独立 Isolate 执行，完后自动切回 UI 线程，不卡顿!
  return await compute(parseUsers, jsonStr);
}

常见误配、事故后果与排障

1. 事故：向 compute() 传递闭包或包含不可序列化对象的实例导致崩溃

• 误配原因：在 compute() 参数中传递了包含 BuildContext、Widget 或类内部方法的闭包。
• 后果：Isolate 之间传递数据时需要进行序列化；传递了不可序列化的对象会抛出 ArgumentError: Cannot send object across isolates。
• 排障与修法：传给 compute() 的函数必须是顶层函数 (Top-Level Function) 或 静态函数 (Static Function)，且入参仅包含基础数据类型、Map、List 或原始 Byte 数组。

对应实验

各章节内已嵌入跳转链接；此处汇总全部 Lab：

Lab	说明
dart-event-loop-isolate	EventLoop / Microtask Queue / Event Queue / Isolate 调度顺序验证

复习检查题

1. 在 Flutter 开发中，为什么在主线程处理 10MB 的 JSON 反序列化会导致界面严重卡顿？应该如何解决？

   答：因为 Flutter 的 UI 渲染和 Dart 代码默认运行在单线程的 Main Isolate 中。解析 10MB 的 JSON 属于 CPU 密集型计算，会在主线程独占 EventLoop 数百毫秒，导致这期间的 UI 刷新脉冲无法被响应引发严重卡顿。解决办法是使用 compute() 或 Isolate.spawn() 将解析逻辑丢到后台独立的 Isolate 中并行计算。

2. Dart 的 Isolate 之间是如何进行数据传递的？为什么天然没有死锁问题？

   答：Dart Isolate 之间采用“无共享内存 (Share-Nothing)”架构，每个 Isolate 拥有完全独立的堆内存。Isolate 之间只能通过 SendPort / ReceivePort 端口进行消息传递（默认进行深拷贝）。由于没有共享的内存变量，因此从根源上消除了多线程竞态条件与锁竞争，天然不存在死锁问题。

速记

• 核心模型：Isolate 堆内存完全隔离，天然无锁无死锁。
• UI 保流畅：耗时 JSON 解析/大图像处理统一用 compute() 移走。
• 传入限制：传给 compute 的必须是顶层/静态函数，参数须可序列化。