👣 Влияет ли выбор state management на производительность Flutter?
Можно ли ускорить Flutter-приложение, просто выбрав другой state management? Автор данной статьи решил проверить это не на искусственном тесте, а на реальном приложении. Результат оказался неожиданным.
Как проводили тестирование:
Для эксперимента использовалось специально подготовленное Android-устройство с контролем температуры, CPU/GPU scaling и других факторов. Тестирование длилось пять дней, было проведено 2100 испытаний и 300 раундов на каждый подход.
Сравнивались семь подходов: setState как базовое решение, ChangeNotifier + Provider, Freezed + Provider + ValueNotifier, Bloc, Riverpod, GetX и Signals.
Измерялось прежде всего время build, а не искусственная скорость изменения состояния.
Результаты:
Provider + ChangeNotifier практически не отличается от обычного setState, как и Freezed + Provider + ValueNotifier.
GetX, Riverpod и Signals дают примерно +5-6 микросекунд к времени сборки. Звучит неплохо для бенчмарка, но в реальном приложении это практически ничего.
При 120 Гц бюджет одного кадра составляет примерно 8333 микросекунды. Дополнительные 6 микросекунд - это около 0,07% бюджета кадра. Разница находится далеко за пределами того, что имеет практическое значение для пользователя.
Что насчет Bloc:
Интереснее всего оказался результат Bloc. В тесте он позволил сократить среднее время сборки примерно на 21 микросекунду. Это по-прежнему ничтожно малая величина (0,263% при частоте обновления экрана 120 Гц), но, если рассматривать общую картину, это уже тот показатель, который теоретически может иметь значение.
Проблема в том, что реализация на Bloc отличалась не только библиотекой. В ней было больше мелких обновлений виджетов, а некоторые части иерархия виджетов располагалась иначе. И здесь всплывает главная сложность любых бенчмарков: мы сравниваем не state management, а архитектуру приложения.
🔗 Читать подробнее
💡 Вывод:
На основании этого эксперимента нельзя честно сказать, что Riverpod быстрее Provider или Bloc быстрее GetX. В реальном приложении разница между популярными state management решениями оказалась настолько маленькой, что выбирать библиотеку только по производительности практически бессмысленно.
Гораздо важнее, сколько виджетов обновляется, насколько большая часть иерархии виджетов пересобирается, что выполняется внутри метода build, сколько времени занимает расчет расположения и отрисовка, какие операции выполняются в главном потоке.
То есть проблема обычно не в том, выбрали вы Riverpod или Provider. Проблема в том, что именно вы заставляете Flutter перестраивать.
Выбор state management должен основываться на удобстве, читаемости и поддерживаемости кода. Производительность здесь - не главный критерий. Если ваше приложение тормозит, проблема почти наверняка не в библиотеке, а в том, как организована иерархия виджетов и сколько лишних обновлений виджетов происходит.
Подписаться на канал:
➡️ Flutter & Dart | Мобильный трудоголик
Можно ли ускорить Flutter-приложение, просто выбрав другой state management? Автор данной статьи решил проверить это не на искусственном тесте, а на реальном приложении. Результат оказался неожиданным.
Как проводили тестирование:
Для эксперимента использовалось специально подготовленное Android-устройство с контролем температуры, CPU/GPU scaling и других факторов. Тестирование длилось пять дней, было проведено 2100 испытаний и 300 раундов на каждый подход.
Сравнивались семь подходов: setState как базовое решение, ChangeNotifier + Provider, Freezed + Provider + ValueNotifier, Bloc, Riverpod, GetX и Signals.
Измерялось прежде всего время build, а не искусственная скорость изменения состояния.
Результаты:
Provider + ChangeNotifier практически не отличается от обычного setState, как и Freezed + Provider + ValueNotifier.
GetX, Riverpod и Signals дают примерно +5-6 микросекунд к времени сборки. Звучит неплохо для бенчмарка, но в реальном приложении это практически ничего.
При 120 Гц бюджет одного кадра составляет примерно 8333 микросекунды. Дополнительные 6 микросекунд - это около 0,07% бюджета кадра. Разница находится далеко за пределами того, что имеет практическое значение для пользователя.
Что насчет Bloc:
Интереснее всего оказался результат Bloc. В тесте он позволил сократить среднее время сборки примерно на 21 микросекунду. Это по-прежнему ничтожно малая величина (0,263% при частоте обновления экрана 120 Гц), но, если рассматривать общую картину, это уже тот показатель, который теоретически может иметь значение.
Проблема в том, что реализация на Bloc отличалась не только библиотекой. В ней было больше мелких обновлений виджетов, а некоторые части иерархия виджетов располагалась иначе. И здесь всплывает главная сложность любых бенчмарков: мы сравниваем не state management, а архитектуру приложения.
🔗 Читать подробнее
💡 Вывод:
На основании этого эксперимента нельзя честно сказать, что Riverpod быстрее Provider или Bloc быстрее GetX. В реальном приложении разница между популярными state management решениями оказалась настолько маленькой, что выбирать библиотеку только по производительности практически бессмысленно.
Гораздо важнее, сколько виджетов обновляется, насколько большая часть иерархии виджетов пересобирается, что выполняется внутри метода build, сколько времени занимает расчет расположения и отрисовка, какие операции выполняются в главном потоке.
То есть проблема обычно не в том, выбрали вы Riverpod или Provider. Проблема в том, что именно вы заставляете Flutter перестраивать.
Выбор state management должен основываться на удобстве, читаемости и поддерживаемости кода. Производительность здесь - не главный критерий. Если ваше приложение тормозит, проблема почти наверняка не в библиотеке, а в том, как организована иерархия виджетов и сколько лишних обновлений виджетов происходит.
Подписаться на канал:
➡️ Flutter & Dart | Мобильный трудоголик