Const Constructors vs Runtime Instantiation: When to Prioritize Immutable Widgets

Answer

Using const constructors can reduce frame‑time overhead in Flutter 3.x, but only when the widget subtree is composed entirely of compile‑time constants. If any field depends on runtime data or the subtree reads an InheritedWidget that may change, the const instance will not rebuild and can cause stale UI.

Confirmed Facts

• A const widget is created once at compile time and reused across rebuilds, skipping the widget‑creation and layout passes for that subtree.
• All constructor parameters must be final and have values known at compile time (literals, other const objects, or static const fields).
• If a const widget references an InheritedWidget (directly or indirectly) whose value can change, the widget will not receive the update because the same instance is reused.
• Flutter’s DevTools Performance tab and the performance overlay (debugShowPerformanceOverlay: true) can measure frame‑time differences when the rest of the app is held constant.

Likely Explanation

The performance gain comes from avoiding the allocation, initialization, and layout of the widget subtree on each frame. In deep or frequently rebuilt trees (e.g., large lists, grids, or custom paint hierarchies) this can shave a few milliseconds off the frame budget. In shallow trees the effect is usually negligible because the overhead of widget creation is already small.

Steps to Verify Frame‑Time Improvement

1. Identify a widget subtree that is rebuilt often and whose constructor arguments are all compile‑time constants (e.g., static icons, static text, fixed sizes).

2. Wrap that subtree with a const constructor:

   const MyConstantSubtree(
     Key? key,
   ) : super(key: key);
   

3. Run the app in profile mode (flutter run --profile) and enable the performance overlay:

   MaterialApp(
     debugShowPerformanceOverlay: true,
     home: MyHomePage(),
   );
   

4. Record the average frame time (ms) shown in the overlay for a stable interval (e.g., 10 seconds).

5. Remove the const qualifier, rebuild, and repeat the measurement under identical conditions.

6. Compare the two averages; a consistent reduction indicates a measurable benefit.

When const Widgets Fail to Rebuild

A const widget will not rebuild if:

• Its parent state changes but none of the const widget’s fields change (the instance is reused).
• The widget subtree reads an InheritedWidget whose value can change; because the same instance is reused, the new value is ignored, leading to stale UI.

Systematic DevTools Approach to Detect Stale UI

1. Enable the "Widget Inspector" in DevTools and turn on "Highlight updates" to see which widgets rebuild each frame.
2. Interact with the UI to trigger a change in the suspected InheritedWidget (e.g., toggle a theme, change locale).
3. Observe whether the const subtree receives a highlight. If it does not, the widget is likely stale.
4. Optionally, add a temporary print or logger in the widget’s build method to confirm it is not being called.

Missing Diagnostic Detail

To decide whether to apply const safely, we need to know: Does the widget subtree (or any of its descendants) depend on an InheritedWidget whose value can change at runtime? If the answer is yes, const should be avoided or the subtree should be split so that only the truly constant parts are const.