💡Привет! Это Анна, Friflex Flutter Team Lead.

Сегодня поговорим об утечках памяти во Flutter-приложениях. Рассмотрим, что может их вызывать и почему не все объекты очищаются самостоятельно.

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

Для снижения утечек памяти в Dart есть специальный механизм —Garbage Collector (GC). Его основная задача — выполнять автоматическую очистку неиспользуемых объектов в программе. GC самостоятельно отслеживает все объекты, которые создаются в процессе работы. Затем очищает те объекты, которые не имеют активные ссылки в программе.

Представим, что у нас есть некоторый класс User. Метод createUser() внутри себя создаст его экземпляр и выполнит с ним некоторые манипуляции. После завершения работы метода createUser() объект user больше не будет иметь активных ссылок, и GC легко его очистит.

void main() {
  createUser(); // Вызываем функцию, которая внутри создает пользователя
  print('Пользователь создан, но больше не используется');
  // После этого GC может удалить объект User
}

void createUser() {
  final user = User(name: 'Anna');
  print('Привет, ${user.name}');
  // Когда функция завершится, переменная user исчезнет из области видимости
}

Но если создать пользователя на уровень выше, в самом main(), GC очистить его не сможет, так как активная ссылка будет существовать.

void main() {
  final user = User('Alice');
  // Даже если мы больше не используем user, ссылка на него все еще существует.
  // GC не удалит объект.
}

Больше подробностей о работе GC можете найти в этих статьях
▪️ Flutter: Don’t Fear the Garbage Collector
▪️ Garbage Collection in Dart and Its Implications in Flutter
▪️ How Dart’s Garbage Collector Works (And When It Fails You!)

Как мы выяснили, Garbage Collector не может очистить все объекты, поэтому многие источники утечки памяти разработчику требуется отслеживать самостоятельно.

Наиболее часто встречающиеся:
✔️ контроллеры — например, TextEditingController, PageController
✔️ подписки — StreamSubscription
✔️ таймеры — Timer
✔️ слушатели — при добавлении addListener()
✔️ глобальные и статические объекты

Здесь стоит соблюдать ряд простых правил:
▫️ если создаете контроллер или подписку, обязательно вызывайте методы dispose() или cancel()
▫️ таймеры также необходимо отменять с помощью cancel()
▫️ при добавлении слушателя через addListener() не забывайте удалять его через removeListener()
▫️ если в коде глобальные или статические объекты вам больше не нужны, можно явно обнулить их ссылки, присвоив null
▫️ систематически проверяйте свое приложение на утечки памяти

📎Отследить утечки памяти вам помогут специальные инструменты, например, Dart DevTools (вкладка Memory) и библиотека leak_tracker_flutter_testing.

🎉 Результаты розыгрыша:

🏆 Победитель:
1. Shakhan Saken uli (@sha_khan)

✔️Проверить результаты

🔗Всем привет, это Роза, Flutter Dev Friflex

Сегодня сделаем с вами обзор библиотеки по локализации — slang. Многие из вас наверняка слышали про .arb и работали с intl, но про slang, возможно, вы слышите впервые.

Что же это такое?
Это библиотека для генерации локализаций. У нее есть ряд существенных преимуществ по сравнению с intl.

Давайте по порядку!

Генерация
Slang поддерживает больше форматов, чем intl: JSON, YAML, ARB и CSV.

Код генерируется командой:

dart run slang

Также можно использовать build_runner,  если добавить дополнительный пакет slang_build_runner.

Перед генерацией необходимо создать конфигурационные файлы —  slang.yaml или build.yaml. Они во многом похожи на l10n.yaml, но позволяют настроить больше параметров.

Поддержка placeholders
Здесь все стандартно: plural, gender. Но кроме placeholders так же есть возможность работы с links, richText.

{
  "user": {
    "messageCount": {
      "one": "У тебя 1 сообщение",
      "other": "У тебя {count} сообщений"
    }
  }
}

Получаем

t.user.messageCount(count: 5);

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

Если ключа нет — компилятор не даст собрать проект.  

Поддержка Flutter
Пакет slang_flutter предоставляет провайдер для управления локалями в проекте.
Можно легко переключать язык в рантайме, получать переводы через контекст context.t и использовать ленивую инициализацию делегатов.

CLI-команды
Библиотека предоставляет набор CLI-команд:

