Dart is single-threaded by default, yet a Flutter or Dart application can handle timers, API requests, user interactions, file operations, and asynchronous code without freezing everything.
One important reason is Dart’s event loop.
The event loop works with two important queues:
- Microtask Queue
- Event Queue
The most important rule is simple:
Dart processes pending microtasks before processing the next event from the event queue.
Understanding this behavior helps you predict the execution order of Future, async/await, timers, streams, and other asynchronous operations.
What Is the Dart Event Loop?
Each Dart isolate has its own execution flow and event loop.
When synchronous Dart code runs, it executes first. Asynchronous work can schedule callbacks that will run later.
A simplified model looks like this:
Synchronous Code
↓
Microtask Queue
↓
Event Queue
↓
Microtask Queue
↓
Next Event
↓
...
The important point is that Dart does not simply execute asynchronous callbacks in the exact order in which you see them in the source code.
The queue where a callback is scheduled matters.
What Is the Microtask Queue in Dart?
The microtask queue contains asynchronous work that should execute as soon as the current synchronous operation finishes, before Dart processes another regular event.
You can explicitly schedule a microtask using:
import 'dart:async';
void main() {
scheduleMicrotask(() {
print('Microtask executed');
});
print('Normal code executed');
}
Output:
Normal code executed
Microtask executed
Why?
Because the synchronous print() executes first.
After synchronous execution finishes, Dart processes the pending microtask.
The execution order is therefore:
Synchronous Code
↓
Microtask Queue
↓
Event Queue
What Is the Event Queue in Dart?
The event queue contains regular asynchronous events waiting for the isolate to process them.
Events can come from operations such as:
- Timers
- I/O completion
- User interactions
- Stream events
- External asynchronous operations
- Certain
Futureoperations
For example:
void main() {
Future(() {
print('Future executed');
});
print('Normal code executed');
}
The output is:
Normal code executed
Future executed
The synchronous code finishes first. Afterward, the event loop can process the scheduled asynchronous event.
Microtask Queue vs Event Queue
Here is the core difference:
| Feature | Microtask Queue | Event Queue |
|---|---|---|
| Priority | Higher | Lower |
| Runs after synchronous code | Yes | Yes |
| Runs before next event | Yes | No |
| Common example | scheduleMicrotask() | Future(), timers, I/O events |
| Best for | Small urgent asynchronous work | Normal asynchronous operations |
The event loop prioritizes microtasks before moving to the next event.
That priority is what makes the difference important.
Simple Microtask vs Future Example
Consider:
import 'dart:async';
void main() {
Future(() {
print('Future');
});
scheduleMicrotask(() {
print('Microtask');
});
print('Normal');
}
The output will be:
Normal
Microtask
Future
Even though the Future appears before scheduleMicrotask() in the source code, the microtask executes first.
Why?
Initially, the queues conceptually look like:
Microtask Queue
----------------
Microtask
Event Queue
----------------
Future
Dart finishes:
print('Normal');
Then it drains the microtask queue.
Only after pending microtasks have been processed does it continue with the next event.
Therefore:
Normal
↓
Microtask
↓
Future
Understanding Future() in Dart
A common misunderstanding is that every Future behaves exactly the same way.
It does not.
For example:
Future(() {
print('Task');
});
creates asynchronous work that is scheduled to run later through the event-processing mechanism.
Example:
void main() {
print('Start');
Future(() {
print('Future');
});
print('End');
}
Output:
Start
End
Future
This happens because the current synchronous code must finish first.
What About Future.microtask()?
Dart also provides:
Future.microtask()
As the name suggests, it schedules computation using the microtask queue.
Example:
void main() {
print('Start');
Future(() {
print('Normal Future');
});
Future.microtask(() {
print('Microtask Future');
});
print('End');
}
Output:
Start
End
Microtask Future
Normal Future
The microtask receives priority over the regular future event.
scheduleMicrotask() vs Future.microtask()
Both can schedule work through the microtask queue.
scheduleMicrotask()
scheduleMicrotask(() {
print('Hello');
});
It directly schedules the callback as a microtask.
Future.microtask()
Future.microtask(() {
print('Hello');
});
This is useful when you also want a Future representing the result.
For example:
final result = Future.microtask(() {
return 100;
});
result.then((value) {
print(value);
});
In normal application development, you rarely need to manually manage microtasks. Most asynchronous code should use standard Future, async, and await patterns.
What About Future.delayed()?
Consider:
Future.delayed(Duration.zero, () {
print('Delayed Future');
});
A zero duration does not mean:
Execute immediately.
It means the callback can run asynchronously after the current synchronous execution, through the event-processing mechanism.
Example:
import 'dart:async';
void main() {
print('Start');
Future.delayed(Duration.zero, () {
print('Future delayed');
});
scheduleMicrotask(() {
print('Microtask');
});
print('End');
}
Expected order:
Start
End
Microtask
Future delayed
Again, the microtask queue gets priority.
Timer.run() and the Event Queue
Dart also provides:
Timer.run(() {
print('Timer');
});
Timer.run() schedules a callback asynchronously as soon as possible through the timer/event mechanism.
Example:
import 'dart:async';
void main() {
print('Start');
Timer.run(() {
print('Timer');
});
scheduleMicrotask(() {
print('Microtask');
});
print('End');
}
The microtask runs before the timer callback:
Start
End
Microtask
Timer
Execution Priority in Dart
A useful mental model is:
1. Current synchronous code
↓
2. Drain microtask queue
↓
3. Process next event
↓
4. Drain newly scheduled microtasks
↓
5. Process next event
↓
6. Continue...
This explains many Dart asynchronous execution-order questions.
Nested Microtasks
Now consider a more interesting example:
import 'dart:async';
void main() {
scheduleMicrotask(() {
print('Microtask 1');
scheduleMicrotask(() {
print('Microtask 2');
});
});
Future(() {
print('Future');
});
}
Output:
Microtask 1
Microtask 2
Future
The second microtask is created while Dart is processing the first one.
Dart continues draining the microtask queue before processing the next event.
Conceptually:
Microtask 1
↓
Creates Microtask 2
↓
Microtask 2
↓
Future Event
This behavior is powerful, but it can also cause problems.
Microtask Starvation
Because microtasks have priority, continuously adding new microtasks can prevent the event queue from getting a chance to run.
Consider:
import 'dart:async';
void repeat() {
scheduleMicrotask(repeat);
}
void main() {
repeat();
Timer.run(() {
print('Will this get a chance to run?');
});
}
Each microtask schedules another microtask.
Conceptually:
Microtask
↓
Microtask
↓
Microtask
↓
Microtask
↓
...
The event loop keeps finding pending microtasks.
As a result, regular events can be delayed indefinitely.
This is known as event queue starvation.
For that reason, scheduleMicrotask() should not be used as a replacement for normal asynchronous programming.
Future.then() and Microtasks
Future.then() deserves special attention.
When a Future completes, callbacks registered with methods such as:
.then()
are scheduled asynchronously according to Dart’s Future scheduling rules, commonly through microtask processing once the Future has completed.
For example:
void main() {
Future.value(10).then((value) {
print('Future value: $value');
});
print('End');
}
Output:
End
Future value: 10
Even though Future.value() represents an already available value, the .then() callback does not interrupt the currently executing synchronous code.
This keeps Future-based asynchronous behavior predictable.
How async and await Fit Into the Event Loop
Consider:
Future<void> loadData() async {
print('Loading');
await Future.delayed(
const Duration(seconds: 1),
);
print('Loaded');
}
void main() {
print('Start');
loadData();
print('End');
}
Initially, Dart executes:
Start
Loading
End
After the delayed Future completes, the asynchronous function can continue and print:
Loaded
So the final output is approximately:
Start
Loading
End
Loaded
await does not block the entire isolate while waiting for the Future.
Instead, execution of that asynchronous function pauses, allowing the event loop to process other work.
A More Practical Execution Example
Consider:
import 'dart:async';
void main() {
print('1');
Future(() {
print('2');
});
scheduleMicrotask(() {
print('3');
});
Future.microtask(() {
print('4');
});
Future.delayed(Duration.zero, () {
print('5');
});
print('6');
}
First, synchronous code runs:
1
6
Next, microtasks execute in the order they were scheduled:
3
4
Then regular asynchronous events can execute:
2
5
Therefore, the expected output is:
1
6
3
4
2
5
Understanding this example gives you a strong foundation for reasoning about Dart’s asynchronous execution model.
Microtask Queue in Flutter
The same Dart event-loop concepts apply to Flutter because Flutter applications run Dart code.
However, manually scheduling microtasks is usually unnecessary.
In a real Flutter application, you will more commonly work with:
Future
async
await
Stream
Timer
For example:
Future<void> fetchUsers() async {
final response = await api.getUsers();
users = response;
}
This is much easier to maintain than manually controlling microtask scheduling.
Microtask vs addPostFrameCallback
Flutter developers sometimes confuse:
scheduleMicrotask()
with:
WidgetsBinding.instance.addPostFrameCallback()
They solve different problems.
A microtask means:
Run this asynchronous work before the next regular event when the current synchronous work finishes.
A post-frame callback means:
Run this callback after Flutter finishes rendering the current frame.
For example:
WidgetsBinding.instance.addPostFrameCallback((_) {
// Work after the frame has been rendered.
});
This is often useful when you need BuildContext after the initial layout, want to show a dialog after a screen appears, or need measurements after layout.
Do not replace addPostFrameCallback() with scheduleMicrotask() without understanding the lifecycle requirement.
When Should You Use scheduleMicrotask()?
Use it only when work genuinely needs to happen before the next event.
For example:
scheduleMicrotask(() {
updateInternalState();
});
It can be useful in low-level libraries or framework-style code where precise scheduling matters.
For ordinary Flutter application development, prefer:
Future
async
await
because the intent is clearer and the code is easier to maintain.
When Should You Use the Event Queue?
Most normal asynchronous application work naturally belongs to event-based processing.
Examples include:
API requests
Timers
File operations
Database operations
User interactions
Network responses
Stream events
You normally do not manually push these operations into the event queue. Dart’s asynchronous APIs handle the scheduling for you.
Common Mistake: Thinking async Means Parallel
Asynchronous code is not automatically parallel code.
For example:
Future<void> fetchData() async {
// asynchronous operation
}
does not mean Dart automatically created another CPU thread.
An isolate has its own event loop and processes Dart execution sequentially.
For CPU-intensive parallel work, Dart provides isolates.
This distinction is important:
Async/Await
↓
Concurrency without blocking while waiting
Isolates
↓
Separate isolate execution for independent work
Microtask Queue vs Event Queue vs Isolate
These concepts should not be confused.
| Concept | Purpose |
|---|---|
| Microtask Queue | High-priority asynchronous callbacks |
| Event Queue | Regular asynchronous events |
| Event Loop | Coordinates execution of queued work |
| Future | Represents a value/error available later |
| async/await | Simplifies Future-based asynchronous code |
| Isolate | Independent Dart execution environment |
Microtasks and events operate within an isolate’s event-processing model.
Isolates are used when you need independent execution, especially for CPU-heavy work.
Best Practices
For most Dart and Flutter applications, follow a few simple rules.
Prefer async/await
Instead of manually managing scheduling:
Future<void> loadUser() async {
final user = await repository.getUser();
updateUser(user);
}
This is easier to understand and maintain.
Avoid unnecessary microtasks
Do not write:
scheduleMicrotask(() {
scheduleMicrotask(() {
scheduleMicrotask(() {
// ...
});
});
});
unless you have a very specific scheduling requirement.
Keep synchronous work short
The event loop cannot make heavy synchronous CPU work disappear.
A huge synchronous loop can still block responsiveness.
Use isolates for CPU-heavy work
For expensive calculations, parsing, image processing, or other CPU-heavy operations, consider isolates rather than trying to solve the problem with microtasks.
Understand execution order
When debugging asynchronous behavior, ask:
Is this synchronous?
Is this a microtask?
Is this an event?
When does this Future complete?
These questions usually make execution order much easier to understand.
Quick Execution Cheat Sheet
Remember this:
Synchronous Dart Code
↓
Microtask Queue
↓
Next Event
↓
Microtasks created by that event
↓
Next Event
↓
...
Or even more simply:
SYNC
↓
MICROTASK
↓
EVENT
For example:
print('A');
Future(() => print('B'));
scheduleMicrotask(() => print('C'));
print('D');
Output:
A
D
C
B
If you understand why this happens, you understand the most important difference between Dart’s microtask queue and event queue.
Frequently Asked Questions
What is the microtask queue in Dart?
The microtask queue contains asynchronous callbacks that Dart processes after the current synchronous execution and before moving to the next regular event.
What is the event queue in Dart?
The event queue contains regular asynchronous events waiting to be handled by an isolate’s event loop, such as timer and I/O-related events.
Which has higher priority: microtask or event queue?
The microtask queue has priority. Dart drains pending microtasks before processing the next event.
Is Future() a microtask?
A normal:
Future(() {
// work
});
is scheduled for later event processing.
However:
Future.microtask(() {
// work
});
explicitly uses microtask scheduling.
Therefore, you should not assume that every Future is simply a microtask.
Is Future.delayed(Duration.zero) a microtask?
No. A zero-duration delayed Future is still scheduled asynchronously through timer/event processing rather than being given microtask priority.
Should I use scheduleMicrotask() in Flutter?
Usually, no.
Most application code is clearer with Future, async, and await. Use scheduleMicrotask() when you specifically need microtask scheduling and understand why that priority is required.
Can too many microtasks slow down a Flutter app?
Yes. Continuously scheduling microtasks can delay normal events and create event starvation. Keep microtask work short and use it only when necessary.
Conclusion
The difference between the microtask queue and event queue in Dart mainly comes down to scheduling priority.
Dart first executes the current synchronous code. After that, it drains pending microtasks before processing the next event from the event queue.
The easiest mental model is:
Synchronous Code
↓
Microtask Queue
↓
Event Queue
However, the process continues as a loop: after an event executes, Dart again handles pending microtasks before moving to another event.
For everyday Flutter development, you normally do not need to control these queues manually. Use Future, async, and await for normal asynchronous operations, and reach for scheduleMicrotask() only when precise scheduling is actually necessary.
Once you understand this execution model, debugging asynchronous Dart code becomes much easier because you can predict what executes now, what executes later, and what gets priority.
