связаться

обсудить проект

Как избежать ошибок после асинхронных
операций во Flutter

29 мая 2026 · ? просмотров · ? мин

Ноутбук с Flutter и Visual Studio Code на темном фоне, разработка Flutter-приложений.

подписаться на канал

...

Обсуждаем тренды AI, разработки IT проектов
с экспертами рынка
и других отраслей

Содержание

Обновление экрана после асинхронной
Сетевые запросы, отмена и порядок ответов
FutureBuilder, Stream и ручные подписки
Диалоги, навигация и BuildContext после ожидания
Практический чек-лист для ревью
Заключение

Во Flutter экран связан с жизненным циклом виджета: пользователь может вернуться назад, открыть другую вкладку или свернуть приложение, после чего состояние экрана уже будет уничтожено. При этом асинхронная операция может продолжать выполняться: сетевой запрос, обработка данных или отложенный callback не завершаются мгновенно.

Основная сложность заключается в том, что после ожидания состояние приложения может измениться: экран мог быть закрыт, пользователь мог ввести новый поисковый запрос, а активная вкладка — смениться. Если после этого без дополнительных проверок обновить состояние или выполнить действие с интерфейсом, приложение может показать устаревшие данные, вызвать лишнюю перерисовку или получить ошибку при обращении к уже неактуальному экрану.

В этой статье рассматриваются практические сценарии, которые часто встречаются в обычных Flutter-приложениях: загрузка данных, поиск, работа с подписками и обновление интерфейса после асинхронной операции.

Содержание

Обновление экрана после асинхронной операции

Когда код ожидает результат асинхронной операции и затем обновляет интерфейс, между этими действиями проходит некоторое время. За этот период экран может быть закрыт, пользователь может перейти на другой экран, а данные формы или текущего запроса могут потерять актуальность.

Проблемный пример:

Future<void> loadProfile() async {
  final profile = await repository.fetchProfile();
 
  setState(() {
    _profile = profile;
  });
}

Если экран успели закрыть, вызов setState для уже уничтоженного состояния во Flutter приведет к ошибке (или к предупреждению в зависимости
от версии и режима).

Даже если ошибку не видно сразу, это признак того, что код пытается обновить интерфейс, который уже неактуален.

Базовое исправление для виджета с State: перед обновлением проверить, подключен ли еще виджет к дереву:

Future<void> loadProfile() async {
  final profile = await repository.fetchProfile();
 
  if (!mounted) return;
 
  setState(() {
    _profile = profile;
  });
}

mounted здесь простыми словами означает: «этот экран еще на экране, его состояние еще живое». Если пользователь уже ушел — выходим и не трогаем интерфейс.

Похожая ситуация возможна и в проектах, где состояние вынесено в Bloc
или Cubit. В этом случае экран может закрыться, а связанный с ним объект состояния — быть освобожденным.

Если после этого асинхронная операция завершится и код попробует отправить новое состояние, приложение может получить ошибку.
Например, в Cubit это может выглядеть так:

class ProfileCubit extends Cubit<ProfileState> {
  ProfileCubit(this.repository) : super(const ProfileState.initial());
 
  final ProfileRepository repository;
 
  Future<void> loadProfile() async {
    emit(const ProfileState.loading());
 
    final profile = await repository.fetchProfile();
 
    emit(ProfileState.loaded(profile));
  }
}

Если ProfileCubit был закрыт вместе с экраном во время ожидания, последний emit уже не должен выполняться. Более аккуратный вариант:

class ProfileCubit extends Cubit<ProfileState> {
  ProfileCubit(this.repository) : super(const ProfileState.initial());
 
  final ProfileRepository repository;
 
  Future<void> loadProfile() async {
    emit(const ProfileState.loading());
 
    final profile = await repository.fetchProfile();
 
    if (isClosed) return;
 
    emit(ProfileState.loaded(profile));
  }
}

