WidgetsBinding vs SchedulerBinding: Who Rings the Bell When Flutter Finishes Drawing?

Ever tried to access widget size in initState() and got 0.0?

Or ran code after build… but Flutter said,
“Too early, buddy.”

So who actually tells Flutter:
“Okay, the screen is done. You can run your code now.”

Meet: WidgetsBinding and SchedulerBinding.

Why This Matters

Flutter renders UI in frames, and different callbacks run at different stages of a frame.

Flutter paints your app like an artist.

If you interrupt while it’s still painting, you’ll see half-finished work.

Knowing when to run code avoids bugs that feel random but aren’t.

Let’s break it down in simple terms

Imagine Flutter as a school classroom.

🎨 Drawing Time (Frame Rendering)

• Students draw on the board

• Teacher says: “Draw!”

• Drawing happens in stages

🔔 Bell Rings (Post Frame)

Only after the drawing is complete can you:

• check the board

• take a photo

• add stickers

That bell is rung by Bindings.

There are three callbacks available in flutter which rendering flutter widgets.

Flutter Frame Phases

- Transient Callbacks

Transient callbacks are triggered at the beginning of a frame and are used to update animations and time-based changes.

This is Flutter warming up — animations stretching before the race.

Examples:

• AnimationController

• Ticker

- Persistent Callbacks

Persistent callbacks are responsible for laying out and painting the widget tree.

Flutter is actively drawing pixels on the screen here.

This is when:

• widgets get sized

• layouts are calculated

• UI is painted

- Post-Frame Callbacks

Post-frame callbacks run after the rendering pipeline has completed for a frame.

The painting is done.
You can safely look at the screen now.

This is the sweet spot for most UI-dependent logic.

WidgetsBinding

WidgetsBinding is the glue between the Flutter framework and the Flutter engine, coordinating widget lifecycle, rendering, and platform events.

It comes with WidgetsBindingObserver mixin which has many callbacks but one which required to use is didChangeAppLifecycleState that returns AppLifecycleState.

It’s the manager that understands widgets and the system.

It knows:

• when the app goes to background

• when widgets are built

• when UI is ready

Common usage

WidgetsBinding.instance.addPostFrameCallback((_) {
  // UI is fully rendered
});

---

SchedulerBinding

SchedulerBinding coordinates the scheduling of frames and callbacks with the system’s rendering pipeline.

It’s Flutter’s clock, focused only on time and frames.

It does not know:

• app lifecycle

• widgets

• context

It only knows:

“A frame just finished.”

❌ Common Mistakes

• Expecting initState() to mean “UI ready”

• Using SchedulerBinding for widget work

• Assuming build() runs only once

• Forgetting post-frame callbacks run once

WidgetsBinding vs SchedulerBinding (Side-by-Side)

🏁 TL;DR Recap

• Flutter renders in frames

• UI isn’t ready during initState()

• Post-frame = safe UI access

• WidgetsBinding = widgets + lifecycle

• SchedulerBinding = timing only

• Most apps → use WidgetsBinding

🔗 What’s Next

BuildContext: Why Every Widget Carries an Invisible Map

🌐Let's connect - Linkedin | Instagram | GitHub | Twitter