Flutter in the life cycle Widget

Foreword

And other frameworks such as the android Activity view as the view Widget flutter in there life cycle, lifecycle callbacks now put the State above. Flutter understanding of the life cycle, write us a reasonable control is essential. State lifecycle finishing assembly as shown below:


730571-7ac148f75dac52dc.png
Widget Life Cycle

Roughly three stages can be seen as

  • Initialization (insert rendering tree)
  • State change (present in the rendering tree)
  • Destruction (removed from rendering tree)

Constructor

This function is not part of the life cycle, because this time the State of the widget property is empty, if you want to access the widget properties in the constructor will not work. But the constructor must be to the first call.

initState

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

didChangeDependencies

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

730571-20861d4ab29fd2e2.png
didChangeDependencies

This function initState immediately after the call and can be called BuildContext.inheritFromWidgetOfExactType, then what BuildContext.inheritFromWidgetOfExactType usage scenario is it? The most classic scenario is

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

TabBar would need to define a tabController, but the outside sleeve layer DefaultTabController not need to define a TabContrller, look Source:

@override
  void didChangeDependencies() {
    super.didChangeDependencies();
    _updateTabController();
    _initIndicatorPainter();
  }

void _updateTabController() {
    final TabController newController = widget.controller ?? DefaultTabController.of(context);

Notice here DefaultTabController.of (context)

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

Actually call BuildContext.inheritFromWidgetOfExactType, it said in didChangeDependencies, you can get the data across components.

didUpdateWidget

/// Called whenever the widget configuration changes.

730571-a14342ad30917329.png
didUpdateWidget

When the state of the components of change will call didUpdateWidget, such as call setState.
In fact here flutter framework creates a new Widget, binding of this State, and pass the old Widget in this function.
This function is generally used to compare new and old Widget, to see which properties have changed, and the State to make some adjustments.
It should be noted that the changes related to the controller, listeners need to remove the old controller is in this function, and create a new controller's listening.
730571-747ae1402257aaca.png
TabBar_didUpdateWidget

730571-9183d3eba4bd824c.png
_updateTabController

deactivate

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

Before dispose, we will call this function.

dispose

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

Once this stage, the component about to be destroyed, this function is generally removes monitor, clean up the environment.
Or TabBar:


730571-12b50b00e6813a82.png
dispose

The actual scene

Suppose we jump from page A to page B, then A, B page life cycle will be like?

B initialization status page, are sequentially performed four functions: Constructor> initState> didChangeDependencies> Widget build, this time the page loaded into the operating mode.
A page sequentially performed at this time deactivate> build function. Note A page at this time did not unload.

Then we assume that there is only one page B button, click the button B page, change the button text, the method performs build a widget, (in theory, should also be performed didUpdateWidget, but I do not have).

At this time, we click on the back button to return pages from B to A page.
A page redisplay, B page to begin unloading.
Then A first implementation deactivate> build, then Page B followed by the implementation: deactivate> dispose.
At this time, the operating mode into the page A, B page removed.

in conclusion

stage Invocations Whether to support setState
Constructor 1 no
initState 1 Invalid (setState use and do not use the same)
didChangeDependencies >=1 invalid
didUpdateWidget >=1 Yes
deactivate >=1 no
dispose 1 no

Reproduced in: https: //www.jianshu.com/p/762bb2b7fa00

Guess you like

Origin blog.csdn.net/weixin_34072857/article/details/91060905
Recommended