Flutter-widget life cycle

Flutter-widget life cycle

The life cycle

• Essence: Callback method (function)
• Content: Let developers know what state the widget is currently in
• role
  • Listen for events in widgets
  • Initializing data (creating data, sending network requests…)
  • Memory management (destroy data, remove listener, destroy timer…)
• phase
  • Initialize (insert render tree)
  • State changes (present in the render tree)
  • Destroy (remove from render tree)
    

    

    Pictures fromBlog.csdn.net/u011272795/…

Widget lifecycle callback function call order

StatelessWidget

class MyApp extends StatelessWidget {
  // This widget is the root of your application.
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      theme: ThemeData(
        primarySwatch: Colors.blue,
        visualDensity: VisualDensity.adaptivePlatformDensity,
      ),
      home: Scaffold(
        appBar: AppBar(
          title: Text('life cycle'),
        ),
        body: MyHomePage(title:'hello'),),); }}Copy the code

print

Flutter: +++++++StatelessWidget- Construct flutter: +++++++StatelessWidget-buildCopy the code

PS: Maybe when you test yourself, the print order looks like this, and the constructor and build methods are called twice. This is actually a bug in AS.

Flutter: + + + + + + + structure flutter: + + + + + + + build flutter: + + + + + + + structure flutter: + + + + + + + buildCopy the code

You can run the test project again using a hot reload or terminal to get the same results

➜ ~ / Users/ricefun/Desktop/Flutter_case/flutter_app_lifecycle ➜ flutter_app_lifecycle flutter run Launching lib/main.dart on iPhone SE (2nd generation)indebug mode... Running Xcode build... └ ─ the Compiling, linking and signing... 5.2s Xcode build done. 18.0s flutter: +++++++ construct flutter: +++++++build Syncing files to device iPhone SE (2nd generation)... 128msCopy the code

StatefulWidget

class MyApp extends StatelessWidget {
  // This widget is the root of your application.
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      title: 'Flutter Demo',
      theme: ThemeData(
        primarySwatch: Colors.blue,
        visualDensity: VisualDensity.adaptivePlatformDensity,
      ),
      home: Scaffold(
        appBar: AppBar(
          title: Text('life cycle'),
        ),
        body: MyHomePage(title:'hello'),),); } } class _MyHomePageState extends State<MyHomePage> {_MyHomePageState() {print('----------- statefulWidget-state - constructor ');
  }

  @override
  void initState() {
    // TODO: implement initState
    super.initState();
    print('-----------StatefulWidget-State-initState()');
  }

  @override
  void dispose() {
    // TODO: implement dispose
    super.dispose();
    print('-----------StatefulWidget-State-dispose()');
  }

  @override
  void didUpdateWidget(MyHomePage oldWidget) {
    // TODO: implement didUpdateWidget
    super.didUpdateWidget(oldWidget);
    print('-----------StatefulWidget-State-didUpdateWidget()');
  }

  @override
  void didChangeDependencies() {
    // TODO: implement didChangeDependencies
    super.didChangeDependencies();
    print('-----------StatefulWidget-State-didChangeDependencies()'); } // When the State object is removed from the render tree! Destroyed soon! @override voiddeactivate() {
    super.deactivate();
    print('-----------StatefulWidget-State-deactivate()');
  }

  @override
  Widget build(BuildContext context) {
    print('-----------StatefulWidget-State-build()');
    returnContainer(); }}Copy the code

print

Flutter: -----------StatefulWidget_ Construct flutter: ----------- statefulWidget-State - construct flutter: -----------StatefulWidget-State-initState() flutter: -----------StatefulWidget-State-didChangeDependencies() flutter: -----------StatefulWidget-State-build()Copy the code

DidChangeDependencies ()

This method appears in the print above after state-initstate (), which seems useless. But when used with the InheritedWidget, it gets interesting. Let’s look at an example:

The original:

