这是你这段经历的整理优化版博客文章，逻辑更清晰、语言更流畅，适合发布在技术社区或个人博客：

如何优化 Flutter 子进程 stdout 输出导致的卡顿问题

在使用 command_manager 管理命令行子进程时，我遇到了一个难以复现但影响体验的问题 —— 应用偶发性卡顿。本文记录了我分析、定位并优化这个问题的过程，希望对你也有帮助。

❓ 问题现象

当我通过 command_manager 启动某些输出频繁的命令（如编译脚本、批量打印等）时，Flutter 应用 UI 会发生卡顿甚至无响应现象。

起初我怀疑是子进程执行本身太猛，CPU 跑满，导致主线程无法响应。后来经过和 GPT 交流，我意识到更可能是：

子进程通过 stdout 输出大量数据，主线程监听后频繁触发 notifyListeners()，引起 UI 过度 rebuild，最终导致卡顿。

这就把问题从「CPU 过载」重新定位到了「UI 重建过频」上。

🧪 如何复现

因为问题是偶发的，我写了一个命令用于模拟高强度输出：

1

1..10000 | ForEach-Object { Write-Output "Line $_" }

这能在极短时间内输出 1 万行数据，完美复现 Flutter UI 卡顿。

⚠️ 原始代码存在的问题

1
2
3
4

listen((line) {
  rc.output.write(line);
  notifyListeners();
});

问题有两个：

1. notifyListeners() 每行触发一次，极度频繁；
2. UI 渲染使用了 rc.output.toString() 全量拼接字符串，并 .replaceAll(RegExp(...)) 做 ANSI 转义清洗，数据一大，运算量极其庞大：

1
2
3
4
5

Text(
  rc.output
      .toString()
      .replaceAll(RegExp(r'\x1B\[[0-9;]*[a-zA-Z]'), ''),
)

✅ 优化方案

🧱 1. 使用 List<String> 替代 StringBuffer

改用 rc.lines 存储每行：

1
2
3
4
5
6

listen((line) {
  rc.lines.add('$line');
  if (rc.lines.length <= 5) {
    notifyListeners();
  }
});

这样只在前 5 行触发 UI 更新，显著减少 rebuild 次数。

✂️ 2. 限制 UI 中的数据处理量

原本 UI 渲染时拼接了所有 stdout 内容，非常危险：

1

rc.output.toString().replaceAll(...)

优化后只取前 5 行，并在映射前清理 ANSI 转义字符：

1
2
3
4
5

rc.lines
  .take(5)
  .map((line) =>
    line.replaceAll(RegExp(r'\x1B\[[0-9;]*[a-zA-Z]'), ''))
  .join('');

这样即使子进程输出再多，UI 也只处理一小部分字符串，运算量骤降。

🚀 效果总结

优化后：

• 子进程可以高频输出不影响 UI；
• stdout 数据仍然完整保存；
• UI 渲染流畅，不卡顿；
• 控制台输出清晰，处理逻辑更易维护。

🧠 小结

通过这次问题排查我意识到：

• 不是所有性能问题都来自“后台”或“CPU”，UI rebuild 本身就是非常重的操作；
• 当监听大量数据时，适当做 debounce、节流或分批处理很重要；
• 对于控制台类 UI，“只显示可视区域 + 懒加载” 是更合理的方式；
• 正则操作 .replaceAll() 在大文本上是非常昂贵的，不要对全量数据反复处理。

你是否也遇到过类似子进程或大量输出导致的 Flutter 卡顿问题？欢迎交流 👇

需要我为你生成 markdown、掘金、CSDN、知乎等平台的格式版本也可以。是否加个图或动画演示更直观？