Workflow to nudge users to fix common initState and build anti-patterns

[jacob314]

There is existing tooling to trace all widget build times in the performance page but it requires users to know it exist, know when to use it, and search through the flame chart for actionable data.

Instead we should prompt users when they should enable the functionality, and surface when there are build times that are slow enough to be considered anti-patterns.

Suggested flow:

1. Surface warnings in DevTools suggesting that users enable trackWidgetBuilds whenever the widget build time was measured to be above some threshold.
2. When trackWidgetBuilds is enabled, surface warnings when specific widget build times are above some threshold (in profile mode). Warnings could be for both inclusive (includes subtree) and exclusive (widget only) build times. For example, a widget that does expensive HTML parsing could show an expensive exclusive build time. Inclusive build times could be skewed by reasonable widgets that just happen to render a very large amount of complex content.

Open questions:

1. Do we need to disambiguate excessive time spent in initState or just build methods?
2. Are the exclusive cases better covered by the existing bottom up view of the cpu profiler view?
3. Should we seek tooling that works on the command line to warn about very slow build methods even without launching DevTools?

[srawlins]

The "Frame analysis" tab on the Performance screen now implements the workflow proposed here. When you select a frame, DevTools identifies the longest UI phase (build, layout, or paint) and surfaces a hint prompting you to enable the corresponding tracing option ("Track widget builds", "Track layouts", "Track paints") and reproduce the behavior, with a button to toggle that option inline. See frame_hints.dart. There are additional hints for intrinsic operations, saveLayer calls, and shader compilation jank.

Since the core ask here (prompting users to enable trackWidgetBuilds rather than expecting them to know it exists and to hunt through the flame chart) is covered by that feature, closing this out.

If there is more work to do here, please let us know by filing a new issue with up to date information. Thanks!