Оптимизация производительности приложений на Flutter

Производительность Flutter-приложения напрямую зависит от того, как написан код. Лишние перестройки UI, тяжелые операции в основном потоке, неправильная работа со списками и изображениями - все это ведет к фризам, падению FPS и раздраженным пользователям. В этом посте обсудим наиболее распространенные ошибки, которые превращают быстрый фреймворк в тормознутое приложение.

Лишние перестройки UI:

Самая частая проблема - setState, который пересобирает все дерево виджетов целиком. Даже если изменился один текст, Flutter заново вызывает build() для всех дочерних элементов. В маленьком проекте это незаметно. Когда же внутри есть списки, картинки и сложные layout'ы, каждое нажатие кнопки начинает тормозить интерфейс. Решение - использовать ValueListenableBuilder, StreamBuilder или аналоги, которые обновляют только нужную часть.

Отсутствие const:

Многие забывают про const. Без него каждый rebuild создает новые объекты виджетов, даже если они идентичны предыдущим. Это увеличивает нагрузку на сборщик мусора и процессор. В больших списках или сложных UI это дает заметный прирост производительности - достаточно просто добавить const там, где это возможно.

Логика внутри build():

build() может вызываться десятки раз в секунду - при анимациях, скролле, обновлениях. Если внутри выполнять сортировку, фильтрацию или парсинг, это напрямую убивает производительность. Даже простая операция sort() на среднем списке может занимать миллисекунды, а для 60 FPS на каждый кадр есть всего 16 мс. Вся логика должна быть вынесена в initState или бизнес-слой.

ListView без builder:

Когда вы используете ListView(children: [...]), Flutter создает все элементы списка сразу, даже если пользователь видит только первые 5–10. При 100+ элементах это приводит к лишним аллокациям, перегрузке памяти и долгому первому рендеру. ListView.builder создает элементы лениво - только те, что видны на экране. Это значительно снижает нагрузку.

Отсутствие ключей:

Без key Flutter не может корректно сопоставить старые и новые элементы при обновлении списка. В результате он пересоздает виджеты вместо их обновления, что приводит к лишним rebuildам и визуальным багам - например, прыгающим элементам. ValueKey или ObjectKey решают эту проблему.

Частый setState в таймерах:

Частые вызовы setState (например, каждые 16–100 мс) перегружают UI-поток. Flutter вынужден постоянно пересчитывать layout и перерисовывать виджеты. Для анимаций есть специализированные инструменты: AnimationController, AnimatedBuilder. Они оптимизированы и обновляют только нужные части UI в синхронизации с частотой кадров.

Огромный StatefulWidget:

Когда весь экран - один StatefulWidget, любое изменение состояния пересобирает всю структуру. Это дорого и плохо масштабируется. Разделение UI на маленькие независимые виджеты позволяет локализовать rebuildы, переиспользовать код и улучшить читаемость.

Future в build():

Если вызывать fetchData() прямо в build(), каждый rebuild создает новый Future и новый запрос. Это приводит к множественным HTTP-запросам, миганию UI и лишней нагрузке на сеть. Правильный подход - создать Future один раз (в initState) и переиспользовать его.

Картинки без кеша:

Image.network по умолчанию не обеспечивает полноценное кеширование. При каждом rebuild изображение может заново загружаться или декодироваться. В списках это особенно заметно. Библиотеки вроде cached_network_image добавляют дисковый и memory кеш, уменьшая количество запросов.

Opacity вместо прозрачных цветов:

Opacity создает отдельный compositing layer и требует дополнительного прохода рендеринга. Это дорогая операция, особенно внутри списков. В простых случаях достаточно использовать withOpacity у цвета - это не требует отдельного слоя.

Глубокая вложенность:

Каждый виджет добавляет стоимость на этапах build и layout. Глубокие деревья (10+ уровней) увеличивают время рендеринга. Часто разработчики используют лишние обертки (Container, Align, SizedBox), хотя их можно заменить более простыми конструкциями.

Тяжелый JSON в UI:

Парсинг большого JSON - CPU-bound операция. Если выполнять ее в UI-потоке, приложение зависает на время обработки. compute() позволяет вынести парсинг в background-изолят, освобождая UI-поток.

Вывод:

Большинство проблем с производительностью возникают не из-за сложности задачи, а из-за мелких решений, которые легко упустить в процессе разработки. Лишний rebuild, тяжелая операция в основном потоке, список без builder - каждое из этих решений кажется безобидным, пока приложение не начинает тормозить. Хорошая новость в том, что большинство описанных проблем решаются относительно просто. Главное - не откладывать это на потом.