我接手过一个被用户吐槽“滑不动”的资讯类App首页。一千多条内容数据一次性从接口返回前端用最直观的写法把ListView铺满每条item里塞着封面图、标题、摘要、来源标签和一堆操作按钮。滑动的时候明显掉帧在低端机上甚至会出现整段空白。团队里刚转Flutter的同事第一反应是“数据量太大做成分页吧”但产品说这个页面的策略要求就是内容一次给到于是谁都没敢动。后来我把整个列表的构建、数据和刷新链路重新拆了一遍优化完再测滑动已经恢复到“顺滑”的体感。也是从那个项目开始我确认了一件事Flutter大列表性能优化是团队里真正能拉开工程师层级的专项方向之一。它不是“知道几个API”就能解决的而是要求你理解渲染机制、布局流程、数据刷新粒度并且能动手把每一个环节的浪费都找出来。这篇文章我会围绕大列表优化先讲清背后的机制再给出一份可以直接照着做的优化清单最后用一个实测用例展示两种写法的差距。适合那些已经被列表卡顿折腾过、但还没有系统梳理过优化思路的Flutter开发者。1. 大列表优化为什么能区分工程师层级三个认知断层1.1 只知道builder和真正理解懒加载是两回事很多人一谈到Flutter列表优化第一反应就是“ListView.builder”。这当然没错也比直接用ListView(children: [...])要高级。但如果你只是把一个写好的构造方式换成另一个而不理解它为什么快那距离真正的优化还差得很远。先看最基础的事实ListView(children: ...)会为传入的所有子项创建Widget和对应的Element即使这些子项根本不在屏幕上。数据量小的时候没什么问题一旦到了几百上千条仅仅构建这几千个widget、完成它们各自的layout和paint就已经足够让UI线程在进入首帧之前就卡上一阵。用户感受到的就是“打开页面慢半拍”以及滚动时伴随的顿挫。ListView.builder并不是魔法它只是把“构建全部子项”换成了“构建视口内可见项视觉缓存区内的项”。Flutter默认会在可视区域之外额外构建一块cacheExtent默认250个逻辑像素的缓冲。滚动时滚出缓存区的项会被销毁新进入的项会被创建。这种懒加载才是它快的原因。但问题是很多项目的卡顿并没有因为换用builder而消失。为什么因为懒加载只解决了“一次性创建全部widget”的问题而滚动过程中的持续卡顿通常来自每个item自身的构建成本过高、滚动时频繁触发重建以及数据刷新时把整个列表重新刷了一遍。这些才是后面要逐项解决的问题。1.2 把“卡顿”归因到错误的环节是绝大多数项目的通病我在上一条提到换掉构造函数并不能解决所有问题。这里要解释一个更重要的认知当用户说“卡”的时候“卡”到底发生在哪个环节Flutter一帧渲染要经过三个阶段Build构建widget树、Layout计算尺寸和位置、Paint绘制。它们都发生在UI线程上之后还有一个Raster线程负责把绘制好的图层合成到屏幕上。如果Build/Layout/Paint时间太长表现为“UI线程卡顿”如果Raster线程太慢则表现为画面合成掉帧常见原因有大面积半透明叠加、复杂阴影、超清图片解码等。很多工程师在优化列表时第一件事不是看数据而是“凭感觉改代码”。比如看到某个item里有个阴影效果就把它去掉结果帧率没有明显变化因为真正的瓶颈是item里那张网络图片在滚动时反复解码。所以我的建议是先给问题定性再动手。用性能工具把“卡在哪个阶段”测出来比猜重要得多。为什么这一点能拉开层级因为初级工程师在改代码中级工程师在找根因而高级工程师会先建立“耗时发生在哪个管线”的判断框架然后带着数据去改。1.3 高级视角从渲染树而不是代码行看问题这里想再往深挖一层大列表优化的终极思路是“让Flutter少干活”而不是“让代码看起来更少”。我见过一些人把item的结构写得很“优雅”比如把几十行代码抽成一个函数、抽成小组件感觉上“精简了”但每次build时这些代码仍然会全部执行该创建的widget一个都没少。反过来有些优化看起来只是“加了几个关键字”比如const、itemExtent但它们是直接作用于渲染树的效果比重构代码结构明显得多。所以我的视角里大列表优化的对象始终是渲染树Widget数量、Element是否复用、RenderObject是否重复布局、绘制区域是否有不必要的合成。带着这个视角去看下面的每个优化点你会更容易理解每个手段背后的逻辑。2. 理解Flutter列表懒加载与复用机制别把机制用错2.1 cacheExtent缓存区的收益和代价继续沿着懒加载机制往下走。cacheExtent这个参数很多人知道但很少人认真思考它的默认值意味着什么。默认250逻辑像素意味着屏幕之外还有一小段提前构建的缓冲区目的是让滚动时新item“提前就绪”不会出现空白。有些开发者遇到过“滑动时出现空白”第一反应是把cacheExtent调大比如设成2000、5000。这样确实能让更多项提前构建但代价是屏幕上明明只有10个item可见后台可能已经构建了上百个。这些widget都有对应的Element、RenderObject它们要参与布局计算内存占用和build耗时都会明显上升。如果在低端机上还叠加复杂的item结构那结果就是“空白少了卡顿更严重了”。正确做法是什么先搞清楚空白出现的原因。多数情况下空白并不是缓存区不够而是滚动过程中新进入的item构建太慢比如内部图片解码拖慢了UI线程或者item里有大量计算。把item的构建成本降下去之后250已经能覆盖大多数滚动场景。如果你确实需要调大建议结合滚动速度测试而不是一步加到几千。2.2 Widget重建与Element复用为什么类型和key不能乱来Flutter里常提“三棵树”Widget、Element、RenderObject。Widget是配置描述Element是实例化的节点RenderObject负责布局和绘制。列表滚动时滚出视野的项对应的Element会被销毁但重新滚回来时如果新Widget和旧Widget的runtimeType与key一致Flutter会尽量复用已有的Element和RenderObject而不是从零重建。复用的好处是省掉了大量布局和绘制工作。这个机制在日常编码中有两个直接推论。第一itemBuilder返回的组件类型要保持稳定不要根据数据变化而在两个不同类型之间切换否则每次变化都会触发Element销毁重建。第二key要稳定且具备唯一性。很多人习惯用index当key这在纯末尾追加时问题不大但一旦列表发生插入、删除、排序index会变Flutter会把新旧widget对应错位引发一系列状态错乱和额外重建严重的还会导致图片闪烁、输入框内容串位。正确做法是用数据的唯一id做key。它一方面让Element复用更稳定另一方面让Flutter知道“这一项还是那一项”只是内容变了从而把更新代价降到最低。2.3 keepAlive与状态保留哪些场景值得用哪些是坑懒加载机制还有一个不可避免的副作用滚出缓存区后item可能从树中移除状态随之丢失。如果你在item里放了滚动位置、输入内容、视频播放进度就会遇到“滑走再滑回来状态没了”的问题。Flutter提供了AutomaticKeepAliveClientMixin这个保活机制。很多人的第一反应是“那就全保活吧”但这恰恰是最大的坑一旦所有item都保活懒加载就形同虚设内存里会堆积所有item的Element和状态列表越长内存越夸张反而把“滚动流畅”这个目标牺牲掉了。我的建议是只保活少数必须保留状态的item。比如视频播放器、复杂的表单区为它们单独使用KeepAlive。普通文字、图片列表完全不值得保活。顺带说一句如果只是希望滚动位置不丢更合适的做法是记录ScrollController的offset而不是给item做保活。3. 列表项构建的减负清单把每一毫秒的build时间都抠出来3.1 从子树规模入手const、拆分与独立组件现在进入实操环节。大列表优化的核心战场是item本身一个item在滚动过程中会被重复创建所以item的build耗时直接决定滚动流畅度。第一个手段是const。在itemBuilder内部凡是传入参数不变、结构固定的子树都应该尽量用const构造。const的好处是如果同一个const widget在前后两次构建中保持相同的runtimeType和参数它就是同一个实例Flutter可以直接复用整个子树连build的过程都省了。写代码的时候要注意const生效需要满足条件可以在IDE里看那个“const keywords can be omitted”的提示或者禁用相关lint。实际优化中我常常建议把item拆成多个小组件但目的不是“好看”而是为了让“不变部分”和“变化部分”边界清晰。比如头像区、标题区、底部按钮区如果只有标题会变那就让只有标题的那个小组件被重新build其他部分用const稳定下来。这能显著减少重建范围。3.2 图片加载是列表最大的隐形杀手如果你用Profile工具看过一个大列表的Raster线程大概率会发现图片解码占了大头。Image.network直接写在item里表面上看没什么问题但它会在每次item被重新创建时触发图片的加载、解码甚至重新请求网络而且解码是昂贵的操作。我的建议有几个层级。第一层如果列表项里的图片都是固定尺寸展示就给cacheWidth或cacheHeight让解码出来的位图尺寸和显示尺寸一致避免一张几MB的图被缩到一个小方块纯属浪费。第二层引入cached_network_image这类持久化缓存方案避免滚动时反复请求。第三层给每张图片预留宽高占位这非常关键——如果图片加载前没有占位尺寸图片到达后布局会重新计算导致整个列表项跳动用户会感受到“滚动在抖”。还有一个容易忽略的细节尽量让服务端返回合适尺寸的图客户端不要依赖Image.network的自动缩放。移动网络环境下大图下载本身就会造成滚动卡顿和流量浪费。3.3 itemExtent让布局跳过测量成本再讲一个“一行代码换明显收益”的优化itemExtent。在ListView.builder里每个item的高度默认是未知的Flutter只能在滚动到附近时去实际测量它的尺寸。测量本身要跑layout成本不低。如果你能确定所有item的高度一致直接设置itemExtentSliver就会根据索引直接算出每个item的偏移量跳过对item的尺寸测量。这在结构简单的列表里可能只省几毫秒但在复杂列表里收益非常明显。当然前提是高度真的固定。如果item高度会变硬设itemExtent会导致内容被裁剪或溢出这时候可以考虑prototypeItem用一个示例item先测出大概尺寸减少部分测量压力。我自己更常用itemExtent配合同一卡片模板的信息流因为设计稿本来就定了高收益稳定。3.4 半透明、阴影与重绘边界别在item里堆视觉效果很多花哨的视觉设计到了列表页就成了性能杀手。半透明叠加、多层BoxShadow、复杂的渐变和模糊都会让Raster线程在合成时付出额外代价尤其半透明层级越多GPU合成的工作量越大。处理手段主要有两个第一能用不透明背景尽量不透明阴影效果能简化就简化。第二合理使用RepaintBoundary。它的作用是给子树建立独立的图层滚动时如果这个item没有变化可以直接复用绘制结果不用重绘。听起来很好但用错的也很多——有人给item里的每个小图标都包一层RepaintBoundary而RepaintBoundary本质上是额外的图层内存开销包得太多反而更卡。正确思路是在item的外层包一个RepaintBoundary让整个item的绘制结果在内容不变时被复用如果某个item内部频繁变化比如动画进度条反而不要包住它变化的部分。这个度需要结合Profile来把握不是拍脑袋决定的。4. 数据层与刷新粒度优化到后期瓶颈往往在这里4.1 不可变模型与相等判断引用变了再浅比较也白搭很多人在列表优化做完一轮后发现滚动本身很顺了但只要数据一刷新页面又卡了一下。这时候问题就从构建层转移到数据层。Flutter判断一个widget是否需要更新有一个关键逻辑Widget来回比对时如果引用相同直接跳过如果引用不同则会深入比较。这意味着如果你每次刷新数据都创建一个全新的ListModel即使里面的内容大部分没变Flutter也会认为整个列表都变了所有item都重新build一遍。解决办法是让模型具备“不可变性”并且在更新时尽量复用未变化项的实例。比如接口返回的数据里只有第3条变了那就只替换第3条的model其他项的引用保持不变。配合EqualList或重写模型的和hashCode你可以让Flutter知道“只有这一项变了”。这里也有一个小技巧与其重写复杂的真实相等判断不如在模型里放一个稳定的版本号字段。刷新时如果版本号没变直接复用旧实例。这个思路在业务复杂的列表里更好维护。4.2 setState的范围和频率不要让一个按钮震整个列表数据层的第二个高频问题是刷新粒度太大。最常见的场景用户点赞某个列表项代码在页面根组件里调用了setState结果整个ListView的所有可见item全部重新build。一两个item还好几十个可见item一起重建帧耗时立刻飙升。为什么会这样因为ListView的itemBuilder是在父组件build时被调用的父组件setState之后整个列表区域的widget都会重建。解决办法有两个层面第一层把item做成独立的StatefulWidget点赞时只在item内部setState第二层如果item之间有联动比如点赞数要同步到另一个位置的汇总按钮可以用ValueNotifier或轻量级状态管理只让真正关心这个数据的组件去更新。记住一个原则setState的粒度应该精确到“数据真正发生变化、并且UI需要刷新”的最小范围而不是“整个页面安全地重画一遍”。4.3 分页加载与预加载不要让列表长到你不得不优化最后说一个看起来投机、但高级工程师一定会考虑的手段不要让列表无限变长。懒加载解决了“一次性构建”问题但当列表有几个以上时即使只构建可视区滚动距离变长、内存中的缓存项变多整体压力还是在上升。最典型的是图片缓存和事件监听——很多图片缓存方案会保留近期加载过的位图列表越长留在内存里的位图越多。所以分页加载、滚动到底预加载下一页不只是“产品需求”更是性能设计的一部分。在业务允许的情况下给列表一个合理的数据上限配合“加载中”、“没有更多了”这些尾部占位可以让优化工作事半功倍。这方面我踩过不少坑比如预加载阈值设得太高导致列表还没到底就开始请求或者加载更多后没有保持滚动位置读者可以在实现时特别注意。5. 实测对比同一个信息流页面两种写法的性能差距5.1 两种写法怎么搭出来的理论讲再多不如摆一个实测结果。我先说明环境和复现方式。这次测试我模拟了某个业务的信息流页面1000条数据item包含头像、标题、正文摘要、一张封面图和点赞按钮。测试设备是一台中等配置的Android手机Flutter运行在Profile模式下。写法A是“最直接版本”用ListView(children: ...)一次性构建全部item图片用Image.network点赞操作在页面根组件setStateitem高度随机不可预知。写法B是“经过优化的版本”ListView.builderitemExtent 拆分组件 const复用 图片缓存与固定解码尺寸 点赞只在item内部局部setState数据刷新时保持未变化项引用不变。5.2 测试流程和指标怎么采集测试方法是清理页面后从顶部开始匀速往下滚动持续5秒用DevTools Performance页录制Timeline再结合Flutter自带的SchedulerBinding统计帧耗时。我重点看了三个指标UI线程单帧平均耗时、超过16ms的掉帧次数、以及内存占用峰值。这里说明一下Profile模式下的数据反映的是真实release性能不要把Debug模式下的数据拿来对比因为Debug模式大量断言和开发检查会显著拖慢运行速度数据失真。5.3 优化前后的数据对比两个版本跑完差距用表格摆出来这是我当天测试的实测数据不同设备和数据下会有浮动但方向和量级有参考价值指标写法A写法BUI线程平均帧耗时约14ms约4ms滚动中超过16ms的掉帧数28次/5秒3次/5秒首屏构建耗时约800ms约350ms峰值内存占用约380MB约210MB可以看到写法B在UI线程耗时、掉帧率、首屏构建和内存占用上都明显优于写法A。实际体验上写法A在低端机上滑动有明显的“拖拽感”偶尔整块区域会在松手后继续跳动写法B则基本保持画面稳定滚动结束时也不会出现二次刷新。这个对比最有意义的点不是“B比A好”而是每个差异都能对应到前面讲过的机制builder把一次性构建改为懒加载itemExtent省掉测量const和组件拆分减少重复build图片相关优化降低Raster线程压力局部setState避免整表重建。优化不是玄学是一环一环做出来的。6. 用Profile工具定位真实瓶颈优化要落到数据上6.1 先分清UI线程卡还是Raster线程卡很多人把“看Profile”理解成“打开Performance overlay看帧率”这只是一个起点。更关键的是要能区分瓶颈在UI线程还是Raster线程。Profile模式下用DevTools Performance页录制滚动过程Timeline每条帧会显示Build、Layout、Paint等UI线程耗时以及Raster线程耗时。如果Build和Layout高说明问题在widget构建与布局优先做减负和复用如果Raster高说明问题在绘制与合成优先处理图片、阴影、透明度。我见过不少团队对着高Raster帧率去优化builder写法方向完全反了。6.2 一套可复用的定位步骤我自己的排查流程大致是在Profile模式下启动应用用Performance overlay确认是否是“持续掉帧”还是一个操作后的单次卡顿。用DevTools的Timeline录制一次完整的滚动统计平均帧耗时和掉帧区间。点击耗时最高的某一帧看它里面Build / Layout / Paint / Raster分别花了多少时间定位到具体阶段。如果卡在Build回到代码里看itemBuilder是否在频繁创建非const子树如果卡在Raster检查图片列表和阴影绘制。逐项优化后重新录制同场景对比前后指标不要凭体感说“看起来顺了”。这套流程听起来不复杂但真正坚持做下来的人不多。大多数项目优化不到点上就是因为缺少这个“先量化、再动手”的习惯。6.3 工程层面容易被忽略的细节最后补充几个我在实际项目中踩过的工程细节。第一release包和Profile包行为有差异有的问题只在release触发有的只在debug出现定位时别用错构建模式。第二别忽略列表页被嵌套在Column或者Stack里导致的双重滚动布局风险这类问题在Timeline上会表现成长帧。第三部分机型上硬件加速和出厂动画设置不同导致同一个列表在不同设备上的表现差异很大测试尽量覆盖低端机。另外想说一句优化做到后面你会发现自己主要在跟“哪里在浪费”做斗争而不是“哪段代码写得不对”。大列表优化的工程价值恰恰体现在这种细致而系统的排查过程中。如果让我总结一下大列表优化这件事我想说的是它没有银弹没有一句“用builder就不卡了”的万能答案。真正有效的路径永远是理解机制量化瓶颈然后针对性地减少渲染树里的无效劳动。我个人体会最深的一点是事后你回头看那些改动往往每一行都平平无奇加个const、设个itemExtent、调整setState粒度、给图片加缓存和固定尺寸。但组合在一起帧率就是能差出一倍。这背后靠的就是对Flutter渲染机制的把握以及一套“让数据说话”的排查习惯。希望这篇内容能帮你少走一些弯路。 
长河君 · 2026/10/10 6:33:18 · 阅读 1.2k Flutter大列表性能优化实战：机制、优化清单与实测对比
我接手过一个被用户吐槽“滑不动”的资讯类App首页。一千多条内容数据一次性从接口返回前端用最直观的写法把ListView铺满每条item里塞着封面图、标题、摘要、来源标签和一堆操作按钮。滑动的时候明显掉帧在低端机上甚至会出现整段空白。团队里刚转Flutter的同事第一反应是“数据量太大做成分页吧”但产品说这个页面的策略要求就是内容一次给到于是谁都没敢动。后来我把整个列表的构建、数据和刷新链路重新拆了一遍优化完再测滑动已经恢复到“顺滑”的体感。也是从那个项目开始我确认了一件事Flutter大列表性能优化是团队里真正能拉开工程师层级的专项方向之一。它不是“知道几个API”就能解决的而是要求你理解渲染机制、布局流程、数据刷新粒度并且能动手把每一个环节的浪费都找出来。这篇文章我会围绕大列表优化先讲清背后的机制再给出一份可以直接照着做的优化清单最后用一个实测用例展示两种写法的差距。适合那些已经被列表卡顿折腾过、但还没有系统梳理过优化思路的Flutter开发者。1. 大列表优化为什么能区分工程师层级三个认知断层1.1 只知道builder和真正理解懒加载是两回事很多人一谈到Flutter列表优化第一反应就是“ListView.builder”。这当然没错也比直接用ListView(children: [...])要高级。但如果你只是把一个写好的构造方式换成另一个而不理解它为什么快那距离真正的优化还差得很远。先看最基础的事实ListView(children: ...)会为传入的所有子项创建Widget和对应的Element即使这些子项根本不在屏幕上。数据量小的时候没什么问题一旦到了几百上千条仅仅构建这几千个widget、完成它们各自的layout和paint就已经足够让UI线程在进入首帧之前就卡上一阵。用户感受到的就是“打开页面慢半拍”以及滚动时伴随的顿挫。ListView.builder并不是魔法它只是把“构建全部子项”换成了“构建视口内可见项视觉缓存区内的项”。Flutter默认会在可视区域之外额外构建一块cacheExtent默认250个逻辑像素的缓冲。滚动时滚出缓存区的项会被销毁新进入的项会被创建。这种懒加载才是它快的原因。但问题是很多项目的卡顿并没有因为换用builder而消失。为什么因为懒加载只解决了“一次性创建全部widget”的问题而滚动过程中的持续卡顿通常来自每个item自身的构建成本过高、滚动时频繁触发重建以及数据刷新时把整个列表重新刷了一遍。这些才是后面要逐项解决的问题。1.2 把“卡顿”归因到错误的环节是绝大多数项目的通病我在上一条提到换掉构造函数并不能解决所有问题。这里要解释一个更重要的认知当用户说“卡”的时候“卡”到底发生在哪个环节Flutter一帧渲染要经过三个阶段Build构建widget树、Layout计算尺寸和位置、Paint绘制。它们都发生在UI线程上之后还有一个Raster线程负责把绘制好的图层合成到屏幕上。如果Build/Layout/Paint时间太长表现为“UI线程卡顿”如果Raster线程太慢则表现为画面合成掉帧常见原因有大面积半透明叠加、复杂阴影、超清图片解码等。很多工程师在优化列表时第一件事不是看数据而是“凭感觉改代码”。比如看到某个item里有个阴影效果就把它去掉结果帧率没有明显变化因为真正的瓶颈是item里那张网络图片在滚动时反复解码。所以我的建议是先给问题定性再动手。用性能工具把“卡在哪个阶段”测出来比猜重要得多。为什么这一点能拉开层级因为初级工程师在改代码中级工程师在找根因而高级工程师会先建立“耗时发生在哪个管线”的判断框架然后带着数据去改。1.3 高级视角从渲染树而不是代码行看问题这里想再往深挖一层大列表优化的终极思路是“让Flutter少干活”而不是“让代码看起来更少”。我见过一些人把item的结构写得很“优雅”比如把几十行代码抽成一个函数、抽成小组件感觉上“精简了”但每次build时这些代码仍然会全部执行该创建的widget一个都没少。反过来有些优化看起来只是“加了几个关键字”比如const、itemExtent但它们是直接作用于渲染树的效果比重构代码结构明显得多。所以我的视角里大列表优化的对象始终是渲染树Widget数量、Element是否复用、RenderObject是否重复布局、绘制区域是否有不必要的合成。带着这个视角去看下面的每个优化点你会更容易理解每个手段背后的逻辑。2. 理解Flutter列表懒加载与复用机制别把机制用错2.1 cacheExtent缓存区的收益和代价继续沿着懒加载机制往下走。cacheExtent这个参数很多人知道但很少人认真思考它的默认值意味着什么。默认250逻辑像素意味着屏幕之外还有一小段提前构建的缓冲区目的是让滚动时新item“提前就绪”不会出现空白。有些开发者遇到过“滑动时出现空白”第一反应是把cacheExtent调大比如设成2000、5000。这样确实能让更多项提前构建但代价是屏幕上明明只有10个item可见后台可能已经构建了上百个。这些widget都有对应的Element、RenderObject它们要参与布局计算内存占用和build耗时都会明显上升。如果在低端机上还叠加复杂的item结构那结果就是“空白少了卡顿更严重了”。正确做法是什么先搞清楚空白出现的原因。多数情况下空白并不是缓存区不够而是滚动过程中新进入的item构建太慢比如内部图片解码拖慢了UI线程或者item里有大量计算。把item的构建成本降下去之后250已经能覆盖大多数滚动场景。如果你确实需要调大建议结合滚动速度测试而不是一步加到几千。2.2 Widget重建与Element复用为什么类型和key不能乱来Flutter里常提“三棵树”Widget、Element、RenderObject。Widget是配置描述Element是实例化的节点RenderObject负责布局和绘制。列表滚动时滚出视野的项对应的Element会被销毁但重新滚回来时如果新Widget和旧Widget的runtimeType与key一致Flutter会尽量复用已有的Element和RenderObject而不是从零重建。复用的好处是省掉了大量布局和绘制工作。这个机制在日常编码中有两个直接推论。第一itemBuilder返回的组件类型要保持稳定不要根据数据变化而在两个不同类型之间切换否则每次变化都会触发Element销毁重建。第二key要稳定且具备唯一性。很多人习惯用index当key这在纯末尾追加时问题不大但一旦列表发生插入、删除、排序index会变Flutter会把新旧widget对应错位引发一系列状态错乱和额外重建严重的还会导致图片闪烁、输入框内容串位。正确做法是用数据的唯一id做key。它一方面让Element复用更稳定另一方面让Flutter知道“这一项还是那一项”只是内容变了从而把更新代价降到最低。2.3 keepAlive与状态保留哪些场景值得用哪些是坑懒加载机制还有一个不可避免的副作用滚出缓存区后item可能从树中移除状态随之丢失。如果你在item里放了滚动位置、输入内容、视频播放进度就会遇到“滑走再滑回来状态没了”的问题。Flutter提供了AutomaticKeepAliveClientMixin这个保活机制。很多人的第一反应是“那就全保活吧”但这恰恰是最大的坑一旦所有item都保活懒加载就形同虚设内存里会堆积所有item的Element和状态列表越长内存越夸张反而把“滚动流畅”这个目标牺牲掉了。我的建议是只保活少数必须保留状态的item。比如视频播放器、复杂的表单区为它们单独使用KeepAlive。普通文字、图片列表完全不值得保活。顺带说一句如果只是希望滚动位置不丢更合适的做法是记录ScrollController的offset而不是给item做保活。3. 列表项构建的减负清单把每一毫秒的build时间都抠出来3.1 从子树规模入手const、拆分与独立组件现在进入实操环节。大列表优化的核心战场是item本身一个item在滚动过程中会被重复创建所以item的build耗时直接决定滚动流畅度。第一个手段是const。在itemBuilder内部凡是传入参数不变、结构固定的子树都应该尽量用const构造。const的好处是如果同一个const widget在前后两次构建中保持相同的runtimeType和参数它就是同一个实例Flutter可以直接复用整个子树连build的过程都省了。写代码的时候要注意const生效需要满足条件可以在IDE里看那个“const keywords can be omitted”的提示或者禁用相关lint。实际优化中我常常建议把item拆成多个小组件但目的不是“好看”而是为了让“不变部分”和“变化部分”边界清晰。比如头像区、标题区、底部按钮区如果只有标题会变那就让只有标题的那个小组件被重新build其他部分用const稳定下来。这能显著减少重建范围。3.2 图片加载是列表最大的隐形杀手如果你用Profile工具看过一个大列表的Raster线程大概率会发现图片解码占了大头。Image.network直接写在item里表面上看没什么问题但它会在每次item被重新创建时触发图片的加载、解码甚至重新请求网络而且解码是昂贵的操作。我的建议有几个层级。第一层如果列表项里的图片都是固定尺寸展示就给cacheWidth或cacheHeight让解码出来的位图尺寸和显示尺寸一致避免一张几MB的图被缩到一个小方块纯属浪费。第二层引入cached_network_image这类持久化缓存方案避免滚动时反复请求。第三层给每张图片预留宽高占位这非常关键——如果图片加载前没有占位尺寸图片到达后布局会重新计算导致整个列表项跳动用户会感受到“滚动在抖”。还有一个容易忽略的细节尽量让服务端返回合适尺寸的图客户端不要依赖Image.network的自动缩放。移动网络环境下大图下载本身就会造成滚动卡顿和流量浪费。3.3 itemExtent让布局跳过测量成本再讲一个“一行代码换明显收益”的优化itemExtent。在ListView.builder里每个item的高度默认是未知的Flutter只能在滚动到附近时去实际测量它的尺寸。测量本身要跑layout成本不低。如果你能确定所有item的高度一致直接设置itemExtentSliver就会根据索引直接算出每个item的偏移量跳过对item的尺寸测量。这在结构简单的列表里可能只省几毫秒但在复杂列表里收益非常明显。当然前提是高度真的固定。如果item高度会变硬设itemExtent会导致内容被裁剪或溢出这时候可以考虑prototypeItem用一个示例item先测出大概尺寸减少部分测量压力。我自己更常用itemExtent配合同一卡片模板的信息流因为设计稿本来就定了高收益稳定。3.4 半透明、阴影与重绘边界别在item里堆视觉效果很多花哨的视觉设计到了列表页就成了性能杀手。半透明叠加、多层BoxShadow、复杂的渐变和模糊都会让Raster线程在合成时付出额外代价尤其半透明层级越多GPU合成的工作量越大。处理手段主要有两个第一能用不透明背景尽量不透明阴影效果能简化就简化。第二合理使用RepaintBoundary。它的作用是给子树建立独立的图层滚动时如果这个item没有变化可以直接复用绘制结果不用重绘。听起来很好但用错的也很多——有人给item里的每个小图标都包一层RepaintBoundary而RepaintBoundary本质上是额外的图层内存开销包得太多反而更卡。正确思路是在item的外层包一个RepaintBoundary让整个item的绘制结果在内容不变时被复用如果某个item内部频繁变化比如动画进度条反而不要包住它变化的部分。这个度需要结合Profile来把握不是拍脑袋决定的。4. 数据层与刷新粒度优化到后期瓶颈往往在这里4.1 不可变模型与相等判断引用变了再浅比较也白搭很多人在列表优化做完一轮后发现滚动本身很顺了但只要数据一刷新页面又卡了一下。这时候问题就从构建层转移到数据层。Flutter判断一个widget是否需要更新有一个关键逻辑Widget来回比对时如果引用相同直接跳过如果引用不同则会深入比较。这意味着如果你每次刷新数据都创建一个全新的ListModel即使里面的内容大部分没变Flutter也会认为整个列表都变了所有item都重新build一遍。解决办法是让模型具备“不可变性”并且在更新时尽量复用未变化项的实例。比如接口返回的数据里只有第3条变了那就只替换第3条的model其他项的引用保持不变。配合EqualList或重写模型的和hashCode你可以让Flutter知道“只有这一项变了”。这里也有一个小技巧与其重写复杂的真实相等判断不如在模型里放一个稳定的版本号字段。刷新时如果版本号没变直接复用旧实例。这个思路在业务复杂的列表里更好维护。4.2 setState的范围和频率不要让一个按钮震整个列表数据层的第二个高频问题是刷新粒度太大。最常见的场景用户点赞某个列表项代码在页面根组件里调用了setState结果整个ListView的所有可见item全部重新build。一两个item还好几十个可见item一起重建帧耗时立刻飙升。为什么会这样因为ListView的itemBuilder是在父组件build时被调用的父组件setState之后整个列表区域的widget都会重建。解决办法有两个层面第一层把item做成独立的StatefulWidget点赞时只在item内部setState第二层如果item之间有联动比如点赞数要同步到另一个位置的汇总按钮可以用ValueNotifier或轻量级状态管理只让真正关心这个数据的组件去更新。记住一个原则setState的粒度应该精确到“数据真正发生变化、并且UI需要刷新”的最小范围而不是“整个页面安全地重画一遍”。4.3 分页加载与预加载不要让列表长到你不得不优化最后说一个看起来投机、但高级工程师一定会考虑的手段不要让列表无限变长。懒加载解决了“一次性构建”问题但当列表有几个以上时即使只构建可视区滚动距离变长、内存中的缓存项变多整体压力还是在上升。最典型的是图片缓存和事件监听——很多图片缓存方案会保留近期加载过的位图列表越长留在内存里的位图越多。所以分页加载、滚动到底预加载下一页不只是“产品需求”更是性能设计的一部分。在业务允许的情况下给列表一个合理的数据上限配合“加载中”、“没有更多了”这些尾部占位可以让优化工作事半功倍。这方面我踩过不少坑比如预加载阈值设得太高导致列表还没到底就开始请求或者加载更多后没有保持滚动位置读者可以在实现时特别注意。5. 实测对比同一个信息流页面两种写法的性能差距5.1 两种写法怎么搭出来的理论讲再多不如摆一个实测结果。我先说明环境和复现方式。这次测试我模拟了某个业务的信息流页面1000条数据item包含头像、标题、正文摘要、一张封面图和点赞按钮。测试设备是一台中等配置的Android手机Flutter运行在Profile模式下。写法A是“最直接版本”用ListView(children: ...)一次性构建全部item图片用Image.network点赞操作在页面根组件setStateitem高度随机不可预知。写法B是“经过优化的版本”ListView.builderitemExtent 拆分组件 const复用 图片缓存与固定解码尺寸 点赞只在item内部局部setState数据刷新时保持未变化项引用不变。5.2 测试流程和指标怎么采集测试方法是清理页面后从顶部开始匀速往下滚动持续5秒用DevTools Performance页录制Timeline再结合Flutter自带的SchedulerBinding统计帧耗时。我重点看了三个指标UI线程单帧平均耗时、超过16ms的掉帧次数、以及内存占用峰值。这里说明一下Profile模式下的数据反映的是真实release性能不要把Debug模式下的数据拿来对比因为Debug模式大量断言和开发检查会显著拖慢运行速度数据失真。5.3 优化前后的数据对比两个版本跑完差距用表格摆出来这是我当天测试的实测数据不同设备和数据下会有浮动但方向和量级有参考价值指标写法A写法BUI线程平均帧耗时约14ms约4ms滚动中超过16ms的掉帧数28次/5秒3次/5秒首屏构建耗时约800ms约350ms峰值内存占用约380MB约210MB可以看到写法B在UI线程耗时、掉帧率、首屏构建和内存占用上都明显优于写法A。实际体验上写法A在低端机上滑动有明显的“拖拽感”偶尔整块区域会在松手后继续跳动写法B则基本保持画面稳定滚动结束时也不会出现二次刷新。这个对比最有意义的点不是“B比A好”而是每个差异都能对应到前面讲过的机制builder把一次性构建改为懒加载itemExtent省掉测量const和组件拆分减少重复build图片相关优化降低Raster线程压力局部setState避免整表重建。优化不是玄学是一环一环做出来的。6. 用Profile工具定位真实瓶颈优化要落到数据上6.1 先分清UI线程卡还是Raster线程卡很多人把“看Profile”理解成“打开Performance overlay看帧率”这只是一个起点。更关键的是要能区分瓶颈在UI线程还是Raster线程。Profile模式下用DevTools Performance页录制滚动过程Timeline每条帧会显示Build、Layout、Paint等UI线程耗时以及Raster线程耗时。如果Build和Layout高说明问题在widget构建与布局优先做减负和复用如果Raster高说明问题在绘制与合成优先处理图片、阴影、透明度。我见过不少团队对着高Raster帧率去优化builder写法方向完全反了。6.2 一套可复用的定位步骤我自己的排查流程大致是在Profile模式下启动应用用Performance overlay确认是否是“持续掉帧”还是一个操作后的单次卡顿。用DevTools的Timeline录制一次完整的滚动统计平均帧耗时和掉帧区间。点击耗时最高的某一帧看它里面Build / Layout / Paint / Raster分别花了多少时间定位到具体阶段。如果卡在Build回到代码里看itemBuilder是否在频繁创建非const子树如果卡在Raster检查图片列表和阴影绘制。逐项优化后重新录制同场景对比前后指标不要凭体感说“看起来顺了”。这套流程听起来不复杂但真正坚持做下来的人不多。大多数项目优化不到点上就是因为缺少这个“先量化、再动手”的习惯。6.3 工程层面容易被忽略的细节最后补充几个我在实际项目中踩过的工程细节。第一release包和Profile包行为有差异有的问题只在release触发有的只在debug出现定位时别用错构建模式。第二别忽略列表页被嵌套在Column或者Stack里导致的双重滚动布局风险这类问题在Timeline上会表现成长帧。第三部分机型上硬件加速和出厂动画设置不同导致同一个列表在不同设备上的表现差异很大测试尽量覆盖低端机。另外想说一句优化做到后面你会发现自己主要在跟“哪里在浪费”做斗争而不是“哪段代码写得不对”。大列表优化的工程价值恰恰体现在这种细致而系统的排查过程中。如果让我总结一下大列表优化这件事我想说的是它没有银弹没有一句“用builder就不卡了”的万能答案。真正有效的路径永远是理解机制量化瓶颈然后针对性地减少渲染树里的无效劳动。我个人体会最深的一点是事后你回头看那些改动往往每一行都平平无奇加个const、设个itemExtent、调整setState粒度、给图片加缓存和固定尺寸。但组合在一起帧率就是能差出一倍。这背后靠的就是对Flutter渲染机制的把握以及一套“让数据说话”的排查习惯。希望这篇内容能帮你少走一些弯路。