How does the Widget Lifecycle work in Flutter?

Question

To optimize the performance of a Flutter App it's important to only rebuild Widgets when it's actually needed to rebuild them. Between using const Widgets, the TransitionBuilder pattern, Keys and overwritten the == operator there seem to be different approaches to reduce Widget rebuilds, but I have no good idea of how the interact.

The official documentation suggests to do as little work as possible in build methods. How does that compare to work done in the constructor of the Widget? Does the constructor get called as often as the build function, more then it or less then it? If I have a Stateful Widget can I improve performance by caching some data in the state instead of in the constructor or build method?

On Reddit there's a discussion about using functions vs. Stateless Widgets where some people argue that Stateless Widgets cause less rebuilds and others that there's no difference. I would like to understand Flutter's Widget Lifecycle well enough to understand whether in a particular case there's a difference between the two or there isn't.

I'm looking for an explanations of how those different mechanisms interact to make good decisions about how to reduce unnecessary Widget builds in my app.

Answer 1

Not every rebuild is expensive as you may think

This question bugged me a lot in the past :) until you realize that widgets is not the whole story . It is just the tip of the iceberg! . For every widget object there actually two other objects associated with it first is element the other one is called render you can consider widgets as just configuration objects when widgets destroyed and then created this in itself is not expensive what is expensive is the creation of the render object , fortunately the render objects is not reconstructed with every build until it is needed so it is compared and re associated with the new widget in a very efficient and smart way that is why flutter is so performant out of the box . Hope that help, I will be more than happy to clarify more if needed.

Answer 2

Rather the me butchering a nice explanation from the developers themselves, here is a short clip explaining the widget lifecycle

A more detailed explanation was made in 2019 At Google Developer Days China

If you talk about performance, the functional approach is better. Consider this:

class TestWidget extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    final streamController = StreamController<String>.broadcast();

    Future.delayed(Duration(seconds: 3)).then((_) {
      streamController.sink.add('new value to received');

      streamController.close();
    });

    return StreamBuilder(
      stream: streamController.stream,
      builder: (BuildContext context, AsyncSnapshot<String> snapshot) {
        final newVal = snapshot.data;
        return Text(newVal ?? 'this is initial value');
      },
    );
  }
}

In a functional approach the state is held not by the widget but by the streamController, and the TestWidget's build method is called only once, and the builder block is called every time there is a new event inside the stream.

I find this approach the most flexible to develop also, since you can have multiple streams in one place and as a puppeteer control them all.

==== A small tangent =====================================================

I suggest you looking into that the BLoC pattern.

From my experience, if you fanatically follow one approach over the other you could end up "hurting yourself", so i'll suggest to not be afraid to use both, depending on the use-case.

For example if you have a button with an incrementing int value inside it (like a badge), and when you tap it increments. Sending the value to the BLoC and persisting it there, then sending an event through the stream back to update the UI is overkill, this is where i would use a StatefulWidget.