Comments 43
Эх сравнить бы в лоб этот Flutter с Tauri.
Что значит «в лоб»? Даже избранные места, Impeller супротив Canvas, непросто сравнить.
Чисто теоретически, WebView можно внедрить в Flutter, значит по скорости рендеринга Flutter проиграть не может. Но, если всё будет как обычно, проиграет по объёму и памяти.
Эх сравнить бы отдельно отказ от использования нативных компонентов с самостоятельной отрисовкой, что по мне есть очевиднейший для кроссплатформы шаг, и отдельно рендереры, и отдельно вычислительную производительность - Rust должен быть быстрее Dart, а JavaScript медленнее. Богатейшая тема…
В KMP порог входа существенно выше, чем во Flutter.
В KMP Куча конфигов повторяющихся, хотя сам по себе язык классный, но экосистема там сильно усложнена, наверное наследие от Java. Грубо говоря отличие только тем, что используется gradle вместо xml. Что бы сделать импорт зависимости ее надо прописать в нескольких местах.
А нельзя во flutter изображение рендерить в фоне сначала, а потом уже готовым выводить на экране?
А когда вы сделали миграцию? В React Native где-то погода назад переписали ядро, там сейчас сама архитектура ядра другая и скорость должна была поменяться драматически.
Flutter - это отличная технология, чтобы получать зарплату повыше из-за отсутствия спецов, но мой друг, который так делает, мне рассказывал, что там экосистема вообще пустая, почти ничего нету готового.
После смены архитектуры РН начал стабильно держать 60 фпс, но не более. Разрыв всё ещё весьма ощутим.
Очень странный у тебя друг. Начиная с того, что зарплаты флаттер разработчиков обычно чуть ниже, чем у нативщиков, и заканчивая огромнейшей экосистемой пакетов под любые задачи на все платформы, доступной в централизованном хранилище pub.dev.
там экосистема вообще пустая, почти ничего нету готового
Вы не попутали с KMP?
Кажется вы явно перепутали flutter с чем-то еще. Потому что в п.2 у вас оба утверждения, мягко говоря, странные.
Может влияет рынок Россия/СНГ, но вот как правило вакансии нативщиков в среднем выше (но это неточно, никаких убедительных доводов кроме личного наблюдения у меня нет).
Но вот второй постулат точно не про флаттер, там написано чуть больше чем нужно, даже mobX есть на флаттер. Я когда увидел, чуть со стула себя фейспалмом не снес. А потом ничего, втянулся :)
Актуальных пакетов/библиотек там больше чем на андроид
выйгрышь. Э-хе-хе.
низкая производительность на слабых Android-устройствах
Сомнительно, что с Flutter сильно лучше будет учитывая, что для комфортной разработки нужны нехилые такие системные ресурсы.
Однако с Flutter сильно лучше)))
Я присматриваюсь к кроссплатформенным фреймворкам для своего пет-проекта и Flutter конечно впечатляет своей дружелюбностью к разработчику. Тот же hot reload и пр. Но на моем стареньком железе все работает слишком медленно чтобы что-то разрабатывать. Казалось бы стоит задуматься об апргрейде, но на reddit пишут, что и 32 GB RAM мало. Попробовал поиграть с этим демо-примером на бюджетном Android, тоже подтормаживает. Думаю можно найти что-то более легковесное.
На реддите странные люди сидят. Дарт при отладке жрёт пару гигов ОЗУ, не более. Без каких-либо проблем разрабатываю на виндоноуте с 16гб озу. А что именно работает медленно? Просто у нас есть проблемы с анализатором сейчас, которые фиксят. Может то, с чем ты столкнулся, уже поправили.
Если говорить про пример, то последнее обновление там год назад. Соответственно там ещё не включен impeller, используется Skia. А у скии есть прикол с подтормаживаниями при первом запуске. Флаттер по производительности сейчас буквально лучшее, что есть, не считая полного натива, от которого он редко отстаёт.
А в какой плоскости проект? Кроссплатформу довольно комфортно и на относительно слабом железе можно делать на haxe + openfl. Если приложение чисто UI, то с HaxeUI, если более широкоразвлекательного толка, то с HaxeFlixel, хотя и у самого openfl достаточно богатый апи.
Пока что конкретного проекта нет, есть много задумок разных мелких приложений и утилиток офисного плана, которые бы хотелось делать не в виде веб-страничек, адреса которых все забывают, а чтобы можно было и оффлайн работать, и с общими данными на сервере, и на мобилке (если у человека нет компа), и на компьютере (где большой экран), и с локальными файлами-каталогами, и с локальной БД. Про Haxe вроде где-то слышал - судя по заголовкам выглядит интересно, но терзают смутные подозрения, что технология либо сыровата, либо бедна функционалом. Тем более что последняя статья на Хабре 5-летней давности.
UPD. Смотрю что для десктопа этот Haxe использует либо WxWidgets либо тянет тяжеловесный Electron с браузером. Соответственно вопрос - если я набросал интерфейс с кнопочками, который преобразовался в WxWidgets на десктопных приложухах, то каким образом этот интерфейс можно переиспользовать в мобильных приложениях и в веб-версии? Или по любому придётся для мобилок и веба с нуля специфические интерфейсы пилить?
За haxe не стоит никого "с маркетингом", поэтому он не на слуху. Нюансы, разумеется, есть. Но языку 20 лет, готовится к релизу 5 версия. На нем написан ряд весьма успешных проектов, есть компании, работа которых полностью построена на этой технологии. Если называть эту технологию сырой – вылизанных просто не существует.
По функционалу я вообще думаю конкурентов найти сложно. В какой плоскости функционал вас интересует? Могу подсказать.
Смотрю что для десктопа этот Haxe использует либо WxWidgets
В самом haxe вообще нет gui – это язык/транспилятор. На нем написан ряд gui фреймворков, каждый из которых может использовать свой подход к кроссплатформенности.
Если говорить про haxeui, то он реализует слой абстракции с переключаемыми бакэндами.
То есть, gui реализованные на haxeui можно запустить поверх: openfl, wxWidget, html, pixi.js, kha.
Можно просто собрать приложение всеми способами и сравнить, какой лучше подходит.
В этом случае сборка с wxWidget будет работать только на десктопе, но все остальные способы можно так или иначе запустить везде. Openfl/nme бэкэнды при этом самые универсальные. Они содержат в себе SDL и графический апи поверх него. Код на haxe в этом случае транспилируется в c++, слинкуется с этими библиотеками и будет рисовать кнопки через openGL на любой платформе с фолбэком в софтверный рендер, никаких внешних доп зависимостей при этом не потянет.
Ещё с осени Impeller это движок по умолчанию на Android и IOS, какая Skia?
И проблема с изображениями решается прекэшем полностью, а не частично
Если у вас картинки уже сразу после запуска, то достаточно прекэшить пока отображается сплэш запуска. А сами картинки желательно в webp перегнать для минимального размера.
А если выбросить оба фреймворка на помойку, будет еще быстрее. Но тогда нужно для IOS искать отдельно разработчиков.
Потратили полгода, заменяя одни костыли другими костылями чуть получше
А как же MAUI? Существовал в виде Xamarin когда ещё не было мобильной кроссплатформы как такового явления.
Как по мне, это тот самый гем - про который все забывают
Как быть, если хочется не только мобильное приложение, но и десктоп? Хочу из вебдева вкатиться в кроссплатформенную разработку и ищу такую серебрянную пулю, чтобы под силу было программисту в одиночку один раз код написать и везде его запустить ))
React Native вроде бы в десктоп не умеет. Flutter объячил поддержку десктоп, но изначально ориентирован на Windows 10 и новее. А ведь многие до сих пор пользуются Windows 7 на стареньких компах и ноутах.
Попробовал Tauri, но он требует наличия в системе webview-браузера, что опять же приводит к пляскам с бубном на Win7. А собранный APK для андроида оказался размером 30 Мб - как-то слишком жирно для мелкого приложения. Для сравнения - тестовая APK в Ionic уместилась в приятные 4 Mb. Но Ionic увы не умеет в десктоп :(
Напрашивается такая полумера - делать мобильную версию в Ionic, а десктопную версию готовить отдельно в NW.JS. На устаревших версиях Windows (даже на WinXP!) NW.JS отлично запускается, если использовать соответсвующую старую версию и придерживаться стандарта ES6.
Но неожиданно для себя на этой неделе узнал про существование такого фреймворка как Quazar. Пока что не успел его пощупать, но по описанию он позволяет из Vue-приложения сделать мобильное (подтянув автоматом Ionic), десктопное (подтянув автоматом Electron), и даже PWA-версию.
Правда немного непонятно, как решается вопрос с типичными для десктопа функциями работы с файловой системой и работой с локальной ДБ? Как я понимаю это всё пишется на Node.js. Но ведь в мобилках Node.js не запускается! Получается по любому нужно этот нативный функционал отдельно реализовывать специфичными средствами то ли в Ionic, то ли в RN, то ли во Flutter?
Потому что в apk попадают so файлы флаттера для нескольких архитектур. Настроив ndk.abiFilters можно сильно уменьшить размер.
А у вас ЦА пользуется устаревшими девайсами в основном? Имхо, ради 1% пользователей, нет смысла заморачиваться. Windows 10 вышла 10 с половиной лет назад. Давно уже попереходили все. Для самых отчаянных любителей семёрки можно веб версию запустить, благо флаттер прекрасно это позволяет.
Базовый апк флаттера под одну архитектуру — 7-8 мегабайт. С учётом того, что найти девайс, не поддерживающий armv8, сейчас фактически нереально, билдить можно только его. Это базовый размер на движок, дальнейшее расширение веса почти не добавляет. Среднего размера приложение с кучей библиотек у нас в районе 11-12 мегабайт в апк получилось.
А маркет использует aab, позволяя пользователям загружать файлы только для своей архитектуры, то есть получите то же самое, но даже с поддержкой armv7.
Рустор в aab тоже умеет, кстати
Флаттер требует Виндовс 10 для разработки, но не для запуска программ.
Спасибо, надо будет попробовать как в этом плане работает самая свежая версия. Раньше с Flutter дело иметь не приходилось, а прямо сейчас я далеко от домашнего компа, с собой есть только старенький ноут с Windows 8.1. Но я всё-таки решил заморочиться - и получилось наладить Flutter-разработку на этой старой версии Windows. Для этого оказалось достаточно установить прошлогодние версии Flutter и Android Studio - они ещё были рассчитаны на Windows 7/8. А микрософтовский софт уже нужен двухгодичной давности. К тому же сейчас все эти старые версии устанавливать немного проблематично, приходится гуглить ссылки на припрятанные архивы и кое-где танцевать с бубном.
Вот рабочий рецепт настройки Flutter-разработки на Windows 7/8 (чтобы не потерять)
Скачать архив flutter_windows_3.19.6-stable.zip с этой страницы: https://docs.flutter.dev/install/archive (распаковать его и прописать в системную переменную PATH путь к папке bin).
Скачать и установить Android Studio версии Koala Feature Drop 2024.1.2 с этой страницы: https://developer.android.com/studio/archive?hl=ru (если вдруг нужен Android Emulator, то последняя совместимая с Windows 7 версия - 33.1.24, а последняя совместимая версия HAXM - 7.7.1)
Скачать и установить MS Visual Studio версии 17.6.22. Для этого нужно скачать архив "VisualStudioUpdate-17.0.0To17.6.22-Online.zip" со страницы https://www.catalog.update.microsoft.com/Search.aspx?q=visual+studio+2022+version+17&p=1
далее архив распаковать и запустить в командной строке такую команду:vs_setup.exe install --channelId VisualStudio.17.Release.LTSC.17.6 --productId Microsoft.VisualStudio.Product.CommunityПри установке включить опцию "Разработка классических приложений на C++".
Скачать и установить Visual Studio Code версии 1.79.2 по ссылке:
https://code.visualstudio.com/updates/v1_79
Добавить в него расширения Flutter и Dart, после чего можно в Command Palette запустить команду "Flutter: New Project".Созданный новый проект можно скомпилировать в десктопное и мобильное приложения такими двумя командами:
flutter build windows
flutter build apk --split-per-abiЧто могу отметить по итогам первого впечатления:
Небольшое резюме:
Плюсы:
Всё компилируется в микроскопический exe-файл, который работает в связке с 18 мегабайтной dll-кой и 6-мегабайтной папкой с данными (в отличие от Node.JS приложений, которые мало того что не компилируются, так ещё и тянут за собой браузер и Node.JS суммарно на 200 Мб).
В системе не нужно наличие WebView - похоже всё работает без браузера.
Минусы:
VIsual Studio устанавливается через онлайн-установщик, который по умолчанию старается выкачать новую версию и откатиться до нужной старой можно только ухищрениями в командной строке. При этом есть риск, что в любой момент ссылки могут перестать работать и всё сломается.
Это бы ещё ничего, но даже когда всё установлено и начинается компиляция релиза, то без включения VPN процесс выдаёт ошибку. Что как бы намекает на риски связанные с недостаточной автономностью в плане импортозамещения - хорошо если через VPN всё продолжит работать. но ведь может и сломаться! В этом плане у Node.JS есть запасной вариант в виде независимых зеркал репозиториев, на которые можно при случае переключиться. Может и для Flutter такое есть? Для десктопной разработки в этом плане конечно идеальна Lazarus IDE, которая открыта и бесплатна, создаёт нативные скомпилированные приложения, компилирует всё мгновенно и работает полностью оффлайн - но увы, на мобильные и веб-версии она не рассчитана, а умеющий в мобилки Delphi не свободен и не бесплатен.
Отдельной темой конечно возникает вопрос, что делать с бэкендом - на чём его писать? Если в экосистеме Node.JS можно этот же самый Node.JS использовать на сервере, и кругом будет старый знакомый JavaScript, то при использовании Flutter логично было бы делать бэкенд на Dart - но судя по гуглению это малопопулярно, а значит специалистов может было мало, подсказок и готовых решений в случае различных затруднений можно не найти. Что ли в сторону компилируемого Go тогда смотреть, раз уж разработка ведётся на компилируемом Dart? Но это тогда придётся осваивать ещё один язык помимо Dart - как в таких случаях говорится "этот манёвр будет мне стоить 51 день (если не недель)" :/
В вашем случае тоже можно посмотреть на вариант из моего комментария выше. Апкшка чистого проекта под 2 архитектуры была около 10 мб, если память не изменяет. Дополнительных зависимостей не тянет, код транспилируется в плюсы и линкуется с библиотекой, построенной вокруг SDL. Для веба просто транспилируется в js. Есть и другие варианты сборки.
Разве не лучше тогда использовать .Net Maui
MAUI не щупал, но вот тут в комментарии выше кто-то написал, что MAUI не актуален:
https://habr.com/ru/articles/929058/#comment_28593652
На мой взгляд, KMP отлично подходит для готовых продуктов, которые уже написаны на Kotlin и хотят добавить поддержку iOS с минимальными затратами.
В какой то степени вы правы. На самом деле ситуация ещё более плачевная: поддержка iOS - это не только чтобы просто запустилось на Айфоне, это что-то типа: "запустилось на большинстве айфонов и все виды виджетов при скроллинге не лагают". Команда флаттера над этим работает несколько лет и с каждым обновлением фиксит айосовские виджеты. В котлине механизм UI чуток другой, но суть в том что iOS тот же самый. Т е можно убежать от флаттера, но убежать от iOS не получится.
И вот здесь становится понятной главная фишка флаттера: разработчики жрали волков чтобы на айос хорошо работало и действительно, по сравнению с другими, теперь работает хорошо (субъективно говоря: даже лучше чем родной Swift).
Поэтому когда говорят о конкуренции в кроссплатформе - претендентов много. Когда начинаешь серьёзно копать в детали - остаётся один флаттер.
В результате мы приняли решение форкнуть существующую библиотеку и дописать весь необходимый функционал самостоятельно
из-за чего на каждый чих приходится залазить на NPM и искать библиотеку, за поддержку которой никто не отвечает.
Блеск и нищета open source. Гуглы-Меты сами всё сделайте. А авторы (может одиночки) мелких библиотек ни за что ещё не отвечают.
Средний FPS вырос на глазах - [...] 85 кадров в секунду!
Но еще больше меня удивило другое: пользователи iOS начали сами писать в чаты, что интерфейс стал заметно плавнее и отзывчивее.
При всей любви к KPI, у авторов мобильных приложений, тем более автомобильно-рабоче-навигационных, не бывает мысли, что быстродействие приложения равно времени работы от аккумулятора, что критически важно для пользователя?
Вы предлагает технически занижать FPS?
Хе-хе, у водителей всегда есть доступ к зарядке 12V))
Вы предлагает технически занижать FPS?
В каждой шутке... Да. Когда заряд батареи становится меньше условных 30-40% можно было бы начать экономить такими мерами.
Хе-хе, у водителей всегда есть доступ к зарядке 12V))
Кто за рулем работает - да. У других пассажиров или других типов приложений - не факт, что в общественном месте вообще что-то будет. Мне интересно, каким боком велосипедисты-развозчики питают свои лопаты?
Как мы переписали мобильное приложение с React Native на Flutter