Производительность Flutter в сравнении с нативом

Java нативная?

Наверное тс имеет в виду андроид

Да, я имел ввиду разработку под Android на Java/Kotlin и под iOS на Swift. Вопрос родился из многочисленных обсуждений производительности на различных ресурсах, хотелось бы услышать срез мнений.

Есть, например, вот такое сравнение скорости работы Flutter в сравнении c Swift и React.Native на iOS, и Flutter тут показывает очень плохой результат при большом количестве элементов. https://blog.theodo.com/2023/09/ios-rendering-performance/

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

Вот выдержка из теста на iOS:

2000 views with Text

По итогу тестов на разных параметрах среднее стандартное отклонение составило:

SwiftUI: 24ms

React Native: 30ms

Flutter: 530ms

Хотелось бы услышать мнение людей, имевших дело с вопросом.

В 2023 Flutter перевели на рендер-движок Impeller (кроме Web), который использует Metal/Vulkan, что должно показать лучшую производительность в сравнении со старым Skia: https://docs.flutter.dev/perf/impeller.

React Native в версии 0.68 внедрил экспериментально «New Architecture», которая работает без моста между JS и нативом (bridgeless), что также должно хорошо сказаться на производительности. As of 2024, this version of React Native has been proven at scale and powers production apps by Meta: https://reactnative.dev/architecture/landing-page.

Однако актуальных бенчмарков найти не смог. Что по твоей ссылке, что, например, здесь – везде используется старый стек.

На vc.ru (там очень много разработчиков собирается, так как изначально сайт, в целом - про стартапы), в комментах многократно были дискуссии на данную тематику, люди пишут, что даже после перехода стало немного получше, но в целом - те же грабли.

Да, за примерами далеко ходить не надо, вот, например, год назад (то есть в 2024) был тред на Reddit и не где-нибудь, в сообществе разработчиков Flutter, что приложение 9to5Mac (популярное у маководов) перевели (на iOS) с Swift на Flutter, и оно ужасно лагать стало (на идентичном функционале). https://www.reddit.com/r/FlutterDev/comments/186mbxy/9to5mac_has_rebuilt_their_app_using_flutter/ (то есть проблема проявляется уже после перехода на новую архитектуру)

На видео видно, как оно ужаснейшим образом лагает после перехода на Flutter https://streamable.com/cwvwik

Да и Swift-разработчики от Flutter не в восторге, как и от любой мультиплатформы https://www.reddit.com/r/swift/comments/1i8os04/title_swift_vs_flutter_which_should_i_choose_for/

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

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

Невесело, если Flutter так хреново себя показывает.

Я сам меньше месяца назад взял Flutter, не имея никакого опыта в мобильной разработке. React Native даже не смотрел, из-за соображений, что он будет компилироваться в нативный код и обходить React Native по производительности, а также из-за JavaScript. О том, что современный React Native стал bridgeless и даёт писать на TypeScript узнал уже впоследствии. JUST DO IT подход, короче.

Натив даже не рассматривал из-за необходимости писать свой код для Android и iOS, а также исходя из предположения, что в моём случае требовательного к производительности дизайна не предвидится. Для сложных анимаций хочу попробовать Lottie, но это если и будет, то в самую последнюю очередь.

Сейчас тестирую сырой прототип на своём Xiaomi 11 Lite, на iOS даже не проверял ещё, поэтому выводы делать рано.

Для быстрого прототипирования Flutter субъективно легко зашёл. Есть опыт с WPF/C# под Венду, Flutter как мана небесная в плане вёрстки после WPF (в т.ч. наличием неплохих библиотек для разых компонентов и Material Design из коробки), на радостях даже сделал возможность переключения светлой/тёмной темы; Dart после C# относительно без проблем заходит.

С Reddit заинтересовал комментарий касательно шейдеров:

Well. When developer don’t attach precompiled shaders to published builds that may be the result. Most of them don’t know they have to do this manually. Also it appears that developers without native experience tend to put big Columns inside SingleChildScrollView. I’d say yank most of the time it’s issue with developers.

Для меня вердикт примерно таков:

Use what you’ll most likely be able to stay motivated with and finish the project. If it really becomes a problem in the future (Swift or Flutter) you can always pivot - by that point if you’re still working on the app you’ll be passionate or successful enough to be willing to start re-writing features

Кстати, в прошлом году появился форк Flutter – Flock:

Flock redefines speed. With a reworked rendering engine, it ensures buttery-smooth animations and faster load times, even for complex UIs. This makes Flock the go-to choice for developers building apps where responsiveness is non-negotiable.

Натив лучше /thread

Все эти кросс фреймворки хороши только для POC каких нибудь или простых по дизайну приложений. Если взаимодействие будет с железом или нужно будет выжимать проценты быстродействия то только натив, даже возможно используя С++ какой-нибудь.

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

Вот и я много раз слышал подобные мнения, как в профильных чатах в Telegram, так и на других ресурсах (vc.ru, reddit и прочие), что как ты не вертись - всё равно натив тащит, а вся мультиплатформа - это для прототипирования и быстрого запуска (POC и MVP). Касательно применения - да, всё как вы описали, т.е., нанимается один разработчик, вместо целой команды, причём часто это ещё и делается с умыслом сымитировать «бурную деятельность»: выпустим «мультиплатформенный продукт», который на деле так лагает, что пользоваться им почти невозможно.

