Flutter widget life cycle detailed

Foreword

Like other view frameworks such as Android Activity, the view widget in flutter also has a life cycle, and the callback function of the life cycle is presented in the State. Understanding the life cycle of flutter is very important for us to write a reasonable control. The life cycle of the component State is organized as shown below:


 
Widget life cycle

Can roughly be seen as three stages

  • Initialization (insert rendering tree)
  • State change (exists in render tree)
  • Destroyed (removed from render tree species)

Constructor

This function does not belong to the life cycle, because the widget property of the State is empty at this time, if you want to access the widget property in the constructor, it will not work. But the constructor must be called first.

initState

/// Called when this object is inserted into the tree. Called when inserted into the
rendering tree, this function is only called once in the life cycle. Here you can do some initialization work, such as initializing State variables.

didChangeDependencies

/// Called when a dependency of this [State] object changes.

 

 
didChangeDependencies

This function will be called immediately after initState, and can call BuildContext.inheritFromWidgetOfExactType, so what is the usage scenario of BuildContext.inheritFromWidgetOfExactType? The most classic application scenario is

 

new DefaultTabController(length: 3, child: new TabBar( tabs: [ "主页","订单","我的" ] .map( (data)=>new Text(data) ).toList(), 

TabBar originally needed to define a TabController, but there is no need to define TabContrller by setting a layer of DefaultTabController outside, see the source code:

@override
  void didChangeDependencies() { super.didChangeDependencies(); _updateTabController(); _initIndicatorPainter(); } void _updateTabController() { final TabController newController = widget.controller ?? DefaultTabController.of(context); 

Note here DefaultTabController.of (context)

 static TabController of(BuildContext context) { final _TabControllerScope scope = context.inheritFromWidgetOfExactType(_TabControllerScope); return scope?.controller; } 

In fact, it is called BuildContext.inheritFromWidgetOfExactType, which means that in didChangeDependencies, you can get data across components.

didUpdateWidget

/// Called whenever the widget configuration changes.

 

 
didUpdateWidget

When the state of the component changes, didUpdateWidget is called, for example, setState is called.
In fact, the flutter framework will create a new Widget, bind this State, and pass the old Widget in this function.
This function is generally used to compare new and old widgets, see which attributes have changed, and make some adjustments to the State.
It should be noted that when it comes to controller changes, you need to remove the old controller listener and create a new controller listener in this function.
 
TabBar_didUpdateWidget

 
_updateTabController

 

deactivate

/// Called when this object is removed from the tree.

This function will be called before dispose.

dispose

/// Called when this object is removed from the tree permanently.

Once at this stage, the component will be destroyed, this function will generally remove the listener and clean up the environment.
TabBar:


 
dispose

Actual scene

Suppose we jump from page A to page B. What will be the life cycle of pages A and B?

Page B enters the initialization state, and executes 4 functions in sequence: constructor> initState> didChangeDependencies> Widget build, at this point the page is loaded and enters the running state.
At this time, page A executes deactivate> build function in sequence. Note that page A is not uninstalled at this time.

Then we assume that there is only one button on the B page. Clicking the button on the B page to change the button text will execute the widget's build method (in theory, didUpdateWidget should also be executed, but I don't have it here).

At this time, we click the back button to return from page B to page A.
Page A is displayed again, and Page B starts to uninstall.
Then A executes deactivate> build first, then page B executes sequentially: deactivate> dispose.
At this time, page A enters the running state, and page B is removed.

in conclusion

stage Calls Whether to support setState
Constructor 1 no
initState 1 Invalid (use setState is the same as not using)
didChangeDependencies >=1 invalid
didUpdateWidget >=1 Yes
deactivate >=1 no
dispose 1 no


Author: ershixiong
link: https: //www.jianshu.com/p/762bb2b7fa00
Source: Jane books
are copyrighted by the author. For commercial reproduction, please contact the author for authorization, and for non-commercial reproduction, please indicate the source.

Guess you like

Origin www.cnblogs.com/xiaochii/p/12709823.html