Flutter 鸿蒙性能优化实战：用 Isolate.run 把大 JSON 解析移出 UI 线程

网络请求本身是异步的，但 JSON 解析和数据转换可能是 CPU 密集工作。如果把几十 MB 的响应直接在 UI isolate 中 jsonDecode，请求已经返回，页面仍然会短暂冻结。本文项目生成约 30000 条记录，提供主线程解析和 Isolate.run 解析两个按钮。

项目地址：flutter_ohos_isolate_demo。核心对比代码会在固定输入和测量口径明确后展开。

一、实测环境和测量方式

项目	实测版本或条件
Flutter OH	3.44.9+ohos-0.0.1-canary1
Dart	3.12.2
DevEco Studio	26.0.0 Release
HarmonyOS	7.0.0.105 (API 26)
构建模式	profile
数据量	约 30000 条记录，固定 JSON 约 678 KB

本文把网络下载排除在实验之外，只比较同一份输入在 UI isolate 和后台 isolate 中的 CPU 工作。

final value = inIsolate
    ? await Isolate.run<Object>(() => jsonDecode(payload))
    : jsonDecode(payload);

我用 Stopwatch 记录解析耗时，并输出 ISOLATE_BENCHMARK。这里有两个重点：第一，Isolate 的启动、序列化和结果传递也有成本；第二，单次毫秒数不能代表用户体验，必须同时观察解析时能否滚动、点击和绘制下一帧。小 JSON 可能放在主线程更简单，大 JSON 或复杂转换才值得拆分。

Isolate 不能直接访问 Flutter 插件、窗口、BuildContext 或平台对象。正确做法是把输入变成可传递的数据，把纯计算函数放在 isolate 中，回到 UI isolate 后再更新状态。不要把一个包含控制器和上下文的闭包直接塞进去，也不要在 isolate 中调用 setState。

鸿蒙真机验证时，我会准备固定 JSON、同一设备、同一 profile 构建，连续采样至少 5 次，报告中位数和 P95。除了解析耗时，还要记录动画期间慢帧数和首帧恢复时间。若数据来自网络，网络下载耗时应单独列出，不能把网络和解析混成一个数字。

仓库已经通过 flutter analyze、Widget 测试和 HAP 无签名构建。README 说明了 Isolate 的边界。本文配图用于确认两个按钮、解析中的状态和最终结果；HiLog benchmark 与 profile 时间线仍应通过复现命令单独采集。

二、先看容易出问题的解析写法

1. 网络异步不等于解析离开 UI isolate

网络请求返回只代表数据已经到达，并不代表后续工作已经离开 UI isolate。jsonDecode、字段转换、排序和模型组装仍然会占用执行它们的 isolate。如果一次解析 30000 条记录，用户感受到的卡顿可能发生在请求完成之后：按钮点不动，动画停一下，下一帧迟迟出不来。

这个 Demo 把输入固定成约 678 KB 的 JSON，分别走主线程和 Isolate.run。固定输入的好处是每次比较的工作量一致，也不会把网络延迟混进解析耗时。页面用 Stopwatch 展示结果，并输出 ISOLATE_BENCHMARK，但我不会只拿一个毫秒数宣布“Isolate 一定更快”。Isolate 启动、数据传递和结果回传本身也有成本。

2. 先用真机截图确认任务状态

初始页面显示固定 JSON 的大小和“等待解析”，两个解析按钮都使用同一份输入。截图只能确认测试入口和页面状态，不代表某一次解析耗时就是稳定基线。

点击 Isolate 解析后，页面会进入等待或完成状态。下面两张图分别保留了任务进行中的状态和最终结果，用于说明用户可见反馈与解析结果之间的关系。

3. Isolate 的边界

传入 isolate 的闭包应当只依赖可传递的数据和纯计算逻辑。它不能直接访问 BuildContext、Widget、插件实例、窗口对象或页面 State，也不能在后台 isolate 中调用 setState。本项目把 JSON 字符串作为输入，解析完成后回到 UI isolate 更新 _result，这就是比较安全的边界。

数据量很小时，主线程解析更简单，强行拆 isolate 反而增加复杂度；数据量较大或转换逻辑明显占 CPU 时，才值得进一步验证。若解析期间还需要展示进度，可以把任务拆成多个批次或设计可取消的工作，但不要为了展示进度而频繁跨 isolate 传递大量对象。

4. 不只测解析时间

正式验证至少要记录四项：主线程和 Isolate 的解析耗时、解析期间是否能滚动或点击、任务结束后首帧恢复时间、进程内存变化。网络下载、解压、JSON 解析和数据库写入要分别计时，不能把所有时间归到 Isolate 身上。

三、换成可比较的 Isolate 实现

1. 对照代码要尽量接近真实业务

只把 jsonDecode 放到 isolate 里，容易低估真实成本。业务代码通常还会遍历 Map、转换日期、补默认值，再组装成模型。更有代表性的写法是把这些纯计算一起放入函数：

List<Task> parseTasks(String payload) {
  final raw = jsonDecode(payload) as List<Object?>;
  return raw
      .cast<Map<String, Object?>>()
      .map(Task.fromJson)
      .toList(growable: false);
}

final tasks = await Isolate.run(() => parseTasks(payload));

