Generally, Flutter applications are performant by default, so you only need to avoid common pitfalls to get excellent performance instead of needing to micro-optimize with complicated profiling tools. These best recommendations will help you write the most performant Flutter app possible.
How do you design a Flutter app to most efficiently render your scenes? In particular, how do you ensure that the painting code generated by the framework is as efficient as possible? Here are a few things to consider when designing your app:
Call setState thoughtfully
- Avoid repetitive and costly work in
build()can be invoked frequently when ancestor Widgets rebuild.
- Localize the
setState()call to the part of the subtree whose UI actually needs to change. Avoid calling setState() high up in the tree if the change is contained to a small part of the tree.
- When a widget rebuilds, but the build stops a child from rebuilding, reuse the same child widget.
Apply effects only when needed
Use effects carefully, as they can be expensive. Some of them invoke
saveLayer() behind the scenes, which can be an expensive operation.
Some general rules when applying specific effects:
- Use the Opacity widget only when necessary. See Transparent image in the Opacity API page for an example of applying opacity directly to an image, which is faster than using the Opacity widget.
Clipping doesn’t call
saveLayer()(unless explicitly requested with
Clip.antiAliasWithSaveLayer) so these operations aren’t as expensive as Opacity, but clipping is still costly, so use with caution. By default, clipping is disabled (
Clip.none), so you must explicitly enable it when needed.
Other widgets that may trigger
saveLayer() and are potentially costly:
cause call to
disabledColorAlpha != 0xff
cause call to
saveLayer()if there’s an
Ways to avoid calls to
- To implement fading in an image, consider using the FadeInImage widget, which applies a gradual opacity using the GPU’s fragment shader. For more information, see Opacity.
- To create a rectangle with rounded corners, instead of applying a
clipping rectangle, consider using the
borderRadiusproperty offered by many of the widget classes.
Render grids and lists lazily
Use the lazy methods, with callbacks, when building large grids or lists. That way only the visible portion of the screen is built at startup time.
- Working with long lists in the Cookbook
- Creating a ListView that loads one page at a time by AbdulRahman AlHamali
- Listview.builder API
Build and display frames in 16ms
Since there are two separate threads for building and rendering, you have 16ms for building, and 16ms for rendering on a 60Hz display. If latency is a concern, build and display a frame in 16ms or less. Note that means built in 8ms or less, and rendered in 8ms or less, for a total of 16ms or less. If missing frames (jankyness) is a concern, then 16ms for each of the build and render stages is OK.
If your frames are rendering in well under 16ms total in a profile build, you likely don’t have to worry about performance even if some performance pitfalls apply, but you should still aim to build and render a frame as fast as possible. Why?
- Lowering the frame render time below 16ms may not make a visual difference, but it will improve battery life and thermal issues.
- It may run fine on your device, but consider performance for the lowest device you are targeting.
- When 120fps devices become widely available, you’ll want to render frames in under 8ms (total) in order to provide the smoothest experience.
If you are wondering why 60fps leads to a smooth visual experience, see the video Why 60fps?
If you need to tune your app’s performance, or perhaps the UI isn’t as smooth as you expect, the Flutter plugin for your IDE can help. In the Flutter Performance window, enable the Show widget rebuild information check box. This feature helps you detect when frames are being rendered and displayed in more than 16ms. Where possible, the plugin provides a link to a relevant tip.
The following behaviors might negatively impact your app’s performance.
Avoid using the
Opacitywidget, and particularly avoid it in an animation. Use
FadeInImageinstead. For more information, see Performance considerations for opacity animation.
When using an AnimatedBuilder, avoid putting a subtree in the builder function that builds widgets that don’t depend on the animation. This subtree is rebuilt for every tick of the animation. Instead, build that part of the subtree once and pass it as a child to the AnimatedBuilder. For more information, see Performance optimizations.
Avoid clipping in an animation. If possible, pre-clip the image before animating it.
Avoid using constructors with a concrete List of children (such as
ListView()) if most of the children are not visible on screen to avoid the build cost.
For more performance info, see the following resources: