Describe Flutter's architecture — how does a widget end up as pixels on screen?
Short Answer
Flutter has three parallel trees — Widget, Element, and RenderObject — where widgets are immutable configuration, elements are the mutable instances that manage the tree, and render objects handle layout, painting, and hit-testing.
The Widget tree you write in build() methods is just a lightweight, immutable description of UI — widgets are cheap to create and thrown away on every rebuild. Flutter uses that description to update a parallel Element tree, which is long-lived and knows how to diff the new widget configuration against the old one (this is the reconciliation step, similar in spirit to React's virtual DOM diffing).
Each Element that needs to draw something is backed by a RenderObject, which performs the actual layout (sizing and positioning) and painting (turning itself into drawing commands). Those drawing commands are handed to the engine (Skia or Impeller), which rasterizes them into pixels via the GPU. This three-tree split is why Flutter can skip expensive work: if a widget's configuration hasn't meaningfully changed, the element can reuse its existing render object instead of creating a new one.
Interview Tips
- →If asked to go deeper, mention that `const` constructors let Flutter skip rebuilding a widget entirely because it can prove the instance is identical.
Related Questions
What is Flutter?
Flutter is Google's open-source UI toolkit for building natively compiled apps for mobile, web, and desktop from a single Dart codebase.
Why should you use const widgets in Flutter?
A `const` widget is created once at compile time and reused across rebuilds — Flutter can skip rebuilding it entirely because it knows the instance can never change.