Flutter中Cupertino DateTime picker干扰滚动致卡顿问题排查

云原生阿岚

2026-8-27

问题原因

这个卡顿是Cupertino系列选择器在长滚动场景下的典型资源泄漏问题，触发逻辑和代码实现直接相关：

给两个CupertinoDatePicker添加UniqueKey()的写法，会导致每次外层滚动触发build时，Flutter判定两个picker为全新组件，直接销毁旧实例、创建新实例。但CupertinoPicker内部持有的滚轮动画控制器、高频ticker回调、手势识别器不会随实例销毁被立即回收，反复全幅滚动5-6次后，内存中堆积的未释放渲染对象和回调会让UI线程每帧计算量线性上涨，最终帧率跌到个位数。
即使去掉UniqueKey，CupertinoPicker本身实现也存在缺陷：只要组件处于挂载状态，哪怕完全滚出可视区域、没有任何用户交互，它内部的滚轮滚动监听、ticker也会持续运行，不会自动暂停。用SingleChildScrollView+Column的写法会一次性渲染所有子组件，滚出屏幕的picker不会被回收，这些后台运行的回调不仅拖慢滚动，还会阻塞页面转场的动画调度，所以点击返回按钮时也会出现明显卡顿。
iOS真机上渲染调度优先级更高、渲染开销比模拟器大，因此卡顿表现会明显很多。

修复方案

按改造成本从低到高排序：

先删除两个CupertinoDatePicker上的key: UniqueKey()配置，这是当前代码里最直接的泄漏触发点，去掉后能缓解60%以上的卡顿，但不能完全解决后台ticker持续运行的问题。
不要把时间选择器常驻嵌在滚动页面里，这也是Flutter官方推荐的Cupertino选择器用法：把常驻的picker替换成普通的文本/按钮，用户点击时通过showCupertinoModalPopup弹出底部弹窗承载选择器，选完时间后自动关闭弹窗销毁组件，从根源上避免选择器长期挂在组件树里占资源。核心实现参考：

// 替换原来常驻的SizedBox+CupertinoDatePicker
SizedBox(
  width: MediaQuery.of(context).size.width * .9,
  height: MediaQuery.of(context).size.height * .2,
  child: TextButton(
    style: TextButton.styleFrom(
      backgroundColor: Colors.grey[200],
    ),
    onPressed: () async {
      final DateTime? res = await showCupertinoModalPopup(
        context: context,
        builder: (context) => SizedBox(
          height: 250,
          child: CupertinoDatePicker(
            use24hFormat: true,
            onDateTimeChanged: (DateTime newtime) {},
            initialDateTime: DateTime(2020, 3, 6, 8),
            maximumDate: DateTime(2020, 3, 6, 20),
            mode: CupertinoDatePickerMode.time,
          ),
        ),
      );
      // 此处处理选中的时间即可
    },
    child: const Text("点击选择时间"),
  ),
)

如果业务要求必须把选择器常驻在滚动页面内，做两个优化：
- 把根容器的SingleChildScrollView+Column换成ListView.builder实现懒加载，滚出缓存区域的组件会自动暂停渲染、释放不必要的回调资源。
- 给每个选择器加可视区域判断：当组件完全滚出屏幕时，用同等尺寸的占位组件替换CupertinoDatePicker，滚回可视区域时再渲染真实选择器，避免不可见状态下后台空跑。
临时规避方案：给常驻的CupertinoDatePicker添加physics: const NeverScrollableScrollPhysics()配置，禁用选择器自身的滚动响应，避免和外层滚动视图的手势识别冲突，这个方案效果有限，仅适合临时救急。

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