Understanding Flutter Render Engine

问题:

The docs here about how to update a ListView say:

In Flutter, if you were to update the list of widgets inside a setState(), you would quickly see that your data did not change visually. This is because when setState() is called, the Flutter rendering engine looks at the widget tree to see if anything has changed. When it gets to your ListView, it performs a == check, and determines that the two ListViews are the same. Nothing has changed, so no update is required.

For a simple way to update your ListView, create a new List inside of setState(), and copy the data from the old list to the new list.

I don't get how the Render Engine determines if there are any changes in the Widget Tree in this case.

AFAICS, we care calling setState, which marks the State object as dirty and asks it to rebuild. Once it rebuilds there will be a new ListView, won't it? So how come the == check says it's the same object?

Also, the new List will be internal to the State object, does the Flutter engine compare all the objects inside the State object? I thought it only compared the Widget tree.

So, basically I don't understand how the Render Engine decides what it's going to update and what's going to ignore, since I can't see how creating a new List sends any information to the Render Engine, as the docs says the Render Engine just looks for a new ListView... And AFAIK a new List won't create a new ListView.

回答1:

Flutter isn't made only of Widgets.

When you call setState, you mark the Widget as dirty. But this Widget isn't actually what you render on the screen. Widgets exist to create/mutate RenderObjects; it's these RenderObjects that draw your content on the screen.

The link between RenderObjects and Widgets is done using a new kind of Widget: RenderObjectWidget (such as LeafRenderObjectWidget)

Most widgets provided by Flutter are to some extent a RenderObjectWidget, including ListView.

A typical RenderObjectWidget example would be this:

class MyWidget extends LeafRenderObjectWidget {
  final String title;

  MyWidget(this.title);

  @override
  MyRenderObject createRenderObject(BuildContext context) {
    return new MyRenderObject()
      ..title = title;
  }

  @override
    void updateRenderObject(BuildContext context, MyRenderObject renderObject) {
      renderObject
        ..title = title;
    }
}

This example uses a widget to create/update a RenderObject. It's not enough to notify the framework that there's something to repaint though.

To make a RenderObject repaint, one must call markNeedsPaint or markNeedsLayout on the desired renderObject.

This is usually done by the RenderObject itself using custom field setter this way:

class MyRenderObject extends RenderBox {
  String _title;
  String get title => _title;
  set title(String value) {
    if (value != _title) {
      markNeedsLayout();
      _title = value;
    }
  }
}

Notice the if (value != previous).

This check ensures that when a widget rebuilds without changing anything, Flutter doesn't relayout/repaint anything.

It's due to this exact condition that mutating List or Map doesn't make ListView rerender. It basically has the following:

List<Widget> _children;
List<Widget> get children => _children;
set children(List<Widget> value) {
  if (value != _children) {
    markNeedsLayout();
    _children = value;
  }
}

But it implies that if you mutate the list instead of creating a new one, the RenderObject will not be marked as needing a relayout/repaint. Therefore there won't be any visual update.