Мне вообще кажется, что Flutter - изначально ущербный концепт. Если бы Google его представили, как инструмент для POC/MVP, то проблем бы не было, а так, по факту, просто клепается одно тормознутое приложение за другим, причём это даже заметно стало последние годы, что приложения очень тормознутые стали, в целом, потому что Google пиарит это всё своим гугловским ресурсом, как «прогрессивное решение», а по факту, очередная тормознутая мультиплатформа. По поводу того, что «обычно просто думают, что можно будет не нанимать дорогих мобильных разработчиков и переиспользовать опыт фронтендеров» - Flutter, кстати, и в обратном направлении работает. То есть, мобильных разработчиков можно на фронтенде использовать.

Было бы, интересно, кстати, ещё замерить скорость работы Flutter на фронтенде против чистого JavaScript, ну тут я думаю тоже всё печально, как и с любым фронтенд-фреймворком… Пока писал это предложение - решил загуглить, и вот пожалуйста, сравнение Flutter с JS фронтендом:

https://codewithandrea.com/videos/flutter-web-html-css-js-performance-comparison/

Отставание больше чем на порядок от JS на небольшом сайте

Кстати, на большом количестве объектов React(!) на замерах показал отставание от JS в 28 раз

https://stackoverflow.com/questions/68115288/react-js-vs-vanilla-js-performance-28x-faster

Даже самые минималистичные virtual-DOM фреймворки (например, Preact) как минимум раз в десять медленнее JS

https://gomakethings.com/just-how-much-faster-is-vanilla-js-than-frameworks/

Ещё раз о силе JavaScript на фронтенде…

Я думаю, можно подытожить хорошей цитатой из этого https://dev.to/nikl/react-is-slower-than-vanilla-js--pfo обсуждения:

Highly optimised VanillaJS will always be faster than any framework. Period.

That said, such code would likely be a nightmare to work with. It’s a trade-off.

Harvard Business Review пишет, что компании, которые выходят на рынок первыми, получают на 30% больше доли рынка.

если вы осознали эту мысль, то дальше можете писать хоть на ассемблере

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

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

Да никто не спорит, что для быстрого запуска Flutter идеален. Фронтенд, мобайл - обе платформы разом, десктоп, просто идеальный фреймворк, что бы быстро собрать и запустить что-то. Просто потом, когда приложение разрастается (а оно всегда разрастается) по идее его надо на что-то нормальное переписывать, а его никто не переписывает, по итогу получаем повсеместное наличие приложений с средней задержкой рендера элемента в полсекунды, вплоть до полутра секунд и выше на большом количестве элементов (с замеров Flutter на iOS).

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

Современный фронтенд это вообще дичь в плане ресурсоёмкости. Даже для базовых задач используются ресурсоёмкие фреймворки, по итогу у пользователя в райнтайме на машине огромная куча кода вращается, когда там надо, скажем два меню сделать (для чего уже даже JS не нужен) и несколько манипуляций с DOM.

Однако актуальных бенчмарков найти не смог. Что по твоей ссылке, что, например, здесь – везде используется старый стек.

https://nateshmbhat.medium.com/flutter-vs-react-native-performance-benchmarks-you-cant-miss-%EF%B8%8F-2e31905df9b4

Там, кстати в комментах дельный комментарий, касательно производительности React Native

For that test you used Animated package from RN. But almost nobody use it nowadays due to performance. Fair test should be done with Reanimated3 library, commercial standard for React Native apps. Also, FastImage is quite outdated lib as well. You can use stock Image, or expo/image (better solution) Plus, you can try to measure performance with new architecture enabled (it’s disabled in grade settings now). List test also has not optimized code, without any memoization and etc, what can influence performance. Also, you can try to measure performance with a FlashList instead of FlatList. Best regards.

Автор статьи же переделал потом на Reanimated и в репе бенчмарка есть коммит соответствующий. См. ответ автора к этому комменту.

когда приложение разрастается … его надо на что-то нормальное переписывать

в узких кругах широко распространено мнение, что для бизнес приложений производительности флаттера хватает, с харрошим таким запасом
а синтетика типа стопицот анимированных штукоёвин, да в ресайзящиеся контейнеры, да поскроллим так чтоб ум за разум зашел, да чтоб не вышел - это такоэ, боевых применений не имеет.

Ну я там уже выше кидал пример как flutter лагает на базовом функционале (блоки в которых картинка + текст), как только элементов чуть больше чем несколько. То есть для банковского приложения, с несколькими блоками и куцым функционалом это пойдёт, но всё, что больше - всё, он не вывозит вообще никак. При работе с графикой - даже простая графика трепыхается и дребежжит (fps мало). Flutter, насколько я заметил, просто терпеть не могут в ui/ux тусовке (bloatware же - по сути) и очень любят в бизнес-среде. Диаметрально противоположные мнения. Даже тут был старый тред по flutter, я по нему пробежался - одно из первых сообщений это жалобы на производительность. Много лет прошло, а воз и ныне там.

Qt/C++, Lazarus, wxWidgets