Enhance Your Mobile Apps: Optimize Multitasking with Isolates

Imagine your Flutter app as a busy restaurant kitchen. The head cook — the UI thread — needs every dish (your animations, taps, scrolls) plated and served on time. Then you ask that same cook to also prep dessert, scrub the ovens, and take phone orders. Things slow down, and your diners start tapping their watches.

Dart isolates are extra chefs, each with a fully equipped kitchen of their own. They take the heavy lifting — parsing huge JSON files, resizing images, running complex calculations — off the head cook entirely, without ever crowding the main kitchen.

Mobile users expect a buttery-smooth UI even while an app crunches data in the background. On Flutter, the tool that makes that possible is the isolate.

1. Why multitasking matters on mobile

Every Flutter app runs its UI on a single main isolate — the platform's "UI thread." Heavy work (JSON parsing, file I/O, encryption, ML inference) run directly on that isolate blocks it, which shows up to the user as jank or, in the worst case, an ANR (Android's "app not responding" dialog). Moving that work to a background isolate lets the UI keep rendering frames at 60–120fps while the heavy lifting happens somewhere else entirely.

2. What exactly is an isolate?

An isolate is a Dart execution context with its own event loop and its own memory heap. Unlike traditional OS threads, isolates share no mutable state — they communicate exclusively by passing messages (SendPort ↔ ReceivePort) containing simple values or transferable typed data like Uint8List. If you're coming from Java or Kotlin, the right mental model is the actor model, not synchronized blocks — there's no shared memory to protect with a lock, because there's no shared memory at all.

3. When to reach for isolates

