Flutter中Wrap组件渲染3000/5000条数据时UI加载耗时过长求助

问题根源 #

Wrap组件会一次性构建并渲染所有子Widget，当数据量达到3000+时，大量Widget实例的创建、布局和绘制会占用大量UI线程资源，导致加载耗时过长。

解决方案 #

方案1：用GridView.countBuilder模拟Wrap（子项宽度固定时首选）

如果你的子项宽度固定，可利用GridView.countBuilder的懒加载特性，实现类似Wrap的流式布局，仅渲染可见区域内的子项：

LayoutBuilder(
  builder: (context, constraints) {
    // 子项固定宽度
    const itemWidth = 100.0;
    // 计算每行可容纳的子项数量
    final crossAxisCount = (constraints.maxWidth / itemWidth).floor();
    
    return GridView.countBuilder(
      padding: const EdgeInsets.symmetric(horizontal: 8),
      crossAxisCount: crossAxisCount,
      itemCount: _items.length,
      // 懒加载构建子项
      itemBuilder: (context, index) => Text('Item ${_items[index]}'),
      mainAxisSpacing: 8.0,
      crossAxisSpacing: 8.0,
    );
  },
)

方案2：分批次渲染子项（快速实现，适合任意子项尺寸）

通过分批次加载并构建子Widget，避免一次性创建所有实例，降低初始渲染压力：

List<Widget> _visibleItems = [];
int _loadedBatch = 200; // 每次加载的数量

@override
void initState() {
  super.initState();
  // 初始化加载第一批次
  _visibleItems = _items.take(_loadedBatch).map((i) => Text('Item $i')).toList();
  // 后台分批加载剩余内容
  _loadMore();
}

void _loadMore() {
  if (_visibleItems.length >= _items.length) return;
  final nextBatchEnd = min(_visibleItems.length + _loadedBatch, _items.length);
  final newItems = _items
      .sublist(_visibleItems.length, nextBatchEnd)
      .map((i) => Text('Item $i'))
      .toList();
  
  setState(() => _visibleItems.addAll(newItems));
  // 延迟加载下一批，避免阻塞UI
  Future.delayed(const Duration(milliseconds: 100), _loadMore);
}

// 使用Wrap渲染已加载的子项
Wrap(
  alignment: WrapAlignment.spaceBetween,
  children: [
    ..._visibleItems,
    const Spacer(),
    const Spacer(),
  ],
)

方案3：自定义懒加载Wrap（复杂但效果最优）

如果需要完全保留Wrap的灵活布局特性（子项宽度不固定），可自定义一个支持懒加载的Wrap组件：

1. 使用SingleChildScrollView作为滚动容器
2. 结合ScrollController监听滚动位置
3. 通过自定义RenderBox或CustomMultiChildLayout记录子项的布局信息
4. 仅构建可见区域及前后缓冲范围内的子项

这个方案需要对Flutter的渲染机制有一定了解，核心是通过计算视口范围筛选出需要渲染的子项，避免不必要的Widget构建。

内容的提问来源于stack exchange，提问作者tkn