Performance And Rendering
Flutter performance work starts with measurement, then rebuild scope, layout cost, rasterization cost, memory, app size, and target-specific rendering behavior.
Performance Stack
| Layer | What to watch |
|---|---|
| Dart code | CPU work, JSON parsing, sync IO, allocations |
| Widget rebuilds | Rebuild scope, unstable keys, expensive build() methods |
| Layout | Intrinsic passes, unbounded constraints, giant lists |
| Paint/raster | Opacity, clipping, saveLayer, shadows, images |
| Engine/renderer | Impeller/Skia/web renderer behavior by target |
| Package size | Assets, fonts, native libraries, deferred loading |
Frame Discipline
If a frame budget is 16ms, expensive work cannot happen casually during user interaction. Move CPU-heavy work out of build(), split widget subtrees, cache derived values, and profile before optimizing.
Impeller Position
The official docs checked during this run describe Impeller as the default renderer for iOS and Android API 29+ in current Flutter docs, with target-specific caveats. Treat renderer facts as versioned and re-check before making hard claims.
Gotcha: Performance advice ages quickly. Re-check current Flutter performance and renderer docs when the app’s Flutter version changes.