Flutter中如何不阻塞UI更新TextView 解决长文本渲染卡顿问题

你遇到的UI冻结和setState调用本身没有关系，核心原因是Text组件渲染超长文本时，文本断行、字形测量、行高计算、渲染节点构建的全流程默认运行在主UI Isolate上，2000行文本的计算量会直接占满UI线程的时间片，阻塞帧绘制、手势响应等核心任务，最终出现10秒以上的冻屏。哪怕你不通过setState更新，直接把全量文本硬编码到Text组件初始化参数中，首帧渲染一样会卡顿。

• 方案1：分块懒加载（最通用，性能提升最明显）
  不要一次性把全量文本塞给单个Text组件，先把长文本按固定行数（单块30-50行，保证单块布局耗时在单帧预算内）拆分为多个文本块，用ListView.builder/SliverList做懒加载承载，仅对可视区域内的文本块做布局计算，可视区域外的文本会被自动回收，不会占用主线程计算资源。
  注意：文本拆分属于CPU密集型操作，必须丢到后台Isolate执行，不要在UI线程同步处理：

  // 顶层函数，供compute调用
  List<String> _splitTextByChunk(String fullText) {
    const chunkLineCount = 50;
    final allLines = fullText.split('\n');
    final List<String> chunks = [];
    for (int i = 0; i < allLines.length; i += chunkLineCount) {
      final endPos = i + chunkLineCount > allLines.length ? allLines.length : i + chunkLineCount;
      chunks.add(allLines.sublist(i, endPos).join('\n'));
    }
    return chunks;
  }
  
  List<String> _textChunks = [];
  bool _isLoading = false;
  
  // 加载文本逻辑
  Future<void> loadLongText(String fullText) async {
    setState(() => _isLoading = true);
    // 后台Isolate执行拆分，不阻塞UI
    _textChunks = await compute(_splitTextByChunk, fullText);
    setState(() => _isLoading = false);
  }
  
  // 渲染部分
  @override
  Widget build(BuildContext context) {
    if (_isLoading) return const Center(child: CircularProgressIndicator());
    return ListView.builder(
      itemCount: _textChunks.length,
      padding: const EdgeInsets.all(16),
      itemBuilder: (context, index) => Text(
        _textChunks[index],
        style: const TextStyle(fontSize: 16, height: 1.4),
      ),
    );
  }
  

• 方案2：渐进式追加渲染（适配需要连续阅读体验、不能出现列表分割感的场景）
  首帧仅渲染前1-2屏可见的文本内容（约100行以内），首帧绘制完成后通过WidgetsBinding.instance.addPostFrameCallback监听帧结束回调，在后续每一个空闲帧里逐块追加剩余文本，每次追加的文本量控制在布局耗时<10ms，保证不阻塞正常交互，直到全量文本渲染完成。
• 方案3：后台预排版（适配必须一次性全量展示文本的场景）
  如果业务要求不能分块渲染，就把文本排版逻辑迁移到后台Isolate：把文本内容、样式参数、布局宽度约束传到后台Isolate，通过ParagraphBuilder提前完成全量文本的排版计算，生成可直接绘制的Paragraph对象后回传给UI线程，交给RichText直接渲染，跳过UI线程的测量排版步骤。注意：Isolate之间不能直接传递UI组件实例，仅传递排版需要的基础参数和最终的绘制对象。
• 额外避坑项
  • 给长文本做样式时，不要加阴影、模糊、透明度过渡这类重绘开销极高的效果，外层不要套Opacity、Transform这类会触发离屏渲染的组件，否则渲染耗时会成倍增加。
  • 如果需要支持文本选中，优先用SelectionArea包裹分块后的文本列表，不要直接用单个SelectableText加载全量文本，后者的选中计算逻辑在长文本场景下开销远高于普通Text。

所有和文本相关的正则替换、格式处理、内容拆分、样式匹配等CPU密集型操作，一律放到后台Isolate执行，UI线程只保留最终的轻量渲染逻辑，从根源上避免阻塞。

内容的提问来源于stack exchange，提问作者Code Learner.