A Deep Dive into How Flutter Works 'Under the Hood'

I have been with Flutter for more than 2,5 years and during this time I managed to appreciate and feel its various qualities. Today I would like to share an article by my colleague and Flutter Tech Lead in Surf, Mikhail Zotyev (@mjk), about how exactly Flutter works under the hood. You can also find it in .

Widget

Describes the configuration for an [Element].

Widgets are the central class hierarchy in the Flutter framework. A widget is an immutable description of part of a user interface. Widgets can be inflated into elements, which manage the underlying render tree.

• a widget is an immutable description of part of a user interface
• a widget is associated with a certain extended representation called an element
• an element controls some entity in the render tree.

Widgets themselves have no mutable state (all their fields must be final).
If you wish to associate mutable state with a widget, consider using a [StatefulWidget], which creates a [State] object (via [StatefulWidget.createState]) whenever it is inflated into an element and incorporated into the tree.

A given widget can be included in the tree zero or more times. In particular a given widget can be placed in the tree multiple times. Each time a widget is placed in the tree, it is inflated into an [Element], which means a widget that is incorporated into the tree multiple times will be inflated multiple times.

• a widget is a central class hierarchy.
• a widget describes a configuration.
• a widget is an immutable description of part of a user interface.
• a widget is associated with an element that controls rendering.
• mutable state of a widget can be described by an entity that is associated with an element representing that widget and not with the widget itself.

Element

An instantiation of a [Widget] at a particular location in the tree.

Widgets describe how to configure a subtree but the same widget can be used to configure multiple subtrees simultaneously because widgets are immutable. An [Element] represents the use of a widget to configure a specific location in the tree. Over time, the widget associated with a given element can change, for example, if the parent widget rebuilds and creates a new widget for this location.

• An element is created by calling Widget.createElement on the widget that will be used as the element’s initial configuration.
• The mount method adds the newly created element to the tree at a given slot in a given parent. Calling this method also allows you to inflate any child widgets and attach elements to the render tree.
• At this point, the widget is considered active and might appear on screen.
• If the widget associated with an element is changed (e.g. its parent element is rebuilt), there are several possible scenarios. If the new widget has the same runtimeType and key as the old widget, the element will be associated with the new widget. Alternatively, the current element is removed from the tree and a new element is created to be associated with the new widget.
• In case the parent decides to remove a child or an intermediate ancestor, it will lead to removing that element’s render object from the render tree and adding it to the list of inactive elements, thus deactivating that element by calling deactivateChild.
• Once an element is considered inactive, it will not appear on the screen. An element can remain in the inactive state only until the end of the current frame. If it remains inactive at this point, the framework considers it defunct and this element will be unmounted.
• If the element gets reincorporated into the tree (e.g., because it or one of its ancestors has a global key that is being reused), it will be removed from the owner’s list of inactive elements. The framework will call activate on the element, and reattach the element’s render object to the render tree. This means that the element might appear on the screen again.

As we can see from the class declaration, the element implements the BuildContext interface. BuildContext is an entity that handles the location of a widget in the widget tree, as stated in its documentation. It is almost identical to the element description. This interface is used to avoid direct manipulation of elements but at the same time give access to the necessary context methods. For example, the findRenderObject method allows you to locate this element’s render object in the tree.

RenderObject

The last class we will look into is RenderObject. As the name implies, it is a render object. RenderObject has a parent as well as a slot where the parent can store child-specific data, for example, this object’s position. This object is responsible for implementing the basic layout and paint protocols.

RenderObject does not define a child model. It can consist of zero, one, or more children. On top of that, it does not define a coordinate system. You are free to choose from Cartesian coordinates, polar coordinates, or whichever system suits your needs. There are also no restrictions on layout protocols. You can decide either to adjust the width and height of the layout, or constrain the size of the layout, or set the size and position of the child. If needed, the children can use their parent’s data.

Putting it all together

• The widget tree declares configurations and stores properties.
• The element tree handles lifecycle and arranges widgets into a hierarchy as well as associates render objects with widgets.
• The render tree manages painting, sizes, and constraints.

Let us put ourselves in Flutter’s shoes for a moment. Say, we are given this particular widget
tree.

Flutter: Hey, Padding, I need your element.
Padding: Sure thing, here’s SingleChildRenderObjectElement.

Flutter: That’s where you’ll be staying, element, make yourself at home.
SingleChildRenderObjectElement: It’s all good, guys, but I need RenderObject.
Flutter: Padding, how am I supposed to render you?
Padding: There you go, one RenderPadding, as requested.
SingleChildRenderObjectElement: Great. I’m on it!

