文章 · Flutter Isolate 并发实战

当 Flutter 应用出现卡顿，很多人会说“放到 Isolate 里跑”。但 Isolate 不是万能解药，它是一个需要工程化设计的并发模型。本篇帮你把 Isolate 从“概念”变成“可落地的并发策略”。

1. Isolate 是什么：它和线程的差别

Isolate 是 Dart 的并发单元。和传统线程不同：

内存不共享：每个 Isolate 都有独立堆
通信靠消息：必须通过消息传递
避免竞态：减少锁与共享资源问题

这意味着：CPU 密集任务适合放 Isolate，但共享状态/频繁通信的任务需要谨慎。

2. 适合放 Isolate 的任务类型

图片压缩/滤镜处理
JSON/大文件解析
加解密、签名计算
大量数据聚合

示例：用 compute 处理大 JSON 解析

import 'dart:convert';
import 'package:flutter/foundation.dart';

List<Map<String, dynamic>> parseLargeJson(String raw) {
  final list = jsonDecode(raw) as List<dynamic>;
  return list.cast<Map<String, dynamic>>();
}

Future<List<Map<String, dynamic>>> parseInIsolate(String raw) {
  return compute(parseLargeJson, raw);
}

不适合的场景：

UI 相关逻辑
频繁访问共享状态
需要高频 UI 反馈的小任务

3. 并发架构设计：任务分流与结果回收

推荐实践是“任务队列 + Worker 池”：

主 Isolate 收集任务
分配到 Worker Isolate
Worker 返回结果
主 Isolate 更新 UI

这样可以避免频繁创建 Isolate 的开销。

示例：简化的 Worker 任务派发结构

class TaskMessage {
  TaskMessage(this.id, this.payload);
  final int id;
  final Map<String, dynamic> payload;
}

class TaskResult {
  TaskResult(this.id, this.output);
  final int id;
  final Object output;
}

4. 通信模型：消息结构要设计

消息传递不是随便丢个对象。需要明确：

任务类型（type）
参数（payload）
任务 id（用于回收）

建议统一成结构化消息，方便追踪和监控。

示例：统一的消息协议（type + payload + taskId）

Map<String, dynamic> buildMessage({
  required String type,
  required int taskId,
  required Map<String, dynamic> payload,
}) {
  return {
    'type': type,
    'taskId': taskId,
    'payload': payload,
  };
}

5. 性能边界：何时会适得其反

Isolate 也有成本：

启动成本：创建 Isolate 有延迟
拷贝成本：消息是深拷贝
通信开销：高频消息会拖慢主线程

经验原则：

小任务不要丢 Isolate
大任务必须丢
多个小任务合并成一个批次

6. 实战建议：可直接套用的策略

重计算任务合并批次
高并发任务用 Worker Pool
统一消息协议，便于监控
对大对象使用 TransferableTypedData

7. 结语：Isolate 不是魔法，是工程

正确使用 Isolate 的前提是你能准确识别“CPU 瓶颈”与“通信瓶颈”。
把它当成工程化工具，你的 Flutter 应用会更稳、更快、更可控。