Isolating and reducing excessive widget rebuilds

What's really being asked

Whether you can distinguish the build, layout and paint phases and apply targeted techniques to shrink the blast radius of a state change.

The full answer

First diagnose with the DevTools performance view and the rebuild profiler to see which widgets rebuild and how often. Then reduce scope. Push state down so setState lives in the smallest widget that owns it, not a high ancestor. Mark unchanging subtrees as const so they are skipped during rebuilds. For a single value, use ValueListenableBuilder or, with Provider, Selector, so only the builder closure rebuilds rather than the parent. Pull expensive painting, like a chart or shader, behind a RepaintBoundary so the compositor caches its layer and a neighbor's repaint does not invalidate it. Use builders like ListView.builder for lazy construction.

The mistakes people make

Wrapping the entire tree in RepaintBoundary, which costs memory and composition without targeting the cause. Confusing a rebuild, which is element work, with a repaint, which is canvas work. Using setState at the top of the screen for a tiny toggle. Believing const is purely cosmetic.

What usually comes next

What exactly does RepaintBoundary isolate versus ValueListenableBuilder. How does const cut rebuilds. When does a rebuild not cause a repaint. How do you measure improvement.

A concrete example

A dashboard rebuilds the full screen each second to update one clock label, dragging a heavy chart along. The fix wraps the clock in a ValueListenableBuilder driven by a ValueNotifier so only the label rebuilds, marks the static header const, and wraps the chart in a RepaintBoundary so its cached layer survives the label updates. Frame times drop because the costly subtree no longer participates in the per-second update.