Future vs Stream for Continuous Polling: Which Keeps Memory Usage in Check?

Answer

For a single background consumer polling a REST endpoint every minute, use a sequential Future loop. Await each response before scheduling the next poll. A Stream is the better fit only when multiple independent consumers must react to the same result.

Confirmed vs. Likely

Confirmed: Neither Future nor Stream leaks memory by itself. Heap growth over hours comes from uncanceled subscriptions, an unclosed StreamController, retained response objects, listeners capturing large contexts, or buffered errors.

Likely: A linear async/await chain is easier to debug because stack traces follow the await path. A long-lived Stream spreads lifecycle, controller state, and error handling across emissions, making hour-long sessions harder to trace.

Recommended Pattern

Use a cancellable loop rather than Timer.periodic with an async callback. This prevents overlapping HTTP responses if a poll takes longer than one minute.

bool _running = true;

Future<void> _pollLoop() async {
  while (_running) {
    try {
      final res = await _pollEndpoint();
      _process(res); // release res after processing
    } catch (e, st) {
      _logError(e, st);
    }
    if (!_running) break;
    await Future.delayed(const Duration(minutes: 1));
  }
}

void dispose() {
  _running = false;
  // cancel any pending HTTP work if possible
}

If you choose a Stream, close it deterministically:

final _controller = StreamController<PollResult>.broadcast();
StreamSubscription? _sub;

void start() {
  _sub = _controller.stream.listen(_handle);
}

void dispose() {
  _sub?.cancel();
  _controller.close(); // after listeners are gone
}

Memory and Lifecycle Checks

• Cancel the Timer or set the loop flag to false in dispose.
• If using a StreamController, cancel all subscriptions before calling close(); do not add events after close.
• Do not store every Future or response in a list or map. Process and drop each response.
• Release BuildContext, large JSON, images, and listener closures after each poll so the GC can reclaim them.

Platform Reality

Confirmed: iOS and Android do not guarantee continuous background execution for hours. The OS may suspend or terminate the isolate. If the service must run while the app is backgrounded, use platform background fetch or a work-manager plugin; the in-app loop only covers foreground execution.

Verification

Run the service in Flutter DevTools memory view for an extended period. After garbage collection, the heap should not step upward with each poll. Log poll start, completion, error, and dispose to confirm no accumulation. This article assumes current stable Flutter; verify background plugin behavior against your target OS versions.

The one detail that would change this recommendation is whether more than one consumer needs each poll result. If yes, switch to a broadcast Stream with the lifecycle above; otherwise the sequential Future loop remains the simpler, lower-risk choice.