Привет, Хабр!
Меня зовут Данил Абдрафиков и уже более пяти лет я занимаюсь мобильной разработкой, три из которых — на Flutter. Последние несколько лет я разрабатываю продукты для энтерпрайза в TAGES, и за это время у меня успел накопиться определенный опыт, которым я бы хотел поделиться с вами в сегодняшней статье. Я расскажу, что нужно знать опытному мобильному разработчику для перехода на Flutter, с какими особенностями можно столкнуться и стоит ли вообще переходить на него.
Чтобы вам было удобнее знакомиться с инструментами и технологиями, используемыми во Flutter, в материале будут упоминания нативных языков и инструментов, приближенных к привычному представлению процесса мобильной разработки.
Что такое Flutter?
Flutter — это открытый набор инструментов для разработки кроссплатформенного программного обеспечения, в котором используется язык Dart. Если вы знакомы с Kotlin, Swift или Java, то Dart вам может показаться до боли знакомым.
Отличительные особенности:
Проект с открытым исходным кодом и большим активным сообществом.
Собственный движок рендеринга, кроссплатформенность и единый язык разработки.
Безопасное взаимодействие с нативным кодом по каналу платформы.
Высокая производительность по отношению к другим кроссплатформенным инструментам.
Достоинства
1. Dart — главная причина, по которой разработчики любят Flutter
Язык Dart создавался командой Google в качестве альтернативы JavaScript. Начать писать на нем можно довольно быстро, даже если у вас нет особого опыта в программировании на одном из перечисленных ранее языков. Для наибольшего эффекта рекомендую приступать к изучению языка с небольшой экскурсии.
К слову, сам язык «из коробки» многопоточный (с некоторыми ограничениями), который предоставляет механизмы Event Loop, Isolates, помогающие работать с асинхронными и параллельными операциями. Внешне это может выглядеть почти так же, как корутины в Kotlin или Concurrency в Swift. Но только внешне. Ключевое отличие находится в технической составляющей. Dart выполняет одну операцию за раз, одну за другой, что означает, что пока выполняется одна операция, ее нельзя прервать никаким другим кодом Dart.
Для наглядности сравним синтаксис:
Dart
class Language {
const Language(this.name);
final String name;
Future<void> learn(Duration duration) {
return Future<void>.delayed(
duration, () => print('Well done! $name is learned!'),
);
}
}
Future<void> main() async {
final dart = Language('Dart');
await dart.learn(Duration(seconds: 2));
}Kotlin
import kotlinx.coroutines.delay
class Language(private val name: String) {
suspend fun learn(duration: Long) {
delay(duration)
print("Well done! $name is learned!")
}
}
suspend fun main() {
val kotlin = Language("Kotlin")
kotlin.learn(2000L)
}Swift
import Foundation
class Language {
let name: String
init(name: String) {
self.name = name
}
func learn(interval: TimeInterval) async throws -> Void {
try await Task.sleep(nanoseconds: UInt64(interval * 1_000_000_000))
print("Well done! \(name) is learned!")
}
}
Task.init {
let swift = Language(name: "Swift")
try await swift.learn(interval: 2.0)
}Как можно заметить, Dart имеет хорошую визуальную эстетичность кода, но, помимо этого, он еще и поддерживает:
Just-In-Time в режиме разработки и Ahead-Of-Time в режиме выпуска.
2. Простая и гибкая верстка
Процесс построения пользовательского интерфейса декларативный и состоит из виджетов — в своем роде компонентов, которые могут располагаться на экране. Если сравнивать с привычными инструментами, то это как Jetpack Compose для Android или SwiftUI для iOS.
По умолчанию, для отрисовки виджетов используется Skia, но можно переключиться на Impeller (на данный момент он доступен для предварительного просмотра). Они не требовательны к версии и самой платформе, что позволяет воплощать многие задумки. Физика и сами виджеты стараются быть максимально приближенными к нативным компонентам, повторяя гайдлайны той или иной системы, что открывает дополнительную возможность максимально их кастомизировать под свои цели и задачи.
Ознакомиться с компоновкой пользовательского интерфейса можно в блоке «Введение в виджеты» из официальной документации.
3. Быстрая адаптация к изменениям ОС
Создатели инструментов для кроссплатформенной разработки порой довольно неохотно подходят к изменениям в операционных системах, что мешает разработчикам идти в ногу со временем.
Рассмотрим пример с поддержкой дисплеев ProMotion, обладающих динамической частотой кадров:
Для любого инструмента кроссплатформенной разработки сейчас эта тема является серьезной задачей, поскольку для внесения изменений в ядро движка необходимо:
внести ряд изменений, которые бы позволили работать с оптимальной частотой кадров для конкретных устройств;
рассмотреть вопросы, связанные с влиянием на энергопотребление;
С появлением iPhone 13 Pro и iPhone 13 Pro Max, оснащенных дисплеем ProMotion, разработчикам стало интересно, как поведут себя приложения написанные на Flutter. Чуда не произошло, и в первый же день продаж в репозитории была заведена проблема, а также появлялись первые наброски решения, которое бы позволило добавить такую поддержку.
На текущий момент разработчикам доступна поддержка через флаг, который по умолчанию прописывается в проекте. Но данное решение нельзя назвать идеальным, поскольку флаг ограничен минимальной частотой, что с одной стороны дает возможность использовать экран на полную, а со второй — приводит к повышенному потреблению заряда аккумулятора.
Одним из важнейших моментов является то, что Flutter поддерживается не только внутренней командой Google, но и обширным сообществом разработчиков, что позволяет вместе справляться с такими проблемами, поскольку совместные усилия приближают кроссплатформу все ближе к нативной.
4. Пакеты от сторонних разработчиков
На сегодняшний день сообщество Flutter активно растет и развивается, что, к примеру, хорошо видно в исследовании Statista. Этому способствуют и разработчики, прилагающие усилия, чтобы оставить в нем свой вклад. Не меньше развитию сообщества способствует и программа Flutter Favorite, задающая планку качества, на которую стоит ориентироваться как начинающим, так и опытным разработчикам при выборе внешней зависимости в проект.
Недостатки
У любого инструмента рано или поздно появляются слабые места. Рассмотрим основные.
1. Кодогенерация
Кодогенерация может казаться идеальным решением для экономии времени разработчика на написание и поддержку рутинных частей проекта, но на деле это не всегда так.
В Dart кодогенерация устроена таким образом, что ее приходится перезапускать каждый раз, чтобы увидеть новые изменения. В больших проектах это особенно неудобно, поскольку такая генерация кода (например, в CI/CD) отнимает у разработчиков немало времени. Да, можно задействовать слушателя. Но он подходит не для всех случаев, поскольку реагирует на любые изменения в коде, что приводит к частым обращениям к накопителю и, в свою очередь, подвисаниям.
Следовательно, для наилучшей производительности разработчикам приходиться выбирать, какую часть проекта можно оставить на кодогенерацию, а какой можно «пожертвовать», поддерживая ее вручную.
В целом, кодогенерация в Dart требует серьезного переосмысления, чтобы закрыть потребности большинства разработчиков.
Для сравнения, в Kotlin есть довольно быстрый фоновый kapt и его более современная замена KSP. В отличие от build_runner в Dart, с ними приятно работать.
2. Имитация пользовательского взаимодействия
Flutter можно отметить за отличную поддержку и оптимизацию только под одну платформу, под которую он затачивался в первую очередь – Android. Если нативному iOS-разработчику дать «пощупать» приложение, написанное на Flutter, то он не получит тот самый первоклассный пользовательский опыт от его использования, поскольку физика и анимации лишь симулируют то, к чему привык пользователь.
Разработчикам все же удалось бесшовно повторить компоненты и физику в стиле Material Design. Исключением можно назвать лишь Human Interface Guidelines, в котором физика и сами компоненты при взаимодействии порой ощущаются искусственными, словно между пальцем и кнопкой существует еще одна прослойка, портящая все ощущения от использования. Причем проблема даже не в самих компонентах, а в том, как Flutter в целом работает на этой платформе.
3. Уровень производительности, платформы и архитектуры
Если говорить о веб-приложениях, то разработка на Flutter Web будет требовать особый и настолько строгий подход к оптимизации, что заставит переосмыслить ее целесообразность. Хочется предостеречь от использования этой платформы для разработки прогрессивных веб-приложений (PWA) и одностраничных приложений (SPA), поскольку их производительность может значительно уступать приложениям, созданным при помощи других инструментов. В свою очередь это негативно сложится на общем впечатлении и пользователя, и разработчика.
Помимо этого, Flutter не поддерживает сборку проекта под архитектуру x86 для Android. Считается, что количество таких устройств на рынке не так велико, и с каждым днем их становится все меньше, а изменения, которые необходимо внести для реализации, потребуют значительного объема работ в компиляторе Dart.
Рекомендую также подробнее ознакомиться с поддерживаемыми платформами, чтобы определиться, подходит ли Flutter для ваших целей.
Стоит отметить, что написать приложение под watchOS не получится, однако можно встроить собственное нативное расширение в текущее приложение, сделанное на Flutter.
4. Анализатор оставляет желать лучшего
Когда в проектах участвуют несколько разработчиков, то чаще всего бывает, что после очередного рефакторинга остаются неиспользуемые поля, методы, классы, файлы и т.д., что в конечном итоге порождает взаимосвязанную цепочку мертвого кода, а о его существовании можно узнать не сразу.
«Из коробки» нам доступен analyzer, и его можно настраивать различными правилами, однако, они ограничены определенными типами предупреждений/ошибок, не позволяющими проводить дорогостоящие операции по нахождению неиспользуемых методов, классов и тому подобного.
В качестве частичного решения проблемы можно использовать Dart Code Metrics, но с ним в больших проектах будет ощущаться низкая скорость проведения статистического анализа, что неприятно.
Ни туда, ни сюда
В этой части я постарался собрать общие рабочие моменты, характерные для кроссплатформенной разработки, чтобы предупредить о возможных особенностях, с которыми можно столкнуться в процессе создания продукта на Flutter.
1. Различие платформ
В кроссплатформенном подходе не каждый дизайнер готов воплощать привычный пользователям UX/UI для различных платформ. Нередко выбирается что-то среднее и, чаще всего, основой в дизайне выступает Human Interface Guidelines. Порой этим злоупотребляют столь часто, что это приводит к поистине галактическим проблемам.
Например, в макете может присутствовать функциональный компонент, который будет привычен на одной платформе, но совершенно непривычен на другой (все равно, что оставить пользователям Android характерный для iOS DatePicker в виде барабана. В моей практике был реальный случай, когда пользователи не могли ввести дату, потому что барабан откручивался назад). Поэтому некоторые компоненты все же необходимо адаптировать под поведение конкретной платформы, чтобы снизить негатив и непонимание со стороны пользователей.
2. Одна кодовая база
Поддерживать кроссплатформенное приложение на одной кодовой базе, конечно, интересное приключение — код с виду один, а условия для взаимодействия с каждой платформой могут значительно разниться. Например, неправильно заложенная архитектура может привести к увеличению сроков на тестирование и поддержку.
Помимо этого, при кроссплатформенном подходе, также следует задуматься и о том, какой функционал стоит проверять на разных платформах, а какой достаточно и на одной.
Выводы
Flutter за неполные шесть лет с момента выхода зарекомендовал себя как современное и быстрое решение для разработки кроссплатформенных приложений. У него есть и свои особенности, но понятно, что через некоторое время все может измениться, и текущие минусы больше не будут актуальны, а на их месте, возможно, появятся новые, требующие внимания разработчиков.
Резюмируя:
Виджеты Flutter позволяют быстро и гибко реализовывать сложные пользовательские представления, а сам Dart представляет собой простой язык, который легче освоить, чем Kotlin, Swift или Java.
Flutter имеет активное сообщество разработчиков, различные пакеты, а также программы для повышения качества этих пакетов. Инструментарий старается идти в ногу со временем, адаптируясь к аппаратным и программным изменениям.
Кодогенерация и статистический анализ кода требуют роста вовлеченности команды, развивающей Flutter, в улучшении этих инструментов.
Реальная производительность может отличаться от платформы к платформе, поэтому необходимо определиться с целевым предназначением.
Пользовательское взаимодействие на некоторых платформах может отличаться от взаимодействия нативного.
Буду рад увидеть ваши комментарии о переходе на Flutter и опыте использования данного фреймворка в целом.
Благодарю моих коллег из TAGES за помощь в подготовке моей первой статьи для Хабр!
P.S. К слову, на обложке статьи изображен маскот Flutter Dash, сгенерированный при помощи сервиса Dashatar. Можете пройти по ссылке и попробовать собрать своего Dash.
Комментарии (53)
MountainGoat
00.00.0000 00:00+6Забыли основной недостаток: надо учить отдельный язык, который больше нигде не используется и не будет. Именно поэтому от Flutter отказываются, а не потому что там кодогенерация.
Да, я не в теме, но экосистема будет, как я понял, от Ноды? То есть, JavaScript учить тоже всё равно придётся?
whoisking
00.00.0000 00:00+2>Да, я не в теме, но экосистема будет, как я понял, от Ноды? То есть, JavaScript учить тоже всё равно придётся?
Экосистема уже есть (pub.dev), она независимая, там нет ноды и джаваскрипта, dart only.
Holofox Автор
00.00.0000 00:00+5Да, несомненно нужно потратить своё время чтобы разобраться в языке, но на деле начать писать на Dart не так сложно. В Flutter бывает начинаешь писать на Dart, потом переключаешься на Kotlin или Swift, чтобы реализовать конкретную нативную часть, и происходит это без страшных последствий. Наверное, с опытом уже неважно на чём писать :)
Neonoviiwolf
00.00.0000 00:00+2давно никакого JavaScript там нет. Object-C учили, swift учили, они кроме как ios вообще не используются же, да и чего там учить, все языки одинаковые, да и по мне Dart намного проще той же жабы, только с котлином можно сравнивать
adarash
00.00.0000 00:00+2Если вы думаете, что выучите один язык и всю жизнь будете на нем писать, то я вас разочарую. Очень мало шансов что так получится. Либо вы сами захотите попробовать что-то новенкое, либо обстоятельства заставят.
transoceanic
00.00.0000 00:00К недостаткам: отсутствие динамического обновления (code push ReactNative).
Иметь возможность внести изменения оперативно, не дожидаясь пока магазин разрешит или пока пользователь обновит проложение - критично для большого круга компаний
PrinceKorwin
00.00.0000 00:00+1Раньше это было запрещено политикой Apple. Я не в курсе, честно. Уже разрешили?
transoceanic
00.00.0000 00:00Ни то что бы разрешили, но и не препятствуют: ReactNative и Cordova, как пример, годами пользуются этой возможностью
PackRuble
00.00.0000 00:00+4Спасибо за материал! Некоторые проблемы, озвученные в статье, могут быть решены в ближайшее время (статическое метапрограммирование). Насколько мне известно, команда dart активно над этим работает. А ещё, ждём вход dart 3 в стабильную ветку flutter (хотя пользоваться можно уже сейчас). А ведь это records (с поддержкой деструктуризации), pattern matching, модификаторы классов...
Pastoral
00.00.0000 00:00Есть вроде как разумное и не особо радостное наблюдение происходящего с Flutter
https://levelup.gitconnected.com/i-am-falling-out-of-love-with-flutter-f667bd450aa
К слову, сам язык «из коробки» однопоточный только если присоединиться к толпе затрудняющейся подобрать слова поточнее чем single threaded. Автор весьма прав утверждая что «ключевое отличие находится в технической составляющей». К сожалению, по тексту почерпнуть из этого что-либо кроме «выше написана ерунда» не удалось. Лучше молчать чем так, хотя я понимаю - по нынешним временам одна эта тема обеспечит статью.
Как по мне, главный вопрос к Flutter - маниакальное упорство Гугол в его «продвижении» требует объяснения. Вонь от бесплатного сыра…
А состояние Flutter - поздняя альфа. Первая версия Dart провалилась и танцы вокруг null safety пока не кончились, хотя вот-вот и должны. Первая версия Flutter провалилась, без Impeller, то есть на мобильных устройствах Эппл, она не рабочая, и обратно без Impeller и, соответственно, 3D, она никому толком не нужна, и без хоть и обещанного но грядущего усовершенствования WebAssembly и, соответственно, применения для Интернета без трансляции в JavaScript, она ещё раз никому толком не нужна. Ключевое слово - толком.
Сам Dart тоже вызывает недоумение - и просто, и быстро, и удобно, и даже где-то красиво, а им всё то Rust то Kotlin подавай, а то и Go, а от Dart фанатеть отказываются. С чего бы это, знают что-то такое чего я не знаю?
Чтобы окончательно добить карму, дам непрошеный совет. Если кто уверен что быстрее чем за год Flutter не выучит, начинайте прямо сейчас.
Necessitudo
00.00.0000 00:00Недавно же добавили Impeller. Это не то?
Pastoral
00.00.0000 00:00Это то, но его не добавили, его добавляют. Flutter, кстати, так поступал с поддержкой десктопа - тут крики что она наступила, а копнуть - честно сказано где альфа а где бета. Да и сейчас к ней есть вопросы. Стиль не меняется.
bean
00.00.0000 00:00+2Очень грустно читать такие статьи.
Потому что сам SDK действительно интересный, в чем-то уникальный и позволяющий делать крутые, приложения c нестандартным красивым дизайном.
Но все эти сравнения с нативом ни к чему хорошему не приводят, потому что:
они только разжигают новые холивары нейтив VS кроссплатформа, чем еще больше отталкивают людей и привлекают троллей.
решения о переходе принимаются не только на основании технических факторов, но многих других (какая аудитория, сроки, на какие платформы запускать, можно ли быстро нанять новых людей и тд). хотя конечно отстутствие быстрых линтеров для удалений неиспользуемых классов/методов это тоже важно.
Как правило, проекты под нейтив и кроссплатформу - это разные типы проектов и они не конкурируют. Те условно, какой-то большой интернет банкинг с кучей клиентов и сотней разрабов врядли будут делать на кроссплатформе потому что и так достаточно ресурсов держать такую армию разрабов и нативщиков нанять быстрее и проще. В тоже время, какой-то стартап который хочет быстрее запуститься под обе мобильные платформы и где, условно, не хватает ресурсов сразу на все - может попробовать начать сразу на Flutter. Поэтому тут не надо никого агитировать переходить, люди сами придут к тому или иному решению, даже если оно технически не совсем правильное, но с которым у них есть опыт и они его могут развивать.
К слову, сам язык «из коробки» однопоточный
Это не так, см Isolate или вот
Для сравнения, в Kotlin есть довольно быстрый фоновый KSP и его более современная замена kapt.
все строго наоборот: сначала был kapt (как реализация стандартного аннотейшн процессора в джаве для котлина, которые работает достаточно медленно), а потом уже появился KSP.
Помимо этого, Flutter не поддерживает сборку проекта под архитектуру x86 для Android.
это конечно очень грустно, но интелы уже давно свои армы под андроид не выпускают, это было очень давно, таким устройствам уже 7+ лет (зенфоны на интеле и др) + там была фишка что заложена эмуляция arm32 либ, тк много кто те времена в приложения не добавлял x86 версии либ, так что может даже и так все заработает.
Если говорить о веб-приложениях, то разработка на Flutter Web будет требовать особый и настолько строгий подход к оптимизации, что заставит переосмыслить ее целесообразность
это все зависит от сценария использованения, для главной страницы магазина - врядли такое подойдет, но для внутренней админки бекенда - вполне, учитывая скорость разработки + функциональность.
Holofox Автор
00.00.0000 00:00Соглашусь, любой инструмент выбирается от задачи и жизненного цикла приложения.
Это не так, см Isolate или вот
Каждому изоляту выделяется отдельный Event Loop и своя память, а взаимодействие между изолятами возможно только посредством сообщений, что ведёт к тому, что в Dart нет параллелизма с общим состоянием. Вообще язык очень хитрый в этом плане, я бы назвал это псевдо многопоточностью? :)
все строго наоборот: сначала был kapt (как реализация стандартного аннотейшн процессора в джаве для котлина, которые работает достаточно медленно), а потом уже появился KSP.
Спасибо за наводку, действительно перепутал местами.
это все зависит от сценария использованения, для главной страницы магазина - врядли такое подойдет, но для внутренней админки бекенда - вполне, учитывая скорость разработки + функциональность.
Конечно это не останавливает разработчиков писать приложения на Flutter Web, но порой сталкиваешься с такими проблемами, которые и вовсе быть не должны. Скорость разработки может упасть, как только разработчик столкнется с проблемой движка, отсюда появляются обходные решения, костыли и креатив разработчика тут уже задействуется на полную. Иногда вот думаешь, а зачем я этими проблеми занимаюсь?
bean
00.00.0000 00:00+1Вообще язык очень хитрый в этом плане, я бы назвал это псевдо многопоточностью?
В оф доках все это есть https://dart.dev/resources/faq#q-is-dart-single-threaded можно было их почитать и не надо придумывать своих терминов и вводить в заблуждение, цитата оттуда:
Is Dart single-threaded?
No. On native targets, Dart’s isolate API can enable multiple threads of execution at any given time. The Dart VM uses multiple processor cores to run those threads concurrently.
И про KAPT все равно не правильно изменили:
Для сравнения, в Kotlin есть довольно быстрый фоновый kapt и его более современная замена KSP. В отличие от build_runner в Dart, с ними приятно работать.
Все кто работал с KAPT знают, что основная его проблема - это скорость, он работает очень медленно, медленее даже чем стандартный java annotation processors, про это много где уже писалось и тд. Так что он никак не быстрый и с ним не очень приятно работать, собственно по этой (и не только) причине появился KSP. Зачем это было писать в статье, если вы не работали с этим? Тем более в контексте сравнения с дартом.
Иногда вот думаешь, а зачем я этими проблеми занимаюсь?
Ну да, а под WEB же когда люди пишут на react или других фреймворках у них проблем не бывает, там же все браузеры одинаково работают и CSS у всех стандартно поддерживается и не надо версиями и багами JS парится, там же всегда все работает. И в либах проблем тоже нет, там же без багов сразу пишут и тд.
Везде есть проблемы, почти все всегда можно решить, для этого и нужны разрабы.
Другое дело что конкретно под ваш проект этот инструмент не подходит, если говорить про Flutter Web, то это у них как раз описано тут https://docs.flutter.dev/development/platform-integration/web/faq
Можно почитать, попробовать, отказаться.Скажу по нашему опыту еще раз, мы делали 2 небольшие админки (REST, авторизация JWT, формы, списки с фильтрацией у группировкой), проблем никаких не было, единственное собирать на CI пришлось заморочиться немного, остальное все работает и сейчас.
Holofox Автор
00.00.0000 00:00+1В оф доках все это есть https://dart.dev/resources/faq#q-is-dart-single-threaded
Спасибо за ссылку, очень полезно
Все кто работал с KAPT знают, что основная его проблема - это скорость, он работает очень медленно
В сравнении с build_runner, это небо и земля. Не было цели сравнивать только kapt и KSP между собой. Посыл был в том, что если это работало хотя бы на уровне kapt, то проблема не казалась бы существенной.
tremp
00.00.0000 00:00С чего это псевдо поточность? Вполне реальная многопоточность там. Просто без компут и изолятов сама по себе асинхронность в общем случае не даёт многопоточности. Поэтому и говорят, что дарт однопоточный с одним ивентлуп. Но есть элементы языка позволяющие организовать вполне нормальную многопоточность.
alerausm
00.00.0000 00:00кроме того стоит заметить что по крайне мере на Android java/kotlin приложение не более нативное чем flutter-приложение, каждое из них исполняется в своей среде исполнения ART и Skia соответственно. Да конечно flutter-приложение запускается из обычного и может взаимодействовать с ним, но сравнивать производительность я бы поостерегся - и то и другое продукт Google.
tremp
00.00.0000 00:00Насчёт банкинга, вот прям с точностью до наоборот. Зачем держать зоопарк натива, когда все кросплатформой реализуется. Да и нативного разработчика переучить под флаттер один раз не так уж сложно(было бы желание разработчика).
Pole2143
00.00.0000 00:00Ждём развития KMM. Писать на compose приятнее, ходят легенды что он будет единым для всех платформ.
Vasilisk777
00.00.0000 00:00-1Еще забыл ОГРОМНЫЙ .apk файл при генерации из Flutter
К примеру пустой проект .apk ->
Flutter: 30мб+
Нативный: 3мб+
Разница в 10 раз!
Но всё равно топлю за Flutter, кодить на нем намного проще и быстрее чем на нативеPackRuble
00.00.0000 00:00+1Вы не используете команду
--split-per-abi? Откуда такой размер для flutter приложения в 30мб? Да даже толстый апк не выйдет весом более 30мб...
Pole2143
00.00.0000 00:00+1Для мультиплатформы сейчас флаттер самое стабильное и зрелое решение, есть KMM, но пока он сырой, но многие именно на него делают ставку в дальнейшей перспективе. Если нужна какая то одна платформа, то лучше использовать натив, тем более появилась возможность декларативной верстки, например compose в плане верстки проще и менее громоздкий чем flutter.
nikita_dol
00.00.0000 00:00+2К примеру пустой проект .apk ->
Flutter: 30мб+Если запустить это в терминале:
flutter create size cd size flutter build apk --release --split-per-abiТо в результате сбилдятся 3 apk:
✓ Built build/app/outputs/flutter-apk/app-armeabi-v7a-release.apk (5.6MB). ✓ Built build/app/outputs/flutter-apk/app-arm64-v8a-release.apk (6.1MB). ✓ Built build/app/outputs/flutter-apk/app-x86_64-release.apk (6.2MB).Конечно, это не 3Мб, но в 6Мб уже весь движок и кусочек приложения
Vasilisk777
00.00.0000 00:00-1И толку тебе от 3 разных apk файлов? Скинешь кому-то не с тем ядром и у него не установится. Выложить куда-то - тоже самое, будет ошибка установке у половины пользователей которые установят не тот апк.
Выход- собирать один включающий эти 3 сразу.nikita_dol
00.00.0000 00:00+2Не вопрос:
✓ Built build/app/outputs/flutter-apk/app-release.apk (16.8MB).Да, это больше чем пустой проект (я создал в студии пустой проект и сделал релизный билд - 4.5Мб), но если это действительно критично, то стоит использовать только нативную разработку
Моё мнение: большинство нативных приложений уже давно имеют размер выше 15Мб - поэтому размер Flutter приложения не так критичен в большинстве случаев
PackRuble
00.00.0000 00:00Спасибо за проверку. Ведь это и в самом деле далеко не 30мб, а вдвое меньше (-44%). И опять же, на чём там популярные сейчас приложухи написаны? Пол гига веса – тут хоть на нативе, хоть на креативе, результат удручающий (как и работа таких чудо приложений на неплохих устройствах)
tremp
00.00.0000 00:00А вы как в каком режиме сгенерели? Девелоп? Или релиз? Думается, мне что девелоп.
SPOGS
00.00.0000 00:00Указано, что
"Для сравнения, в Kotlin есть довольно быстрый фоновый KSP и его более современная замена kapt. В отличие от build_runner в Dart, с ними приятно работать"
Но это KSP как раз более быстрый и свежии. Даже по указанным вами ссылкам можно прочитать, что kapt перешел в maintenance mode
UltimateOrb
00.00.0000 00:00Я считаю что самый ценный ресурс - это время. Тогда становится актуальным вопрос, а нужно ли тратить время на изучение Dart? Кроме Flutter толку от него мало. Сказки про то, что язык можно быстро освоить, можно оставить для джунов. Что бы быть действительно профессионалом своего дела, язык нужно хорошо изучить, знать его фишки, фичи, особенности и нюансы. А на это нужно время. С тем же Kotlin больше профита.
Pole2143
00.00.0000 00:00Можно подумать что swift имеет обширную область применения
UltimateOrb
00.00.0000 00:00Верно, поэтому всплывают проблемы. Из-за санкций меньше сил используется для разработки под iOS/iPhone. У нас лично сократили часть таких разрабов.
vladvdev
00.00.0000 00:00+1Фишки, фичи - все нормальные языки программирования плюс минус синхронизировали сахаров
Особенности и нюансы - это вы про косяки js? в норм языках middle, senior поймёт их проблемы из статьи на 5 минут чтения
И главное - мобильный разработчик выше джуна знает паттерны, виьюшки и их поведение, либы, и другие нюансы которые никогда не зависят от языка.
Я когда переходил с xamarin на flutter, сам язык походу осваивал, и умения построить архитектуру и найти наивыгоднейшее решение отличали меня от джуна....
BraveBanana
00.00.0000 00:00+1Я замечу, что до бизнеса есть несколько недостатков.
Отдельный язык Dart, который больше нигде так или иначе не применяется. Да, он может быть похож на другие языки. Проблемы не со вкатываним в язык, а в том, что на рынке труда проще найти C#-разработчика или того же JS-ника. Другой вопрос в том, что Flutter и Dart являются инструментарием направленным узко в сторону мобильных клиентов. Скажем, в отличии от C# (и его Xamarin a.k.a. MAUI + ASP.NET Core) или JavaScript (Node + React Native). Представленные языки и их окружение могут предоставить разработчикам, например, единство имплементации модели данных. Второй плюс связан с тем, что у вас появляются т.н. full-stack разработчики, когда у тебя нет двух команд (с разной степенью раздельности), а есть единая команда в рамках которой могут быть люди с разной степенью специализации, но всё же говорящих на одном языке.
PlatinumKiller
00.00.0000 00:00Странные вы, а вы расширения, поддержку iPadOS, macOS со всеми внутренностями и и например прикручиваем Mint, Windows. Опять же с работой всей перефирии? Не надо все в кучу сибирать, везде есть ограничения, а Flutter максимум для MVP версий.
rutexd
00.00.0000 00:00-1Как то пробовал года два назад эту тему. По итогу не понравилась. Отдельный язык который непонятно зачем есть и непонятно зачем существует используется в узконаправленном фреймворке.
Пробовал на нем писать. Но после непонятных багов чуть ли не на hello World, где после хотрелоада отпадала клавиатура и ввод и около года открытого issue почти без единого комментария разработчиков - забил. Может быть сейчас уже лучше но серьёзно на нём что то делать кроме мелких проектов - смысла не вижу.
lymes
К недостаткам я бы добавил риск того, что Гугл в один прекрасный день возьмет да и закроет этот проект, как многие другие до этого. Вряд ли, конечно, но имхо это тоже нужно учитывать при выборе кросс-платформ инструмента для разработки коммерческих приложений.
Holofox Автор
Такой риск правда существует, но лишь упомяну, что переход Flutter-разработчика в нативного возможен с меньшими затратами, поскольку присутствует общий опыт взаимодействия с платформами
lymes
Если бы мне пришлось выбирать, я бы выбрал React Native по многим причинам, в том числе и по переиспользуемости языка и навыков.
danial72
Главная фича RN - code push.
pfffffffffffff
А с тормозным мостом взаимодействия с платформой решили както?
Mox
Но какие инструменты разработки закрыл Google? Наоборот, не бросил Dart а дал ему новую жизнь.
Второй момент - инструмент Open Source, я думаю просто передадут его сообществу, как скажем с Rust получилось, во Flutter нет ничего что было бы прямо завязано на гугл.
Так то можно сказать что и Apple всех прокатила с Objective-C когда-то.
lymes
эмм.... что? ))))
Mox
Ну типа все новое пишите на Swift, и вообще готовтесь к Swift UI, Objective-C мы не развиваем больше. В таком виде действительно могут и Flutter тоже задепрекейтить.
lymes
Вы наверное не в курсе, что: 1) swift использует objc runtime, 2) objc продолжает развиваться, что естественно, принимая во внимание пункт 1.
Ну и на затравочку: SwiftUI это не какой-то новый Swift, это всего лишь UI фреймворк.
treblereel
например gwt, который было отнолительно популярен. Теперь куча компаний думает куда мигрировать.
lymes
Кстати да, совсем забыл о нём. Google Web Toolkit, классная была штука раньше, - пишешь фронтенд на Java, компилишь все в яваскрипт бандл и вуаля. Справедливости ради, GWT вроде как еще есть, но не развивается и подзаброшен.
treblereel
В данный момент в режиме поддержки, не будет новых фич, только чтобы можно было все еще запускать старые проекты. Мы старались переписать gwt модули на J2CL, но уткнулись в то, что не понятно как эффективно поддерживать i18n, а это используется почти во всех модулях. Есть closure-library, но тогда нет возможность соблюдать обратную совместимость.
J2CL классная штука, но скажу, что товарищи из компании, где делают только добро, не очень заинтересованы в популяризации (вот сейчас прям я доволен, как мне удолось мягко высказаться), или простым языков им просто плевать на пользователей вне. Наша маленькая группа навояла j2cl-maven-plugin, и им даже можно пользоваться (относительно удобно), но это все равно не так круто, как было с gwt.
В общем по доглу службы мне приходиться иметь дело с решениями гугла, но я был бы очень осторожен, если бы меня спросили стоит ли на них основывать свои бизнес решения.
guvernir4
Google Gears. Закрыли в 2009 году. Сейчас его аналог это React Native/Electron.