Смысл остается тем же: после ожидания нужно проверить, что объект, который должен обновлять интерфейс, все еще актуален. Для StatefulWidget это обычно mounted, для Cubit — проверка isClosed.

Сетевые запросы, отмена и порядок ответов

Другая частая история — пользователь быстро меняет ввод (поиск, фильтры, переключение вкладок). Вы отправили несколько запросов подряд. Ответы приходят не обязательно в том порядке, в каком отправляли.

Упрощенный пример:

Future<void> onQueryChanged(String query) async {
  setState(() => _loading = true);
 
  final results = await repository.search(query);
 
  if (!mounted) return;
 
  setState(() {
    _loading = false;
    _results = results;
  });
}

Пользователь набрал «ко», потом быстро дописал «кот». Пришел сначала ответ на длинный запрос «кот», потом — на короткий «ко». Если последним вы покажете результат для «ко», на экране окажется устаревший список, хотя в поле уже другое слово.

Что можно сделать без усложнения архитектуры:

Вариант А: счетчик или «номер запроса»

Запоминаете, какой запрос последний по смыслу, и игнорируете
все остальное:

int _searchGeneration = 0;
 
Future<void> onQueryChanged(String query) async {
  final generation = ++_searchGeneration;
 
  setState(() => _loading = true);
 
  final results = await repository.search(query);
 
  if (!mounted || generation != _searchGeneration) return;
 
  setState(() {
    _loading = false;
    _results = results;
  });
}

Идея простая: если пользователь снова изменил строку поиска, номер поколения изменился, и старый ответ просто выбрасывается.

Вариант Б: отмена на стороне клиента

Если HTTP-клиент умеет отменять запрос, можно при новом действии пользователя прервать предыдущую операцию. Это особенно полезно
для поиска, фильтров, автодополнения и экранов, где пользователь быстро меняет параметры. В таких сценариях старый запрос уже не нужен: даже
если он успешно завершится, его результат не должен попадать в интерфейс.

У популярной библиотеки Dio для этого используется CancelToken.
Это небольшой объект, который передается в конкретный сетевой запрос
и позволяет позже отправить этому запросу сигнал отмены.
Сам по себе CancelToken не останавливает всю бизнес-логику приложения: он только сообщает HTTP-клиенту, что результат этого запроса больше не нужен.

Общая идея такая: перед новым запросом отменяем предыдущий токен, создаем новый и передаем его в сетевой слой.

Пример для поиска:

CancelToken? _searchCancelToken;
 
Future<void> onQueryChanged(String query) async {
  _searchCancelToken?.cancel();
  _searchCancelToken = CancelToken();
 
  setState(() => _loading = true);
 
  try {
    final results = await repository.search(
      query,
      cancelToken: _searchCancelToken,
    );
 
    if (!mounted) return;
 
    setState(() {
      _loading = false;
      _results = results;
    });
  } on DioException catch (error) {
    if (CancelToken.isCancel(error)) return;
 
    if (!mounted) return;
 
    setState(() {
      _loading = false;
      _error = 'Не удалось загрузить результаты';
    });
  }
}

В dispose текущий запрос тоже стоит отменить, потому что экран больше
не будет использовать его результат:

@override
void dispose() {
  _searchCancelToken?.cancel();
  super.dispose();
}

Важно не воспринимать отмену как единственную защиту. Запрос может завершиться почти одновременно с отменой, а часть логики может выполняться уже после ответа сервера. Поэтому проверка mounted после await все равно остается полезной.

На практике отмену запроса часто сочетают с проверкой актуальности результата.

Это снижает риск ситуации, когда сетевой ответ успел завершиться до обработки сигнала отмены и все равно попал в код обновления интерфейса.

Альтернативное решение. Задержка запроса при поиске

Для поиска часто полезно не отправлять запрос сразу после каждого изменения текста. Пользователь может быстро набрать несколько символов подряд, и промежуточные значения ему уже не нужны. В таком случае запрос можно выполнять только после короткой паузы, например через 300-500 миллисекунд после последнего ввода.

Обычно это называют debounce: старый отложенный запуск отменяется,
а новый создается заново при каждом изменении текста.

Пример:

Timer? _searchDebounce;
 
void onQueryChanged(String query) {
  _searchDebounce?.cancel();
 
  _searchDebounce = Timer(const Duration(milliseconds: 400), () {
    _search(query);
  });
}
 
Future<void> _search(String query) async {
  setState(() => _loading = true);
 
  final results = await repository.search(query);
 
  if (!mounted) return;
 
  setState(() {
    _loading = false;
    _results = results;
  });
}

В dispose таймер тоже нужно отменить:

@override
void dispose() {
  _searchDebounce?.cancel();
  super.dispose();
}

Такой подход уменьшает количество лишних запросов и снижает вероятность устаревших ответов. При этом он не заменяет полностью проверку актуальности результата: запрос все равно может выполняться некоторое время и завершиться уже после изменения экрана.

FutureBuilder, Stream и ручные подписки

Во Flutter данные часто приходят в интерфейс через Future, поток событий или ручную подписку. В таких сценариях важно не только отобразить результат, но и правильно связать асинхронную операцию с жизненным циклом экрана. Ошибки обычно возникают в двух местах: загрузка запускается повторно при каждом перестроении виджета или подписка продолжает работать после закрытия экрана.

Повторное создание Future при перестроении виджета

Если Future создается непосредственно внутри метода build, то при каждом перестроении виджета может запускаться новая загрузка.

В результате интерфейс может повторно переходить в состояние ожидания, а приложение — выполнять лишние сетевые запросы или вычисления.

Проблемный пример:

@override
Widget build(BuildContext context) {
  return FutureBuilder<List<Item>>(
    future: repository.loadItems(),
    builder: (context, snapshot) {
      // ...
      return const SizedBox.shrink();
    },
  );
}

Более корректный подход — создать Future один раз в месте с понятным жизненным циклом, например в initState, и сохранить его в поле состояния:

late final Future<List<Item>> _itemsFuture;
 
@override
void initState() {
  super.initState();
  _itemsFuture = repository.loadItems();
}
 
@override
Widget build(BuildContext context) {
  return FutureBuilder<List<Item>>(
    future: _itemsFuture,
    builder: (context, snapshot) {
      // ...
      return const SizedBox.shrink();
    },
  );
}

В этом случае загрузка не будет запускаться повторно при каждом последующем вызове build.

Ручные подписки на поток и их завершение

Поток может продолжить отправлять события после того, как экран уже закрыт. Если подписка создается вручную через listen, ответственность
за ее завершение лежит на самом экране. Иначе обработчик события может попытаться вызвать setState у состояния, которое уже было уничтожено.

Проблемный пример:

late final StreamSubscription<Message> _subscription;
 
@override
void initState() {
  super.initState();
 
  _subscription = chatRepository.messages.listen((message) {
    setState(() {
      _messages.add(message);
    });
  });
}

Здесь подписка создается, но в показанном коде не видно, где она завершается. Если пользователь уйдет с экрана, поток все еще может отправить новое сообщение, а обработчик попробует обновить уже неактуальный интерфейс.

Более корректный вариант:

late final StreamSubscription<Message> _subscription;
 
@override
void initState() {
  super.initState();
 
  _subscription = chatRepository.messages.listen((message) {
    if (!mounted) return;
 
    setState(() {
      _messages.add(message);
    });
  });
}
 
@override
void dispose() {
  _subscription.cancel();
  super.dispose();
}

Проверка mounted защищает обновление интерфейса, а cancel в dispose завершает саму подписку. Для StreamBuilder часть этой работы выполняет сам виджет, но если поток или подписка создаются вручную, их жизненный цикл все равно нужно контролировать явно.

Диалоги, навигация и BuildContext после ожидания

BuildContext привязан к месту виджета в дереве «здесь и сейчас». После ожидания дерево могло измениться: экран убрали, родитель перестроился.

