跨端界面 列表动画：缩小重建范围，比堆优化更有效

列表动画先守住状态归属

列表项滑出屏幕后又回来，最容易混乱的是动画控制器和业务状态被谁持有。筛选、分页或排序发生时，仍在屏幕上的项应继续使用自己的状态，新建项才初始化；把整个列表当成一个动画容器重置，肉眼看到的就是闪回和跳动。

性能排查可以从一次操作的重建范围开始。打开调试标记，看是哪一层因为一条数据变化而被重新布局；若图片解码或阴影绘制占时，再分别处理。RepaintBoundary 适合隔开稳定且昂贵的子树，放在每个节点上反而可能增加内存和合成成本。先缩小无关重建，通常比堆开关更有效。
Flutter 列表滑动发涩，常见原因不是框架“渲染慢”，而是动画回调触发了过大的 widget 子树重建。先在 Profile 模式看 DevTools 的 frame chart，确认是 build、layout、raster 还是图片解码占用了帧时间，再决定改哪里。

状态放在真正变化的地方

滚动位置、单个卡片的展开状态和页面主题不该共用一次 setState。把卡片局部状态下沉到卡片，或让 ValueListenableBuilder 只包住会改变的片段；列表本身使用 ListView.builder，让屏幕外子项延后创建。

class FavoriteButton extends StatelessWidget {
  const FavoriteButton({super.key, required this.selected});
  final ValueNotifier<bool> selected;

  @override
  Widget build(BuildContext context) {
    return ValueListenableBuilder<bool>(
      valueListenable: selected,
      builder: (_, value, __) => IconButton(
        onPressed: () => selected.value = !value,
        icon: Icon(value ? Icons.favorite : Icons.favorite_border),
      ),
    );
  }
}

RepaintBoundary 不是万能开关

RepaintBoundary 可以把频繁绘制的区域隔开，避免它影响相邻的静态内容；但它也可能新增图层和缓存开销。适合放在独立、持续重绘且面积有限的图表或动画上，不适合把整个长列表包起来。

动画由 AnimationController 驱动时，使用 AnimatedBuilder 或 CustomPainter(repaint: controller)，不要在每一帧调用页面级 setState。对不变的结构补 const 是清晰的优化；不要为了常量化而让代码难读。

最后在低端测试设备、真实列表长度和图片资源下复测。性能优化不是一次性打补丁，数据变大、动效变多后，原来的边界仍可能失效。

动画与数据变化解耦

列表刷新时，数据标识应决定哪个元素延续状态，而不是数组下标。否则插入一条记录就可能让其他项继承错误的动画进度。把进入、离开和重排分别处理，性能问题会更容易定位；某一项卡顿时，也不必把整列都重新创建。

实施时不必把这件事做成一套庞大的流程。先挑一个真实页面或一个典型操作，从输入变化开始观察，到用户看到的结果结束；中间记录发生的状态转换和异常分支。若结果与预期不同，先回到最近的一次可解释变化，不要一边改样式一边改数据和交互。每次只收敛一个原因，问题会比一次性堆优化更容易消失。

代码也要给后续修改留出口。把临时兼容、设备差异和资源降级放在明确的边界处，避免散落在多个回调里。完成后删掉已经失效的开关和注释，保留少量能说明取舍的测试或示例。这样的实现不一定最炫，但在下一次需求变动时，维护者能知道该改哪里、哪些行为不能碰。

若这次改动涉及旧页面，保留一个短暂的对照入口即可。新旧表现出现差异时，先比较数据、布局规则和事件顺序，再决定是否保留兼容；不要因为一处偶发现象就把已经简化的实现重新复杂化。

列表排序和筛选同时发生时，确认每个项仍以稳定标识关联到自己的状态。这样新增数据不会让正在播放的过渡错落到另一条记录上。