The common thread across all five: CPU-bound work that takes more than a few milliseconds. Isolates have real overhead to spin up — they're not the answer for work that's already fast, or for I/O-bound waiting (a network request awaiting a response isn't blocking anything; await already handles that without an isolate).

4. Quick win: compute() and Isolate.run() for one-shot tasks

Flutter's compute() spawns a temporary isolate, runs a pure function on it, returns the result, and tears the isolate down automatically:

Future<List<User>> loadUsers(String jsonStr) async {
  return compute(parseUsers, jsonStr);
}

List<User> parseUsers(String jsonStr) {
  final data = jsonDecode(jsonStr) as List<dynamic>;
  return data.map((e) => User.fromJson(e)).toList();
}

Since Dart 2.19, Isolate.run() does the same job with a slightly more ergonomic API — no separate top-level function required, since it accepts a closure directly:

Future<List<User>> loadUsers(String jsonStr) async {
  return Isolate.run(() {
    final data = jsonDecode(jsonStr) as List<dynamic>;
    return data.map((e) => User.fromJson(e)).toList();
  });
}

Both are zero-boilerplate and correctly self-cleaning — perfect for one-off tasks under a few hundred milliseconds. Isolate.run() is the more current recommendation from the Dart team for new code; compute() remains widely used and is what you'll see in most existing Flutter codebases, so it's worth recognizing both.

5. Full control: long-lived isolates, with cleanup that actually happens

For streaming data or an infinite processing loop, spawn and manage the isolate yourself — but the version of this pattern worth copying has to actually release the isolate when you're done with it, not just gesture at doing so in a bullet list below the code:

class BackgroundWorker {
  BackgroundWorker._(this._isolate, this._sendPort, this._receivePort);

  final Isolate _isolate;
  final SendPort _sendPort;
  final ReceivePort _receivePort;

  static Future<BackgroundWorker> spawn() async {
    final initPort = ReceivePort();
    final isolate = await Isolate.spawn(_entryPoint, initPort.sendPort);
    final sendPort = await initPort.first as SendPort; // handshake: get the worker's inbox

    final receivePort = ReceivePort();
    sendPort.send(receivePort.sendPort); // tell the worker where to send results back

    return BackgroundWorker._(isolate, sendPort, receivePort);
  }

  Stream<dynamic> get results => _receivePort;

  void send(String message) => _sendPort.send(message);

  void dispose() {
    _receivePort.close();
    _isolate.kill(priority: Isolate.immediate); // actually releases the isolate's memory
  }

  static void _entryPoint(SendPort initSendPort) {
    final commandPort = ReceivePort();
    initSendPort.send(commandPort.sendPort);

    SendPort? resultPort;
    commandPort.listen((message) {
      if (message is SendPort) {
        resultPort = message; // first message is always the result channel
      } else if (message is String) {
        final result = _doExpensiveStuff(message);
        resultPort?.send(result);
      }
    });
  }

  static String _doExpensiveStuff(String input) => input.toUpperCase(); // stand-in for real work
}

Usage, with the cleanup wired to the widget's own lifecycle so it can't be forgotten:

class _MyScreenState extends State<MyScreen> {
  BackgroundWorker? _worker;

  @override
  void initState() {
    super.initState();
    BackgroundWorker.spawn().then((w) {
      setState(() => _worker = w);
      w.results.listen((result) => print('Got: $result'));
    });
  }

  @override
  void dispose() {
    _worker?.dispose(); // the isolate dies with the widget that owns it
    super.dispose();
  }
}

The key structural point: dispose() isn't a suggestion mentioned separately from the example — it's tied directly to State.dispose(), so there's no code path where this isolate outlives the screen that created it and quietly leaks.

6. Pattern: a real isolate pool for concurrent jobs

Spinning up a fresh isolate for every short job — a batch of thumbnail resizes, say — pays the isolate-startup cost repeatedly for no benefit. A pool reuses a fixed number of long-lived workers instead. Here's a minimal, working one built on the BackgroundWorker above rather than a black-box package:

class IsolatePool {
  IsolatePool._(this._workers);

  final List<BackgroundWorker> _workers;
  int _nextWorker = 0;

  static Future<IsolatePool> spawn({int size = 3}) async {
    final workers = await Future.wait(List.generate(size, (_) => BackgroundWorker.spawn()));
    return IsolatePool._(workers);
  }

  Future<dynamic> submit(String task) {
    final worker = _workers[_nextWorker];
    _nextWorker = (_nextWorker + 1) % _workers.length; // round-robin dispatch
    final completer = Completer<dynamic>();
    late final StreamSubscription sub;
    sub = worker.results.listen((result) {
      completer.complete(result);
      sub.cancel();
    });
    worker.send(task);
    return completer.future;
  }

  void dispose() {
    for (final w in _workers) {
      w.dispose();
    }
  }
}

size: 3 for CPU-bound work is a reasonable default — Platform.numberOfProcessors - 1 leaves one core free for the UI isolate itself, which is worth reserving rather than saturating every core with background work. For genuinely production-grade pooling with load balancing and error recovery built in, the isolate_pool_2 or worker_manager packages on pub.dev cover more edge cases than this minimal version — but understanding the round-robin dispatch and reuse mechanism above makes debugging either package considerably easier than treating it as a black box.

7. Best practices and gotchas

8. Debugging tips

If frames are still dropping after moving work to an isolate, turn on Track widget rebuilds in DevTools' Inspector — if a widget is rebuilding on every frame regardless of what your isolate is doing, the isolate was never the bottleneck to begin with. If messages between isolates aren't arriving, check that both ports are still open — closing a ReceivePort silently ends its stream, and a common bug is closing one side too early during cleanup and being confused why send() calls seem to vanish. And be aware of platform lifecycle behavior: on Android, isolates spawned while the app is foregrounded can be suspended along with the rest of the app when it's backgrounded, so genuinely background work that must survive the app being closed belongs in WorkManager (Android) or a background fetch mechanism (iOS), not a Dart isolate.

9. Putting it together — a sample architecture

A concrete shape for a screen that decodes a large JSON payload from a network response without ever blocking the UI:

User taps "Refresh"
        │
        ▼
UI isolate: HTTP request (await — non-blocking, no isolate needed here)
        │
        ▼
Response body (raw JSON string) arrives on the UI isolate
        │
        ▼
Isolate.run(() => jsonDecode + parse into model objects)
        │             ← this is the one line that actually needed an isolate
        ▼
Parsed List<User> returned to the UI isolate
        │
        ▼
setState() → ListView rebuilds with the new data

The lesson worth taking from this diagram: only the CPU-bound decode-and-parse step needed an isolate. The network request itself was already non-blocking via await, and wrapping it in an isolate too would have added overhead for no benefit. Isolates are for CPU-bound work specifically — not a general-purpose "make this async" tool, which Future/await already are.

10. Conclusion

Isolates are Dart's built-in concurrency model, and the choice between the tools above comes down to shape of the work: compute() or Isolate.run() for a one-shot CPU-bound task, a hand-managed long-lived isolate for streaming or infinite work — with cleanup tied to whatever owns it — and a small pool when you have many short jobs arriving faster than one isolate can process them. Used for the CPU-bound cases they're built for, and skipped for the I/O-bound cases await already handles, they're the difference between an app that stutters under load and one that doesn't.

References

1. Dart concurrency: isolates

2. Isolate.run() — dart:isolate API reference

3. Flutter compute() function

4. TransferableTypedData — dart:isolate API reference

5. Background execution on Android — WorkManager