开了个新坑聊 Flutter 大列表性能优化。这几年做移动端开发面试过不少人也给团队做过性能专项我发现一个很有意思的现象很多人简历上写着“精通 Flutter”一问到列表性能优化就支支吾吾。为什么偏偏是列表因为列表是 Flutter 应用里最常见的场景同时也是最容易暴露问题的场景。90% 的 App首页不是商品列表就是动态列表一屏能装下的数据有限但滚起来之后帧率掉到多少直接决定了用户在手机上对你的体感。这篇文章不讲花架子从真实业务场景出发把大列表优化的关键节点一个一个拆开顺带讲讲为什么这块能拉开工程师层级。大列表性能优化说起来很简单就是让 60 帧不丢让用户滚起来跟手。但实际做起来牵扯到数据层、Widget 构建层、绘制层、状态管理层甚至还有框架源码层面的理解。你看到的一些现成优化方案比如加个itemExtent、加个RepaintBoundary很多人都会用但为什么要这么用、什么时候不能用、用错了代价是什么就不是所有人都说得清了。这篇文章会把这些“为什么”掰开揉碎讲明白。1. 大列表优化的本质不是渲染慢是“白做”的活儿太多1.1 卡顿的根源每帧只有 16.66ms 的生死线先说为什么要先聊这个。我发现太多人拿着 Flutter 在列表性能优化上折腾半天方向全是错的。做 Flutter 开发你应该早就听说过 vsync、垂直同步、刷新率这些东西。手机屏幕一秒刷新 60 次每帧留给 CPU 和 GPU 的时间大约是 16.66ms。现代中高端手机大多支持 90Hz、120Hz 甚至更高的刷新率留给一帧的时间更短比如 120Hz 屏幕每帧只有 8.3ms。换句话说如果你一帧的布局、绘制、合成工作超过了这些时间预算就会掉帧——屏幕上就会出现卡顿、跳帧、滑动不跟手的现象。大列表为什么最容易卡因为列表的滚动会导致大量 item 持续重建、重新布局、重新绘制。每一帧都要做这些事任何一个环节超时就相当于送给用户一次肉眼可见的卡顿。想优化大列表我得先知道到底是谁在超时。Flutter 的 DevTools 和 Performance Overlay 是可以看到每一帧的 build/layout/paint 时间的。我自己定位问题习惯先看这三项耗时而不是一上来就猜。1.2 ListView.builder 和 ListView(children: []) 是天壤之别我见过不少刚上手的团队直接把所有数据塞进ListView(children: [...])几十上百个 item 一次性全部构建出来。这种写法只适合静态的、数量很少的界面。不要把滚动列表写成固定 children 列表这是最基础的一条铁律。ListView.builder背后是 SliverList SliverChildBuilderDelegate它的核心逻辑是懒加载——只构建那些真正进入视口区域的 itemviewport 外加cacheExtent区域。滚出屏幕的 item 会被销毁或者说被回收内存和构建工作量被限制在一个很小的范围内。这就是一个典型的“做与不做的区别”。我之前见过一个实际案例一个简单信息流页面数据量并不多只有三四十条但每条里面都有一张大图。结果列表从底部往上滑的时候掉帧掉到 20 帧左右。查了半天发现是历史代码用ListView包了Column加循环一次性把全部 item 以及全部图片都构建出来了。改成ListView.builder之后CPU 占用直接降了一半帧率恢复到 55 帧以上。所以这是第一步也是成本最低的一步。1.3 把大列表优化拆成四层按层排查我自己的方法论是把优化工作拆成四个层级数据层数据是否一次性全部加载、是否需要分页、JSON 解析是否放在 UI 线程Widget 构建层build 是否过于频繁、子树是否被不必要地重建、item 内部是否用 const绘制层是否需要 RepaintBoundary、图片是否过大、是否有不必要的透明度和阴影滚动交互层滚动监听、惯性动画是否影响了性能在实际业务里卡顿往往是几层问题叠加的不拆开根本定位不到。高效工程师和普通工程师的区别就在这里普通工程师看到一个“优化大列表”的需求第一反应是找个插件或者加点cacheExtent高层级工程师先看数据流再查性能指标最后才动手改代码。顺序反了白干一场的概率很高。2. Widget 构建层把 item 的 build 成本压到最低2.1 固定高度就用 itemExtent效果立竿见影在很多真实业务里列表 item 高度大多是不固定的比如文本长度变化、图片比例不同。如果高度不固定Flutter 在滚动过程中就需要不断测量每一个 item 的高度这项工作只能在 UI 线程做开销不小。如果你的 item 高度固定或者能够用一个大致估算值代替就可以设置itemExtent。这是最经典、效果最明显的一招。设置itemExtent之后SliverList 不再需要逐个测量 item 的高度它会提前知道所有 item 的位置滚动时的布局工作量大幅降低。实测在某些业务场景里设置了itemExtent后滚动帧率可以从 40 帧左右回升到接近满帧。如果高度实在不固定但差异不大可以用prototypeItem传一个代表性 item让 Flutter 用它来估算高度虽然不是精确的但能省去每次测量的大部分成本。ListView.builder( itemExtent: 88.0, // 固定 item 高度示例 itemBuilder: (context, index) { return MyListItem(...); }, )注意一点itemExtent是硬约束如果实际内容高度超过了设定的值内容会被裁剪或者出现布局溢出报错。所以用之前先跟设计确认绝大部分列表项高度是可以做规整的。如果实在做不到再用prototypeItem这种软估算方案。2.2 cacheExtent 不是越大越好别被带偏了cacheExtent是视口外预加载区域的长度默认值是 250 逻辑像素。很多优化文章说“把 cacheExtent 调大可以提升滚动顺畅度”这句话只对了一半。cacheExtent调大确实让滚动方向上的预构建范围更大item 更容易提前准备好但代价是更多的 item 会被同时构建。如果 item 的 build 成本很高过大的cacheExtent反而会让启动变慢内存占用变高滚动时帧率下降。正确做法是在 item 构建足够轻的前提下按需微调cacheExtent。如果 item 比较重比如每个都包含图片、富文本我一般会保持默认值甚至调小到 100 左右配合前面的itemExtent让滚动更稳定。这里有一个很容易被忽略的点cacheExtent的单位是逻辑像素不是 item 数量。也就是说如果 item 高度是 300默认cacheExtent连一个 item 都覆盖不到。这种情况下适当调大是合理的比如cacheExtent: 600可以预留两个 item。提示调cacheExtent之前先用 Profile 模式测一下你当前滚动区域到底有多少 item 被构建。用什么看DevTools 里的 widget inspector 可以显示当前视口内构建的组件数量和范围。一切以数据为准不要凭感觉调参。2.3 const 构造的力量被严重低估在 build 方法里写一个非 const 的 Widget意味着每次父 Widget 重建时这个子 Widget 也会参与重建。如果这个子 Widget 在页面构建中占大头性能浪费非常可观。override Widget build(BuildContext context) { return Scaffold( body: ListView.builder( itemBuilder: (context, index) const MyListItem(), ), ); }const MyListItem()意味着这是一个编译期常量Flutter 在构建时可以跳过对它的重建。很多人感受不到这层区别是因为在小列表里差距确实不明显。但在大列表场景下如果单个 item 里有一大堆 Container、Text、Icon 等组件const 能直接砍掉一批没有必要的 Widget 重建。其实从 Flutter 性能优化的角度来看const 应该是一种习惯而不是一种优化技巧。这里有个常见误区const 只能优化到构造参数全部不变的情况。如果你的 item 里有 index 或者业务数据在变那 const 是不能用的。这时候需要用 const 包裹 item 内部不变的子组件比如 item 的封面图标、边框装饰、固定的副标题文本。把稳定和动态的部分拆开动态部分越少越好。3. 绘制层优化图片、裁剪与 RepaintBoundary 的边界感3.1 RepaintBoundary 只有在特定场景才值得用RepaintBoundary 是一个渲染层的隔离边界。它会把子树内部的重绘限制在边界内不会触发父级重新绘制。听起来很香但对列表性能来说必须理性使用。如果每个 item 都包一个 RepaintBoundary会创建大量 RenderObject反而增加内存和合成成本。通常我给带图片、视频、自定义动画的复杂 item 加一层 RepaintBoundary让一个 item 的重绘不会污染其他 item。特别是 item 里有进度条、播放动画之类的持续变化场景RepaintBoundary 能阻止脏区域扩散到整个列表。但如果你的 item 本身就是简单文本包 RepaintBoundary 反而会拖慢速度。实际操作经验是只对包含网络图片或者有自定义绘制的 item 加边界并且一层就够不要层层嵌套。这里还有个进阶玩法如果列表项里有动画区域应该把动画区域单独用 RepaintBoundary 包起来而不是包整个 item。这样动画重绘的时候item 的其他静态部分完全不受影响。Widget build(BuildContext context) { return RepaintBoundary( child: Column( children: [ _staticInfo(), // 不参加重绘的区域 RepaintBoundary( child: _animatedProgress(), // 动画区域 ), ], ), ); }3.2 图片优化一张图能让列表卡成 PPT网络图片是最容易忽略的性能炸弹。宽 2000px 的图片直接塞进宽 300 的列表项GPU 要做大量纹理上传和缩放运算。Flutter 的Image.network默认并不会做解码缩放这一点太容易踩坑了。如果你的列表里有大量的网络图片一定要设置cacheWidth或cacheHeight单位是图片显示逻辑像素乘以 devicePixelRatio。Flutter 会自动按比例解码出缩小后的图。Image.network( url, cacheWidth: 300, cacheHeight: 300, fit: BoxFit.cover, )这样底层会用更小的位图去渲染既省内存又省 GPU 开销。我之前遇到过一个列表加载慢的问题排查下来是图片解码后的尺寸是 UI 实际显示尺寸的 6 倍多加上没有缓存策略滚动时每次出现明显卡顿。还有imageCache默认会持有 1000 张图片上限大约是 100MB。如果你的列表图片很多要合理设置imageCache的maxMemoryBytes和maxPendingImages避免图片缓存本身变成内存爆炸的元凶。关于图片还有一个容易被忽略的点占位图和加载出错图。如果每个 item 在图片加载过程中都显示一个全屏占位图而占位图又是一张较大的本地资源一样会增加内存压力。好的方案是用FrameBuilder配合渐显效果或者用极小的占位色块不加载额外的图片资源。3.3 透明、阴影和裁剪的隐藏开销别小看这三个东西。ClipRRect 会给每个 item 生成 clip path。如果列表 UI 里大量使用圆角容器和卡片阴影绘制层的负担就会加大。能用 BoxDecoration 的 borderRadius 解决的不用额外包 ClipRRect。阴影 shadow 在移动端 GPU 上的开销比大多数人想的高尤其是大量 item 都带阴影的场景。如果只是为了视觉层次感可以用边框加浅色背景代替效果大差不差绘制省一个量级。圆形头像也是一个高频坑。用 ClipOval 包一层会导致每个 item 都有 clipping。在大量列表项场景下可以提前把头像裁成圆形图片或者用CircleAvatar它对圆形绘制做了优化比 ClipOval 轻量很多。透明度方面用Opacity包裹大列表项会让整个子树变成一个离屏渲染层非常昂贵。能用颜色透明度实现效果的就不要用 Opacity 组件。这点我在一些开源项目里都看到过反面案例一个大列表从头到尾用 Opacity 包裹 item滚动起来卡到怀疑人生。4. 状态管理setState 一次为何卡一次4.1 setState 的辐射范围是整棵子树很多人问为什么列表配合 Provider 或者 setState 使用后滑动就卡根源在于 setState 的生效范围。当你 setState 时framework 会标记这个 StatefulWidget 的子树上所有需要更新的组件去重新构建。如果你的状态管理在列表的父级比如整个 Page 级别一次 setState 就会触发整个列表的 rebuild。如果列表有几百个 item那每次状态变化都要重新走一遍 itemBuilder——即使它们根本没有变化。最好的方案是状态粒度尽量低。在列表项内部使用自己的状态管理或者用 Selector 只监听 item 内部真正变化的数据让一个 item 的刷新不会波及全部 item。如果实在做不到至少把列表本身抽取成一个独立 Widget并尽可能传常量参数让父级刷新时列表的 Element 可以复用。4.2 正确使用 Provider 的 Selector 和 child 参数Provider 在 Flutter 生态里是应用最广泛的状态管理方案但很多人只用了Provider.of或者context.watch在顶层监听导致整个子树重建。其实 Provider 提供了 Selector可以只监听某个值没变就不重建。SelectorCartModel, int( selector: (context, cart) cart.totalQuantity, builder: (context, quantity, child) { return Text($quantity); }, )这里 builder 的第三个参数child值得单独讲。它是用来做子树缓存的关键。在 builder 里返回的 UI 如果有一部分是不变的你应该把它作为child参数预先构造好传进来这样即使数据变化那一部分子树依然可以完全复用。这个方法在ValueListenableBuilder、AnimatedBuilder等场景同样适用。4.3 独立 StatefulWidget 与局部刷新的套路在列表优化中把 item 拆成独立的 StatefulWidget 也是一种有效手段。比如一个 item 里有收藏按钮和点赞数点击收藏时如果不希望整个 item 重建就把收藏按钮和点赞数封装成一个独立的 StatefulWidget内部 setState 只影响自身。另一个常用组合是ValueNotifierValueListenableBuilder用于 item 内部的高频变化数据。正确姿势不是“不 setState”而是“把 setState 控制到最小范围”。列表项内部一个 20px 小按钮的刷新绝不应该波及到几百个 item 的 build。这个认知是很多中级工程师的盲区也是真正拉开层级的地方。5. 滚动与交互让列表丝滑的底层设计5.1 滚动监听为什么会成为性能杀手常见场景是页面或列表添加了 ScrollController然后在 listener 里做 setState 更新某个状态比如“是否显示返回顶部按钮”。滚动事件每秒会触发几十次甚至上百次如果 setState 的更新范围覆盖了整个列表那就真的会一路卡到底。解法通常是把滚动监听变化的状态用 ValueNotifier 保存只更新真正依赖它的那个小组件。或者直接使用AnimatedBuilder监听 controller只包住那个返回顶部按钮让按钮的显隐动画只影响自身区域。return AnimatedBuilder( animation: _scrollController, builder: (context, child) { return _scrollController.offset 500 ? child! : const SizedBox(); }, child: FloatingActionButton(...), );5.2 滚动中不要执行重任务异步与预加载的正确姿势滚动过程中一旦有耗时操作比如大 JSON 解析、数据库查询、图片解码都会阻塞 UI 线程导致掉帧。正确做法是把耗时任务放到 isolate 或异步队列中执行然后在回调里再更新数据。列表分页加载的核心原则是保持当前视口内容稳定把新数据的加载放在滚动暂停后通过一个防抖/节流机制来触发。或者提前一个屏幕距离加载数据让用户滚到那里时数据已经就绪。这里推荐一个简单有效的三阶段加载策略首页数据加载完成后立刻加载第二页数据但先不渲染当用户滚动到接近底部时触发第三页及后续页加载每次加载成功后以增量方式合并到列表尾部这个策略能让加载与滚动交错进行用户基本看不到 loading 页面。5.3 physics 参数也会影响滚动性能physics也是性能的一部分。BouncingScrollPhysics和ClampingScrollPhysics的差异不只是体验。iOS 上默认BouncingScrollPhysics因为回弹效果滚动末期的动画更复杂在低端机上偶尔有小幅卡顿的可能。如果产品上不需要弹性反馈可以显式指定ClampingScrollPhysics。我通常的做法是列表页面统一使用平台默认但如果列表项很重且低端机型测试有明显卡顿就切换成ClampingScrollPhysics实测对低端 Android 有一定帮助。注意这属于“最后一步的微调”不要指望通过换 physics 解决核心性能问题前面那些构建和绘制层的优化才是大头。6. 数据层优化让列表永远不会“等数据”6.1 分页加载与预加载的标准操作分页加载在很多业务里就是“滚到底部再拉取下一页”但这种实现太被动用户总是能感受到 loading 的等待。更好的做法是估算用户滚动速度提前加载后面 1-2 屏的数据。实现方案可以在滚动通知监听里判断当前滚动位置加屏高是否接近数据总长度如果接近就触发下一页拉取。数据拉取后的合并要注意一个细节用不可变列表newList oldList newData然后更新状态。这样能保证列表数据的 value 在更新时是新对象否则无法触发列表刷新同时避免在 itemBuilder 里做复杂的过滤排序操作这些应该放在数据层处理完。列表数据量大时对每个新数据做唯一 ID 去重也是必要的防止分页重叠导致重复 item。6.2 用 compute 把 JSON 解析移出 UI 线程每次接口返回的 JSON 数据如果直接在 UI 线程用 jsonDecode 解析几百 KB 的数据在低端机上的耗时可以达到几十毫秒甚至更久。这是很隐蔽的掉帧来源。标准做法是拿到 response 后先转成 String然后通过 compute 或 isolate 去解析成强类型 Model再交回 UI 线程使用。final data await compute(parseItems, jsonString);注意 parseItems 需要是顶层函数或者静态方法不能依赖上下文和闭包否则compute会运行失败。还有一点经验不要每个网络请求都开一个新的 isolate频繁创建销毁 isolate 也有成本。如果数据量大且请求频繁可以考虑复用一个长期存活的 isolate 处理解析任务。6.3 三级缓存内存、磁盘到网络的完整链路经验做法是列表页的数据缓存优先级是内存缓存 磁盘缓存 网络。内存缓存可以简单用一个Map配合空安全也可以用 dedicated cache 库。磁盘缓存用 Hive、Drift 或者 sqflite 都可以关键是设备闪存读写一旦做好二次进入列表页的加载速度会快很多尤其对老用户而言。在列表刷新时先用缓存数据快速渲染再在后台拉取新数据成功后再更新列表。这个“旧数据 新数据合并”的思路能让用户体验提升一个台阶。注意缓存数据最好带上时间戳和版本号避免永久缓存导致数据不一致问题。7. 性能分析工具与问题排查手册7.1 别盯着 Debug 模式下的数据看Debug 模式下 Flutter 开启了大量断言检查性能数据完全失真。一定要用 Profile 模式或 Release 模式做真机测试。Profile 模式保留了一些性能分析能力适合定位问题Release 模式则接近用户实际体验。简单跑一遍flutter run --profile配合 DevTools 的 Performance 面板录制一段滚动过程查看 build/layout/paint 每一阶段的耗时分布。我见过不少团队在 debug 模式下测性能然后得出“Flutter 性能不行”的结论这其实是误诊。另外一个容易被忽略的点要在真机上测。模拟器上的 GPU 运算方式和真机差异很大模拟器上可能很流畅真机上卡成 PPT反过来也一样。7.2 Performance Overlay 里的两条竖条怎么看Flutter 内置的 Performance Overlay 可以显示当前帧的耗时情况UI 线程和 Raster 线程的负载会分开显示。如果 UI 线程条很高说明 build 和 layout 占主导如果 Raster 高说明绘制层有问题。这两种情况优化方向完全相反前者要优化 Widget 结构、减少重建、检查状态管理后者要缩减图片尺寸、减少半透明层、降低裁剪复杂度。Timeline 模式更精确可以具体到某个方法的耗时比如自定义 Widget 的 build 方法耗时。定位思路是滚动过程中暂停看哪个方法在时间线上不断出现且耗时高那就是优化的目标。7.3 常见性能问题速查表现象可能原因优先排查项滚动时整体卡顿item 构建过重 / 高度不固定itemExtent、cacheExtent、const、图片尺寸特定 item 卡顿图片过大或动画过多缩略图、RepaintBoundary、图片缓存策略启动时白屏/卡顿数据加载阻塞 UIcompute 解析、分页加载、磁盘缓存快速滚动后持续掉帧item 构建太慢局部刷新、状态管理粒度、异步加载内存持续上涨图片缓存、大量 Widget 常驻imageCache 限制、item 回收、图片过量缓存我在实际项目里踩过一次典型的坑一个新闻列表每条 item 都有一张封面图、一个视频小图标、三个 tab 按钮。那个页面在低端机上滚动卡到 20 帧左右。排查下来发现几个问题叠加图片没有设置 cacheWidth、item 高度不固定且没有用 prototypeItem、整页在滚动监听里做了 setState。修完这三个问题后帧率恢复到 55 帧以上。这类问题你只修其中一个都很难有明显改观必须系统性地排查。8. 从“会用”到“会设计”的层面跃迁8.1 性能优化应当前置而不是事后救火真正拉开层级的地方在于普通工程师在出现卡顿之后才开始优化高级工程师在设计阶段就提前避开坑。可以问自己几个问题列表项是固定高度还是动态高度图片源是否可以调整质量状态更新的频率高吗如果这些问题在需求评审阶段就讨论并定下来后端可以配合输出缩略图设计可以提前约束阴影和圆角的使用开发就能省下大量后期返工。我之前参与过一个资讯类 App 的改版首页是典型的大列表场景。在需求评审时就和设计定了 item 高度方案封面图统一 16:9标题最多两行副标题一行底部操作栏固定高度。这样一来 item 高度可精确计算itemExtent直接设置省掉了后期动态高度的性能调试。真正的高效工程从来不是后期堆优化手段而是前期定规范堵住性能黑洞。8.2 学会读 Flutter 源码遇到问题看实现Flutter 的列表性能优化跟框架实现细节强相关。再往上走你得学会看 SliverList 的布局逻辑、Viewport 的加载时机、RenderObject 的绘制策略。我的经验是遇到问题先去看一眼 Flutter 源码对应实现比盲目搜 stack overflow 有效得多。比如之前有疑问为什么ListView.builder会重新 build 屏幕外的 item看完源码就明白cacheExtent的作用机制了也就理解了为什么默认cacheExtent只有 250 像素而 item 很高时需要调大。源码是对行为最精确的文档比网上拼凑的博客管线靠谱得多。8.3 沉淀团队级优化 checklist最后建议把列表优化的经验沉淀成团队内部的 checklist。接到新列表需求时先对照检查一遍item 是否使用了 builder 模式而不是固定 childrenitem 高度是否固定能否用 itemExtent 或 prototypeItemitem 内部是否有不必要的动态 Widget 和重复 build状态管理是否做到最小范围刷新网络图片是否设置了合理 cacheWidth 和 cacheHeight是否有过度裁剪、阴影和透明度的使用图片缓存大小是否需要调整滚动监听是否只在最小范围内更新JSON 解析与数据库操作是否移出 UI 线程是否预留了分页加载和预加载的接口这套 checklist 是团队从“能跑”到“能流畅跑”的重要保障。单独某一项看着不起眼但每一项都在不同场景下救过命。我个人在实际操作中的体会是性能优化没有银弹也没有一个“统一开关”能一次解决所有问题。大列表优化是一场持久战你得先建立系统化认知再按数据决策而不是一上来就堆各种参数。很多看似高深的优化方案本质上都是在做同一件事把不必要的构建、不必要的布局、不必要的绘制从每一帧的 16.66ms 里面赶出去。这件事做得越彻底你的列表就越跟手你的工程师层级也就越高。