Flutter State Lifecycle

import 'package:flutter/material.dart';
import 'dart:async' show Future;
import 'package:flutter/services.dart' show rootBundle;
import'package:flutter/rendering.dart';

main() => runApp(MyApp());

class MyApp extends StatelessWidget {

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'title',
      home: Text('asdfasf')); Class CounterWidget extends StatefulWidget {CounterWidget({Key Key, this.initValue: 0}): super(key: key); final int initValue; @override _CounterWidgetState createState() => _CounterWidgetState(); } class _CounterWidgetState extends State<CounterWidget> { int _counter; // initState: The Flutter framework calls this callback only once for each State object. Therefore, the Flutter callback usually performs some one-time operations, such as State initialization and subscribing to event notifications of subtrees. Cannot call in the callback BuildContext. InheritFromWidgetOfExactType (the method used to get away from the current Widget in the Widget tree a recent parent InheritFromWidget, We'll cover inheritedWidgets in a later section) because the inheritFromWidgets in the Widget tree may also change after initialization, So the right thing to do is call it in the build () method or didChangeDependencies(). @override voidinitState() {
    super.initState();
    _counter = widget.initValue;
    print("initState"); } // didChangeDependencies() < span style = "box-sizing: border-box! Important; Such as: An InheritedWidget was included in the previous build(), and then the InheritedWidget was changed in the subsequent build(), The didChangeDependencies() callback to the child widgets of the InheritedWidget will be called. The typical scenario is when the system language Locale or the application theme changes, The Flutter Framework tells the widget to call this callback @override void didUpdateWidget(CounterWidget oldWidget) { super.didUpdateWidget(oldWidget);print('didUpdateWidget'); } /// when the State object is removed from the tree /// deactivate() : This callback is called when the State object is removed from the tree. The Flutter framework can re-insert a State object into the tree in some scenarios, such as when the subtree containing the State object moves from one position in the tree to another (this can be done using a GlobalKey). If it is not re-inserted into the tree after removal, the Dispose () method is immediately called. @override voiddeactivate() {
    super.deactivate();
    print("deactivate"); } /// dispose() : called when the State object is permanently removed from the tree; Resources are usually released in this callback. @override voiddispose() {
    super.dispose();
    print("dispose"); } /// rerender /// Reassemble () : This callback is specifically for development and debugging and is called on hot reload, never in Release mode. @override voidreassemble() {
    super.reassemble();
    print("reassemble"); } /// didUpdateWidget() : When a widget is rebuilt, the Flutter Framework calls widget. canUpdate to detect the old and new nodes at the same location in the widget tree and then decides whether an update is needed if widget. canUpdate returnstrueThe callback is invoked. As mentioned earlier, widget. canUpdate returns when the key and runtimeType of the new and old Widget are equaltrueThat is, didUpdateWidget() is called when the key and runtimeType of the new and old widgets are equal. @override voiddidChangeDependencies() {
    super.didChangeDependencies();
    print("didChangeDependencies"); } /// Build layout call /// build() : This callback, which readers should be familiar with by now, is used to build Widget subtrees and is called in the following scenario: /// after initState() is called. /// after calling didUpdateWidget(). / / / in the callsetAfter the State (). // after calling didChangeDependencies(). /// After the State object is removed from one location in the tree (deactivate is called) it is reinserted to another location in the tree. @override Widget build(BuildContext context) {print("Build");
    return Scaffold(
      body: Center(
        child: FlatButton(
          child: Text('$_counter'), onPressed: () {// The counter is pressedsetState(() => ++_counter); }))); }}Copy the code

We run the application and open the routing page. When the new routing page opens, a number 0 appears in the center of the screen and the console logs:

I/flutter ( 5436): initState
I/flutter ( 5436): didChangeDependencies
I/flutter ( 5436): build
Copy the code

As you can see, the initState method is called first when the StatefulWidget is inserted into the Widget tree.

Then we hit the ⚡️ button to hot reload and the console outputs the following log:

I/flutter ( 5436): reassemble
I/flutter ( 5436): didUpdateWidget
I/flutter ( 5436): build
Copy the code

You can see that neither initState nor didChangeDependencies are called, while the didUpdateWidget is called.

Next, we remove the CounterWidget in the Widget tree and change the route build method to:

Widget build(BuildContext Context) {// Remove counter //returnCounterWidget(); // Return a random Text()return Text("xxx");
}
Copy the code

Then hot reload, log as follows:

I/flutter ( 5436): reassemble
I/flutter ( 5436): deactive
I/flutter ( 5436): dispose
Copy the code

We can see that deactive and Dispose are called in turn when CounterWidget is removed from the Widget tree.

This article is from Flutter actual combat