dart run slang                # генерация файлов локализации
dart run slang analyze        # поиск неиспользуемых и отсутствующих переводов
dart run slang normalize      # сортировка переводов по базовой локали
dart run slang configure      # автообновление CFBundleLocalizations
dart run slang edit move loginPage authPage   # переименование или перенос ключей
dart run slang migrate arb src.arb dest.json  # миграция из arb в json

Runtime overrides
Slang поддерживает runtime overrides —  вы можете менять переводы на лету, без пересборки приложения.

Несколько замечаний:
✔️Переопределения могут быть частичными – обновляются только указанные ключи
✔️Повторное переопределение заменяет предыдущее
✔️Новые переводы анализируются, но не активируются
✔️Плейсхолдеры (name) остаются без изменений

❕Не стоит сразу бросаться внедрять slang во все проекты. Он может быть избыточен для небольших проектов, у него сложнее конфигурация, чем у intl. У вас могут возникнуть сложности при работе с многомодульными проектами, где нужно объединять переводы из разных пакетов. Также типобезопасность делает невозможным использование динамических ключей, что в некоторых сценариях может ограничивать гибкость.

Я лишь представила краткий обзор в этом посте, для подробной информации — посетите библиотеку.

🟢Проблема Scrollable.ensureVisible в ListView: почему она до сих пор не решена

Привет, это Катя, Flutter Dev Friflex. Сегодня расскажу о давней проблеме — ограничении метода Scrollable.ensureVisible, которое не работает для элементов, находящихся за пределами видимости в ListView.

Суть проблемы
Метод Scrollable.ensureVisible должен прокручивать список до нужного виджета, но работает он только для элементов, которые уже отрендерены на экране. Когда элемент находится далеко за пределами видимости, Flutter просто не создает для него контекст, и метод перестает работать.

Как проявляется
Допустим, у вас ListView с 11 элементами. При попытке прокрутить к элементу с индексом 1-7 все работает отлично. Но как только пытаетесь прокрутить к 8-му, 9-му или дальше — ничего не происходит.

// Не работает для элементов вне экрана
WidgetsBinding.instance.addPostFrameCallback((_) {
  Scrollable.ensureVisible(selectedDataKey.currentContext);
  // currentContext будет null для невидимых элементов!
});

Почему до сих пор не исправлено
Команда Flutter признала эту проблему еще в 2018 году. Причина — техническая сложность реализации. Чтобы прокрутить к элементу, Flutter должен знать его позицию и размер. Но для невидимых элементов эта информация недоступна, так как они еще не созданы.

Flutter не знает:
▫️в какую сторону прокручивать список
▫️какой offset использовать
▫️какой высоты будет целевой элемент

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

Workaround решения

Вариант 1: SingleChildScrollView для статичных списков

Если список небольшой и не меняется, замените ListView на SingleChildScrollView с Column:

SingleChildScrollView(
  child: Column(
    children: [
      Container(key: firstKey, child: Text('Item 1')),
      Container(key: secondKey, child: Text('Item 2')),
      // Все элементы рендерятся сразу
    ],
  ),
)

// Теперь ensureVisible работает
Scrollable.ensureVisible(firstKey.currentContext);

Минус: не подходит для длинных списков — все элементы рендерятся сразу, что убивает производительность.

Вариант 2: ScrollablePositionedList

Самое популярное решение — использовать пакет scrollable_positioned_list, который добавляет нужную функциональность:

ItemScrollController _scrollController = ItemScrollController();

ScrollablePositionedList.builder(
  itemScrollController: _scrollController,
  itemCount: items.length,
  itemBuilder: (context, index) => items[index],
)

// Прокрутка к любому индексу
_scrollController.scrollTo(
  index: 150,
  duration: Duration(seconds: 1),
  curve: Curves.ease,
);

Это решение работает даже для элементов далеко за пределами экрана.

Вариант 3: Ручная прокрутка жестами

Хелпер для тестов, который эмулирует прокрутку до появления элемента:

Future<void> ensureVisibleByScrolling(
  Finder finder, {
  required Offset scrollFrom,
  Offset scrollBy = const Offset(0, -50),
  int maxScrolls = 100,
}) async {
  final gesture = await widgetTester.startGesture(scrollFrom);
  
  for (var i = 0; i < maxScrolls; i++) {
    await gesture.moveBy(scrollBy);
    await pump();
    
    if (widgetTester.widgetList(finder).length == 1) {
      break;
    }
  }
  
  await gesture.cancel();
  await widgetTester.ensureVisible(finder);
}

