在 Android 原生里和 RecyclerView 斗了几年之后我刚开始接触 Flutter ListView 时心里是带点不屑的又是一个列表控件能玩出什么花真正写完一个带下拉刷新、分页加载和多类型 item 的页面之后我才发现 Flutter 这套声明式列表的思路根本不是在模仿 RecyclerView而是把整个“数据驱动 UI”的逻辑重做了一遍。这篇文章我想从一个 Android 开发者的视角把从 RecyclerView 到声明式列表的迁移过程、核心差异和实战坑位一次讲透适合刚转 Flutter、或者已经在用但总感觉哪里没理顺的朋友。1. 先放下 AdapterRecyclerView 和声明式列表的思维差异1.1 RecyclerView 解决的问题和让人头疼的部分RecyclerView 在 Android 里绝对是统治级的存在。它的核心价值有两个一是 ViewHolder 复用机制让滚动时的视图创建开销降到最低二是 LayoutManager 把布局模式抽象出来LinearLayout、GridLayout、StaggeredGridLayout 随便切。配合 Adapter 的模式你在getItemCount里告诉它总共有多少个 item在onCreateViewHolder里创建视图在onBindViewHolder里填充数据。这套机制本身很优秀但用久了你会明显感觉到命令式 UI 的别扭。工作流是数据变化之后你得手动调用notifyDataSetChanged()或者更精细地用DiffUtil算出差异再notifyItemInserted/notifyItemRemoved。一旦页面里有多处地方改动数据你怎么保证notify的时机和粒度是对的每次都得小心翼翼地在脑子里面走一遍状态和视图的关系。更别提多类型 item 时getItemViewType的写法并不轻松一个列表中塞三四种卡片的时候Adapter 里面的 if-else 能堆到让人烦躁。1.2 声明式列表到底“声明”了什么Flutter 的 ListView 没有 Adapter没有 ViewHolder没有 LayoutManager。它的核心逻辑是一句话给定当前数据build方法描述出完整的 UI 长什么样。数据变了你只管更新状态框架负责重新执行 build 来刷新。没有“通知刷新”这回事也没有“复用”这回事——我这样说可能会让很多 Android 开发者产生一个大胆的疑问那性能不要了这里的关键不同在于Flutter 的 widget 不是真正的视图。它更像一张轻薄的设计图纸创建成本极低。真正的渲染对象由 Element 和 RenderObject 管理框架只在结构变化时增删。ListView.builder 照样是 lazily 构建——滚动到哪一屏才构建哪一屏的 widget。复用机制由框架内部帮你做了我们要操心的只剩数据逻辑。我第一次理解这个差异的时候脑子里蹦出来的类比是点菜和上菜的区别RecyclerView 是你反复告诉厨师“把第 3 桌的菜换掉”Flutter 是整桌重炒但厨房知道哪些菜不用真动。所以条条框框少了很多但底层的性能逻辑依然扎实。2. ListView 三种构造方式别再只会一种2.1 ListView(children:)适合小列表的直观写法Flutter 的 ListView 有几种常见构造方式很多人入门直接写ListView(children: [...])一个页面里放 10 个卡片、几段文字很直观跑起来也没毛病。ListView( children: const [ ListTile(leading: Icon(Icons.person), title: Text(张三)), ListTile(leading: Icon(Icons.email), title: Text(邮件)), ListTile(leading: Icon(Icons.settings), title: Text(设置)), ], )这种方式适合 item 数量固定且不多的场景比如设置页、个人中心这种一眼看得到底的界面。因为它的所有 children 都是立即构建的如果塞个 1000 条数据的长列表性能就直接翻车每条 item 的 widget 从一开始就全部躺在内存里这跟 RecyclerView 的按需回收完全是两个世界。2.2 ListView.builder日常项目的主力处理动态列表、数据来自网络接口的场景我基本只用ListView.builder。它的核心是懒构建配合 itemCount 参数控制“到底要构建多少个 item”。写法上更像 RecyclerView 的 Adapter——有 count有 create item 的回调但少了 ViewHolder 这一层。final items List.generate(100, (i) 第 $i 条数据); ListView.builder( itemCount: items.length, itemBuilder: (context, index) { return ListTile(title: Text(items[index])); }, )一眼看上去是不是很像onCreateViewHolderonBindViewHolder的合并版是的Flutter 把绑定和创建放在一个itemBuilder回调里完成了。你不需要维护 setOnClickListener 每次绑定也不需要处理 ViewHolder 的回收池——框架全包了。这个写法跟我之前写 RecyclerView 的 Adapter 相比代码量直接少掉一半还多。进阶一点的技巧如果列表里的 item 高度是固定的比如统一的 72 像素卡片建议给 ListView.builder 传一个itemExtent: 72。这等于告诉框架“所有 item 高度一致你不用每个都去量”。滚动计算的性能提升非常明显对长列表来说这个参数比很多所谓的优化手段更直接有效。2.3 ListView.separated 和 CustomScrollView 的取舍ListView.separated其实就是在 builder 基础上增加了一个构建分隔线的回调适合聊天记录、带分割线的列表ListView.separated( itemCount: 20, itemBuilder: (context, index) ListTile(title: Text(item $index)), separatorBuilder: (context, index) const Divider(height: 1), )这里要提一个反面经验在项目里见过有人为了条分隔线非要在每个 item 的 bottom 画一条线搞出一堆布局嵌套和条件判断。用separated一个参数就解决了何必呢。当页面结构比较丰富——顶部有轮播 Banner、中间是 Tab、下面才是列表的时候ListView 本身就不够用了。这时候应该上CustomScrollView把各个区块拆成 SliverCustomScrollView( slivers: [ SliverToBoxAdapter(child: BannerWidget()), SliverToBoxAdapter(child: TabBar()), SliverList( delegate: SliverChildBuilderDelegate( (context, index) Card(child: Text(数据 $index)), childCount: 50, ), ), ], )Regular ListView 只能看到一个滚动方向上的一个列表Sliver 体系能组合多个滚动区块。理解了 Sliver 之后你会发现之前用 Android 里 CollapsingToolbarLayout RecyclerView 做的复杂沉浸式页面在 Flutter 里可以用 SliverAppBar SliverList 组合出来代码还更直观。3. 从 Adapter ViewHolder 到 itemBuilder核心迁移映射3.1 一个典型移动页面的代码对照如果你是从 Android 项目转过来最需要做的一件事是忘掉“Adapter/ViewHolder 分离”的思维把所有 UI 描述都放进itemBuilder。我在实际迁移公司项目时把一个“订单列表”页面从 RecyclerView 改写成 Flutter ListView对比一下核心代码差异很清楚。Android 侧典型的做法是class OrderAdapter extends RecyclerView.AdapterOrderViewHolder { ListOrderModel data; // getItemCount // onCreateViewHolder // onBindViewHolder }Flutter 侧则收敛成一个页面组件Widget buildOrderList(ListOrderModel orders) { return ListView.separated( itemCount: orders.length, itemBuilder: (context, index) { final order orders[index]; return OrderCard(order: order); }, separatorBuilder: (context, index) const Divider(height: 8), ); }没有了OrderAdapter这个类也没有ViewHolder整个 UI 呈现逻辑变成“给定一个订单数据返回一个卡片 widget”。单一数据源单一职责看代码时你不需要在 Adapter、ViewModel、Fragment 之间跳来跳去。我自己在迁移时踩过一次坑一开始我会习惯性地写一个OrderCardStatefulWidget然后在里面写一堆状态字段结果列表滑动时频繁重建状态混乱。后面才彻底想明白——列表 item 应当是无状态的展示组件数据从外部传入事件回调通过构造参数往外抛不要在 item 内部持有可变状态这跟 ViewHolder 里也不该有业务逻辑是一个道理。3.2 item 的点击和事件回调怎么设计RecyclerView 里给 item 加点击事件通常是在onBindViewHolder中holder.itemView.setOnClickListener(...)。每绑定一次就设置一次监听这个流程很成熟但也很啰嗦。Flutter 里没有 setOnClickListener你直接在itemBuilder里包裹一个GestureDetector或InkWell即可某些列表项场景下还可以用ListTile.onTap直接声明。itemBuilder: (context, index) { final order orders[index]; return ListTile( title: Text(order.title), trailing: const Icon(Icons.chevron_right), onTap: () _handleOrderTap(order.id), ); }这里有个典型的经验技巧itemBuilder 里每个 item 创建的onTap闭包会持有 index 快照这在 Flutter 的默认行为里没问题。但如果 item 顺序发生了增删旧的 index 就作废了。所以更稳妥的做法是闭包里直接传order.id而不是 index让数据本身成为事件的标识。这也是从 RecyclerView 的getAdapterPosition()踩坑经历里总结出来的经验换个框架教训依然适用。3.3 数据刷新从 notify 到 setState 的思维转换在 RecyclerView 时代数据更新要手动决定调用哪个 notify 方法用错导致闪一下、崩溃、脚标错乱都是常有的事。Flutter 的机制完全不同状态改变用setState包裹一下build 重新执行ListVie w的新 item 自动出现不需要“通知”。void _loadMore() { setState(() { _items.addAll(newItems); }); }代码就这么点。你可能会本能地觉得“每次刷新整个列表难道不浪费”但要知道 Flutter 的重新构建不意味着重新创建所有 RenderObject。框架有个脏标记机制不是所有组件都会真正重建。再说了itemBuilder 里懒构建本身也有缓存。所以别怕 setState用状态驱动的方式它就是这么直接。当你从该调哪个 notify 方法的思考里彻底走出来你就会明白声明式列表的爽点UI 是数据的函数只有一个方向的数据流永远不会出现视图和状态对不上的问题。4. 列表页实战从零搭一个可刷新的 Flutter 列表4.1 页面结构与数据源这里我以实际开发中最常见的信息流页面为例子完整走一遍从数据到 UI 的组装。核心结构有三部分一个ListFeedItem类型的数据源、一个ScrollController用来监听滚到底部、状态机里管理 loading / error / empty 几种 UI 表现。class FeedListPage extends StatefulWidget { override StateFeedListPage createState() _FeedListPageState(); } class _FeedListPageState extends StateFeedListPage { final _scrollController ScrollController(); final ListFeedItem _items []; int _page 1; bool _hasMore true; bool _isLoading false; override void initState() { super.initState(); _scrollController.addListener(_onScroll); _fetchData(); } void _onScroll() { if (_scrollController.position.pixels _scrollController.position.maxScrollExtent - 200) { _loadMore(); } } // ... }列表主体就用一个ListView.builder通过 itemCount 区分正常 item 和底部的加载 footerWidget build(BuildContext context) { return ListView.builder( controller: _scrollController, itemCount: _items.length (_hasMore ? 1 : 0), itemBuilder: (context, index) { if (index _items.length) { return const Padding( padding: EdgeInsets.all(16), child: Center(child: CircularProgressIndicator()), ); } return FeedCard(item: _items[index]); }, ); }这里几个细节值得注意。_onScroll里留了 200 像素的提前量避免滚动到绝对底部才触发加载的顿挫感footer 只在_hasMore为 true 时展示不然分页结束后页面底部一直转圈很尴尬。网络请求结束后要判断返回数据条数是否小于页大小来更新_hasMore。4.2 下拉刷新与加载更多下拉刷新在 Flutter 里用官方组件RefreshIndicator包一层即可onRefresh 里返回一个 Future刷新的动画会自动收起。加载更多则配合上面提到的监听器实现。这两件事写在一起逻辑一定要分开_refresh()负责把 page 重置为 1清空当前列表重新请求第一页_loadMore()负责在 page 基础上 1追加数据到_items不许清空列表最容易犯的错是把这两个方法混着写导致“下拉刷新之后越拉越多”因为 page 变量乱了套。我现在的习惯是每个列表页都维护一个_page和一个_isLoading布尔。_loadMore开场第一件事就是检查_isLoading防止滚动监听器频繁触发造成重复请求。Futurevoid _loadMore() async { if (_isLoading || !_hasMore) return; _isLoading true; try { final moreItems await Api.fetchFeed(page: _page 1); setState(() { _items.addAll(moreItems); _page 1; if (moreItems.length PageSize) _hasMore false; }); } finally { _isLoading false; } }这个 if (_isLoading || !_hasMore) return 是分页功能的防重复请求核心我看到太多新手项目因为没有它滚动一下连发七八个网络请求。这也是 RecyclerView 时代 onScrollStateChanged 事件里同样会遇到的问题,换到 Flutter 后老经验依然管用。4.3 空态、错误态和骨架屏的实现网络列表页最怕一种情况接口请求失败或者返回空数组用户打开页面看到的是一整片空白没有任何反馈。Flutter 里处理空态有一个思路上的转变——把“列表以外的状态”也当作普通 item 来处理。itemCount: _items.isEmpty ? 1 : _items.length (_hasMore ? 1 : 0), itemBuilder: (context, index) { if (_items.isEmpty) { return const Center(child: Text(暂无数据下拉刷新试试)); } // ... }当列表为空时ListView 仍然能渲染出一个空态占位填写在 item 里比直接 if-else 换成一个 Container 再套个Center写起来更自然特殊态也保持着一样的滚动行为。错误态的处理我是通过一个_loadError字段来标记。请求失败时不仅要有文案还要给个重试按钮。骨架屏Skeleton在 Flutter 里实现也不复杂在数据还没回来时用一个灰块占位 item 列表代替 ListView.builder等数据到了再切换回真正的列表。一个需要特别提醒的点在StatefulWidget里网络请求的 Future 没有在 initState 里做取消处理的话页面销毁后 state 还在用setState更新一个已经不显示在界面的组件控制台会出现警告。这个问题在 Android 里对应的是 Activity 销毁后 Adapter 持有旧 Context 导致内存泄漏Flutter 里没有那么严重但严谨一点的页面我会在dispose()里做一个_mounted的判断通过。5. 常见问题与排查技巧实录5.1 白屏和数据不显示的几种原因做 Flutter 开发白屏典型原因有几种。第一个是ListView.builder的itemCount写错了常见于你用了_items?.length但没有处理空列表的情况导致 itemCount 为 null整个 ListView 渲染为空白。第二个是数据请求完成之后没有调用setStatebuild 不可能重新执行。第三是列表外的父容器直接给了固定尺寸比如SizedBox高度为 0列表自然什么都显示不出来。这里我提供一个排查顺序先看有没有报错没有报错就看数据有没有真的进入列表再看 itemCount 的值是不是大于 0最后看父级布局约束。比一次看一堆代码更高效。5.2 Widget 尺寸溢出与列表错位在列表 item 中出现文字过长、图片拉伸导致布局溢出页面上会出现黄黑条纹而且被 KEEPS 在控制台输出下面一段红色的错误。这个跟 RecyclerView 的item_xxx布局写错差不多但 Flutter 的解决方式更明确用Expanded包裹可伸缩部分或者给Text加maxLines和overflow: TextOverflow.ellipsis。ListTile( title: Text( post.title, maxLines: 2, overflow: TextOverflow.ellipsis, ), )顺手分享一个踩坑体验Expanded组件只能用在Row、Column、Flex的直接 child 中。如果你在ListTile的 subtitle 里想实现那种“标题一行 缩略两行 时间一行”的复杂布局最好用ColumnRowExpanded明确地组合而不是层层套Container层级一多约束条件跟着复杂起来溢出问题也就找到你了。5.3 性能优化itemExtent、RepaintBoundary 与 builder 懒加载列表性能问题通常不是 Flutter 渲染引擎本身的问题而是写法上没有发挥出框架的优势。三个点要关注第一ListView.builder一定要用。直接传 children 的 ListView 就没有懒加载可言。第二固定高度场景用itemExtent减少计算第三对单个 item 内部如果有独立的动画或频繁重绘的区块包一层RepaintBoundary让重绘边界隔离开。ListView.builder( itemCount: 1000, itemExtent: 80, itemBuilder: (context, index) RepaintBoundary( child: FeedCard(index: index), ), )这三板斧加完长列表的实测流畅度基本没问题。Flutter 的 Impeller 渲染引擎在 Skia 之后已经做了不少优化列表渲染性能在现役移动设备上普遍都不是瓶颈你真正要防的是代码的动态构建爆炸。5.4 常见问题速查表现象可能原因解决方案列表白屏itemCount 为 null 或为 0设置默认值数据加载后 setState滚动到末尾反复加载缺少 _isLoading 判断加载中标记进入方法即拦截文字溢出黄黑条纹Text 无 maxLines 约束加 ellipsis用 Expanded 约束宽度嵌套滚动页面卡顿ListView 放进 NestedScrollView 或 Column改用 CustomScrollView SliverList图片加载时列表跳动item 高度不固定用固定 size 占位itemExtent 辅助页面销毁后 setState 报错异步请求未取消在 dispose 中标记 _disposed6. 从“找 RecyclerView 的影子”到真正用 Flutter 思考6.1 写少一半代码是真的前提是你接受新思路我在项目里统计过一个中等复杂度的订单列表页在 Android 里需要 Adapter、ViewHolder、ItemDecorator、DiffUtil 四五个文件配合在 Flutter 里核心往往就是一个 ListView.builder 一个 Card widget。代码量压缩一半不是玩笑。但这里有一个真相如果你还是抱着“Android 的那套思路能不能搬到 Flutter 里”的心态去写你会写出一个又一个别扭的 StatefulWidget反而比原生的更恶心。比如有人非要在 Flutter 里手动实现 ViewHolder 缓存池这就是典型的没转过弯来。框架已经做了你再做一遍纯属增加复杂度。6.2 列表和状态管理的关系列表页一旦复杂起来状态管理是绕不开的话题。setState 在小页面里完全够用但一个需要跨页面共享数据、频繁增删列表项的应用建议认真研究一下 Provider。它的原理并不复杂在 widget 树顶层提供一个数据对象子页面用context.watchT()去监听变化数据一变依赖它的 ListView 自动重建。// 简单的 Provider 用法示意 final feedProvider Provider.ofFeedModel(context); ListView.builder( itemCount: feedProvider.feeds.length, itemBuilder: (context, index) FeedCard(feed: feedProvider.feeds[index]), );这跟 Android 里的 LiveData / ViewModel 有相似之处但数据流的方向更统一。我不建议一上来就上 Bloc 或 Riverpod先把 Provider 用明白理解了状态单向流动的思想后面换任何状态管理框架都不难。6.3 给转 Flutter 的开发者的适应建议如果你是从 Android 起步我的建议是别一上来就纠结“ListView.builder 的懒加载原理是什么”先写几个页面感受一遍声明式 UI 的节奏。可以选一个你已经做过的小项目比如一个带有搜索和收藏的列表页分别用 RecyclerView 和 Flutter ListView 实现一遍对比两种写法的差异。很久之后你自然会明白flutter 它不是 RecyclerVie w的又一个变体而是一种更直观的、数据驱动 UI 的现代框架思路。列表是移动应用最常用的组件搞定它你就搞定了大半个 UI 层。后面再遇到 Sliver、StaggeredGrid、嵌套滚动都能在这套思维之下很快吃透。我个人在实际操作中还有个小习惯每个列表页我都会先写好空态和错误态的占位再去写正常 item 的布局。因为列表的开发调试过程往往要反复模拟各种状态这套骨架一开始就在后面接接口时能省很多重复造轮子的时间。这个习惯从 RecyclerView 时代保持到现在我觉得它比任何框架技巧都更通用。