Можно ли ускорить Flutter-приложение, просто выбрав другой state management?
Автор нового benchmark решил проверить это не на искусственном тесте, а на реальном Flutter-приложении. Результат оказался довольно неожиданным 👀
В сравнении участвовали:
•
setState() — baseline•
ChangeNotifier + Provider•
Freezed + Provider + ValueNotifier•
Bloc•
Riverpod•
GetX•
Signals🧪 Как тестировали?
Автор измерял прежде всего время build, а не искусственную скорость изменения состояния.
Для эксперимента использовалось специально подготовленное Android-устройство с контролем температуры, CPU/GPU scaling и других факторов, способных повлиять на результаты.
Тестирование продолжалось:
5 дней 2100 испытаний 300 раундов на каждый подход
Цель — понять, оказывает ли выбор state management заметное влияние на производительность UI.
---
📊 Результаты
Provider + ChangeNotifier
Практически не отличается от обычного
setState().Freezed + Provider + ValueNotifier
Тоже показывает результат примерно на уровне baseline.
А вот:
GetX → примерно +5–6 μs Riverpod → примерно +5–6 μs Signals → примерно +5–6 μs
Звучит неплохо для benchmark'а, но в реальном приложении это практически ничего.
При 120 Hz бюджет одного кадра составляет:
1 000 000 / 120 ≈ 8 333 μsДополнительные 6 μs — всего около 0,07% бюджета кадра.
То есть разница находится далеко за пределами того, что имеет практическое значение для пользователя.
---
🤔 А что насчёт Bloc?
Интереснее всего оказался результат
Bloc.В конкретном тесте он оказался примерно на 21 μs быстрее vanilla.
Но это вовсе не означает, что Bloc быстрее остальных.
Почему?
Потому что реализация отличалась не только библиотекой. В ней были более гранулярные rebuild'ы, а некоторые элементы widget tree находились в других местах.
И здесь возникает важнейшая проблема benchmark'ов.
Мы можем сравнивать не state management, а архитектуру приложения.
---
🧩 Что действительно влияет?
Условно различия можно разделить на три уровня:
A — сама библиотека
Как реализована подписка и обновление состояния.
B — архитектурный подход
Насколько легко разделять состояние и ограничивать rebuild'ы.
C — стиль разработчика
Как именно конкретный человек построил widget tree.
Именно пункты B и C способны дать гораздо большую разницу, чем несколько микросекунд работы самой библиотеки.
---
🎯 Главный вывод
На основании этого эксперимента нельзя честно сказать:
❌ Riverpod быстрее Provider
❌ Bloc быстрее GetX
❌ Signals самый быстрый
❌ setState всегда производительнее
В реальном приложении разница между популярными state management решениями оказалась настолько маленькой, что выбирать библиотеку только по performance практически бессмысленно.
Гораздо важнее:
🔥 сколько widgets rebuild'ится
🔥 насколько большой subtree перестраивается
🔥 что выполняется внутри
build()🔥 сколько времени занимают layout и paint
🔥 какие операции выполняются на UI isolate
То есть проблема обычно не в том, выбрали вы Riverpod или Provider.
Проблема в том, ЧТО именно вы заставляете Flutter перестраивать. 🚀
Источники: Оригинал новости, нашёл тут
#Flutter #Dart #FlutterDev #StateManagement #Provider #Riverpod #Bloc #GetX #Performance #FlutterPulse #FlutterPulseNews