Этот метод постепенно прокручивает список, пока элемент не появится на экране.

Статус в 2025 году
К сожалению, официального решения в стандартной библиотеке Flutter до сих пор нет. Issue открыт с 2018 года, и команда Flutter признала, что не планирует в ближайшее время добавлять нативный scrollToIndex для ListView.

А какой вариант решения проблемы используете вы?

Для тех, кто говорит на языке Flutter! Сегодня на CrossConf разыгрываем футболки и игру мемори.

Условия простые:
✅Подписаться на @flutterfriendly

✅Написать под этим постом: «Я сегодня на CrossConf»

Троих победителей определим с помощью генератора случайных чисел в 17:30. Забрать приз можно будет на стенде Friflex.

Всем перевет, Серёже предложили рассказать про CrossConf, его доклады.
Пойду слушать, все расскажу 💼

Адель рассказал про то, как они пытаются продвинуть Аврору для разработчиков, сделал довольно прикольный uikit, аналогичный Cupertino и Fluent, с поддержкой нативных фич

В принципе прикольно 🤔

Уже вижу как флаттер разработчики пишут псевдонативные прилки под Аврору 😁

Стас Чернышев жалуется (объективно) на Dart 🎉

Станислав Ильин рассказал что сложные вещи в начале лучше не делать, да и вообще пишите по простому, чтобы всем было понятно 🤙

Пришел в этот раз без костюма Марио, я расстроен 😭

Юра показал, что флаттер может быть везде, даже можно под чайник собрать ui 🥳

Довольно прикольно, что это возможно, но сообщество довольно долго обновляет до актуальных версий сдк, исключение пожалуй ОМП и их Аврора

