Вы думали, что Flutter обладает производительностью, близкой к нативной? А вот и нет!

Результаты бенчмарка говорят об обратном.

Используя современные инструменты 2025 года, реальные устройства и повторяемую методологию, Flutter не просто не отставал от нативных iOS и Android. По нескольким ключевым показателям он их значительно превзошёл.

И не на погрешность округления.

Условия: никаких мнений, никаких оправданий

Чтобы избежать обычных войн фреймворков и анекдотических бенчмарков, сравнение строилось на одном правиле: всё должно быть одинаковым, кроме технологии.

Одно и то же приложение Flashcard Generator было реализовано трижды:

• Flutter
• React Native
• Полностью нативное (Swift на iOS, Kotlin на Android)

Пользовательский интерфейс, взаимодействия, поведение при прокрутке, рабочие нагрузки и пользовательские сценарии были намеренно идентичны.

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

Все измерения проводились на реальных устройствах, а не на симуляторах. Каждый тест проводился несколько раз в контролируемых условиях, отслеживая:

• Время рендеринга кадра
• Выпавшие и нестабильные кадры
• Кадры в секунду
• Время до первого кадра
• Увеличение объема памяти
• Размер бинарного файла

Целью было не просто понять скорость. Важно было понять, как эти фреймворки ведут себя, когда пользователи действительно касаются экрана.

Рендеринг кадров

iOS (60 Гц — бюджет 16,7 мс на кадр)

• Flutter: в среднем 1,72 мс, 2,45 мс p95 → огромный запас (примерно в 10 раз меньше бюджета)
• React Native: в среднем 16,65 мс, 16,75 мс p95 → на пределе
• Swift (нативный): в среднем 17,17 мс, 16,65 мс p95 → в среднем фактически превышает бюджет из-за периодически медленных кадров

Android (120 Гц — бюджет 8,3 мс на кадр)

• Flutter: в среднем 4,01 мс, 5,09 мс p95 → используется только ~48–61% бюджета
• React Native: в среднем 8,34 мс → на пределе
• Kotlin (нативный): в среднем 8,34 мс → также на пределе

На iOS при 60 Гц среднее время рендеринга кадра в Flutter составляло около 1,7 мс, при этом даже самые медленные кадры всё ещё были значительно ниже запланированного значения. Это не просто «хорошо». Это огромный запас.

С другой стороны, React Native и нативный Swift находились на грани допустимого времени рендеринга кадра в 16,7 мс. Они были в основном стабильны, но с небольшим запасом на сборку мусора, декодирование изображений или скачки компоновки.

Android при 120 Гц показал аналогичную картину.

Flutter стабильно рендерил кадры значительно ниже 8,3 мс, оставляя достаточно запаса для «поглощения шума» в реальных условиях. React Native и нативный Kotlin оба балансировали на пределе допустимого времени, плавно в идеальных условиях, но без страховки.

Удивительный вывод: Flutter был не просто плавным. Он плавный с огромным запасом.

Пропущенные кадры и задержки: что на самом деле чувствуют пользователи

iOS (60 Гц)

• Flutter: 0% пропущенных кадров, 0% задержек (jank)
• React Native: 15,51% пропущенных кадров, 1,8% задержек
• Swift: 1,61% пропущенных кадров, 1,41% рывков

Android (120 Гц)

• Flutter: 0% пропущенных кадров, 0% задержек
• React Native: 0% пропущенных кадров, 0% задержек (в этом запуске)
• Kotlin: 0,038% пропущенных кадров — практически ноль

Среднее время кадра — это хорошо, но именно пропущенные кадры ощущаются большим пальцем.

Как на iOS, так и на Android Flutter зафиксировал ноль пропущенных кадров и ноль задержек в этих тестах. Не «почти ноль». Ноль.

React Native испытывал трудности на iOS при прокрутке, пропущенные кадры возникали достаточно часто, чтобы это можно было измерить. Нативный Swift показал лучшие результаты, но всё ещё демонстрировал небольшие «хвосты», где частота кадров выходила за рамки допустимого.

На Android все три платформы показали хорошие результаты в этом конкретном сценарии, но Flutter снова продемонстрировал самые чистые временные показатели.

Если вас интересует ощущение прокрутки, это важнее, чем результаты синтетических тестов.

Кадры в секунду

iOS (максимум 60 FPS)