Flutter: Who’s next? StatelessWidget, now you give me an element.
StatelessWidget: Here’s your StatelessElement.
Flutter: StatelessElement, you’ll be subordinate to SingleChildRenderObjectElement. This is your desk, get to work.
StatelessElement: Ok.

Flutter: RichText, may I see your element please?
RichText hands their MultiChildRenderObjectElement over.
Flutter: MultiChildRenderObjectElement, here is your place, get to work.
MultiChildRenderObjectElement: I can’t work without a render.
Flutter: RichText, we need a render object.
RichText: Here’s RenderParagraph.
Flutter: RenderParagraph, you’ll be receiving instructions from RenderPadding. MultiChildRenderObjectElement will be supervising your work.
MultiChildRenderObjectElement: I’m all set now and ready to start.

You’re probably wondering why there isn’t a render object for StatelessWidget since we have stated that elements associate configurations with rendering? Let us take a closer look at the basic implementation of the mount method.

void mount(Element parent, dynamic newSlot) {
    assert(_debugLifecycleState == _ElementLifecycle.initial);
    assert(widget != null);
    assert(_parent == null);
    assert(parent == null || parent._debugLifecycleState == _ElementLifecycle.active);
    assert(slot == null);
    assert(depth == null);
    assert(!_active);
    _parent = parent;
    _slot = newSlot;
    _depth = _parent != null ? _parent.depth + 1 : 1;
    _active = true;
    if (parent != null)
        _owner = parent.owner;
    if (widget.key is GlobalKey) {
        final GlobalKey key = widget.key;
        key._register(this);
    }
    _updateInheritance();
    assert(() {
        _debugLifecycleState = _ElementLifecycle.active;
        return true;
    }());
}

We will not find a render object being created here. Instead, the element implements BuildContext which contains the findRenderObject method. This method leads us to the next getter:

RenderObject get renderObject {
    RenderObject result;
    void visit(Element element) {
        assert(result == null); 
        if (element is RenderObjectElement)
            result = element.renderObject;
        else
            element.visitChildren(visit);
    }
    visit(this);
    return result;
}

In the base case, elements may not create a render object, it is something that RenderObjectElement and its descendants do. However, the element must have a child containing a render object at some level of nesting.

body: Center(
    child: Text(“Hello world!”)
),

Now we have a new widget tree. We mentioned that Flutter tries to make the most of the existing elements. Let us take a look at another method in the Widget class with a telling name canUpdate.

static bool canUpdate(Widget oldWidget, Widget newWidget) {
    return oldWidget.runtimeType == newWidget.runtimeType && oldWidget.key == newWidget.key;
}

Apart from having type and key, a widget is a description and a configuration. This means that parameter values needed for displaying might have changed. That is why the element must initiate updates of the render object after updating the association with the widget. Nothing changes for Center here. Let us continue examining the widgets.

@override
Widget build(BuildContext context) {
    return Scaffold(
        body: Center(
            child: _isFirst ? first() : second(),
        ),
        floatingActionButton: FloatingActionButton(
            child: Text("Switch"),
            onPressed: () {
                setState(() {
                    _isFirst = !_isFirst;
                });
            },
        ),
    );
}

Widget first() => Row(
    mainAxisAlignment: MainAxisAlignment.center,
    children: <Widget>[
        Text(
            "test",
            style: TextStyle(fontSize: 25),
        ),
        SizedBox(
            width: 5,
        ),
        Icon(
            Icons.error,
        ),
    ],
);

Widget second() => Row(
    mainAxisAlignment: MainAxisAlignment.center,
    children: <Widget>[
        Text(
            "one more test",
            style: TextStyle(fontSize: 25),
        ),
        Padding(
            padding: EdgeInsets.only(left: 5),
        ),
        Icon(
            Icons.error,
        ),
    ],
);

As we can see, Flutter only rebuilt RenderPadding and reused the rest.

Widget second() => Container(child: first(),);

Although the tree appears to be the same, the elements and render objects have been rebuilt. This happened because Flutter compares by level. It does not matter that the tree remained mostly unchanged. This part was filtered out when Container and Row were being compared. However, this can be avoided If we use GlobalKey. Let us add this key to Row.

var _key = GlobalKey(debugLabel: "testLabel");

Widget first() => Row(
    key: _key,
    …
);

In conclusion

References

Flutter Code
«How Flutter renders Widgets» Andrew Fitz Gibbon, Matt Sullivan

Also published on: