Я — Евгений Сатуров, Head of Flutter в Surf и ведущий Flutter Dev Podcast. По традиции представляю перевод официальной статьи про свежий мажорный релиз Flutter 3.0, дополненный моими комментариями.

Рады объявить выход Flutter 3. Всего три месяца назад мы анонсировали поддержку Flutter для Windows. Сегодня объявляем, что в дополнение к Windows Flutter теперь работает на macOS и Linux в стабильном канале.

Благодаря совместным усилиям разработчиков, контрибьютивших во Flutter, мы смогли смёрджить 5248 пулл реквеста.

В рамках этого релиза мы подготовили несколько интересных нововведений: обновлённую поддержку Flutter для macOS и Linux, значительное улучшение производительности, обновления для мобильных и веб-версий. Помимо этого расскажем о сокращении поддержки для старых версий Windows, приведём краткий список изменений без обратной совместимости. 

Комментарий Евгения Сатурова

Помните март 2021 года? Отличное было время. Flutter впервые после релиза версии 1.0 в 2018 году обновил мажорную версию, и это принесло много долгожданных возможностей, которыми… во многих действительно больших проектах полноценно не могут воспользоваться до сих пор. Миграция на Flutter 2 – нет, увольте, никогда больше.

Возможно, увидев анонс Flutter 3 вас, как и меня, пробил холодный пот. Опять?! Расслабьтесь, в этот раз всё иначе: повышение мажорной версии сигнализирует вовсе не о радикальных переменах в языке или фреймворке.

Теперь Flutter официально поддерживает шесть платформ в стабильном канале. И делает это хорошо.

Почему мы вдохновлены этим, как никогда ранее? Читайте дальше.

Готовы к выходу в прод на всех десктопных платформах

Версии для Linux и macOS вышли в стабильный канал и включают следующие фичи:

Каскадные меню и поддержка панели системного меню в  macOS

Теперь у вас есть возможность создавать на macOS платформенные панели меню с помощью виджета PlatformMenuBar, который поддерживает вставку платформенных меню и управляет содержимым меню приложений на macOS.

Каскадные меню
Каскадные меню

Полная поддержка ввода текста на иностранных языках на всех десктопных платформах

Ввод текста на иностранных языках, включая те, которые для ввода текста используют редакторы метода ввода (IME). К примеру китайский, японский и корейский теперь полностью поддерживаются на всех трёх десктопных платформах, включая сторонние методы ввода: Sogou и Google Japanese Input.

Доступность на всех десктопных платформах

Flutter для Windows, macOS и Linux поддерживает озвучивание текста на экране, упрощённую навигацию и инверсию цвета.

Формат universal binary по умолчанию на macOS

Начиная с третьей версии Flutter, десктопные Flutter-приложения на macOS собираются в формате universal binary и запускаются на старых маках на основе Intel и на новых девайсах на Apple Silicon.

Windows 7/8 получили статус deprecated для разработки

В новом релизе рекомендованную для разработки версию Windows до Windows 10. Мы не блокируем возможность разработки на более старых версиях (Windows 7, Windows 8, Windows 8.1), однако эти версии больше не поддерживаются Microsoft, и наши возможности тестирования на этих релизах ограничены. Мы продолжим поддерживать старые версии насколько сможем, тем не менее, советуем обновить версию ОС.

Важно: Мы не прекращаем поддерживать Flutter-приложения, которые запускаются на Windows 7 и Windows 8. Изменение касается только рекомендованной среды разработки.

Комментарий Евгения Сатурова

Стабильный релиз Flutter for Web мы восприняли с некоторым скепсисом: этому способствовало довольно специфическое позиционирование технологии и ряд сложнопреодолимых технических ограничений — например, крайне серьезные проблемы с SEO. Десктопный Flutter – это уже не технология компромиссов, а решение, которое я могу рекомендовать для создания десктопных приложений.

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

Простота нативных интеграций, действительно впечатляющие библиотеки UI-компонентов (Windows, macOS), готовые решения для управления мультиоконностью (window_manager), утилиты для сборки десктопных артефактов (msix) – всё это говорит о том, что Flutter не просто запустит мобильное приложение на десктопе, как это уже умеют делать Windows 11 и macOS, он поможет создать настоящее десктопное приложение.

Обновления в мобильной версии

Поддержка складных устройств

В релиз Flutter 3 входит поддержка мобильных раскладушек. Совместно с инициатором проекта — Microsoft — мы внедрили новые фичи и виджеты, с помощью которых вы сможете создавать динамичные и красивые приложения на складных устройствах.

В рамках этого проекта мы включили в MediaQuery перечень DisplayFeatures с описанием всех возможных дополнительных элементов геометрии экрана устройства: шарниры, сгибы и вырезы экрана. Кроме того, виджет DisplayFeatureSubScreen теперь располагает на экране дочерние виджеты, не пересекая границ DisplayFeatures, и уже интегрирован в дефолтные диалоги фреймворка и pop-up меню. Таким образом, Flutter уже из коробки знает о существовании этих элементов и учитывает их в работе.

Чтобы увидеть двойные дисплеи Flutter в действии, посмотрите на примеры кода в эмуляторе Surface Duo, а в особенности на один пример с форком Flutter Gallery.

Комментарий Евгения Сатурова

Во всей истории с поддержкой раскладушек интересна не сама по себе поддержка. У меня нет раскладушки, ни у кого из нашей команды нет раскладушки, владельцев раскладушек на улице тоже встретишь едва ли. Важно другое — скорость появления поддержки раскладушек во фреймворке. Она пришла быстрее, чем это объективно стало кому-нибудь нужно.

Flutter, конечно, является технологией-прослойкой. Теперь в связке «разработчик-фреймворк» появляется ещё фреймворк над фреймворком, благодаря которому и происходит вся кроссплатформенная магия. 

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

Переменная частота обновления на iOS

Во Flutter появилась поддержка переменной частоты обновления на устройствах iOS с дисплеями ProMotion, в том числе на iPhone 13 Pro и iPad Pro. На подобных устройствах Flutter-приложения способны отрисовать экран с частотой обновления до 120 Гц, при том что раньше частота была ограничена 60 Гц. В результате приложение работает плавнее при отображении быстрых анимации вроде скроллинга. Подробнее 

Упрощённые релизы для iOS

Мы добавили новые возможности в команду flutter build ipa, чтобы вам было проще выпускать в релиз своё приложение под iOS. Как только решите выпустить приложение в TestFlight или App Store, запустите flutter build ipa, и фреймворк соберёт архив Xcode (файл .xcarchive) и комплект приложений (файл .ipa). По желанию можете добавить —-export-method ad-hoc, —-export-method development или —-export-method enterprise. Готовый комплект приложений можно загрузить в Apple через macOS-приложение Apple Transport или в командной строке с помощью команды xcrun altool (чтобы ознакомиться с основными инструкциями по аутентификации для App Store Connect API, запустите man altool). Загруженное приложение готово к релизу в TestFlight или App Store. Установив первоначальные параметры проекта Xcode, такие как название и иконку приложения, больше не нужно открывать Xcode, чтобы выпустить приложение в релиз.

Не с первого раза, но Flutter-тулинг побеждает в непростой схватке с тулингом яблочной экосистемы. Последний бастион сложности пал. Теперь можно собирать проект под iOS, и получать на выходе *.ipa, не открывая Xcode. За возможность наконец-то доверить сборку ipa-шки джуниор-разработчику я готов был отдать многое. Да и девопсы будут счастливы: настраивать CI/CD стало чуточку проще.

Обновлённая версия Gradle

Если вы попробуете создать новый проект с инструментами Flutter, то, возможно, заметите, что созданные файлы перешли на свежие версии плагинов Gradle и Android Gradle. Чтобы перейти на них в готовых проектах, нужно вручную поднять версию до 7.4 для Gradle и 7.1.2 для Android Gradle.

Закат эры 32-битных iOS/iOS 9/iOS 10

Как мы уже говорили в феврале 2022 года, в стабильном релизе 2.10 поддержка 32-битных девайсов iOS и версий iOS 9 и 10 подходит к концу. Изменение затрагивает iPhone 4S, iPhone 5, iPhone 5C и устройства iPad 2, 3 и 4 поколений. Flutter 3 — последний стабильный релиз с поддержкой этих версий и устройств на iOS.

Подробнее об изменении: «RFC: поддержка 32-битных iOS девайсов близится к концу».

Обновления поддержки веба

Дешифровка изображений

Flutter Web стал автоматически обнаруживать и использовать ImageDecoder API в поддерживающих его браузерах. Сейчас уже большинство браузеров на базе Chromium (Chrome, Edge, Opera, Samsung Browser и так далее) добавили этот API.

Новый API асинхронно дешифрует изображения из главного потока с помощью встроенных в браузер кодеков изображений. Такое решение ускоряет дешифровку изображений в 2 раза и совсем не блокирует главный поток: это избавляет приложения от лагов, возникавших при загрузке изображений.

Жизненный циклы веб-приложений

С новым API жизненного цикла для веб-приложений на Flutter вы получите широкие возможности контроля над процессом первоначальной загрузки Flutter-приложения из серверной HTML-страницы и сможете упростить анализ производительности своего приложения в Lighthouse. Решение применимо ко множеству сценариев, включая популярные запросы:

  • Заставка splash screen.

  • Индикатор загрузки.

  • Отображение простого интерактивного HTML лендинга перед запуском Flutter-приложения.

Подробнее об этом можно почитать в статье «Как кастомизировать инициализацию веб-приложения» на docs.flutter.dev.

Комментарий Евгения Сатурова

Мы пишем мобильные приложения на Flutter вот уже 3,5 года. А ещё у нас есть внутренний проект, на котором мы пробуем всё то, к чему наши клиенты будут готовы лишь «завтра». Да, это проект на Flutter Web.

Без тени сомнения заявляю: API жизненного цикла входит в разряд тех изменений, которые помогают делать качественнее сам продукт, улучшают UX конечного пользователя, а вместе с тем и чистят карму разработчика. Никаких больше «слепых загрузок» и костылей с HTML-лоадерами, ура!

Обновлённый тулинг

Обновлённый пакет линтеров

Выпустили пакеты линтеров версии 2.0. В них вошли:

Приложения, созданные во Flutter 3 с помощью flutter create, автоматически предоставляют доступ наборам линтов версии 2.0. Уже вышедшие приложения, пакеты и плагины мы рекомендуем мигрировать на v2.0 и следовать новейшим и лучшим практикам из мира Flutter. Просто запустите flutter pub upgrade --major-versions flutter_lints и можете приступать к работе.

Большинство свежедобавленных сообщений об ошибках в v2 мы сопроводили автоматическими фиксами. Так что, обновившись до новой версии пакета в файле pubspec.yaml своего приложения, вы сможете запустить dart fix —-apply в кодовой базе и пофиксить большинство ошибок автоматически (хотя некоторые всё же потребуется править вручную). Приложения, пакеты или плагины, пока не использующие package:flutter_lints, можно мигрировать согласно гайду по миграции.

Улучшения производительности

Благодаря пользователю knopp, partial repaint стала доступна на Android-устройствах с поддержкой этой фичи. По результатам локального backdrop_filter_perf бенчмарк-теста это изменение в среднем сократило 90-й  и 99-й процентили времени кадра на Pixel 4 XL в 5 раз. Частичная перерисовка при наличии единичной «грязной» области прямоугольной формы теперь доступна как на iOS, так и на новых Android-девайсах.

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

Благодаря контрибьютам в опенсорс от пользователя JsouLiang, растровый и UI-потоки движка на Android и iOS получили больший приоритет, чем остальные потоки. К примеру, фоновые потоки сбора мусора Dart VM. По результатам наших бенчмарк-тестов, это решение в среднем сократило время отрисовки кадра на ~20%.

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

Благодаря контрибьютам от пользователя ColdPaleLight, во фреймворке исправлен баг в планировании кадров, из-за которого некоторые кадры выпадали из анимаций на iOS. Спасибо всем, кто сообщил об этой ошибке и предоставил сценарий воспроизведения и видео с пропуском кадров.

Impeller

Наша команда потрудилась над решением проблемы с лагами на iOS и других платформах. В релизе Flutter 3 можно открыть на iOS предпросмотр экспериментального бэкенда для рендеринга под названием Impeller

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

Impeller ещё не готов к выходу в прод и пока далёк от совершенства. Ещё реализованы не все фичи Flutter, но мы уже вполне довольны качеством и производительностью решения в приложении flutter/gallery, и поэтому делимся с вами прогрессом. В частности, самая медленная анимация перехода на новый экран в приложении Gallery занимает в 20 раз меньше времени.

Impeller доступен под флагом в iOS. Чтобы попробовать Impeller, можно передать —-enable-impeller в flutter run или установить флаг FLTEnableImpeller в файле Info.plist на true. Разработка Impeller продолжается на канале master во Flutter. Обновления мы планируем показать уже в следующих релизах.

Комментарий Евгения Сатурова

Если бы каждый релиз Flutter нужно было назвать по названию самой важной и значимой его фиче, то Flutter 3 безальтернативно получил бы название Impeller. Flutter-команда скромничает. Мы уже попробовали Impeller в действии: получили массу впечатлений и огромное удовольствие. На всех проектах, где мы опробовали сборку под новым флагом, никаких неприятных лагов и джанков не замечено вовсе. В прод мы это выпускать, конечно, не будем — подождём отмашки.

Impeller – безусловно самое важное, что случилось с Flutter 3. И никто меня в этом не переубедит.

Встроенная реклама на Android

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

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

Больше интересных обновлений

Material 3

Во Flutter 3 появилась поддержка Material Design 3 — нового поколения Material Design. Во Flutter 3 есть возможность подключить поддержку Material 3. Сюда входят фичи Material You вроде динамического цвета, обновлённой системы цветов и типографики, обновления множества компонентов и новые графические эффекты, появившиеся в Android 12 (к примеру, новый дизайн рипплов и эффект stretch overscroll. Попробовать фичи Material 3 можно в новой кодлабе «Как улучшить своё приложение на Flutter: от скучного к сказочному». Подробнее о том, как подключить новые фичи и какие компоненты поддерживают Material 3, можно прочитать в доках к API. Проследить за нашей работой вы можете по ссылке на Material 3 Umbrella issue.

Расширения тем

Во Flutter теперь можно добавлять что угодно в ThemeData библиотеки Material. Сделать это можно с помощью концепта под названием Theme extensions. Вместо расширения (в контексте Dart) ThemeData и повторного внедрения copyWith, lerp, и других его методов, можно задать расширения ThemeData. Помимо этого, если вы разработчик пакета, вы можете предоставлять доступ к своим ThemeExtensions. Подробнее об этом можно прочитать в flutter.dev/go/theme-extensions. Также можно ознакомиться с примером на GitHub.

Реклама

Мы знаем, что паблишерам важно запрашивать соглашение на персонализацию рекламы и выполнять требования App Tracking Transparency (ATT) от Apple.

Чтобы вам было легче выполнять эти требования, Google предлагает User Messaging Platform (UMP) SDK на замену опенсорсному Consent SDK. В ближайшем релизе GMA SDK для Flutter мы добавим поддержку UMP SDK, чтобы паблишеры могли получать соглашение от пользователей. Подробнее об этом можно почитать на  странице google_mobile_ads на pub.dev.

Изменения без обратной совместимости

Чем больше мы развиваем Flutter, тем больше стремимся сводить к минимуму число изменений без обратной совместимости. Релиз Flutter 3 сопровождается следующими изменениями:

Если вы используете какие-то из этих API, пожалуйста, ознакомьтесь с гайдом по миграции на Flutter.dev.

Подводя итоги

От лица всей команды в Google мы благодарим вас за ту сумасшедшую работу, которую проделало сообщество, помогая Flutter удержать статус самого популярного кроссплатформенного набора инструментов для создания UI (согласно аналитике компаний Statista, SlashData, и т.д.). Мы рады работать вместе с вами над проектом, который приносит удовольствие и разработчикам, и пользователям!

Комментарий Евгения Сатурова

Все мы так любим получать улучшения, не совершая при этом лишних телодвижений. И в этот раз большинство приятностей и полезностей Flutter 3 привнёс в нашу жизнь легко, приятно и ненавязчиво. Обновляйтесь и погнали кодить.

А ещё, мы возобновляем набор в нашу Flutter-команду. Будем рады познакомиться и поработать вместе!

Вакансия Flutter-разработчика в Surf >>

Комментарии (21)


  1. quaer
    19.05.2022 16:31
    +1

    Сколько "весит" минимальное приложение на Flutter? Почему используется вновь изобретенный язык а не какой-то известный? Реально ли в действиетльности написать кроссплатформенное приложение или всё-таки потребуются костыли под разные ОС? Если костыли нужны, на сколько сложно их добавлять и на каких языках это делается?


    1. Bromles
      19.05.2022 18:12
      -1

      Во-первых, UI для ios и android разный, т.е. все равно будет дублирование. Во-вторых, в последний раз, когда я смотрел, Flutter Desktop и Flutter Web были просто ужасны, это был просто тот же самый мобильный UI, просто растянутый на десктопный экран.

      В третьих, я честно не знаю, зачем использовать Flutter со всеми его проблемами + локальным языком, когда есть тот же Kotlin Multiplatform, позволяющий то же, только с гораздо меньшими костылями, нативно и на более популярном и общепринятом языке


      1. quaer
        19.05.2022 18:48
        +1

        А как у Kotlin Multiplatform с ответами на эти же вопросы? Например, приложение под iOS и Android будет иметь полностью общий код? И насколько сложно поддерживать потом приложение?


        1. Bromles
          19.05.2022 22:26

          В КМ приложение бьется на модули/sourceset-ы (иерархию разработчик выбирает сам), один из которых является кроссплатформерным, а остальные - для каждой платформы индивидуально.

          Поддерживается множество платформ, включая WearOS, WatchOS и TVOS

          Обычно всё, кроме UI, выносят в шейред/коммон модуль, а для каждой платформы делают UI отдельно. Но с недавним выходом Compose Multiplatform можно делать UI для Андроида и десктопа один раз, если хочется. В данный момент идет разработка (экспериментальный релиз доступен) Multiplatform Compose (не путать с Compose Multiplatform, его потом собираются вливать туда), который должен позволить писать UI под IOS точно так же, как под Android. С наличием Compose Multiplatform, позволяющим писать под Android и десктоп один раз, дублирование будет только в вебе

          Т.е., если нам надо сделать приложение, работающее везде (десктоп, андроид, айос, веб), то это будет 1 общий модуль с бизнес-логикой, DI, логикой хранения данных и тд, и по 1 модулю для каждой из платформ, где будет UI для них

          Визуализация возможной иерархии модулей
          Визуализация возможной иерархии модулей

          При этом зависимости каждого модуля мы выбираем самостоятельно. Например, при сборке под айос, код на Котлине превратится в библиотеку на Swift, что позволит разрабатывать UI на Swift тем, кто привык работать с айос, использовать их нативные библиотеки и тд. В вебе можно писать как на самом Котлине (его обертке вокруг Compose), для знакомых с разработкой на андроиде, так и на обертке на Котлине вокруг Реакта, так и на чистом нативном Реакте на жс/тс

          Все это дает несколько плюсов и один минус

          Минус:

          • Есть дублирование в виде UI-кода под разные платформы. Частично решается библиотеками, но все равно что-то на визуальной части будет дублироваться, что усложнит поддержку. В данный момент эту проблему как раз и решают, растаскивая Compose на все платформы, куда дотягиваются


          Плюсы:

          • Полный натив. Никакого лишнего движка рендера, как в React Native или Flutter, никакого WebView, как в Ionic. На Андроиде будет фулл натив андроид приложение, на свифте - фулл натив свифт приложение, на десктопе - бинарник на жвм или фулл натив на выбор, в вебе - фулл натив жс.

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

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

          • Разработчик сам определяет еще и какой код нужно выносить на мультиплатформу, а какой оставить только для конкретной. Это делается с помощью иерархии модулей и связки expect/actual. Если хочется, никто не заставляет шарить все, кроме UI. Можно и больше кода вынести на конкретные платформы. Собственно, картинка выше это и отображает. Возможность задать иерархию какого угодно уровня

            Пример связки expect/actual

            Связка expect/actual для разделения объявлений и платформозависимых реализаций
            Связка expect/actual для разделения объявлений и платформозависимых реализаций
            На примере генерации UUID
            На примере генерации UUID

          • Есть уже далеко не малое количество библиотек с поддержкой Kotlin Multiplatform, позволяющих 80-90% кода, включая UI, вынести в коммон/шейред модуль. Базы данных, веб-клиенты, DI, вьюмодели, реклама, безопасность, аналитика и прочее. Есть даже целый проект https://arkivanov.github.io/Decompose/, следующий парадигме pluggable ui для разделения кода

          Отвечая на Ваши вопросы:

          Сколько "весит" минимальное приложение?

          Столько же, сколько и нативное под эту платформу. Kotlin Multiplatform просто собирает модули в библиотеку и позволяет подключить ее при разработке UI, чтобы не писать все, кроме UI, заново.

          Реально ли в действиетльности написать кроссплатформенное приложение или всё-таки потребуются костыли под разные ОС?

          Потребуется как минимум часть UI писать под каждую платформу отдельно. Остальное можно полностью вынести в кроссплатформу, если надо. Если не надо, можно не выносить или вынести часть

          Если костыли нужны, на сколько сложно их добавлять и на каких языках это делается?

          На нативных для каждой платформы. Андроид и WearOS - Java/Kotlin, Веб - Kotlin/JS и/или просто JS/TS, Ios/TVOS/WatchOS - Swift, Десктоп на жвм - Java/Kotlin. Это позволяет использовать нативные библиотеки и не задумываться, сделали уже нужный плагин или нет

          Например, приложение под iOS и Android будет иметь полностью общий код? И насколько сложно поддерживать потом приложение?

          Не совсем общий. Как минимум часть UI будет на разных языках (Kotlin/Swift). Поддержку требовать будут нативные фичи каждой платформы (которые Вы сами решаете, использовать или нет) и сам этот UI

          Прикрепляю пару кроссплатформерных проектов для примера

          1. https://github.com/joreilly/PeopleInSpace

            Поддержка Android, IOS, WearOS, WatchOS, Desktop, Web с несколькими вариантами реализаций для разных платформ

          2. https://github.com/mutualmobile/PraxisKMP

            Поддержка Android, IOS, WearOS, WatchOS, Desktop, Web (React)

          Итого, это не имеющая на данный момент аналогов технология (по крайней мере из того, что на слуху), позволяющая делать мультиплатформерные клиентские приложения с полным нативом и минимальным дублирование кода (а в перспективе и вообще без него), с сохранением полной свободы творчества и возможностей разработчика, при этом использующая максимально привычный и общепринятый инструментарий


          1. andreyverbin
            20.05.2022 01:46

            Как все это соотносится с Xamarin Native?


            1. Bromles
              20.05.2022 01:53

              Не могу ничего сказать, т.к. никогда не писал на шарпе в целом и Xamarin в частности.

              НО: Xamarin в целом же заброшен, насколько до меня слухи доходили. Теперь будет MAUI, по любимой традиции шарпа постоянно бросать "революционные" технологии и заменять их "еще более революционными", чтобы потом забросить уже их. И работать он будет через Моно (везде, кроме винды), а на MacOS вообще через эмулятор ios. Т.е. никаким фулл нативом, возможностью юзать нативные либы платформ и тд даже не пахнет. Будет очередной React Native, но на шарпе

              С учетом такого будущего сравнивать не вижу смысла)


              1. andreyverbin
                21.05.2022 09:10

                Xamarin Native всегда был биндингом на нативные библиотеки платформы. То есть UI на iOS создаётся путём создания объектов типа UITableeView, UITableViewDelegate, UITableViewDataSource и так далее. Сами биндинги ездят на p/Invoke (стандартная для .net вещь) и небольшом рантайме от xamarin. Появление MAUI ничего не меняет, кроме того, что вместо нативного UI вы можете создавать объекты предоставленные MAUI.

                >И работать он будет через Моно (везде, кроме винды),

                нет, в .net под это уже сделали новую реализацию aot. Собирается полностью нативный бинарник.

                >а на MacOS вообще через эмулятор ios.

                Это неправда.

                >Т.е. никаким фулл нативом, возможностью юзать нативные либы платформ и тд даже не пахнет.

                Как я выше объяснил, ближе к платформе чем xamarin быть уже нельзя. Если захотите, конечно. А если не хотите, то MAUI.

                После всех этих слов опять же вопрос. Мне кажется это буквально то, что Kotlin Native делает. Прав ли я?


          1. sved
            20.05.2022 03:08
            +7

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

            Котлин, как я понимаю, не предоставляет кроссплатформенных визуальных библиотек, либо они очень сырые.

            Если это так, то в таком случае сравнение вообще не уместно.

            Да и сам котлин натив не блещет качеством и удобством.

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

            Флутер очень быстр, не медленее чем андроид. Единственная проблема это раздутое приложение.

            Фреймворк продуманный, очень прост в освоении. Это реально как глоток свежего воздуха по сравнению даже с андроид разработкой (про ios - я вообще молчу)

            Что я особенно ценю - так это возможность разрабатывать в windows и проверять на десктопе а затем на андроиде. Для ios достаточно просто скомпилировать в виртуалке и почти наверняка оно будет работать идентично. Работа с xcode в виртуалке, да ещё со сфитом - это боль.


            1. Neikist
              20.05.2022 16:51

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


          1. oldd
            20.05.2022 11:32

            Разрешите вопрос для уточнения? Полный натив десктоп для windows/linux - это что: fat.jar или прям exe/appimage?


          1. quaer
            20.05.2022 12:10

            В данный момент идет разработка ... Multiplatform Compose ..., который должен позволить писать UI под IOS точно так же, как под Android.

            Видимо, стоит пока подождать?


      1. saturovv Автор
        20.05.2022 11:04
        +2

        >> Flutter Desktop и Flutter Web были просто ужасны, это был просто тот же
        самый мобильный UI, просто растянутый на десктопный экран

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

        Фреймворк позволяет написать хорошо адаптированное приложение. Большего от него требовать я бы не стал.


      1. slavap
        20.05.2022 11:40
        +1

        UI почти одинаковый для всех платформ и это реальный плюс - естественно нужно приложить усилия чтобы не был прибит к фиксированному разрешению, но это не сложно. И только если есть жгучее желание можно начать использовать разные виджеты, например Cupertino под iOS и Material под Android - но это опционно. А можно замесить и Cupertino и Material прямо на одном экране ????


    1. saturovv Автор
      20.05.2022 11:00
      +1

      1) Android - 6 Мб, iOS - 29 Мб

      2) Лучше, чем описано в этой статье, я не отвечу: https://hackernoon.com/why-flutter-uses-dart-dd635a054ebf. TL;DR смысл есть, не просто потому что гуглерам взбрело в голову. На момент проектирования фреймворка не существовало другого языка и рантайма, который бы обеспечил его потребности.

      3) Реально писать кроссплатформенные приложения, но нужно понимать, где граница между прикладной надстройкой и платформой. Волшебства не бывает, с платформой надо "разговаривать" на платформенном языке. Но все стандартные кейсы закрыты готовыми плагинами, избавляющими от необходимости часто лезть в нативную часть.

      4) Когда нужно писать платформенную интеграцию, нужно доставать "нативный" для платформы язык. Для iOS - Swift или Obective C, для Android - Kotlin или Java и так далее. Добавлять их не сложно, но некоторое количества бойлерплейта написать придётся.


      1. quaer
        20.05.2022 12:02
        -3

        Интересно, кто выигрывает от дробления платформ? Как пример: пишешь на Java, и приложение работает на Linux, Windows, Mac, включая интерфейс пользователя, без единой строчки платформенного кода.


    1. GoodGod
      20.05.2022 14:45
      +1

      Flutter предоставляет лишь возможность строить UI. Все что нужно делать с API устройства - доступ к контактам, музыкальным альбомам, к геолокации, bluetooth, все все все остальное - нужно делать на нативе. Т.е. на Java/Kotlin или Objective-C/Swift. Flutter предоставляет лишь тонкую прослойку, которая позволяет выполнить код на нативном для платформы языке и получить результат на стороне Flutter. Т.е. платформенного кода очень много. Каждый готовый компонент на Flutter - это тонкая прослойка на Flutter + много нативного кода. Но большинство компонентов уже написано, по-этому может быть что и не придется писать ни строчки нативного кода в типовом проекте.


      1. quaer
        21.05.2022 14:21

        То есть получается, что если писать нативно под Android и iOS, надо знать Java/Kotlin и Swift/Objective-C. Если писать на Flutter, то добавляет стребование знания Dart.

        Интересно, где проходит граница когда становится выгодно выбрать Flutter?


        1. GoodGod
          21.05.2022 14:23

          Куча готовых компонентов. Например получить весь список контактов - стандартная задача. На Flutter не придется писать ничего, т.к. уже есть готовый модуль. На нативе такого маркетплейса модулей нет, и пишется уникальный код. С bluetooth - аналогичная ситуация ну и т.д.


  1. farcaller
    19.05.2022 17:27
    +3

    Почему используется вновь изобретенный язык а не какой-то известный?

    Dart'у уже 10 лет :) я думаю что вся суть flutter в том что он на дарте и использует специфические возможности языка.


    1. quaer
      19.05.2022 18:49

      Он не так, чтобы на слуху.


  1. Tuxman
    19.05.2022 21:04
    +3

    контрибьютивших во Flutter, мы смогли смёрджить 5248 пулл реквеста

    Вам послайсить или целым писом?