How Flutter and Jetpack Compose Implement UI Diff: A Deep Dive

Flutter Diff Implementation

Flutter builds three trees – Widget Tree , Element Tree and RenderObject Tree . Widgets are immutable, so a change creates a new Widget; the real UI representation lives in the Element Tree, while RenderObject handles layout and painting.

The diff logic centers on Element , which manages the lifecycle and creation/update of UI components. Reusing an Element is the key to Flutter's diff mechanism.

When setState() is called, the framework marks the affected Elements as dirty, adds them to BuildOwner._dirtyElements, sorts them, and triggers a rebuild. Only dirty Elements are processed; clean Elements are skipped.

Flutter uses a linear reconciliation algorithm (O(N)) rather than a tree‑diff. The process consists of:

Scanning from the top of the old and new child lists, updating matching Elements until a mismatch is found.

Scanning from the bottom upward to locate the unchanged region.

Processing the middle region by building a <Key, Element> map of remaining old Elements for fast lookup.

Updating or creating Elements based on canUpdate(oldChild, newWidget), which checks runtimeType and key.

Cleaning up remaining old Elements and returning the new Element list.

The core comparison code is:

if (oldChild == null || !Widget.canUpdate(oldChild.widget, newWidget)) {
    break;
}

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

Illustrative diagrams show the top‑down scan, bottom‑up scan, middle‑region processing, and final cleanup.

Jetpack Compose Diff Implementation

In Compose, the @Composable annotation marks UI building blocks. The compiler rewrites each composable function to include a hidden Composer parameter and a $changed flag, similar to Kotlin's Continuation for suspend functions.

The Composer creates and updates a SlotTable , which records composition state (keys, values, snapshots). A second tree, the LayoutNode , handles measurement and drawing.

During recomposition, the framework checks the $changed bitmask to decide whether a node can be skipped. State changes produce a snapshot , which registers observers and triggers diffing of the SlotTable.

SlotTable stores two arrays: groups (metadata for each group) and slots (actual data). Groups form a virtual tree via parent anchors, while slots hold the concrete values. Keys generated at startXXXGroup calls allow the system to detect insertions, deletions, or moves. The diff algorithm operates on the linear SlotTable using a gap‑buffer structure, enabling efficient updates without moving large blocks of nodes.

After diffing, applyChanges iterates over the change list, updating the SlotTable, and finally the Applier propagates changes to the corresponding LayoutNode.

Key points to remember:

If recomposition is aborted, changes are not applied to the SlotTable.

Gap buffers reduce node movement overhead during updates.

The $changed flag and snapshot system drive the decision of what parts of the UI need to be recomposed.

Summary Comparison

Flutter relies on Element reuse based on runtimeType and key, employing a linear scan algorithm that processes only dirty Elements. Compose, on the other hand, uses a compiler‑generated Composer and a SlotTable backed by a gap‑buffer diff, with recomposition driven by state snapshots and a bitmask indicating changed nodes.

Both frameworks aim to minimize work by updating only the parts of the UI that actually changed, but they differ in their internal data structures and the granularity of their diff algorithms.