0x00 Stateless components and state components

Widgets are fundamental controls in Fltter interface development, and like UIView in ios, everything is a widget.

Widgets are classified into statelessWidgets and StatefulWidgets. What are the differences between the two? Statelesswidget is used to display stateless views, while statefulWidget is used to display interactive, dynamic views.

Now that the basic conclusion is out, how does state realize state update?

Original publication address flutterdev.top

0x01 UI programming paradigm

IOS and Android development uses the imperative programming paradigm, while Flutter, the front-end of VUE, and applets are developed declaratively.

Such as ios

UILable * lable  = [UILable new];
label.text = "hello world";
Copy the code

This is imperative, directly to the control of the properties of the precise and efficient assignment control.

But flutter is as follows


class BgChangeView extends StatefulWidget {
  @override
  _BgChangeViewState createState() => _BgChangeViewState();
  Color color = Colors.red;
}

class _BgChangeViewState extends State<BgChangeView> {
  int count = 10;

  void _incrementCounter() {
    setState(() {
      count = count>255 ? 0 :count + 10;
      widget.color = Color.fromARGB(count, 0x00, 0xff, 0xff);
      print("state refresh count ${count}");

    });
  }
  @override
  Widget build(BuildContext context) {
    returnContainer( width: 100, height: 100, child: RaisedButton(onPressed: _incrementCounter, color: widget.color, ), ); }}Copy the code

Specifying color to RaiseButton, color is updated in State, thus updating the background color of RaiseButTom

0x02 How to implement this

State is the state of the view, when setState triggers the destruction and reconstruction of the current view and its children, from parent to child, from top to bottom.

Guess the implementation of internal state

In fact, state is responsible for destroying and rebuilding the widget. During the rebuilding process, the widget tree is re-generated level by level, and the external data is re-assigned to the widget. Because the internal mechanism of the widget reconstruction is very efficient, the destruction process is almost invisible to the naked eye. It will bring great performance overhead, lag, and high CPU and GPU usage. This is also a drawback of declarative programming. Use to avoid excessive setState operations.

PS: Thanks @vadasik for reminding me that assignment is not accurate. Check the setate source code and it is not a direct assignment operation. Remove some exceptions, such as whether the old element is being refreshed or has been discarded, and add it directly to dirtyElements. Call stack, setState -> _element.markNeedsbuild (); –>owner.scheduleBuildFor(this); The core code is as follows:

    if(! _scheduledFlushDirtyElements && onBuildScheduled ! = null) { _scheduledFlushDirtyElements =true;
      onBuildScheduled();
    }
    _dirtyElements.add(element);
    element._inDirtyList = true;
Copy the code

The performance of this part of the Flutter engine is optimized internally. After each rebuild, the space used by the previously requested widget or randerobject is not released one by one. Instead, the space is cleaned by sliding compression. As shown in the figure below

  • Flutter divides the memory region into two parts, active space and inactive space
  • The user uses the app, and Flutter continuously applies for memory space in active Spaces
  • Until the fetch space allocation is full
  • Examines active objects in an active space, marking active objects along with the objects they depend on
  • Move an active object to an inactive area when the app is idle. There is no inactive area between active objects
  • Swap states between inactive and active regions

Refer to the article

  • Because the core technology of actual combat time.geekbang.org/column/arti…
  • Flutter memory technology www.helloted.com/flutter/201…