Task.fromJson 不能引用页面 State、插件实例或 BuildContext。如果解析函数依赖了不可传输的对象，代码可能无法发送到 isolate，或者为了绕开限制而引入更复杂的全局状态，最后反而难以维护。把函数做成纯函数，也是后续单元测试和基准测试的基础。

2. 跨 isolate 的数据边界

发送一个很大的字符串和回传一大批模型都需要复制或序列化成本。数据量小时，主线程解析可能更快；数据量大时，isolate 带来的价值主要是让 UI isolate 在计算期间继续响应。若模型包含二进制内容，不要直接把大块 Uint8List 在多个 isolate 之间来回传递，应评估分块、文件映射或平台侧解析方案。

建议在日志里拆开记录：下载耗时、解压耗时、解析耗时、模型转换耗时、回传耗时，以及任务期间收到的帧数。这样出现“用了 isolate 但总耗时更长”时，能判断是启动和传输成本，还是纯计算本身没有达到拆分阈值。

3. 可取消和错误状态

页面离开后，解析结果回来不能继续更新旧 State。请求和解析都应绑定页面生命周期，至少在回调前检查 mounted，并为失败、超时和取消提供状态。性能方案如果只考虑成功路径，用户在弱网或频繁切换页面时仍会遇到无效计算和错误提示覆盖。

四、主线程和 Isolate 的公平对照

1. 两个分支必须执行同一份工作

对照实验不能让主线程只做 jsonDecode，而 isolate 分支却同时完成字段转换；也不能让其中一组复用上一次解析结果。两组都应该从同一个固定字符串开始，执行相同的 Task.fromJson、排序和列表长度校验，再把最终模型交给页面。每轮测试前清空页面结果，避免缓存和旧对象影响内存。

如果页面在解析期间仍然有动画，动画控制器和滚动列表也要保持相同。可以在解析开始前重置 FrameTiming 收集器，在任务完成后记录收到的帧数、慢帧数和恢复到稳定帧的时间。这样才能判断 isolate 的价值是“总耗时更短”，还是“计算期间 UI 仍然可响应”。

2. Isolate 的启动成本

Isolate.run 不是免费的线程池。它需要创建或唤醒 isolate、发送输入、执行函数并传回结果。应用中如果只是解析几 KB 的配置，主线程执行更简单；如果每次请求都创建 isolate，也可能把启动开销放大。对于连续的大任务，可以考虑复用长期 isolate 或在架构层批量处理，但要额外管理退出、错误和背压。

3. 数据传输和内存峰值

解析过程中可能同时存在原始 JSON、解码后的 List、模型对象和页面列表，峰值内存不一定比主线程更低。文章中的 PSS 和 Dart Heap 需要注明采样时机：请求刚返回、解析进行中、任务完成后，三者的意义不同。若发现 isolate 模式交互更顺但内存峰值更高，应从批量解析、字段裁剪和模型生命周期继续优化。

五、异常、测试与生命周期

1. 解析函数的可测试性

把 parseTasks 做成不依赖 Widget 的纯函数后，可以在不启动 Flutter 引擎的情况下测试空数组、缺字段、错误类型、重复 id 和超大列表。纯函数还方便在主线程和 isolate 中复用，减少“两个分支实现不同”的风险。测试应验证模型数量、关键字段和排序结果，而不是只验证页面上出现了一行“完成”。

2. 错误、取消和重试

解析失败时，页面应保留上一次可用数据或显示明确的错误状态，不能让异常直接穿透到按钮回调。用户连续点击开始按钮时，要么禁用按钮，要么取消前一次任务；否则多个 isolate 会同时解析同一份 payload，最终结果的先后顺序也不可预测。页面退出后，回调必须检查 mounted，并忽略已经失效的任务结果。

3. 复现结论的写法

建议用“在固定输入和设备上，Isolate 模式让解析期间保持了多少帧响应，代价是增加了多少启动和传输时间”来下结论，而不是简单写成“Isolate 更快”。这类表述既保留实测价值，也不会把一个数据量和一个设备的结果扩大成框架级承诺。

六、复现命令和测试范围

flutter pub get
flutter analyze
flutter test
flutter build hap --debug --no-codesign
flutter run --profile -d <ohos-device-id>

进入页面后分别点击“主线程解析”和“Isolate 解析”，每种模式重复多次，记录页面结果、HiLog 的 ISOLATE_BENCHMARK 和 DevTools 时间线。截图中的“等待解析”是任务进行中的真实状态，不等于最终耗时结论。

七、这次实验的实际结论

在固定 JSON、固定设备和相同操作序列下，Isolate 的主要价值是把 CPU 解析从 UI isolate 移开，让页面在计算期间有机会继续响应；它不保证总耗时一定更短，也不保证内存峰值更低。小数据量需要把 isolate 启动、参数传递和结果回传成本一起算进去。

当前 Demo 通过页面状态和 ISOLATE_BENCHMARK 提供复现入口，但文章没有把单次截图或单次毫秒数扩大成框架级结论。正式上线前应至少重复多轮，分别保存解析耗时、UI/Raster 时间线、慢帧和 PSS。

欢迎加入CPF-Flutter 鸿蒙社区：https://atomgit.com/CPF-Flutter