Хотя, как фишка, вдруг кому то пригодиться, недавно под Tizen и webos делал мини кинотеатр с стримингом, было больно интересно 😁 (

На пятых докладах из двух потоков у меня начала плавиться голова 🫠

Андрей рассказал про то, как ПО для управления дрона писали на флухтере, много низкоуровневых штук, как будто оказался на парах в вузе по ассемблеру 💀

Надо потыкать дрона, попробовать поуправлять 🙈

Никита уже рассказывал про свой пакет для BDUi (Duit), как делал оптимизацию новой версию

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

Конструктор как у divkit от Яндекса, но и написание без jsonов 🔔

@floral_whale (Роза) ❤️, рассказывала про их сервис локализации с OTA обновлениями, прикольно

Из известных мне вроде знаю только о phrase

Ждем когда доработают до конца 👍
Выглядит вроде как production-ready

🟢Привет, это Катя, Flutter Dev Friflex.

Сегодня расскажу, как устроен Event Loop и почему понимание его работы критически важно для написания эффективного асинхронного кода.

Event Loop — это механизм управления асинхронностью, который обрабатывает задачи (events) в определенном порядке. Он позволяет выполнять операции ввода-вывода и другие длительные процессы без блокировки основного потока.

Основные компоненты
✔️Future — объект, представляющий результат асинхронной операции, который станет доступен в будущем
✔️Stream — поток асинхронных данных, который может передавать несколько значений со временем
✔️Event Loop — центральный механизм, управляющий очередями задач и их последовательным выполнением
✔️Система очередей
Event Loop работает с двумя типами очередей:

▪️Microtask Queue — очередь микрозадач с наивысшим приоритетом. Выполняется сразу после завершения синхронного кода, до обработки основных событий. 
▪️Event Queue — основная очередь событий, содержащая таймеры, операции ввода-вывода, Future и другие задачи.

Порядок: Сначала синхронный код → все микрозадачи → задачи из Event Queue.

Пример

import 'dart:async';

void main() {
  print('Начало');

  Timer(Duration(seconds: 1), () => print('Timer'));
  scheduleMicrotask(() => print('Microtask 1'));
  Future(() => print('Future')).then((_) => print('Future then'));
  scheduleMicrotask(() => print('Microtask 2'));

  print('Конец');
}

Вывод:

Начало
Конец
Microtask 1
Microtask 2
Future
Future then
Timer

Сначала выполняется синхронный код (Начало, Конец), затем обе микрозадачи, и только после этого Future и Timer из основной очереди.

Работа с async/await
Ключевые слова async и await упрощают работу с асинхронным кодом, делая его похожим на синхронный:

Future<void> fetch() async {
  print('Загрузка...');
  await Future.delayed(Duration(seconds: 2));
  print('Готово!');
}

void main() async {
  print('Старт');
  await fetch();
  print('Финиш');
}

Вывод:

Старт
Загрузка...
(пауза 2 секунды)
Готово!
Финиш

Оператор await приостанавливает выполнение функции до завершения Future, но не блокирует Event Loop — он может обрабатывать другие задачи.

Итого
Синхронный код всегда выполняется первым, микрозадачи имеют приоритет перед обычными событиями, а Future и Timer обрабатываются в порядке добавления в Event Queue.

❓Закрепим знания задачкой

В какой последовательности будут выведены значения?

import 'dart:async';

void main() {
  print('1');
  
  Future(() => print('2')).then((_) {
    print('3');
    scheduleMicrotask(() => print('4'));
  });
  
  scheduleMicrotask(() => print('5'));
  
  Future(() => print('6'));
  
  print('7');
}

🌟Всем привет! Это Анна, Flutter Team Lead Friflex

Наверняка каждый Flutter-разработчик знает, что такое Isolate и как он работает. Немного освежим теорию в памяти.

Dart — однопоточный язык программирования. Когда мы создаем Flutter-приложения, все вычисления и операции выполняются по умолчанию в основном и единственном потоке — изоляте (Isolate).

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

В Dart изоляты можно запускать тремя основными способами:
1️⃣ Isolate.run() — метод запустит новый изолят, в котором будет выполнена переданная функция. По завершении операций из изолята вернутся ожидаемые данные, а поток самостоятельно завершится
2️⃣ Isolate.spawn() — также запускает новый изолят, в который необходимо передавать функцию для выполнения. При этом в отличие от изолята, запущенного через run(), дает возможность непрерывно обмениваться сообщениями с основным потоком
3️⃣ Isolate.spawnUri() — работает аналогично spawn() за одним исключением. В изолят можно отправить прямую ссылку на Dart-программу.

Уверена, простые примеры вы легко сможете найти в интернете или реализовать сами. А сейчас в качестве примера рассмотрим более сложную задачу.

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

В решении этой задачи нам поможет Isolate.spawn() и порты получения данных ReceivePort().

Шаг 1. Создаем top-level метод парсинга данных в изоляте _parseInIsolate(). Метод должен принимать обязательно два порта отправки данных — порт отправки результата парсинга и порт отправки ошибок. Именно в этом методе мы закладываем логику обработки ошибки. В случае перехвата ошибки, отправляем ее в порт ошибок errorSendPort

Future<void> _parseInIsolate(
  ({
    SendPort dataSendPort,
    SendPort errorSendPort,
    List<Map<String, dynamic>> rawDataList,
  }) params,
) async {
  final result = <ResultEntity>[];

  for (final data in params.rawDataList) {
    try {
      // здесь выполняем парсинг каждого элемента
      result.add(...);
    } on Object catch (error, stackTrace) {
      // в случае ошибки парсинга конкретного объекта
      // отправляем ошибку обратно в главный изолят
      params.errorSendPort.send((error: error, stackTrace: stackTrace));
      continue;
    }
  }
  // в порт данных отправляем готовые объекты
  params.dataSendPort.send(result);
}
 

Шаг 2. Создаем метод получения данных fetchData(). В нем выполняем запрос на бэкенд. Дальнейшие шаги будут дополнять этот метод

Future<List<ResultEntity>> fetchData() async {
    final rawDataList = await _httpClient.get('v1/examples/data');
}

3 шаг. После получения данных создаем два порта ReceivePort(). Один порт будет отвечать за передачу обработанных объектов, второй — за передачу данных о локальных ошибках парсинга

final dataPort = ReceivePort();
final errorPort = ReceivePort();

Шаг 4. Открываем новый изолят и запускаем в нем метод _parseInIsolate(). Обязательно передаем в него два порта отправки и данные, которые надо обработать

    final isolate = await Isolate.spawn(
      _parseInIsolate,
      (
        dataSendPort: dataPort.sendPort,
        errorSendPort: errorPort.sendPort,
        rawDataList: rawDataList,
      ),
    );

Продолжение в комментариях👇