• Flutter → 59,31 FPS (~98,85%)
• React Native → 57,49 FPS (~95,8%)
• Swift → 58,54 FPS (~97,6%)

Android (максимум 120 FPS)

• Flutter → 117,75 FPS (~98,1%)
• React Native → 115 FPS (~95,8%)
• Kotlin → 119,84 FPS (~99,9%)

Flutter обеспечил почти полную допустимую частоту обновления на обеих платформах, колеблясь около 99% от теоретического потолка.

React Native отстал на несколько процентных пунктов как на iOS, так и на Android, что соответствует большему количеству пропущенных кадров.

Нативный Kotlin показал практически идеальные результаты на Android, в то время как нативный Swift на iOS продемонстрировал незначительные, но постоянные недостатки.

Ничего катастрофического здесь нет, но стабильность Flutter бросается в глаза.

Время до первого кадра: кто первым отображает пиксели

iOS

• Flutter: 16,67 мс (очень стабильно)
• React Native: 32,96 мс
• Swift: 41,37 мс (высокая вариативность)

Android

• Flutter: 10,33 мс
• React Native: 15,31 мс
• Kotlin: 16 мс (идеально стабильно)

Производительность при запуске часто считается  вторичным показателем, но первое впечатление всё ещё имеет значение.

Flutter оказался самым быстрым при первой отрисовке на обеих платформах. На iOS он достиг первого кадра примерно за одно обновление экрана, с очень небольшой вариативностью. На Android он снова оказался самым быстрым, хотя и с немного большей вариативностью.

React Native работал медленнее, но отличался исключительной стабильностью. Не мгновенный, но предсказуемый.

Нативный Swift преподнес наибольший сюрприз: хотя средний показал старта неплохие результаты, разброс был огромным. Некоторые запуски были быстрыми, другие — заметно медленными.

Конвейер запуска Flutter оказался более эффективным, чем многие ожидали.

Память и размер бинарного файла: единственные реальные компромиссы

Разница в памяти при интенсивной прокрутке:

iOS — Swift: ~9,7 МБ < Flutter: ~25,3 МБ < React Native: ~45,1 МБ

Android — Kotlin: ~6,3 МБ < Flutter: ~14 МБ < React Native: ~33 МБ

Размер бинарного файла (релизные сборки):

iOS — Swift: ~0,5 МБ < Flutter: 18,3 МБ < React Native: 20,2 МБ

Android — Kotlin: 13,3 МБ < Flutter: 41,6 МБ < React Native: 52,1 МБ

Это не сказка. Flutter не выигрывает везде.

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

Flutter использовал больше памяти, чем нативные приложения, но с очень небольшим разбросом и предсказуемым поведением. React Native продемонстрировал наибольший и наиболее нестабильный рост использования памяти на обеих платформах.

Размер бинарного файла следовал ожидаемой схеме:

• Нативные приложения представляли собой крошечные заглушки
• Flutter занял промежуточное положение
• React Native (особенно с Expo) показал наибольший размер

На практике, даже на бюджетном устройстве с 4 ГБ оперативной памяти и 128 ГБ хранилища, эти различия не имеют большого значения.

Кто же в итоге победил?

Flutter явно лидировал по следующим показателям:

• Среднее время рендеринга кадра
• Выпадение и задержки кадров
• Кадры в секунду
• Время до первого кадра

Он немного отставал от нативных приложений по следующим показателям:

• Использование памяти
• Размер бинарного файла

В течение многих лет существовала поговорка: «используйте нативные приложения для максимальной производительности, используйте кроссплатформенные приложения для более быстрой разработки». Это был компромисс. Скорость против удобства.

Этот тест показывает, что этот тезис устарел. Flutter больше не жертвует производительностью ради удобства кроссплатформенности. По таким важным показателям, как стабильность кадров, пропущенные кадры и время запуска, он превосходит нативный код, написанный компетентными разработчиками с использованием собственных инструментов.

Swift и Kotlin — отличные языки с превосходными инструментами. Но движок рендеринга Flutter делает сделан правильно — так, что даже нативные реализации платформ с трудом могут с ним сравниться.

Так что в следующий раз, когда кто-то скажет вам, что Flutter обладает «почти нативной» производительностью? Поправьте его. В 2026 году Flutter не будет обладать «почти нативной» производительностью.

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

Источник