Падение FPS с 60 до 40 при скролле списка из 500+ элементов — типичный симптом неправильного управления памятью во Flutter. В высоконагруженных интерфейсах разница между использованием ListView.builder и неправильно настроенным CustomScrollView может составить до 30% в потреблении RAM и привести к ощутимым «фризам» на устройствах среднего сегмента.
Виртуализация списков и стоимость рендеринга
Основная ошибка новичков — использование стандартного ListView или SingleChildScrollView для больших массивов, что приводит к мгновенному созданию всех виджетов в дереве. При размере элемента в 200 КБ, список из 1000 позиций забьет память на 200 МБ еще до начала взаимодействия. Решение — ListView.builder или CustomScrollView с SliverList, которые реализуют ленивую загрузку (виртуализацию), отрисовывая только те элементы, что видны в viewport плюс небольшой запас (cacheExtent).
Кейс: в приложении-каталоге замена Column внутри SingleChildScrollView на ListView.builder сократила время первого кадра (First Frame) с 800 мс до 120 мс при списке в 200 элементов. Экспертный вывод: любая попытка обернуть список в SingleChildScrollView для реализации сложного дизайна убивает производительность; используйте Slivers для комбинирования разных типов скролла.
Оптимизация перерисовки через RepaintBoundary
Flutter перерисовывает весь слой, если один из его элементов изменился. В бесконечном скролле, где элементы содержат анимации или таймеры, это создает избыточную нагрузку на GPU. Обертывание тяжелых элементов списка в RepaintBoundary создает отдельный слой (Layer), что позволяет движку Skia/Impeller переиспользовать закэшированный битмап элемента вместо полной перерисовки всего экрана.
Практика показывает, что в списках с интегрированным видео или сложным градиентом использование RepaintBoundary снижает нагрузку на CPU на 15-20% при быстром скроллинге. Экспертный вывод: используйте RepaintBoundary только для визуально сложных элементов; избыточное их количество увеличит потребление памяти из-за создания лишних слоев.
Управление состоянием и предотвращение лишних build
Частая проблема — вызов метода build() для всего списка при обновлении одного элемента (например, лайк товара). Если логика обновления состояния завязана на корневой виджет, Flutter будет пересобирать сотни элементов, даже если они находятся вне зоны видимости. Здесь критически важна разработка мобильных приложений на Flutter: системный гид по выбору архитектурного паттерна (BLoC, Riverpod, Cubit) для масштабируемых проектов, чтобы изолировать обновления в конкретном виджете элемента списка.
Пример: переход от setState в корне к использованию BlocBuilder внутри элемента списка снизил количество вызовов build() с 50 до 1 на одно действие пользователя. Экспертный вывод: состояние элемента списка должно быть максимально атомарным; любой подъем состояния (state lifting) выше уровня элемента в бесконечном списке — это технический долг.
Пагинация и стратегия подгрузки данных
Бесконечный скролл требует четкого регламента обработки API. Оптимальный размер страницы (page size) составляет 20-40 элементов. Запрос более 100 объектов за раз увеличивает время ожидания ответа (TTFB) и может привести к лагу интерфейса при парсинге JSON в моделях данных. Важно реализовать «порог срабатывания» (threshold) — запрос следующей страницы должен уходить, когда пользователь доскроллил до 80% текущего списка, а не до самого конца.
В проектах с высокой нагрузкой неправильная реализация пагинации приводила к дублированию элементов при быстром скролле вверх-вниз. Решение — использование уникальных ключей (ValueKey) для каждого элемента. Экспертный вывод: всегда внедряйте debounce-фильтр на запросы пагинации, чтобы избежать «спама» API при резких рывках скролла.
Работа с изображениями и кэширование
Изображения — главный «пожиратель» памяти в списках. Использование CachedNetworkImage с параметром memCacheWidth/Height позволяет декодировать изображение в нужном размере, а не в полном разрешении оригинала. Например, картинка 4К, сжатая до 200px в памяти, занимает в 100 раз меньше места.
Кейс: в e-commerce приложении оптимизация размера кэшированных изображений снизила общий объем занимаемой RAM с 600 МБ до 180 МБ при пролистывании 300 товаров. Экспертный вывод: никогда не используйте Image.network для списков; только специализированные пакеты с контролем размера декодирования и кэшированием на уровне диска.
Вывод
Для достижения стабильных 60 FPS в тяжелых списках необходимо сочетать три уровня оптимизации: использование Slivers для виртуализации, изоляцию состояния через BLoC/Riverpod и жесткий контроль размера декодируемых изображений. Начинайте с профилирования через DevTools (Performance Overlay), чтобы найти конкретные «тяжелые» кадры. Избегайте SingleChildScrollView для массивов данных и ручного управления индексами в больших списках — это путь к утечкам памяти и деградации UX.