class _InheritedDemoState extends State<InheritedDemo> { int count = 1; // override Widget build(BuildContext context) {returnColumn(children: <Widget>[// to pass count to Test2 Test2(count), RaisedButton(child: Text('I am the button'), / /setState!
          onPressed: () => setState(() { count++; }),)],); }} class Test2 extends StatefulWidget {// Declare variables and constructors final count; Test2(this.count); @override _Test2State createState() => _Test2State(); } class _Test2State extends State<Test2> {override Widget build(BuildContext context)returnText(widget.count.toString()); }}Copy the code

In the example above, the count value changes after the button is clicked. In the child widget-test2, final count is declared as the same variable; Get the data via widget.count. When there are many levels of the widget tree, requiring each widget to have the same life variable can be tedious. So you can use the InheritedWidget

[InheritedWidget] [InheritedWidget] [InheritedWidget] [InheritedWidget// Data sharing! class MyData extends InheritedWidget { MyData({this.data, Widget child}) : super(child: child); final int data; // The data that needs to be shared in the child widgets! // Provide a convenient class method to make shared data easily accessible to child widgets! static MyData of(BuildContext context) {returncontext.dependOnInheritedWidgetOfExactType<MyData>(); } override bool updateShouldNotify(MyData oldWidget) {// If data changes, the child Widget that InheritedWidget relies on is notified, and the child Widget calls build().returnoldWidget.data ! = data; } } class InheritedDemo extends StatefulWidget { @override _InheritedDemoState createState() => _InheritedDemoState(); } class _InheritedDemoState extends State<InheritedDemo> { int count = 1; @override Widget build(BuildContext context) {returnMyData(//Column is wrapped in MyData. Any Widget of MyData can use the data field data: count, child: Column(children: <Widget>[ Test2(count), RaisedButton( child: Text('I am the button'), / /setState!
            onPressed: () => setState(() { count++; }),)],),); } } class Test2 extends StatefulWidget { final count; Test2(this.count); @override _Test2State createState() => _Test2State(); } class _Test2State extends State<Test2> { @override Widget build(BuildContext context) {print("++++++++++State-build()"); // MyData provides a method that can easily obtain count datareturn Text(MyData.of(context).data.toString());
  }

  @override
  void didChangeDependencies() {
    print('++++++++++State-didChangeDependencies'); super.didChangeDependencies(); }}Copy the code

Click on the print

flutter: ++++++++++State-didChangeDependencies()
flutter: ++++++++++State-build()
flutter: ++++++++++State-didChangeDependencies
flutter: ++++++++++State-build()
flutter: ++++++++++State-didChangeDependencies
flutter: ++++++++++State-build()
flutter: ++++++++++State-didChangeDependencies
flutter: ++++++++++State-build()
Copy the code

You can see that didChangeDependencies() is called every time you click and count changes. And using inheritedWidgets, we can all share data. So didChangeDependencies() calls:

1. initState()After the call
2. When the dependentInheritedWidgetWhen changes occur, it will also be called, and quietly used multiple times

Theme. Of (context). TextTheme; , MediaQuery. Of (context). The size; It’s all using this technique. There are excellent third party providers on pub.

didUpdateWidget()

Called whenever the widget configuration changes

1. In the Widget tree, when the parent widget is rebuilt, it is also called if the current widget configuration changesdidUpdateWidget(), and after calling, will callbuild()

The build() method is called after the didUpdateWidget() method, so do not call setState() in the didUpdateWidget() method.

deactivate()

Dispose () is called after deactivate() when it is removed from the render tree. Eg: Component removal, such as page destruction, will execute deactivate > dispose in sequence

dispose()

The Dispose () method is called when the widget is deprecated. The above example does not show you overriding this method and calling super.dispose() immediately after if you need to do any cleaning operations (e.g. listeners).

conclusion

StatelessWidget lifecycle function

StatefulWidget lifecycle functions

To explore the

1. AB pages are independent pages. If AB pages passbottomNavigationBarPut, are they life cycle function call order? After the test:

Flutter: -- -- -- -- -- -- -- -- -- -- -- PageA constructor flutter: -- -- -- -- -- -- -- -- -- -- -- PageB constructor flutter: -- -- -- -- -- -- -- -- -- -- -- PageA _PageAState - constructor flutter: -----------PageA-_PageAState-initState() flutter: -----------PageA-_PageAState-didChangeDependencies() flutter: -----------PageA-_PageAState-build() flutter: -----------PageA-_PageAState-build() flutter: = = = = = = = = = = = = = = = = = = = = = = = = = = = A switch to the B flutter: -- -- -- -- -- -- -- -- -- -- -- PageA _PageAState - deactivate () because: -- -- -- -- -- -- -- -- -- -- -- PageB _PageBState - constructor flutter: -- -- -- -- -- -- -- -- -- -- -- PageB _PageBState - initState flutter () : -----------PageB-_PageBState-didChangeDependencies() flutter: -----------PageB-_PageBState-build() flutter: -----------PageA-_PageAState-dispose()Copy the code

2. BC pages are independent pages, push from B to C, pop from C to B, they are life cycle function call order, right? After the test:

Flutter: = = = = = = = = = = = = = = = = = = = = = = = = = = = B push C flutter: -- -- -- -- -- -- -- -- -- -- -- PageC constructor flutter: -- -- -- -- -- -- -- -- -- -- -- PageC _PageCState - constructor flutter: -- -- -- -- -- -- -- -- -- -- -- PageC _PageCState - initState flutter () : -----------PageC-_PageCState-didChangeDependencies() flutter: -----------PageC-_PageCState-build() flutter: =========================== C pop B flutter: -----------PageC-_PageCState-deactivate() flutter: -----------PageC-_PageCState-dispose()Copy the code

Refer to the Flutter Widget lifecycle for details, Flutter lifecycle