Flutter 动画先分清卡在哪一帧Flutter 卡顿不能靠感觉判断。用 DevTools 录制目标操作先分辨是 UI 线程的 build/layout 太重还是 Raster 线程的绘制太重。两边的处理方式不同过早加RepaintBoundary经常只是换了一个难解释的层级。把重绘边界放在有证据的地方RepaintBoundary适合把频繁变化、又不需要带动周边重绘的区域隔开。它会引入图层和内存开销因此需要在录制结果里确认收益。图片解码、模糊和大面积透明层通常也值得单独检查。return RepaintBoundary( child: AnimatedBuilder( animation: controller, builder: (_, child) Transform.scale(scale: value, child: child), child: const Artwork(), ), );日志留给定位不留给猜测性能记录写清设备类别、构建模式、操作步骤和 trace 位置即可。不要把用户输入、页面内容或设备标识塞进日志。修复后重新跑同一条路径并观察首次进入和滚动后的表现只看一个平均值很容易掩盖偶发慢帧。在同一条 trace 里把首屏、第一次触发动画和连续触发三次的结果分开看。首帧慢常与资源准备有关连续卡顿更可能来自每帧重复创建对象或昂贵的绘制指令。两类问题不能用同一个补丁处理。改完后保留前后的录制链接和改动范围后续遇到回归才知道该从哪里检查。先缩小一次慢帧的范围看到红帧后不要立刻把整个组件拆开。先在 DevTools 中定位那一帧的 UI 和 Raster 耗时再回到对应的 widget 树看哪些部分真的发生了 rebuild。若只是一个数值变化却让包含图片、标题和按钮的整张卡片都重建可以把变化收窄到AnimatedBuilder的 builder 内并把不变的 child 传进去。若 UI 线程很轻而 Raster 很重就该检查裁剪、阴影、透明叠层和图片尺寸而不是继续优化状态管理。列表或页面切换时还要区分 debug 与 profile、release 模式。debug 下的性能现象可以帮助发现逻辑错误但不能拿来估算发布后的帧时间。资源首次解码、字体首次加载也会制造偶发慢帧预热是否值得做要看它是否改善用户真正会遇到的第一次操作而不是只让跑分更漂亮。动画结束后也要检查有些问题不发生在动画中而发生在结束后controller 没停、定时器还在跑、缓存图片没有释放页面看似静止却持续消耗资源。退出页面和快速重复进入是必要的验证动作。对于可滚动内容检查离屏区域有没有无谓的动画和重绘对于复杂插画确认它是否在不动时可以被缓存为稳定图层。优化时一次只改一个假设并重新录制同一条操作。这样即使结果变差也能清楚知道是哪个改动造成的。性能工作最怕把多个小补丁同时叠上去最后既难回退也难解释为什么某台设备仍然不顺。如果某项优化只改善极端设备也应写明它是否增加了代码复杂度或内存。比如预缓存图片能降低第一次动画的抖动却可能拉长首屏加载拆分 widget 能缩小 rebuild又可能让状态流转难读。没有免费优化取舍要回到具体用户路径。团队保留一份简短的性能决策记录下一次看到类似 trace 时就不会重复尝试已经证明无效的方案。不要把 profile 结论复制到所有页面。每个页面的资源、布局和交互不同复用的是排查方法不是某条固定补丁。性能修复进入发布说明时写明观察到的现象和验证操作。这样客服或测试收到相近反馈时能快速判断是否属于已知范围而不是只看到一个抽象的优化标题。