“This is the 30th day of my participation in the Gwen Challenge in November. See details: The Last Gwen Challenge in 2021”

Widgets in Flutter, like activities in Android and UIViewController in iOS, have a life cycle. The life cycle is called back functions that let us know the status of the Widget.

The role of life cycle

Different lifecycle callbacks are executed when the Widget is in different time states, and we can do different things in these callbacks:

• Initialize data
  • Creation of variables and constants
  • Sending network requests
• Listening to theWidgetIn the event
• Memory management
  • Destruction of data or listeners
  • The timerTImerThe destruction of

The Widget’s life cycle

As we all know, there are two types of Flutter widgets: stateful and stateless. Stateful widgets are significantly more complex than stateless widgets. Will their lifecycle be different?

Life cycle of the StatelessWidget

We load a simple StatelessWidget page on the interface and pass the title value to the page:

The LessLifeCycleDemo constructor (title: “Stateless Widget life cycle “), and build is the method called when the Widget is rendered; We add print information to two methods:

This is the life cycle of the StatelessWidget, which is relatively simple; Let’s focus on the life cycle of StatefulWidget;

The life cycle of StatefulWidget

We write the following code to add print information to our known lifecycle methods:

The final print order is as follows:

Then click the plus button:

When the setState method is called, only the build method is triggered;

At present, there are few lifecycle functions we use. In addition to the current ones, there are other lifecycle functions:

• didChangeDependencies(): whenStateObject dependencies that change are called; A typical scenario is when the system language changes or the theme changes,FlutterThe framework will tell youWidgetCall this callback;
• reassemble(): This callback only takes effect during development debugging, during hot overloadinghot reloadIs called atReleaseNever callback in mode;
• didUpdateWidget()In:WidgetWhen you rebuild,FlutterThe framework will callwidget.canUpdateTo detectWidgetThe old and new nodes in the same position in the tree, and then determine whether to update if returnedtrue, the callback is called;
  • widget.canUpdateIn the old and newwidgetthekeyandruntimeTypeReturns when both are equaltrue; We’ll talk about this later in the rendering principles;
• deactivate(): whenStateThis callback is called when an object is removed from the tree; In some cases,FlutterThe framework willStateObject is re-inserted into the tree, such as containing thisStateObject’s subtree moves from one position in the tree to anotherGlobalKeyTo achieve).
  • If it is not reinserted into the tree after removal, it is called directlydispose()Methods to destroy;

The scenario that triggers the build method

We all know that the build method is called when building the render Widget. The build method triggers the following:

• callinitState()after
• calldidUpdateWidget()after
• callsetState()after
• calldidChangeDependencies()after
• theStateCalled after the object is removed from a position in the treedeactivate()), and reinserts after the rest of the tree

SetState triggers the nature of the build

We all know that calling the setState method triggers the build method, so why is the build method executed? Let’s look at the source of setState:

We can see that the most important implementation of the setState method is _element! .markNeedsBuild() method, the markup needs to be rendered; So what is _element? We can see from the above code:

_Element is essentially BuildContext, so can we trigger build by calling markNeedsBuild using context directly? We modify the code as follows:

Running results:

The build method is fired;

A bug in Android Studio

Normally, the life cycle information we print in the compiler is executed only once. For example, when we hot reload, the method is executed as follows:

However, when we re-execute the project, the following situation occurs:

The lifecycle method is called twice. This is a bug in Android Studio, which we can verify with Xcode. Running the project directly in Xcode does not cause this: