xmlns="http://www.w3.org/2000/svg"

style="display:

size="3">子玥酱

color="black"

/>

大家好，我是

face="仿宋"

size="5">子玥酱，一名长期深耕在一线的前端程序媛

👩‍💻。

曾就职于多家知名互联网大厂，目前在某国企负责前端软件研发相关工作，主要聚焦于业务型系统的工程化建设与长期维护。

我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括

face="courier

RN、Flutter、跨端方案，

/>在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。

color="black"

/>内容平台：掘金、知乎、CSDN、简书

color="black"

/>创作特点：实战导向、源码拆解、少空谈多落地

color="black"

/>文章状态：长期稳定更新，大量原创输出

我的内容主要围绕前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读展开。

文章不会停留在“API

怎么用”，而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍，希望能帮你在实际工作中少走弯路。

子玥酱

前端成长记录官

关注我，第一时间获取前端行业趋势与实践总结

/>🎁

一起把技术学“明白”，也用“到位”

持续写作，持续进阶。

🌱

引言

只要你做过一段时间

Flutter，大概率都遇到过同一个瞬间：

列表一开始很顺，数据一多，突然就开始掉帧。

很多人的第一反应是：

是不是

ListView

性能不行？

于是开始：

• 换成

  GridView

• 最后上

  Sliver

结果发现——还是会卡。

这说明一个事实：列表卡顿，往往不是控件的问题，而是渲染链路的问题。

列表真正的渲染流程，比想象中更长

从表面看，列表只是“滚动

+

里，一次滚动背后至少包含四步：

1. 构建

   Widget

2. 生成

   绘制

只要其中任意一步变重，帧率就会掉。

很多卡顿并不是发生在“绘制”，而是发生在更前面的build

layout

阶段。

这也是为什么：

明明

CPU

解决的只是一个问题：

避免一次性创建所有

item。

但它解决不了这些更核心的性能点：

• item

  build

  rebuild

• 图片解码阻塞主线程
• 状态变化触发整列表刷新

举个典型反例：

ListView.builder(itemCount:list.length,itemBuilder:(_,i){returnHeavyItem(data:list[i]);},)

如果HeavyItem内部：

• 包含复杂布局
• 多层嵌套

  build

  都做计算

那再懒加载也没用，因为问题出在单个

item

频繁，才是真正的性能杀手

很多列表掉帧的根因，其实是：

滚动过程中

item

被不断重建。

常见触发场景：

• setState

  Key，导致元素复用失败

例如：

setState((){list=newList;});

如果整个

ListView

rebuild。

正确思路应该是：只更新变化的那一小部分。

这也是为什么Key

diff

思想在列表中非常关键。

itemKey

的真正作用，不只是“避免错乱”

很多人只在重排序时才想起

Key，但在性能层面，它还有一个重要价值：

帮助框架复用已有

Element，减少重建。

ListView.builder(itemBuilder:(_,i){returnItemWidget(key:ValueKey(list[i].id),data:list[i],);},)

有了稳定

能判断

是否同一个

不需要销毁再重建

layout

paint

成本都会下降

这一步看似细节，但在长列表中影响非常明显。

缓存策略：AutomaticKeepAlive

不是越多越好

另一个常被忽略的点是缓存。

很多人一遇到滚动重建，就直接：

AutomaticKeepAliveClientMixin

让所有

item

常驻内存。

短列表没问题，但长列表会带来两个副作用：

• 内存持续上涨
• layout

  计算压力变大

正确方式应该是：

• 只对有状态的复杂

  item

  允许回收

缓存从来不是越多越好，而是在重建成本和内存之间找平衡。

图片加载，往往才是掉帧元凶

真实项目里，列表卡顿最常见的原因其实不是布局，而是图片解码。

尤其是：

• 大图未压缩
• 首帧同步解码
• 没有占位图

滚动时如果触发多张图片同时解码，主线程很容易被阻塞，直接掉帧。

优化思路通常包括：

• 使用合适尺寸的缩略图
• 提前缓存
• 添加轻量占位，避免布局抖动

很多时候：

把图片体积减半，比任何代码优化都更有效。

Sliver

也不是“性能开关”

不少文章会给人一种感觉：换

Sliver

的核心价值是：

• 更灵活的滚动组合
• 更精细的可视区域控制

而不是自动性能提升。

如果：

• item

  依然很重

• rebuild

  依然频繁

• 图片依然阻塞

那用不用

Sliver，结果几乎一样。

真正决定性能的，从来不是容器，而是内容。

那些最容易被忽视的隐藏细节

在真实项目中，真正影响列表性能的，往往是一些不起眼的小地方：

布局层级过深，多一层嵌套，就多一次

layout

Clip，这些都会触发额外的合成开销。

在

build

里做计算，例如格式化时间、复杂字符串处理，都会直接拉长帧时间。

这些问题单看都不大，但叠加在一起，就会变成明显卡顿。

总结

列表性能问题，很少是某一个控件造成的。

更多时候，是一整条链路共同作用的结果：

• build

  是否足够轻

• 状态范围是否合理
• 图片是否被正确处理
• 缓存策略是否克制

当把这些点逐个理顺之后，你会发现：

真正让列表变流畅的，从来不是某个“高级组件”，

而是一整套细节习惯。

而这，也正是移动端性能优化最真实的样子。