Flutterの3つのツリー構造を徹底解剖: Widget、Element、RenderObject

If you've written Flutter for more than five minutes, you've heard the famous mantra: 'Everything is a Widget.' But if you take a look at how Flutter actually renders pixels on a screen at 120 FPS, widgets are only the tip of the iceberg.

In reality, Flutter runs three parallel trees simultaneously: the Widget Tree, the Element Tree, and the RenderObject Tree. Understanding how these three trees coordinate is the single biggest unlock for understanding Flutter's performance model.

The 3 Roles at a Glance

• Widget Tree (The Blueprint): Extremely cheap, immutable configuration classes that are created, torn down, and garbage-collected constantly without performance penalty.
• Element Tree (The Manager): The long-lived structural spine of your app. Elements hold memory pointers, manage lifecycle, and perform reconciliation diffing via canUpdate().
• RenderObject Tree (The Painter): Heavyweight layout and paint engine that calculates exact sizes, hit-tests touches, and draws pixels to Skia/Impeller canvas.

Interactive Architecture Simulator

Use the interactive lab below to watch a StatelessWidget lifecycle step-by-step. Notice how rebuilding with identical text triggers zero RenderObject repainting!

How canUpdate() Saves Your Frame Budget

When a parent widget rebuilds, Flutter checks whether the existing Element can be preserved using a static comparison function:

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

If canUpdate() returns true, Flutter does not allocate a new Element or destroy the RenderObject. It simply updates the Element's internal reference pointer to the new widget blueprint and calls updateRenderObject() only if data changed.