Flutter中CustomPainter的paint方法多次触发的原因及单次调用实现方案

触发原因 #

• shouldRepaint的作用范围远小于开发者的普遍认知
  很多人误以为shouldRepaint返回false就能完全阻止paint调用，实际上这个方法仅负责判断当传入CustomPaint的painter对象被替换为新实例时，要不要走重绘流程，根本无法拦截框架本身必须执行的绘制动作：
  • 组件第一次挂载到渲染树时，必然会执行一次paint，这是框架的基础流程，无法通过自定义逻辑拦住
  • 只要渲染树被标记为脏区域——比如鼠标悬停触发按钮的高亮变化、页面旋转/尺寸调整、内容被临时覆盖后重新露出、窗口切前台的焦点变化——Flutter都会对涉及的渲染节点强制走一遍绘制逻辑，和shouldRepaint返回值是true还是false无关
  • 当前代码中shouldRepaint永远返回false，仅能挡住“painter实例更换时要不要重绘”这个环节的判断，对系统触发的paint调用完全起不到拦截作用
• 频繁重建对象会放大无效重绘的概率
  代码在build方法中每次都会直接实例化新的ColorCircle传给CustomPaint，哪怕两个对象存储的颜色完全一致，框架也会将其识别为配置变更，进入重绘判断流程，变相增加了不必要的paint触发次数。

优化调整 #

• 修正shouldRepaint的判断逻辑，不要硬返回false
  原实现会导致哪怕颜色真的发生变化，框架也可能因为判断逻辑不对跳过重绘。正确的写法是对比新旧painter的实际属性，仅当颜色真正变化时才允许触发重绘：

  @override
  bool shouldRepaint(covariant ColorCircle oldDelegate) {
    return oldDelegate.myColor != myColor;
  }
  

• 缓存painter实例，不要在build方法中随意新建对象
  直接在State中把painter对象存为成员变量，只有当颜色真正变化时，才生成新的painter实例：

  // 缓存painter实例，初始值和当前颜色绑定
  late var _circlePainter = ColorCircle(myColor: actualColor);
  
  // 点击按钮切换颜色时，先判断颜色真的变更再执行更新
  void _changeColor(MaterialColor targetColor) {
    if (targetColor == actualColor) return;
    setState(() {
      actualColor = targetColor;
      _circlePainter = ColorCircle(myColor: targetColor);
    });
  }
  

  这样哪怕build因为无关原因被触发——比如按钮内部处理悬停状态、系统发出窗口重绘要求——传给CustomPaint的始终是同一个painter对象，配合正确的shouldRepaint逻辑，框架会直接跳过自定义paint流程，不会执行绘制方法里的日志和绘制逻辑。
• 明确预期：完全做到paint仅调用1次是不现实的，毕竟Flutter的绘制机制本身就会在需要的时候走基础流程。这些调整的核心目标，是消除所有因为代码逻辑不当导致的非必要paint调用，仅在颜色真正变更时才触发一次实际绘制。

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