Flutter is rapidly becoming a go-to framework for creating applications of various scales. Google Trends and Stack Overflow confirm that Flutter has become a more popular search term than React Native for the last several years (seehttps://trends.google.com/trends/explore?q=%2Fg%2F11f03_rzbg,%2Fg%2F11h03gfxy9&hl=en andhttps://insights.stackoverflow.com/trends?tags=flutter%2Creact-native). Flutter consistently appears in various development ratings: the top 3 GitHub repositories by number of contributors (https://octoverse.github.com/2022/state-of-open-source), the top 3 most downloaded plugins in JetBrains Marketplace (https://blog.jetbrains.com/platform/2024/01/jetbrains-marketplace-highlights-of-2023-major-updates-community-news/), and second in Google Play Store ratings right afterKotlin (https://appfigures.com/top-sdks/development/apps).

This isn’t a surprise, since Flutter offers a delightful toolkit that allows developers to build smooth and pixel-perfect UIs almost immediately after their first encounter with the framework. Flutter also does a great job of hiding away the details of the rendering process. However, because it is so easy to overlook those details, a lack of understanding of how the framework actually works can lead toperformance issues.

This chapter explores the benefits of using Flutter’s declarative UI-building approach, as well as how that approach affects developers. We will discuss methods for optimizing performance and avoiding interference with the framework’s building and rendering processes. We will also examine how this approach works under the hood and provide best practices for creating beautiful andblazing-fast interfaces.

By the end of this chapter, you will understand the concept of the Flutter tree system and how to scope your widget tree for the best performance. This knowledge will provide the foundation necessary for learning architectural design patterns based on the framework’sbuild system.

In this chapter, we’re going to cover the followingmain topics:

• Understanding the difference between declarative and imperativeUI design.
• Everything is a widget! Oris it?
• Reduce,reuse, recycle!

The beauty of technology is that it evolves with time based on feedback about developer experience. Today, if you’re in mobile development, there is a high chance that you have heard about Jetpack Compose, SwiftUI, React Native, and of course Flutter. The thing these technologies have in common is both that they’re used for creating mobile applications and the fact that they do it via a declarative programming approach. You may have heard this term before, but what does it actually mean and why isit important?

To take full advantage of a framework, it’s important to understand its paradigm and work with it rather than against it. Understanding the “why” behind the architectural decisions makes it much easier to understand the “how,” and to apply design patterns that complement theoverall system.

Native mobile platforms have a long history of development and major transitions. In 2014, Apple announced a new language, Swift, that would replace the current Objective-C. In 2017 the Android team made Kotlin the official language for Android development, which would gradually replace Java. Those introductions had a hugely positive impact on the developer experience, yet they still had to embrace the legacy of existing framework patterns and architecture. In 2019, Google announced Jetpack Compose and Apple announced SwiftUI – completely new toolkits for building UIs. Both SwiftUI and Jetpack Compose take advantage of their respective languages, Swift and Kotlin, leaving legacy approaches behind. Both toolkits also loudly boast their declarative programming paradigm. But language advantages aside, let’s explore why declarative is now the industrial de facto and what is wrongwith imperative.

Understanding the imperative paradigm

By definition, the imperative programming paradigm focuses on how to achieve the desired result. You describe the process step by step and have complete control of the process. For example, it could result in code suchas this:

fun setErrorState(errorText: String) {    val textView = findViewById<TextView>(R.id.error_text_view)    textView.text = errorText    textView.setTextColor(Color.RED)    textView.visibility = View.VISIBLE    val button = findViewById<Button>(R.id.submit_button)    button.isEnabled = true    val progressView = findViewById<ProgressBar>(R.id.progress_view)    progressView.visibility = View.GONE}

In the preceding snippet, we imperatively described how to update the UI in case of an error. We accessed the UI elements step by step and mutatedtheir fields.

This is a real example of code that could’ve been written for a native Android application. Even though this approach may be powerful and gives the developer fine-grained control over the flow of the logic, it comes with the possibility of thefollowing problems:

• The more elements that can change their presentation based on a state change, the more mutations you need to handle. You can easily imagine how this simplesetErrorState becomes cumbersome as more fields need to be hidden or changed. The approach also assumes that there are similar methods for handling a progress and success state. Code such as this may easily become hard to manage, especially as the amount of views in your app grows and the state becomesmore complex.
• Modifying the global state can produce side effects. On every such change, we mutate the same UI element and possibly call other methods that also mutate the same elements. The resulting myriad of nested conditionals can quickly lead to inconsistency and illegal states in the final view that the user sees. Such bugs tend to manifest only when certain conditions are met, which makes them even harder to reproduceand debug.

For many years, the imperative approach was the only way to go. Thankfully, native mobile frameworks have since started adopting declarative toolkits. Although these are great, developers who need to switch between paradigms inside of one project can encounter many challenges. Different tools require different skills and in order to be productive, the developer needs to be experienced with both. More attention needs to be paid to make sure that the application that is created with various approaches is consistent. While the new toolkits are in the process of wider adoption, some time and effort are required until they are able to fully implement what their predecessors already have. Thankfully, Flutter embraced declarative fromthe start.

Understanding the declarative paradigm

In an imperative approach, the focus is on the “how.” However, in the declarative approach, the focus is on the “what.” The developer describes the desired outcome, and the framework takes careof the implementation details. Since the details are abstracted by the framework, the developer has less control and has to conform to more rules. Yet the benefit of this is the elimination of the problems imposed by the imperative approach, such as excessive code and possible side effects. Let’s take a look at thefollowing example:

Widget build(BuildContext context) {     final isError = false;     final isProgress = true;     return Column(      children: [        MyContentView(          showError: isError,        ),        Visibility(          visible: isProgress,          child: Center(            child: CircularProgressIndicator(),          ),        ),      ],    );}

In the preceding code, we have built a UI as a reaction to state changes (such as theisError orisProgress fields). In the upcoming chapters, you will learn how to elegantly handle the state, but for now, you only need to understandthe concept.

This approach can also be called reactive, since the widget tree updates itself as a reaction to a changeof state.

Does Flutter use the declarative or imperative paradigm?

It is important to understand that Flutter is a complex framework. Conforming to just one programming paradigm wouldn’t be practical, since it would make a lot of things harder (seehttps://docs.flutter.dev/resources/faq#what-programming-paradigm-does-flutters-framework-use). For example, a purely declarative approach with its naturalnesting of code would, make describing aContainer orChip widget unreadable. It would also make it more complicated to manage all oftheir states.

Here’s an excerpt from thebuild method of theContainer describing how to build the childwidget imperatively:

  @override  Widget build(BuildContext context) {    Widget? current = child;    // ...    if (color != null) {      current = ColoredBox(color: color!, child: current);    }    if (margin != null) {      current = Padding(padding: margin!, child: current);    }    // ...}

Even though the main approach of describing the widget tree can be viewed as declarative, imperative programmingcan be used when it feels less awkward to do so. This is why understanding the concepts, patterns, andparadigms is crucial to creating the most efficient, maintainable, andscalable solutions.

If you are coming from an imperative background, getting used to the declarative approach of building the UI may be mind-bending at first. However, shifting your focus from “how” to “what” you’re trying to build will help. Flutter can help you too, as instead of mutating each part of the UI separately, Flutter rebuilds the entire widget tree as a reaction to state changes. Yet the framework stillmaintains snappy performance, and developers usually don’t need to think aboutit much.

In the next section, let’s take a closer look at the abstraction to understandhow thewhat actually works. We will explore not only how to use the widgets as a developer but also how the framework efficiently handles them under the hood. We will cover what to do and what not to do to avoid interfering with the building andrendering processes.

You have probably heard this phrase many times. It has become the slogan of Flutter – in Flutter, everything is a widget! But what is a widget and how true is this saying? At first glance, the answer might seem simple: a widget is a basic building block of UI, and everything you see on the screen is a widget. While this is true, these statements don’t provide much insight into the internals ofa widget.

The framework does a good job of abstracting those details away from the developer. However, as your app grows in size and complexity, if you don’t follow best performance practices, you may start encountering issues related to frame drop. Before this can happen, let’s learn about the Flutter build system and how to make the mostof it.

What is a widget?

For most of our development, wewill create widgets that extendStatelessWidget orStatefulWidget. The following is the codefor these:

abstract class StatelessWidget extends Widget {...}abstract class StatefulWidget extends Widget {...}@immutableabstract class Widget {...}

From the source code, we can see that both of these widgets are abstract classes and that they inherit from the same class: theWidget class.

Another important place where we see theWidget class is in ourbuild method:

Widget build(BuildContext context) {...}

This is probably the most overridden method in a Flutter application. We override it every time we create a new widget and we know that this is the method that gets called to render the UI. But how often is this method called? First of all, it can be called whenever the UI needs an update, either by the developer, for example, viasetState, or by the framework, for example, on an animation ticker. Ultimately, it can be called as many times as your device can render frames in a second, which is represented by the refresh rate of your device. It usually ranges from 60 Hz to 120 Hz. This means that thebuild method can be called 60-120 times per second, which gives it 16-8 ms (1,000 ms / 60 frames-per-second = 16 ms or 1, 000 ms / 120 frames-per-second = 8 ms) to render the wholebuild method of your app. If you fail to do that, this will result in a frame drop, which might mean UI jank for the user. Usually, this doesn’t make users happy! But all developer performance optimizations aside, surely this can’t be what’s happening? Redrawing the whole application widget tree on every frame would certainly impact performance. This is not what happens in reality, so let’s find out how Flutter solvesthis problem.

When we look at theWidget class signature, we see that it is marked with an@immutable annotation. From a programming perspective, this means that all of the fields of this class have to befinal. So after you create an instance of this class, you can’t mutate any of its fields (collections are different but let’s ignore this for now and return to it inChapter 4). This is an interesting fact when you remember that the return type of ourbuild method isWidget and that this method can be called up to 120 times per second. Does that mean that every time we call thebuild method, we will return a completely new tree of widgets? All million of them? Well, yes and no. Depending on how you build your widget tree and why and where it was updated, either the whole tree or only parts of it get rebuilt. But widgets are cheap to build. They barely have any logic and mostly serve as a data class for another Flutter tree that we will soon observe. Before we move on to this tree though, let’s take a look at one specialtypeof widget.

Getting to know the RenderObjectWidget and its children

We have already discussed that when dealing with widgets, we mostly extendStatelessWidget andStatefulWidget. Inside thebuild method of our widgets, we only compose them like Lego bricks using the widgets already provided by the Flutter framework, such asContainer andTextFormField, or ourown widgets.

Most of the time, we only use thebuild method. Less often, we may use other methods such asdidChangeDependencies ordidUpdateWidget from theState object. Sometimes we may use our own methods, such as click handlers. This is the beauty of a declarative UI toolkit: we don’t even need to know how the UI we compose is actually rendered. We just use the API. However, in order to understand the intricacies of the Flutter build system, let’s think about it fora moment.

How many times have you usedSizedBox to add some spacing between other widgets? An interesting thing about this widget is that it extends neitherStatelessWidget norStatefulWidget. It extendsRenderObjectWidget. As a developer, you will rarely need to extend this widget or any other that containsRenderObjectWidget in its title. The important thing to know about this widget is that it is responsible for rendering, as the name suggests. Each child ofRenderObjectWidget has an associatedRenderObject field. TheRenderObject class is one of the three pillars of the Flutter build system (the first being the widget and the last being theElement, which we will see in the next section). This is the class thatdeals with actual low-level rendering details, such as translating user intentions ontothe canvas.

Let’s take a look at another example: theText widget. Here is a piece of code for a very simple Flutter app that renders theHello, Flutter text onthe screen:

void main() {  runApp(    const MaterialApp(      home: Text('Hello, Flutter'),    ),  );}

We use two widgets here: theMaterialApp, which extendsStatefulWidget, andText, which extends aStatelessWidget. However, if we take a deeper look inside theText widget, we will see that from itsbuild method, aRichText widgetis returned:

// Some code has been omitted for demo purposesclass Text extends StatelessWidget {  @override  Widget build(BuildContext context) {    return RichText(...);  }}class RichText extends MultiChildRenderObjectWidget {...}

An important difference here is thatRichText extendsMultiChildRenderObjectWidget, which is just a subtype of aRenderObjectWidget. So even though we didn’t do it explicitly, the last widget in our widget tree extendsRenderObjectWidget. We can visualize the widget tree, and it will look somethinglike this:

Figure 1.1 – Visual example of a widget tree

Even though you, as a developer, won’t be extendingRenderObjectWidget often, you need to rememberone takeaway!

This is important!

No matter how aggressively you compose your widget tree, the widgets that are actually responsible for the rendering will always extend theRenderObjectWidget class. Even if you, as a developer, don’t do it explicitly, you should know that this is what is happening deeper in the widget tree. You can always verify this by following the nesting of thebuild methods.

Let’s sum up whatwe’ve learned about thewidget types:

Table 1.1 – Widget differences

But if widgets are immutable, then who updates therender objects?

Unveiling the Element class

From thecreateRenderObject andupdateRenderObject we understand that renderobjects are mutable. Yet the widgets themselves that create those render objects are immutable. So how can they update anything, if they are recreated every time theirbuild methodis called?

The secret lies within theWidget API itself. Let’s take a closer look at some of its methods, startingwithcreateElement:

@immutableabstract class Widget {  Element createElement();}

The first method that should interest us iscreateElement, which returns anElement. The element is the last of the three pillars of the Flutter build system. It does all of the shadow work, giving the spotlight to the widget.createElement gets called the first time the widget is added to the widget tree. The method calls the constructor of the overridingElement, such asStatelessElement. Let’s take a look at what happens in the constructor of theElement class:

abstract class Element { Widget? _widget; Element(Widget widget)      :_widget = widget {...}}

We pass thewidget field as the parameter to the constructor and assign it to the local_widget field. This way, the Element retains the pointer to the underlying widget, yet the widget doesn’t retain the pointer to the element. The_widget field of the element is notfinal, which means that it can be reassigned. But when? The framework calls theupdate method of theElement any time the parent wishes to change the underlying widget. Let’s take a look inside theupdate methodsource code:

abstract class Element { void update(covariant Widget newWidget) {   _widget = newWidget; }}

As we can see, the pointer to the_widget field is changed tonewWidget, so the old widget is thrown away, yet our element stays the same. But in order for this reassignment to happen and for this method to be called, firstly thecanUpdate method of theWidget class is called. ThecanUpdate method checks whether theruntimeType andkey of the old and new widgets are the sameas follows:

abstract class Widget { static bool canUpdate(Widget oldWidget, Widget newWidget) {     return oldWidget.runtimeType == newWidget.runtimeType         && oldWidget.key == newWidget.key;   }}

Only if this method returnstrue, which means that theruntimeType andkey of the old and new widgets are the same, can we update our element with a new widget. Otherwise, the whole subtree will be disregarded and a completely new element will be inserted inthis place.

To better understand the flow of this process, let’s take a look at thefollowing diagram:

Figure 1.2 – Element relationship with the widget

The fact that the element can be updated instead of being recreated is even more important for the performance ofRenderObjectWidget, since it deals with render objects that do the low-level painting. In the update method ofRenderObjectElement, wealso callupdateRenderObject, which is a performance-optimized method: it only updates the render objects if there are any changes, and it only updates them partially. That’s why even though there may be many calls of the build method, it doesn’t mean that the whole tree getscompletely repainted.

Finally, let’s summarize everything we’ve learned about the Fluttertree system:

Table 1.2 – Summary of widget, Element, and RenderObject roles

As we have just seen, Flutter has some straightforward yet elegant algorithms that make sure your application runs smoothly and looks flawless. Unfortunately, it doesn’t mean that the developer doesn’t have to think about performance at all, since there are many ways the performance can be impacted negatively if the best practices are ignored. Let’s take a look at how we can support Flutter in maintaining a delightful experience forour users.

Now that we know that thebuild method can be called up to 120 times per second, the question is: do we really need to call thewholebuild method of our app if only a small part of the widget tree has changed? The answer is no, of course not. So let’s review how we can makethis happen.

First things first, let’s get one obvious but still important thing out of the way. Thebuild method is supposed to be blazing fast. After all, it can have as little as 8 ms to run without dropping frames. This is why it’s crucial to keep any long-running tasks such as network or database requests out of this method. There are better places to do that which we will explore in detail throughoutthis book.

Pushing rebuilds down the tree

There can be several situationswhen pushing the rebuilds down the tree can impact performance in apositive way.

Calling setState of StatefulWidget

One of the most used widgets isStatefulWidget. It’s a very convenient type of widget because it can manage state changes and react to user interactions. Let’s take a look at the sample app that iscreated every time you start a new Flutter project: the counter app. We are interested in the code of the_MyHomePageState class, which is theStateofMyHomePage:

class _MyHomePageState extends State<MyHomePage> {  int _counter = 0;  void _incrementCounter() {    setState(() { _counter++; });  }  @override  Widget build(BuildContext context) {    return Scaffold(      appBar: AppBar(        title: const Text('Flutter Demo Home Page'),      ),      body: Center(        child: Column(          mainAxisAlignment: MainAxisAlignment.center,          children: <Widget>[            const Text(              'You have pushed the button this many times:',            ),            Text(              '$_counter',              style: Theme.of(context).textTheme.headlineMedium,            ),            // In the original Flutter code the increment button is a            // FloatingActionButton property of the Scaffold,            // but for demonstration purposes, we need a slightly             // modified version            TextButton(              onPressed: _incrementCounter,              child: const Text('Increase'),            )          ],        ),      ),    );  }}

The UI is very simple. It consists of aScaffold with anAppBar and aFloatingActionButton. Clicking theFloatingActionButton increments the internal_counter field. The body of theScaffold is aColumn with twoText widgets that describe howmany times theFloatingActionButton has been clicked based on the_counter field. The preceding example differs from the original Flutter sample in one regard: instead of using theFloatingActionButton for handling clicks, we are using theTextButton. So every time we click theTextButton, the_incrementCounter method is called, which in turn calls thesetState framework method and increments the_counter field. Under the hood, thesetState method causes Flutter to call thebuild method of_MyHomePageState, which causes a rebuild. An important thing here is thatsetState causes a rebuild of the wholeMyHomePage widget, even though we are only changingthe text.

An easy way to optimize this is topush state changes down the tree by extracting them into a smaller widget. For example, we can extract everything that was inside theCenter widget ofScaffold into a separate widget and callitCounterText:

class _MyHomePageState extends State<MyHomePage> {  @override  Widget build(BuildContext context) {    return Scaffold(      appBar: AppBar(        title: const Text('Flutter Demo Home Page'),      ),      body: const Center(child: CounterText()),    );  }}class CounterText extends StatefulWidget {  const CounterText({Key? key}) : super(key: key);  @override  State<CounterText> createState() => _CounterTextState();}class _CounterTextState extends State<CounterText> {  int _counter = 0;  void _incrementCounter() {    setState(() { _counter++; });  }  @override  Widget build(BuildContext context) {    return Column(...// Same code that was in the original example );  }}

We haven’t changed any logic. We only took the code that was inside of theCenter widget of_MyHomePageState and extracted it into a separate widget:CounterText. By encapsulating the widgets that need to be rebuilt when an internal field changes into a separate widget, we ensure that whenever we callsetState inside of the_CounterTextState field, only the widgets returned from thebuild method of_CounterTextState get rebuilt. The parent_MyHomePageState doesn’t get rebuilt, because itsbuild method wasn’t called. We pushed the state changes down the widget tree, causing only smaller parts of the tree to get rebuilt, instead of the whole screen. In real-life app code, this scales very fast, especially if your pagesare UI-heavy.

Subscribing to InheritedWidget changes via .of(context)

By extracting the changing counter text into a separateCounterText widget in the last code snippet, we have actually made one more optimization. The interesting line for us isTheme.of(context).textTheme.headlineMedium. You have certainly usedTheme and other widgets, such asMediaQuery orNavigator, via the.of(context) pattern. Usually, those widgets extend a special type of class:InheritedWidget. We will look deeper into its internals in the state management part (Chapters 3 and4), but for now, we are interested in two ofits properties:

• Instead of creating thosewidgets, we will access them via static getter and use some of their properties. This means that they were created somewhere higher up the tree. Hence, we will inherit them. If they weren’t and we still try to look them up, we will getan error.
• For some of those widgets, such asTheme andMediaQuery, the.of(context) not only returns the instance of the widget if it finds one but also adds the calling widget to a set of its subscribers. When anything in this widget changes – for example, if theTheme was light and became dark – it will notify all of its subscribers and cause them to rebuild. So in the same way as withsetState, if you subscribe to anInheritedWidget, changes high up in the tree will cause the rebuild of the whole widget tree starting from the widget that you have subscribed in. Push the subscription down to only those widgets that actuallyneed it.

Extra performance tip

You may have usedMediaQuery.of(context) in order to fetch information about the screen, such as its size, paddings, and view insets. Whenever you callMediaQuery.of(context), you subscribe to the wholeMediaQuery widget. If you want to get updates only about the paddings (or the size, or the view insets), you can subscribe to thisspecific property by callingMediaQuery.paddingOf(context),MediaQuery.sizeOf(context), and so on. This is becauseMediaQuery actually extends a specific type ofInheritedWidget – theInheritedModel widget. It allows you to subscribe only to those properties that you care about as opposed to the whole widget, which can greatly contribute to widgetrebuild optimization.

Avoiding redundant rebuilds

Now that we’ve learned how to scope our trees so that only smaller sections are rebuilt, let’s find out how to minimize the amount of thoserebuilds altogether.

Being mindful of the widget life cycle

Stateless widgets are boring in terms of their life cycles. Stateful widgets, on the other hand, are not. Let’s take a look at the life cycle oftheState:

Figure 1.3 – Main methods of State life cycle

Here are a few things that we shouldcare about:

• TheinitState method gets called only once per widget life cycle, much like thedispose method.
• ThedidChangeDependencies method gets called immediatelyafterinitState.
• didChangeDependencies is always called when anInheritedWiget that we subscribed to has changed. This is the implementation aspect of what we have just discussed in theprevious section.
• The build method always gets called afterdidChangeDependencies,didUpdateWidget,andsetState.

This is important!

Don’t callsetState indidChangeDependencies ordidUpdateWidget. Such calls are redundant, since the framework will always callbuild afterthose methods.

The best performance practices in the preceding list are also the reason why it’s better to decouple your widgets into other custom widgets rather than extract them into helper methods such asWidget buildMyWidget(). The widgets extracted into methods still access the same context or callsetState, which causes the whole encapsulating widget to rebuild, so it’s generally recommended to prefer widget classes ratherthan methods.

One more important thing regarding the life cycle of theState is that once itsdispose method has been called, it will never become alive again and we will never be able to use it again. This means that if we have acquired any resources that hold a reference to thisState, such as text editing controllers, listeners, or stream subscriptions, these should be released. Otherwise, the references to these resources won’t let the garbage collector clean up this object, which will lead to memory leaks. Fortunately, it’s usually very easy to release resources by calling their owndispose orclose methods inside thedispose oftheState.

Caching widgets implicitly

Dart has a notion of constant constructors. We can create constant instances of classes by adding aconst keyword before the class name. But when can we do this and how can we take advantage of themin Flutter?

First of all, in order to be able todeclare aconst constructor, all of the fields of the class must be marked asfinal and be known at compile time. Second, it means that if we create two objects viaconst constructors with the same params, such asconst SizedBox(height: 16), only one instance will be created. Aside from saving some memory due to initializing fewer objects, this also provides benefits when used in a Flutter widget tree. Let’s return to ourElement classonce again.

We remember that the class has anupdate method that gets called by the framework when the underlying widget has changed its fields (but not type or key). This method changes the reference to the widget. Soon the framework calls rebuild. Since we’re working with a tree data structure, we will traverse its children. Unless your element is a leaf element, it will have children. There is a very important method in theElement API calledupdateChild. As the name says, it updates its children elements. But the interesting thing is how itdoes it:

#1 Element? updateChild(Element? child, Widget? newWidget,    Object? newSlot) {#2    // A lot of code removed for demo purposes#3#4    final Element newChild;#5    if (child.widget == newWidget) {#6        newChild = child;#7     } else if (Widget.canUpdate(child.widget, newWidget)) {#8        child.update(newWidget);#9        newChild = child;#10    }#11#12    return newChild;#13 }

In the preceding code, in case our current widget is the same as the new widget as determined by the== operator, we only reassign the pointer, and that’s it. By default, in Dart, the== operator returnstrue only if both of the instances point to the same address in memory, which istrue if they were created via aconst constructor with thesame params.

However, if the result isfalse, weshould check the already-familiarWidget.canUpdate. However, aside from reassigning the pointer to the new element, we also call itsupdate method, which soon causesa rebuild.

Hence, if we useconst constructors, we can avoid rebuilds of whole widget subtrees. This is also sometimes referred to as caching widgets. So useconst constructors whenever possible and see whether you can extract your own widgets that can make use ofconst constructors, even if nestedwidgets can’t.

Keep in mind that you have to actually use theconst constructor, not just declare it as a possibility. For example, we have aConstText widget that has aconst constructor:

class ConstText extends StatelessWidget {  const ConstText({super.key});  @override  Widget build(BuildContext context) {    return const Text('Hello World');  }}

However, if we create an instance of this widget without using theconst constructor via theconst keyword as in the following code, then we won’t get any of the benefits of theconst constructor:

// Don't!class ParentWidget extends StatelessWidget {  const ParentWidget({Key? key}) : super(key: key);  @override  Widget build(BuildContext context) {    return ConstText(); // not const!  }}

We need to explicitly specify theconst keyword when creating an instance of the class. The correct usage of theconst constructor lookslike this:

// Doclass ParentWidget extends StatelessWidget {  const ParentWidget({Key? key}) : super(key: key);  @override  Widget build(BuildContext context) {    return const ConstText(); // const, all good  }}

In the preceding code, we used theconst keyword during the creation of aConstText widget. This way, we will get all of the benefits. This small keyword isvery important.

Explicitly cache widgets

The same logic can be applied if the widget can’t be created with aconst constructor, but can be assigned to afinal field of theState. Since you’re literally saving the pointer to the same widget instance and returning it rather than creating a new one, it will follow the same execution path as the one we saw withconst widgets. This is one of the ways in which you can work around theContainer not beingconst. You might do so using the following,forexample:

class _MyHomePageState extends State<MyHomePage> {  final greenContainer = Container(    color: Colors.green,    height: 100,    width: 100,  );  @override  Widget build(BuildContext context) {    return Column(      children: [        greenContainer,        Container(          color: Colors.pink,          height: 100,          width: 100,        ),      ],    );  }}

In the preceding code, theupdate method of the green container won’t be called. We have retained the reference to an already-existing widget by caching it in a localgreenContainer field. Hence, we return the exact same instance as in the previousbuild. This falls into the case described on line 5 in theupdateChild method code snippet providedearlier in this section. If the instances are the same based on the equality operator, then theupdate method is not called. On the other hand, the pinkContainer will be rebuilt every time because we create a new instance of the class every time thebuild method is called. This is described in line 7 of the samecode snippet.

Avoiding redundant repaints

Up to this point, we have looked at tips to help you avoid causing redundant rebuilds of the widget and element trees. The truth is that the building phase is quite cheap when compared to the rendering process, as this is where all of the heavy lifting is done. Flutter optimizes this phase as much as possible, but it cannot completely control how we create our interfaces. Therefore, we may encounter cases where these optimizations are not enough or are notworking effectively.

Let’s take a look at what happens when one of the render objects wants to repaint itself. We may assume that this repainting is scoped to that specific object – after all, it was the only one marked for repaint. But this is notwhat happens.

The thing is, even though we have scoped our widget tree, our render object tree has a relationship of its own. If a render object has been marked as needing repainting, it will not only repaint itself but also ask its parent to mark itself for repaint too. That parent then asks its parent, and so on, until the very root. And when it finally comes to painting, the object will also repaint all of its descendants. This happens until the framework encounters what is known as arepaint boundary. A repaint boundary is a Flutter way of saying “stop right here, there is nothing further to repaint.” This is done by wrapping your widget into another widget – yes, theRepaintBoundary widget.

If we wanted to depict this flow visually, it would be somethinglike this:

Figure 1.4 – Flow of the render object’s repainting process

Here is what’s happening inFigure 1.4:

1. We start fromRenderObject #12, which was the initial one to be markedfor repainting.
2. The object goes on to callparent.markNeedsPaint ofRenderObject #10. Since theisRepaintBoundary field isfalse, theneedsPaint gets set totrue and goes on to ask the same forits parent.
3. TheisRepaintBoundary value ofRenderObject #5 istrue, soneedsPaint staysfalse and the parent marking is stoppedright there.
4. Then the actual painting phase is started from the top widget marked asneedsPaint. It traverses its children. SinceisRepaintBoundary ofRenderObject #11 isfalse, ittraverses further.
5. ButisRepaintBoundary ofRenderObject #15 istrue, so the process is stoppedright there.

So we end up repainting render objects #10, #11,and #12.

Let’s take a look at an example where aRepaintBoundary widget can be useful – in aListView. This is the simplified version of theListViewsource code:

class ListView {  ListView({      super.key,      bool addRepaintBoundaries = true,      ... // many more params  });  @override  Widget? build(BuildContext context, int index) {     if (addRepaintBoundaries) {       child = RepaintBoundary(child: child);     }     return child;  }}

TheListView constructor accepts anaddRepaintBoundaries parameter in its constructor, which by default istrue. Later, when building its children, theListView checks this flag, and if it’strue, the child widget is wrapped in aRepaintBoundary widget. This means that during scrolling, the list items don’t get repainted, which makes sense because only their offset changes, not their presentation. TheRepaintBoundary widget can be extremely efficient in cases where you have a heavy yet static widget, orwhen only the location on the screen changes such as during scrolling, transitions, or other animations. However, like many things, it has trade-offs. In order to display the end result on the screen, the widget tree drawing instructions need to be translated into the actual pixel data. Thisprocess is calledrasterization.RepaintBoundary can decide to cache the rasterized pixel values in memory, which is not limitless. Too many of them can ironically lead toperformance issues.

There is also a good way to determine whether theRepaintBoundary is useful in your case. Check thediagnosis field of itsrenderObject via the Flutter inspector tools. If it says something along the lines ofThis is an outstandingly useful repaint boundary, then it’s probably agood idea tokeep it.

Optimizing scroll view performance

There are two important tips for optimizing scrollview performance:

• First, if you want to build a list of homogeneous items, the most efficient way to do so is by using theListView.builder constructor. The beauty of this approach is that at any given time, by using theitemBuilder callback that you’ve specified, theListView will render only those items that can actually be seen on the screen (and a tiny bit more, as determined by thecacheExtent). This means that if you have 1,000 items in your data list, you don’t need to worry about all 1,000 of them being rendered on the screen at once – unless you have set theshrinkWrap propertytotrue.
• This leads us to the second tip: theshrinkWrap property (available for various scroll views) forces the scroll view to calculate the layout of all its children, defeating the purpose of lazy loading. It’s often used as a quick fix for overflow errors, but there are usually better ways to address those errors without compromising performance. We’ll cover how to avoid overflow errors while maintaining performance in thenext chapter.

In this chapter, we explored the relationships between theWidget,Element, andRenderObject trees. We learned how to avoid rebuilds of theWidget andElement trees by scoping theStatefulWidgets and subscriptions to inherited widgets, as well as by caching the widgets viaconst constructors andfinal initializations. We also learned how to limit repaints of the render object subtrees, as well as how to effectively work withscroll views.

InChapter 2, we will explore how to make our already performant interfaces responsive on the ever-growing set of devices. We will cover how sizing and layout work in Flutter, how to fix overflow errors, and how to ensure that your application is usable forall users.