Поэтому опасно делать цепочку вида «подождали → сразу вызываем навигацию или достаем наследника через контекст», не проверив, что контекст еще валиден.

В современных версиях Flutter для этого есть свойство
у контекста: context.mounted. Если оно ложно — контекст не стоит использовать для поиска родителей, навигации и показа диалогов.

Параллельно для класса с State по-прежнему уместно mounted перед setState.

Например, экран отправляет форму на сервер и после успешного ответа должен показать диалог:

Future<void> submitForm(BuildContext context) async {
  final result = await repository.sendForm();
 
  showDialog<void>(
    context: context,
    builder: (context) {
      return AlertDialog(
        title: const Text('Готово'),
        content: Text(result.message),
      );
    },
  );
}

Проблема в том, что к моменту завершения запроса пользователь уже мог закрыть экран. В этом случае перед использованием context нужно проверить, что он все еще связан с деревом виджетов:

Future<void> submitForm(BuildContext context) async {
  final result = await repository.sendForm();
 
  if (!context.mounted) return;
 
  showDialog<void>(
    context: context,
    builder: (context) {
      return AlertDialog(
        title: const Text('Готово'),
        content: Text(result.message),
      );
    },
  );
}

Данная проверка важна для действий, которые зависят от положения виджета в дереве: открытия диалога, перехода на другой экран, показа SnackBar или обращения к объектам, полученным через контекст.

При этом проверка context.mounted не должна становиться способом везде передавать BuildContext внутрь асинхронной логики. Более устойчивая практика — выполнять запрос в слое состояния, а в интерфейсе реагировать на изменение этого состояния.

Тогда асинхронный метод не знает о диалогах, навигации и расположении виджета в дереве.

Например, Cubit может только менять состояние:

Future<void> submitForm() async {
  emit(const FormState.sending());
 
  final result = await repository.sendForm();
 
  if (isClosed) return;
 
  emit(FormState.success(result.message));
}

А экран уже решает, как отреагировать на успешный результат:

BlocListener<FormCubit, FormState>(
  listener: (context, state) {
    if (state is FormSuccess) {
      showDialog<void>(
        context: context,
        builder: (context) {
          return AlertDialog(
            title: const Text('Готово'),
            content: Text(state.message),
          );
        },А экран уже решает, как отреагировать на успешный результат:
      );
    }
  },
  child: const FormView(),
)

В таком варианте BuildContext остается в UI-слое, где его жизненный цикл понятнее. Асинхронная операция отвечает только за получение результата

и изменение состояния, а не за прямое управление интерфейсом после ожидания.

Практический чек-лист для ревью

Короткий список вопросов, которые хорошо задавать при просмотре кода:

— После любого ожидания есть ли проверка, что экран еще жив, перед setState?

— Если результат может прийти не по порядку (поиск, фильтры), есть ли защита от устаревшего ответа или отмена старого запроса?

— FutureBuilder: будущее не создается заново при каждом build без необходимости?

— Есть ли симметричная очистка: подписки и таймеры отменяются в dispose?

— После паузы не используется ли контекст вслепую для навигации и доступа к наследникам?

— Если используется Bloc или Cubit, асинхронная логика не должна напрямую зависеть от BuildContext; реакции интерфейса лучше выполнять при изменении состояния.

Эти пункты не требуют экзотических инструментов. Они помогают держать интерфейс предсказуемым там, где пользователь действует быстрее, чем успевает ответить сервер.

Заключение

Ожидание — обычная часть приложения. Ошибки начинаются там, где код делает вид, что за время паузы ничего не изменилось: экран все еще открыт, запрос все еще «правильный», контекст все еще годится для любых действий.

Достаточно нескольких привычек: проверять жизнь экрана перед обновлением, защищаться от устаревших ответов при частых действиях,
не перезапускать загрузку без нужды и закрывать подписки вместе
с экраном.

Тогда интерфейс реже применяет уже неактуальные результаты и остается предсказуемым в простых сценариях.