First, let's look at the declaration cycle methods

class _NumState extends State<NumWidget> {
   _counter = 0;

  @override
  void initState() {
    super.initState();
    //Initialization status
    _counter = widget.initValue;
    print("initState");
  }

  @override
  Widget build(BuildContext context) {
    print("build");
    return Scaffold(
      body: Center(
        child: TextButton(
          child: Text('$_counter'),
          //After clicking, the counter will increase automatically
          onPressed: () => setState(
            () => ++_counter,
          ),
        ),
      ),
    );
  }

  @override
  void didUpdateWidget(NumWidget oldWidget) {
    super.didUpdateWidget(oldWidget);
    print("didUpdateWidget ");
  }

  @override
  void deactivate() {
    super.deactivate();
    print("deactivate");
  }

  @override
  void dispose() {
    super.dispose();
    print("dispose");
  }

  @override
  void reassemble() {
    super.reassemble();
    print("reassemble");
  }

  @override
  void didChangeDependencies() {
    super.didChangeDependencies();
    print("didChangeDependencies");
  }
}

In the new route, we only show one NumWidget

class TestWidget extends StatelessWidget {
  const TestWidget({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return CartWidget();
  }
}

Running the application to open this route will execute the following life cycle.

I/EGL_emulation(18206): initState
I/EGL_emulation(18206): didChangeDependencies
I/EGL_emulation(18206): build

Then we click ⚡  if the button is hot overloaded, the following declaration cycle will be executed:

I/EGL_emulation(18206): reassemble
I/EGL_emulation(18206): didUpdateWidget 
I/EGL_emulation(18206): build

Next, we remove the CartWidget from the widget tree and change the build method of TestWidget to:

class TestWidget extends StatelessWidget {
  const Test({Key? key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    // return CartWidget();
    return Text('I'm the new control');
  }
}

click ⚡ Hot heavy load of button

I/EGL_emulation(18206): reassemble
I/EGL_emulation(18206): deactive
I/EGL_emulation(18206): dispose

• initState: the widget will be called when it is inserted into the widget tree for the first time. For each State object, the fluent framework will only call the callback once. Therefore, some one-time operations are usually done in the callback, such as State initialization, subscribing to the event notification of the subtree, etc. BuildContext. cannot be invoked in this callback. DependOnInheritedWidgetOfExactType (this method is used to get a parent InheritedWidget closest to the current widget on the widget tree) because the InheritFrom widget in the widget tree may change after the initialization is completed, so the right way to do it is to call it in build () method or didChangeDependencies().

• didChangeDependencies(): called when the dependency of the State object changes; For example, if an Inherited widget is included in the previous build(), and the Inherited widget changes in the subsequent build(), then the didChangeDependencies() callback of the child widget of the Inherited widget will be called. A typical scenario is that when the system language Locale or application theme changes, the fluent framework will notify the widget to call this callback. It should be noted that when the component is first created and mounted (including re creation), the corresponding didChangeDependencies will also be called.

• build(): this callback should be familiar to readers by now. It is mainly used to build widget subtree and will be called in the following scenarios:

    In call initState()After that.
    In call didUpdateWidget()After that.
    In call setState()After that.
    In call didChangeDependencies()After that.
    stay State When an object is removed from a position in the tree (called deactivate)After reinserting into other parts of the tree.
  

• reassemble(): this callback is specially provided for development debugging. It will be called during hot reload. This callback will never be called in Release mode.

• didUpdateWidget(): when the widget is rebuilt, the fluent framework will call the widget Canupdate to detect the old and new nodes at the same position in the widget tree, and then decide whether to update if the widget If canupdate returns true, this callback will be called. As mentioned earlier, widget Canupdate will return true when the key and runtimeType of the old and new widgets are equal at the same time, that is, didUpdateWidget() will be called when the key and runtimeType of the old and new widgets are equal at the same time.

• deactivate(): this callback is called when the State object is removed from the tree. In some scenarios, the fluent framework will reinsert the State object into the tree. For example, when the subtree containing the State object moves from one position of the tree to another (it can be realized through GlobalKey). If dispose is not called, it will be reinserted into the tree.

• dispose(): called when the State object is permanently removed from the tree; Typically, resources are released in this callback.

The above contents are used for reference The tutorial written by this big man His introduction is more detailed. Let's make a simple record as a study. If there is any inappropriate contact, delete [boxing] [boxing]