A Crucial Performance Fundamental I Wish I’ve Learned Sooner in Flutter
If being asked to name one thing that I wish I’ve known sooner in Flutter, it would definitely be the art of state management, of which importance grows significantly as your app develops. It could have an enormous impact on the overall performance, if not being handled properly, a hard lesson learned speaking from own experiences.
Let me explain why:
The well-known Stateful Widget helps you manipulate UI according to the change of state, which subsequently triggers a re-rendering of the widget, a very simple work flow. However, an often overlooked fact is that we build apps under the structure of multiple widget trees, where data is shared in complexity within. Passing down variables to child widgets could be a normal practice for new comers. The app could look like this:
When assigning a new value to Variable 4, Widget F is re-rendered as expected, just one, easy peasy. But what if changing the value inside the mother widget such as Variable 2? It might shock you that every single widget extended from the mother will be re-rendered, 6 widgets in sum, even the widgets totally unrelated to Variable 2 (B, D, E and F). Not to mention, widget trees in reality are usually more complicated. A rendering of the whole tree could cause a serious suffering on performance.
This is when the importance of state management shines and should be urgently considered from the start of the development, if your app is going to scale. There are 3 disciplines I hold on making sure that states are properly managed:
✖ Cautious When Using setState()Develop not merely code but also the consciousness towards it. Every time when using setState(), ask the question of how broad the impact could be and how many widgets would be affected and possibly pended to re-rendering.
✖ The Use of constA prefix that could deliver an immense win of efficiency. Assigning this powerful keyword to a widget basically tells Flutter that this widget does not change and will always stay constant. When a re-render is triggered from a mother widget, Flutter will NOT re-render any const children beneath it. Take a close look at the previous example:
Here, we are able to assign const to D and F that do not have a relation to their parents. Now, a re-render from the mother widget will skip these two reducing the original amount from 6 to 4.
✖ The Use of Data Providers
The most advanced strategy would be relocating variables to a data provider eliminating the dependency between widgets and also making variables accessible to any widgets down to the widget tree. A look at the previous model with a data provider:
Here, we do not pass down any variables. Instead, they are given from the data provider breaking the bounds of dependency. Each widget can now be defined as const type. Let’s apply a change to Variable 2 same as the previous examples. This time, only Widget A and C, that contain the variable, will be re-rendered further reducing the render amount from 6 to merely 2 or even not the 2 whole widgets (see the example below).
Aside from the native Provider() and Consumer(), there are several other powerful state management libraries such as Bloc and Riverpod worth checking out.
Overall, the best to handle states seems to be the last, but it should always be weighted based on individual cases to flexibly apply the mixture of them all. Building an app with a conscious management over states from the beginning is really the key to the optimal performance and spares lots of time on reworking it, which I greatly wish every new comer can acknowledge sooner. And now you do :)
These might interest you as well:
