Почему Flutter побеждает?

    Последний год я так или иначе пишу приложения на Flutter для iOS и Android. До этого у меня был и есть 5 летний опыт работы с Xamarin. Это были замечательные 5 лет. Благодаря Xamarin и моей любви к этому фреймворку я, в принципе, перешел в стан разработчиков, этот инструмент помог заработать мне немалых денег, знаний и найти замечательных коллег. Так почему же сейчас я пишу на Flutter? Короткий ответ, потому что Flutter покрывает все потребности кросс-платформенной разработки.


    Немного истории


    Поправьте меня если я не прав, но 2009 год был во многом ключевым для мобильной разработки в целом и кроссплатформенной разработки в частности. В 2009 вышел iPhone 3gs, который позволял запускать сторонние приложения из AppStore. Впервые эта возможность появилась в годом ранее в iPhone 3g, но по настоящему массовым, «народным» айфоном стал 3gs. Опять же, годом ранее, в сентябре 2008 Android был представлен публике и в 2009 многие производители телефонов стали пробовать Android для своих новый моделей телефонов. Весной 2009 компания Nitobi представила PhoneGap — новый фреймворк для создания кроссплатформенных приложений на основе HTML5, CSS и JS. В том же году, в сентябре компания Ximian выпустила MonoTouch, который позволял писать iOS приложения с использованием Mono и C#. В том же 2009, в декабре, компания Rovio Entertainment выпустила игру для iOS и, на минуточку, Maemo, которая во многом положила начало индустрии мобильных игр — Angry Birds. Последний пример здесь не случайно.

    Первым кросс-платформенным фреймворком «для народа» можно считать PhoneGap (Qt разработчики, не кидайте камнями). Это была замечательная и вполне очевидная идея — принести веб в мир мобильной разработки. К 2009 году, возможности веба уже начали распространяться за пределы браузера (привет node.js), при этом писать приложения для веба на JS было делом довольно простым. Второй, не менее важный момент — рендер UI. То как происходит рендер лежит на движке браузера и все эти движки более или менее следуют стандартам W3C по HTML, CSS и DOM. Любой веб-разработчик сверставший сайт ожидает что его сайт бyдет выглядеть почти идентично в любом браузере, на любой платформе. Это, по моему мнению, наиболее важная сторона веба как открытой платформы. Зачем мне учить новый язык/фреймворк для рисования UI для каждой из платформ, если уже давно есть стандарт по моделирования UI для разных браузеров.

    После этого, от PhoneGap'a отпочковалась Cordova, а от нее Ionic. Казалось бы, это идеальный фреймворк, но было 2 момента: производительность и интеграция с OS. Одной из главных целей или, если хотите, бенчмарков приложений, написанный на кроссплатформенный решениях были их «нативность». Т.е. в идеале, 100% пользователей должны считать, что твое кроссплатформенное приложение — нативное. А это значит, что оно должно выглядеть как нативное, работать как нативное и иметь все возможные интеграции с ОС. В начале все эти пункты для PhoneGap были недостижимы, мощностей смартфонов 10-летней давности не хватало для 60 fps'ного рендера UI, интеграция с ОС была минимальной. Сейчас существует довольно много приложений на Ionic которые трудно отличить от нативных, но мимикрировать под нативное приложение все еще остается задачей, а не данностью как таковой. Давайте подведем небольшие итоги. Писать веб-приложения, а точнее hybrid-приложения на iOS и Android можно и удобно. Удобно потому что механизм рендера UI всецело лежит на WebView платформы, плюс есть уже обученный пласт программистов, которые хорошо разбираются в веб. Однако в hybrid-приложениях производительность и интеграция с ОС могут хромать.

    Одновременно с PhoneGap в 2009 году вышел на свет MonoTouch, что в дальнейшем было переименовано в Xamarin.iOS. Также, в этом же году вышел в свет Titanium, который также в свою очередь позволял писать приложения для iOS на javascript. По началу Titanium работал абсолютно в такой же парадигме как PhoneGap — опираясь на WebView. Но потом они переняли Xamarin подход. Что же это за подход? Его можно рассмотреть как нечто посередине. Подход Xamarin/Titanium/React.Native заключается в том, что вместо того, чтобы пытаться создать/перенести свой/существующий UI рендер, фреймворк просто интегрируется с существующим, нативным.

    Вместо того, чтобы рисовать формочку в HTML, Xamarin вызывает нативный UI элемент для этого (UITextField, TextEdit, etc). Действительно, зачем изобретать велосипед? Все нужные UI элементы существуют в нативных SDK и рантаймах, нужно просто наyчиться коммуницировать с ними из своих VM (mono, v8, etc). При этом, как вы уже догадались, можно использовать свой любимый C#, JS, TS, F#, Kotlin, etc и при этом код, который непосредственного не взаимодействует с UI — 100% кроссплатформенный. Можно иди еще дальше. Те же UITextField и TextEdit концептуально идентичные сущности, они имеют довольно много схожих свойств и интерфейсов взаимодействия, а посему, можно создать абстрактный Entry (привет Xamarin.Forms) и работать только с ним, за редким (не очень) исключением спускаясь до платформенного UI элемента. Я уже не упоминаю, что если твоя vm может работать с UI нативно, скорее всего твоя vm может вызывать любые платформенные API. Кажется, это идеальный вариант. Нативный UI, нативная производительность (привет Bridges в React.Native), 100% интеграция с ОС. Неужели это идеальный вариант? Скорее всего — нет, и проблема заключается в том, что на самом деле эти решения не решают проблему кроссплатформенной разработки — единый UI. Они ее маскируют. Я хочу write once, run everywhere. Это далеко не лучшее motto для всех типов программ и проблем, но это хорошо ложится на UI. Я хочу писать UI одинаково для всех, независимо от платформы. Почему веб-разработчик может позволить себе использовать HTML и CSS для написания какого-либо сайта, который потом будет одинаково отображаться в Safari на iOS и в Chrome на Android а нативный разработчик нет?

    На самом деле, программисты давно пишут высокопроизводительный UI c общей кодовой базой для iOS и Android. Этих программистов зовут гейм девелоперы. Angry Birds была написана на Cocos2d-x движке, Cuphead на Unity, а Fortnite на Unreal Engine. Если гейм движки в состоянии показывать умопомрачительные сцены на твоем телефоне, то кнопочки да списки с плавной анимацией точно смогут. Так почему никто их не использует в данном ключе? Ответ просто и банален, они не предназначены для этого. Когда ты открываешь игру, тебе абсолютно до фонаря насколько UI похож на нативный, тебе практически никогда не нужно взаимодействовать с геолокацией, пушами, видеокамерой и тд. Пока ты играешь ты живешь другую жизнь в своем маленьком мире который рендерится через Canvas в твоем UIViewController/Activity. Поэтому в игровых движках относительно слабая интеграция с ОС, поэтому же нет (или я не видел) мимикрирования нативного UI поверx движка.

    Промежуточные итоги


    Для идеального кроссплатформенного фреймворка нам нужны:

    • Нативное отображение UI
    • Нативная производительность UI
    • 100% возможность вызвать любой API OS, как будто это нативное приложение

    Вы сейчас думаете что я начну подводить под Flutter, но я уже слышу гневные комментарии «А где Qt!? Он все это может!». Действительно, Qt в той или иной степени подходит под эти критерии. Хотя я сильно сомневаюсь в первом из них. Но главная проблема Qt не в сложности написания нативного UI, главная проблема — C++. Тут я уже вытираю лицо от плевков тру-кодеров на плюсах. Плюсы это швейцарский нож на анаболиках, на плюсах можно делать все. Но мне, как frontend разработчику, не нужно это все. Мне нужен простой и понятный язык который работает с UI и I/O. Итак, к нашим трем пунктам выше добавилось:

    • Легкий в освоении и достаточно выразительный язык
    • Рантайм, который хорошо вписывается во frontend парадигму разработки

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

    Нативное отображение UI



    Как мы выяснили ранее, существуют два противоположных подхода к работе с UI в кроссплатформенных фреймфорках. Это рендер UI с помощью WebView или нативные вызовы элементов UI на каждой из платформ. У каждого подхода есть преимущества и недостатки. Но они не покрывают весь спектр потребностей разработчика: выглядеть неотличимо от нативного UI + нативная производительность. Flutter покрывает все эти потребности с головой. Команда Flutter потратила некоторое количество ресурсов на создание «нативных» элементов в самом фреймфорке. Все виджеты во Flutter разделены на три большие категории:


    Если вы зайдете в купертино раздел, то вы увидите что эти виджеты неотличимы от нативных iOS элементов. Как разработчик, который использует Flutter некоторое время я могу подтвердить, они неотличимы. Если вы воспользуетесь CupertinoDatePicker, например, то при скролле вы почувствуете абсолютно такой же, приятный фидбек от Taptic/Haptic engine на вашем iPhone как будто это и есть нативный элемент нативного приложения. Скажу больше, периодически я открываю приложение сайта realtor.com на моем iPhone и до последнего времени я понятия не имел, что оно написано на Flutter (или на чем-то не нативном).

    Flutter не только позволяет использовать «нативные» виджеты для 2 платформ, но и создавать свои, и это очень легко! Вся парадигма что everything is widget работает. Вы можете создавать удивительно сложные UI элементы и анимации в короткие сроки. Прелести и премудрости подхода работы с UI во Flutter недавно были описаны в этой статье на хабре, рекомендую к прочтению. Т.к. все это работает на едином графическом движке, который непосредственно рендерит все это для каждой из платформ (о нем поговорим позже), вы можете быть уверены, что все будет отображаться так, как вы планировали.

    Еще один довольно удивительный момент. Flutter поддерживает платформы начиная с iOS 8 и Android API v16. С точки зрения рендера UI, Flutter'у по большому счету без разницы какие API доступны на конкретной платформе. Ему бы возможность работать с Canvas и какое-никакое взаимодействие с графической подсистемой. А это значит что мы можем рисовать самые последние UI элементы из AndroidX, например, на телефоне 8ми летней давности. Тут конечно есть вопрос производительности такого подхода на самых старых поддерживаемых платформах, но это другой вопрос.

    Нативная производительность UI



    Как вы могли понять, подход Flutter к рендеру UI ближе к подходу hybrid-приложений, таких как Ionic. У нас есть единый движок для отрисовки UI на всех платформах, это Skia Graphics Library. Google купила Skia как продукт в 2005 году и превратила его в Open Source проект. Это как минимум говорит о том, что это достаточно зрелый продукт. Некоторые особенности производительности Skia:

    • Copy-on-write для графических элементов и других типов данных
    • Использование стек-памяти где только это возможно, для уменьшения фрагментации
    • Thread-safety, для лучшего распараллеливания

    Я не нашел убедительных тестов производительности Skia по сравнению со схожими библиотеками (см. Cairo), но некоторые тесты говорят о 50% выигрыше в производительности в среднем, за исключением некоторых специфичных ситуациях. Да это и не особо важно, потому как эти тесты основаны на использовании OpenGL на десктопах, а…

    Skia может взаимодействовать с множеством GPU backends. С недавнего времени на iOS, с 11 версии, Flutter по умолчанию использует Metal в качестве GPU бэкэнда. На Android начиная с API 24 — Vulkan. Для версий ниже — OpenGL. Все это дает нам очевидный выигрыш в производительности. На остальных «хардварных» платформах, насколько я понимаю, Skia/Flutter использует OpenGL что в принципе не мешает нам писать приложения с достаточной графической производительностью.

    Особняком стоит Web. На текущий момент весь UI рендер по прежнему ложится на связку Canvas/HTML. Поэтому Skia никоим образом не участвует в этом процессе. Плюс, Dart VM не взаимодействует непосредственно c DOM. Сначала идет преобразование в js. Все это не лучшим образом сказывается на производительности и это прям заметно невооруженным глазом. Однако ведутся работы по внедрению СanvasKit во Flutter, что в свою очередь позволит использовать Skia в браузерах через WebGL.

    Напоследок, C# программисты относительно давно использует SkiaSharp — обертку над Skia для Mono/.Net x. А Xamarin сообщество использует эту либу для рисования кастомных UI элементов и это очень популярная библиотека. Если это не победа, то я не знаю что это.

    100% возможность вызвать любой API OS


    Во Flutter существует 2 принципа взаимодействия со «внешним» миром:


    Platform Channels позволяют взаимодействовать с нативным runtime/API посредством системы сообщений. С архитектурной точки зрения на это можно посмотреть следующим образом. Визуально, Flutter это просто Canvas, который растянут на весь экран в единственной Activity/UIViewController вашего нативного приложения. Это абсолютно такой же подход, что использую гейм девелоперы (гейм-движки). Т.е. вы можете открыть iOS/Android проект вашего приложения и добавить любую другую функциональность на Swift/Kotlin/etc. Проблема в том, что нативный рантайм и Dart VM не будут ничего знать об друг друге (помимо того, что нативный рантайм будет знать что в приложении есть Canvas и там что-то отображается). Далее, если вы, например, откроете файл MainActivity.kt вашего Android проекта ты вы увидите что-то вроде этого:

    class MainActivity: FlutterActivity() {
      override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        GeneratedPluginRegistrant.registerWith(this)
      }
    }

    Вы уже заметили, что ваша Activity наследуется от FlutterActivity? Это и дает нам возможность настроить механизм отправки сообщений непосредственно во Flutter/DartVM. Для этого нам нужно переопределить метод configureFlutterEngine и определится с названием вызываемого метода и названием канала для отправки асинхронных сообщений. Все. Это дает возможность писать нам любой нативный код и вызывать любые нативные API! При этом уже сейчас существует большое количество плагинов (packages), которые избавляют вас от написания нативного кода, можно использовать только Dart. Это же просто замечательно! Пишешь UI отдельно и один раз для любой платформы, используешься DartVM для работы с UI, I/O и просто как вычислительный компонент, используешь плагины, которые реализуют нативные возможности и которые покрывают 99% всего функционала. А если этого недостаточно, пишешь нативно и коммуницируешь посредством механизма сообщений. Сказка.

    Второй механизм это Foreign function interface или FFI. Это довольно распространенный термин для обозначения механизма итеропа с другими языками, в основном с Си. В .Net мире этот механизм носит имя P/Invoke, для JVM это JNI. Если кратко, это возможность взаимодействия с библиотеками написанными на С/С++/etc. В момент появления .Net Framework, например, не было никакого ПО написанного на C# и подавляющее большинство ПО было написано на C/C++, поэтому нужен был механизм для работы с этими библиотеками. Тоже самое применимо и к JVM, Python, you name it. FFI так или иначе используется во всех кроссплатформенных мобильных фреймворках. С недавнего времени DartVM также начал поддерживать FFI для интеропа с Си и JavaScript! Пока эта возможность находится в бэта-ветке, но уже доступна для пользования (на свои страх и риск).

    Как вы можете видеть, Flutter и DartVM покрывают 100% возможностей на нативных платформах, и даже больше.

    Легкий в освоении и достаточно выразительный язык


    Я признаюсь честно, пока Dart для меня остается не самым лучшим языком на свете. Тут нет строгой системы типов, тут нет функциональных плюшек, типа Pattern Matching или возможности Immutability (вроде скоро завезут), etc. О системе типов, Dart изначально задумывался как «без типовой» язык, аля JS, но для нормальной поддержки AOT компиляции пришлось все таки приводить систему типов к более строгой, хоть и не до конца, я бы сказал. Меня по-прежнему раздражает работать с сигнатурами методов, а именно с аргументами. Все эти скобочки, @required почему-то бесят. Но dart очень легкий в освоении язык. По синтаксису это что-то среднее между Java и JS для меня. Dart прощает очень многое, как JS. В общем, это довольно простой в освоении язык, я не испытал каких-то существенных проблем.

    Рантайм, который хорошо вписывается во frontend парадигму разработки


    Теперь поговорим о Dart VM. Вообще Dart VM включает в себе множество вещей, от GC до Profiler и Observatory. Здесь я хочу поговорить только о GC и условном Runtime. Вы можете ознакомится с тем, как работает рантайм и из чего он состоит здесь. Я не специалист в этой области, но для себя я отметил некоторые преимущества Dart VM, которые постараюсь описать. До этого, я бы хотел отметить что Dart и соответствующая VM изначально разрабатывалась как замена JS, что как бы намекает на ориентированность на frontend разработку.

    Isolates

    В Dart VM есть концепт Isolate. Isolate это комбинация одного main thread, который непосредственно бежит по Dart коду и изолированной куче, где собственно аллоцируются объекты из Dart кода. Это упрощенная структура. В Isolate также есть вспомогательные/системные треды, есть ОС треды, которые могут входить и выходить в Isolate, и т.д. Стэк также присутствует в Isolate но вы, как пользователь, не оперируете им. Главное что тут нужно подчеркнуть, что если смотреть на один Isolate, то это single-thread окружение. По умолчанию, Flutter использует один дэфолтный Isolate. Ничего не напоминает? Да это же JS окружение. Точно также как и в JS, программисты Dart не могут работать с multithreading. Кто-то может подумать, что это непорядок, упрощение и ущемление прав настоящих разработчиков, но я считаю что при работе с UI, когда ты оперируешь условным DOM (а не вырисовываешь полигоны на экране), тебе не нужно, опасно оперировать несколькими тредами.

    Тут я конечно слукавил, если очень хочется, то вы можете использовать отдельно запущенные Isolate для выполнения параллельных задач (привет WebWorkers) Тут можно подробно посмотреть как можно работать с дополнительными Isolate во Flutter. Вообще, Isolates, как можно догадаться из названия — не знают друг о друге ничего, не держат ссылки друг на друга и общаются посредством системы сообщений.

    Помимо single-thread подхода, тот факт, что для каждого Isolate выделяется отдельная куча, без возможности манипулирования стэком этого треда, по моему тоже очень неплохой подход. Если вы пишете серверное приложение, которое манипулирует огромным количеством строк, например, и эти строки хранятся в куче, где появляются и исчезают с огромной скоростью, при этом фрагментируют память и добавляют работы GC, любой вариант переноса этих строк, или хотя бы части, из кучи в стек сэкономят ресурсов и повысят производительности. Пример так себе но вы меня поняли. Но при работе с UI, где есть, возможно, достаточное количество UI элементов, которые могут иметь короткое время жизни (при анимации например), но при этом всего один клиент и количество обрабатываемых данных ничтожно мало по сравнению с серверным приложением, возможность напрямую работать со стэком просто ненужна. Я уже не говорю про boxing/unboxing, который мог бы быть в этом случае и который абсолютно бессмысленен. Причем надо отметить, что объекты в Dart VM аллоцируются довольно часто. Даже для вывода суммы double из метода Dart VM отдельно аллоцирует кусок в куче. Как же GC справляется с этой нагрузкой? Давайте посмотрим.

    Young Space Scavenger (и Parallel Mark Sweep)

    Во-первых, как и все GC, GC в Dart VM имеет поколения. Также GC в Dart VM можно разделить по принципу работы на 2 составные части: Young Space Scavenger и Parallel Mark Sweep. На последнем принципе я не буду останавливаться, это довольно популярный принцип очистки памяти, который реализован практически везде и не дает Flutter особого преимущества. Нам интересен первый. Принцип работы Young Space Scavenger хорошо проиллюстрирован на следующей картинке:


    Она достаточно наглядно демонстрирует преимущества этого подхода. Young Space Scavenger работает для самых новых объектов в памяти, можно сказать что для первого/нулевого поколения объектов. Зачастую, и это характерно для Flutter/Dart VM, большинство новых объектов имеют непродолжительную жизнь. В ситуации, когда вы аллоцируете множество объектов которые живут не долго, память может быть очень фрагментирована. В этом случае вам придется заплатить либо объемами памяти либо процессорным временем для устранения проблемы (хотя такими способами устранять проблему не стоит). Young Space Scavenger решает это проблему. Если посмотреть на картинку выше, то 6 шага на самом деле нет, вам не нужно очищать первый чанк памяти, по дэфолту мы считаем что этот чанк пустой после копирования объектов во второй. Ну и при копировании выживших объектов во второй чанк, мы естественно, ставим их один за другим, не создавая фрагментации. Все это позволяет VM аллоцировать множество новых объектов за довольно низкую цену.

    Idle Time GC

    Как вы понимаете, команды Flutter и Dart VM тесно сотрудничают между собой и результатом этого сотрудничества можно рассматривать Idle Time GC. Как можно понять из названия, это сборка мусора в момент когда ничего не происходит. В контексте Flutter, в момент когда приложение визуально ничего не меняет. Нет никакой анимации, скроллинга и взаимодействия с пользователем. В эти моменты Flutter отправляет сообщения в Dart VM о том, что сейчас, в принципе, неплохой момент чтобы начать сбору мусора. Далее сборщик мусора решает, стоит ли ему начать свою работу. Разумеется, сборка мусора в этом плане происходит для более старых объектов которые управляются через Parallel Mark Sweep, что само по себе довольно дорогой процесс и Idle Time GC в этом плане очень полезный механизм.

    Есть еще такие вещи как Sliding Compaction и Compressed Pointers. Первый это механизм дефрагментации памяти после работы Parallel Mark Sweep. Это также дорогой процесс и работает он только если есть Idle Time. Второй подход, Compressed Pointers, сжимает 64-разрядные поинтеры в 32 разряда, что позволяет сэкономить памяти (я думаю это намного полезнее в серверной среде, чем в мобильной).

    Итоги


    Если вы дочитали до этой строчки, то, во-первых, поздравляю, во-вторых, я должен сказать что у меня нет никакого опыта написания статей, поэтому я не вполне понимаю, получилось ли у меня донести свою мысль. А мысль проста, когда вы пишете мобильное приложение с Flutter, оно получается нативным. А еще в виде бонуса вам прилетает очень приличная скорость разработки приложения. Hot Reload/Restart просто незаменимая вещь во Frontend разработке. Вы можете представить какого-нибудь верстальщика, которому при каждом изменении цвета какой-либо кнопки нужно было бы собирать/компилить весь проект для каждого браузера, например? Конечно нет. Вообще Hot Reload/Restart заслуживает отдельной статьи. Но я отвлекся.

    Мой опыт работы с Flutter говорит мне, что этот фреймворк будет доминирующим в ближайшем будущем. Периодически, я прохожу собеседования на позицию Flutter девелопера и в половине случаев, компании, которые ищут Flutter девелопера на самом деле имеют штат мобильных нативных разработчиков. Они просто попробовали Flutter на внутренних/side проектах, остались довольны/в восторге и потихоньку перемещаются к Flutter. Это настоящая победа, как мне кажется. Чего не скажешь о Xamarin, к сожалению. Довольно часто решение выбрать Xamarin обусловлено просто тем, что весь остальной стек написан на .Net, а это скользкий путь.

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

    Подробнее
    Реклама

    Комментарии 137

      +1
      А как насчет адаптивной верстки UI? Есть уже какие-то родные Flutter-решения?
        +2
        нормально с ней все, есть кастомные пакеты с версткой в формате media — когда ты задаешь виджеты под каждый тип девайса, есть просто LayoutBuilder и deviceSize- когда ты можешь определить вручную необходимые параметры. Верстка кодом и css немного отличаются в подходе — но на мой взгляд все прекрасно и быстро. Колонки, строки, wrap и многое другое, конечно, тоже есть.
        +2
        Спасибо, интересно. А как у Flutter с гейм-разработкой? Или все-таки не его/не предназначен?
          +1

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

            +1
            Есть интеграция с Unity — что позволяет интерфейсы рисовать на flutter, а саму игру на unity. Как сказано в статье у игровых движков достаточно сложно делать многие вещи из «приложений». Кроме того есть интеграция с Rive(flare) и попытки создания своих игровых движков, но из-за достаточно раннего этапа — это не самый лучший выбор сейчас.
              0
              Ох уж и монстр получится flutter + unity, будем вспоминать, что когда-то приложения весили несколько мегабайт
                0
                по сравнению с весом графики — flutter достаточно маленький. Обычно раазмер сильно растет из-за нативных проектов. Сейчас еще bitcode для ios появился — он снижает размер, но руки не доходят потестить.
                  0
                  Для небольших игр это ощутимо все равно. К тому же, помимо занимаемого веса, и в рантайме этот монстр лучше не будет
              0
              Есть Flame, довольно популярный движок во Flutter сообществе.

              Год назад, примерно когда я стал интересоваться флаттером, написал на нем игру-клон Flutter.Bird, было довольно интересно и надо сказать легко.

              Примеры продакш ready игр на этом движке я не знаю, но знаю одну почти игру, написанную на этом движке и выложенную в сторы, можете поиграться:

              apps.apple.com/us/app/darkness-dungeon/id1506675248
              play.google.com/store/apps/details?id=com.rafaelbarbosatec.darkness_dungeon
              github.com/RafaelBarbosatec/bonfire
              0

              Есть material, а есть cupertino. Как в результате получается "нативное" приложение для двух платформ? И там и там делают одинаково или


              if platform == android window = MaterialWindow
              if platform == ios window = CupertinoWindow
                +2
                Чаще всего делают усредненный дизайн, если нужен именно родной, то использую или обертки в которых уже зашита подстановка платформенных виджетов или пишут свою обертку — где if…, а в самом коде уже без if…
                  0
                  Flutter из коробки автоматически эмулирует многие аспекты платформы, например, физика скролла, типографика или иконки.

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

                  Но если требуется нативный вид для всех виджетов, то, действительно, нужно их явно указывать через if.
                  +6
                  Я вот попытался опубликовать небольшое приложение для macOS — завернули за дизайн :D теперь сижу и думаю что делать)
                    0
                    Не по гайдлайнам?
                  +1
                  Последний год я так или иначе пишу приложения на Flutter для iOS и Android. До этого у меня был и есть 5 летний опыт работы с Xamarin.

                  Так почему же флаттер побеждает, если такие статьи идут только от мобилоразработчиков?
                  Где статьи «Я, Вася, делал сайтики и десктоп на электроне, пересел на флаттер, и теперь меня не оторвать»?

                  То, что мобилоразработчики наконец-то перестали маяться дурью и писать отдельно под каждый из двух вендор-локов — это прекрасно, но это не «победа», это уже делал react native. Которым, кстати, продолжают пользоваться те, кто пришел имея сайтик и кому нужен апп. Несмотря на все его многочисленные недостатки.
                    +4
                    Их, нет, потому что flutter не поддерживает десктоп. Они обещаяют её в будущем, пока есть только бета macOS.

                    Я писал на Qt, и для меня кроссплатформенный десктоп UI без С++ выглядит очень заманчивой идеей. Надеюсь на скорую поддежку.
                      0
                      Qt… кроссплатформенный десктоп UI без С++
                      QML?
                      +2
                      Я не Вася, бэкенд разработчик. На новогодние прошёл курс по Flutter. На работе предложил написать приложение для внутреннего использования, на прошлой неделе выкатил альфу для тестирования. Это паралельно основной работе. Очень понравилось, приятно видеть результат работы. Буду уходить со временем на мобильную разработку.
                      +10
                      А недостатки Xamarin какие по вашему мнению? И есть ли преимущество перед Flutter?
                        +1
                        С моей колокольни (ксамарин 5+ лет и флаттер второй год)

                        минусы:
                        ксамарин натив — недружелюбная vs4mac для проектирования ui, приходилось переключаться в as и xcode; для подключения популярных андроидовских и иосных либ надо делать биндинги.
                        ксамарин формс — постоянный спуск к рендерерам, у меня не было проектов, чтобы в нем не было с десяток кастомных рендереров. стандартный набор контролов весьма куцый, по моему мнению для сложного дизайна формс абсолютно не подоходит, нам приходилось сильно изворачиваться, чтобы сделать что то нестандартное.

                        плюсы над флаттером:
                        ксамарин натив — честно, не знаю. разве что у вас какой то интерпрайз и вы подключите огромные дотнетовские либы, и не надо будет переводить код в дарт.
                        формс — мне очень нравятся возможности для mvvm из коробки от майков, что в uwp, wpf и xamforms.
                          +1
                          недружелюбная vs4mac для проектирования ui

                          Есть же райдер.


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

                          На xaml разве нельзя сделать кастомный контрол?

                            0
                            Можно, но это отнимает больше времени, чем хотелось бы…
                              0
                              Есть же райдер.

                              по vs4mac я говорил про нативный ui. для xf формочек для проектирования нет нигде.

                              На xaml разве нельзя сделать кастомный контрол?

                              Можно конечно, но он будет состоять из других контролов — которые абстракции над нативом, если вы имеете ввиду композицию в xaml. А сам набор очень ограничен.
                            +2
                            Про один недостаток я написан, отсутствие дефолтного UI рендера (для кого-то это вовсе не минус). Все опирается на нативные контроллы. Хотя если использовать SkiaSharp, то жить можно.

                            Другой минус(ы), очень субъективный, который лично мне сложно выразить словами.
                            Почему, например, Xamarin так и не подвез Catalyst для Mac? Почему с покупкой Xamarin майкрософтом они все больше превращают ex-Xamarin Studio в IDE для работы с .Net Core, чем собственно с Xamarin? Я уже не говорю о том, что Xamarin.Forms за последние несколько лет превратился собственно в синоним Xamarin. Хотя, тут ответ наверное очевиден. Майкрософт всегда был бизнесом, ориентированным на корпоративный сегмент. Я хочу делать красивый UI и удобные приложения а не формочки для страховой компании.

                            Как минус Xamarin можно также занести отсутствие Hot Reload/Restart. Вроде как они что-то похожее сделали, но это работает только в Forms и даже (поправьте если ошибаюсь) только с iOS… В общем, так же как во Flutter у них не получится сделать просто потому что бессмысленно, все равно в итоге все упирается в нативный UI.
                              +1
                              Hot Reload в Xamarin.Forms есть с 2019 года, и для Android и для iOS, постоянно пользуюсь.
                              Насчет Xamarin.Native не скажу.
                                +1

                                Если не ошибаюсь, релоад сейчас только xaml, что несравнимо с релоадером флаттера.

                                  0
                                  Для Native есть Hot Reload ресурсов Android.
                                  0
                                  рефреш xaml работает в дебаге стабильно для ios-droid. Рестарт — вроде тоже, скорость старта, особенно андроида, в последних релизах сильно апали.
                                  Основная проблема xf — медленный интерфейс, медленный старт приложения. Рендеры — то такое, можно списать на издержки технологии, но вот что делать с перформансом, когда у тебя простенький список лагает на среднем телефоне двухлетней давности?
                                    0
                                    Да, раньше списки были действительно проблемой, но с появлением CollectionView списки шустрые и лагов не замечал. (Не успел протестировать на действительно сложных списках, но простые или 1 колонкой работают плавно даже с быстрой прокруткой).
                                    А вот с более медленным стартом приложения придется мириться, но тут у всего кроме натива будут проблемы. Xamarin Forms мы используем в основном для внутренних приложений, там где это будет не так критично. Например, внутренний документооборот, управление складами, курьерские приложения.
                                  +1
                                  А я вот не увидел особо преимуществ перед Xamarin.
                                  На стороне Xamarin огромное количество библиотек, как минимум. Найдите достойные аналоги для того же Autofac, Automapper.
                                  При использовании Native подхода, мы можем оптимизировать рендеринг по-максимуму, не теряя ни капли производительности в сравнении с Java или iOS, причем 100% знаем как это работает, с flutter такое не пройдет.
                                  Изучая SDK Android и iOS мы будем это реально использовать в Xamarin приложениях, соответственно переход от Xamarin на swift, java, kotlin — не проблема, как и обратный подход.
                                  Что плохо — это визуальное накидывание интерфейса на iOS, но мы его и не используем, в команде сториборды — это ад, мы создаем интерфейс программно.
                                  Прототип на Xamarin Forms написать намного быстрее и проще, все-таки XAML — это мощь.
                                  Производительность Xamarin Forms на списках, за что его много хейтили, стала намного лучше сейчас, когда добавили CollectionView и наши клиенты не замечают разницы c приложениями на iOS и Java.
                                  Плюс идет развитие Blazor, значит и SPA приложения можно будет писать на C#. Blazor мы уже опробовали, есть проблемы с производительностью, но мы были вполне довольны используя его для админок.
                                    0
                                    Вопрос в том, что использование autofac и automapper не лучшим образом влияет на запуск приложения. Мне кажется, для мобильной разработки они не очень то и подходят.
                                      0
                                      Если бездумно пользоваться инструментом, то конечно.
                                      Не вижу причин по которым эти инструменты не подходят, ни в одном приложении не было проблем. Зато к гибкости и скорости разработки жирный плюс.
                                  +8
                                  Но главная проблема Qt не в сложности написания нативного UI, главная проблема — C++.
                                  Qt на мобильных платформах — это QML, а там можно вообще всю логику писать на JS.

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

                                  «Настоящая» главная проблема там в багах типа такого, вечных проблем с текстовыми полями, сложности в получении некоторых действительно нативных контролов и эффектов, например лупы из iOS. Но это относительно нативных приложений, у других кросс-платформенных фреймворков многое из этого тоже не решено.
                                    0
                                    Но главная проблема Qt не в сложности написания нативного UI, главная проблема — C++
                                    Qt на мобильных платформах — это QML,

                                    Ну если хочется кросплатформенности, то и на Desktop QML неплохо работает,
                                    и во многом уже лучше Qt/Widgets к сожалению.


                                    Так что я бы C++ назвал преимуществом, вряд ли ffi Dart также просто сделать
                                    как интеграцию C++ и QML/JavsScript.


                                    У Qt на мой взгляд другие проблемы:


                                    • Намного слабее маркетинг
                                    • Типизация, здесь Dart выигрывает по сравнению с QML, но вроде в Qt 6.x собираются поправить
                                    • Направленность на "Embedded Linux", такое чувство что остальные платформы тестируются
                                      намного меньше
                                    +5

                                    Flutter, WPF/UWP/Avalonia, Qt (и, быть может, другие тулкиты, которы отрисовывают контроллы сами) имееют ряд преимуществ и недостатков. Преимущества расписаны, а к недостаткам я бы отнес тот факт, что им приходится мимикрировать под нативные. Разработчикам тулкитов требуется создавать разные наборы контроллов/темы под разные ОС (или, может, даже версии). И, видимо, это придется поддерживать в актуальном состоянии.


                                    Также, замечу некую "философскую" проблему, которая, может, и не проблема для промышленного применения, но немного меня расстраивает. По-сути, выполняется двойная работа, разработчиками ОС и разработчиками тулкита по созданию контролов. А приложения раздуваются в размере засчет кода, аналог которому уже есть в ОС.

                                      +5

                                      А можете поделиться ссылочкой на какое-нибудь приложение в сторе, которое хорошо сделано на flutter и совсем неотличимо от нативного UX?

                                        +2
                                        Как я написал в статье, я периодически пользуюсь приложением от Realtor.com, и к моему удивлению я узнал что оно написано на Flutter. Оно наверное больше тяготит к Material Design но у меня и мысли не было, что это не нативное iOS приложение.

                                        apps.apple.com/US/app/id336698281?mt=8
                                        play.google.com/store/apps/details?id=com.move.realtor&hl=en_US
                                          +2

                                          На Android может быть и на Flutter, но на iOS оно полностью нативное, так что неудивительно, что его было не отличить от нативного.


                                          Заголовок спойлера

                                          image

                                            0
                                            Oops, извиняюсь, я опирался на эту ссылку — flutter.dev/showcase
                                              +2

                                              Я так и понял, но все равно решил это не игнорировать https://medium.com/@acedened/ios-app-from-flutters-showcase-page-might-not-use-flutter-at-all-23488ff82407

                                                +1
                                                Надеюсь, кто-нибудь из realtor появится в комментариях)
                                                  0
                                                  было бы интересно почитать их ответ конечно))
                                                    0
                                                    Будет забавно если это какая-то внутренняя договорённость с Гуглами в обмен на какие-то вкусные коврижки.
                                                      0
                                                      Выяснилось, что это приложение использует Flutter лишь на нескольких экранах, и в комментарии пользователь указал, что Realtor.com «медленно интегрирует» Flutter в приложение.

                                                      Тем не менее, ставить такое приложение в showcase, мягко говоря, нечестно.
                                                        0
                                                        По каким-то линкам вроде было написано, что это только предположение по поводу нескольких экранов, а не утверждение. Возможно, я что-то пропустил или не дочитал.
                                                        Про нечестность согласен. К сожалению, часто весь этот «showcase» чистой воды реклама и не более.
                                        +4
                                        К сожалению, но нет. Возможно, какие-то некритичные приложения и будут писать на флаттере. Но опыт, хамарина, киви, react native показал, что это верный путь получить ряд проблемных клиентов, которые опустят рейтинг твоих апок в маркете, и ты не сможешь достичь коммерческие цели.
                                          +2
                                          react native даже рядом не стоит к Flutter) Может сейчас и не все идеально, но в базе зашита возможность развития и приведения к идеалу.
                                          + весь корпоративный софт на мой взгляд перейдет на Flutter)
                                            +14
                                            Корпоративный софт не может перейти на Java 8 уже сколько лет. А вы тут про сырой flutter от гугла, который то Java пихает, то Kotlin, то Flutter, то убивает проекты. Весьма простодушное мнение.

                                            P.s. еще никого не уволили за выбор Java.
                                              0
                                              Java 8 не сокращает затраты на разработку и time to market, не упрощает процессы и менеджмент. Я не говорю про старые проекты, я про начало новых, особенно в условиях кризиса и уменьшения финансирования. Flutter эффективнее от 2 до 6 раз с точки зрения затрат на несколько платформ.
                                                +19
                                                Вы просто поймите.

                                                Сидит начальник мобильной разработки гугла и отдел юристов с одной стороны. С другой стороны сидит начальник отдела лицензирования от Oracle и его отдел юристов. И они торгуются.

                                                • Если Oracle блокирует гуглу Java, то они говорят — хрен с вами, мы переходим на Kotlin.
                                                • Если Oracle блокирует гуглу JVM, то они переходят на Js с его Dart и Flutteroм.
                                                • Если по всем пунктам получается договориться, то они оставляют Java.


                                                Flutter — просто технология, которая снижает риски Google от лицензионных исков Oracle. Вполне вероятно, что если они решат эти риски, флуттер будет не нужен и его выбросят на помойку. А вы тут уже рисуете картины розового будущего.
                                                  +1
                                                  Dart публично разрабатывается с 2011. Dart как замена JS — провал, начиная с 2015, следуя вашей логике гугл давно должен был закрыть проект.

                                                  Гугл не вкладывался в Kotlin до момента пока JetBrains не довели его до стабильного состояния. Да и вообще Kotlin не продукт Гугла, это самостоятельный продукт. Просто «повезло», так сказать.

                                                  Flutter не разменная монета. Flutter доказал что как продукт имеет очень существенный преимущества перед конкурентами. И если статья не убеждает в этом, то есть не-Васи, непредвзятые бэкенд разработчики (Phoenix_free), которым зашло.
                                                    +1
                                                    Flutter доказал что как продукт имеет очень существенный преимущества перед конкурентами.
                                                    Сколько продуктов отсюда этого не доказали?

                                                    killedbygoogle.com
                                                    +1
                                                    Выбросят вместе Fuchsia? «Fuchsia будет принципиально отличаться от Android. При этом ОС должна получить поддержку приложений Android. Ее интерфейс и ПО пишутся с применением Flutter SDK, позволяющего создавать кроссплатформенный код с возможностью запуска и на Android, и на iOS. Кроме того, в Fuchsia поддерживается язык Dart „
                                          +1
                                          Первая часть чуть ли не способствовала «бросить все» и перейти на Flutter, вторая же часть статьи (про минусы Dart) быстро опустило на землю и фантазия захлопнулась… Все таки, как по мне, пока Avalonia на первом месте для проб и ошибок. Там тоже Skia, да и по первому опыту нареканий пока нет.
                                            0
                                            Давно хочу попробовать Avalonia, да все руки не доходят. А язык, все-таки, дело десятое. К языку довольно быстро можно привыкнуть.
                                              0

                                              Авалонию делают три энтузиаста. Мало того, она desktop-first. Какие тут могут быть перспективы?

                                            +4
                                            Flutter просто замечательный фреймворк, но очень не хватает возможности построения UI в стиле Vue. Когда описание внешнего вида компонента идет отдельно от кода. Я слышал, что это сделано для повышения производительности, но мне кажется вряд ли там прям все так серьезно бы просело.
                                              0
                                              Когда описание внешнего вида компонента идет отдельно от кода.

                                              Что именно вы имеете в виду? Описание внешнего вида компонента – это в любом случае код. Он может быть написан на языке разметки, типа HTML/XML, а может на том же языке, что и остальной код приложения (и, как по мне, это гораздо удобнее и гибче).


                                              А отделять бизнес-логику от UI – это всегда хорошая практика. И Flutter никак в этом не мешает.

                                              +4
                                              Как и в любом другом фреймворке, здесь тоже не все так радужно. На моем Android 7.0 некоторые приложения, скачанные из Google Play нещадно тормозят. Это касается не всего приложения в целом, а отдельных его элементов, что еще страннее:







                                                +1
                                                Есть такой грех за Flutter. Фреймворк не прощает, или прощает меньше, если вы пихаете все подряд в UI тред, например. Любая операция не должна превышать 16 миллисекунд. Работа со списками тоже имеет свои особенности, как и везде. Но если знать некоторые основы, с производительностью не будет проблем. Сейчас я работаю над приложением, в котором просто уйма анимация и списки виджетов с более 500 елементов в нем. Пока критичных проблем с производительность нет.
                                                  0
                                                  В том-то и дело, что 500 + элементов в списке работают без тормозов как, например, в Kivy или ReactNative, а простой шейдер типа FadeTransition экранного менеджера в любом приложении Flutter безбожно тормозит! И ладно… И пусть… Пусть есть какие-то проблемы, которых в любом фреймворке с головой… Но я не понимаю, почему тогда Flutter позиционируют как самый быстрый, самый крутой, который рендерит анимации как покурить и в таком духе… Объясните…
                                                    0

                                                    Какое-то приложение, скачанное с Google Play тормозит… эка невидаль. Какая разница, на чем оно написано, без исходников "объяснить" почему кто-то написал тормозное приложение – ну так себе просьба.


                                                    А я вас помню – вы как-то обещали в следующей статье показать, какой Flutter тормоз. Будет статья с кодом?


                                                    P.S. мультиаккаунты же вроде были запрещены на хабре?

                                                      0
                                                      Вам этого мало? Любое приложение Flutter нещадно тормозит при использовании списков и анимации типа Transition в менеджере экранов! Это касается и официальных приложений и не официальных. Также (не хотел снова поднимать этот вопрос) существует только пара-тройка виджетов типа «Cupertino» для iOS во Flutter. Почему-то это гордо называется «Поддержка iOS/Кроссплатфора». Почему замалчивают тот факт, что поддержки iOS виджетов во Flutter просто не существует? Расскажите это человеку, который оставил здесь комментарий на тему, как отклонили его приложение в Apple за не соответствие UI!
                                                        0

                                                        Не думал, что когда-нибудь придется объяснять такие вещи разработчику, но:


                                                        ∃ ≠ ∀

                                                        Также (не хотел снова поднимать этот вопрос) существует только пара-тройка виджетов типа «Cupertino» для iOS во Flutter.

                                                        Вы хотели сказать пара десятков?


                                                        Почему замалчивают тот факт, что поддержки iOS виджетов во Flutter просто не существует?

                                                        Да вроде английским по белому написано, как работает система виджетов.


                                                        Расскажите это человеку, который оставил здесь комментарий на тему, как отклонили его приложение в Apple за не соответствие UI!

                                                        А где он писал, что его приложение отклонили? Есть какие-то пруфы? Зато есть вот такая официальная информация.


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

                                                          +2
                                                          Вы хотели сказать пара десятков?

                                                          Если быть точным — 11. А если отбросить элементы «Переключатель», который ничем не отличается от того же на Android, «Navigation bar», который на самом деле просто обычный список (не понятно, зачем его включили в раздел Cupertino), «Кнопки» (две), которые оказываются на самом деле просто RaisedButton и FlatButton из Android, «Activity indicator», который просто обычный спиннер, страшнючие текстовые поля (два), которые нормальный человек никогда не будет использовать в своем приложении, «Pull to refresh», который идентичен элементу в Android (опять же, не понятно, зачем его включали в раздел Cupertino), — то можете сами посчитать, сколько там виджетов для iOS. Я написал то, что увидел в официальном демо приложении от 2020 года.
                                                          0
                                                          если вы про меня — то у меня отклонили приложение для macOS =). Flutter прекрасен. есть соотношение затраты-качество, у Flutter оно прекрасное, никто не говорит что тормозов никогда не будет, но их меньше чем по многих других решениях и обычно можно сделать хорошо. Мне виджетов хватает. С дизайном мобилок проблем нет.
                                                      –1

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

                                                        0
                                                        С исходниками, я бы подсказал где собака зарыта
                                                          0

                                                          Стандартная аппликуха, которая делается при create myapp плюс в ней Drawer виджет с ListView, у которого в шапке картинка (через BoxDecoration и DecorationImage виджеты) и пару Row(children:[Text("lala")]. Т.е. косячить там негде, все сделано, как описано в доках.
                                                          Там, возможно, в кишках нет прелоада ресурсов и он картинку с диска читает и декодит в момент первого открытия drawer-а, я хз. Лагает только при первом открытии, дальше все ок.

                                                            +2
                                                            github.com/g0rdan/drawer_perf_test
                                                            flutter run --release

                                                            Результат (iPhone XR):


                                                            Причем картинка 3.8 мб, специально
                                                              0

                                                              Да, кажется, это я лоханулся. Я привык работать в дебаг версии :) И в ней Drawer лагает знатно, а вот в release версии перестает лагать :)

                                                                0
                                                                Бывает) Да и проблема сама по себе существует. Сделать тормозное приложение во Flutter довольно легко. Не потому что фреймворк плох, потому что писать не нем нужно немного по-другому. Плюс, насколько я понимаю, есть проблемы с андроидом, в плане реализации и фрагментации видео подсистем.
                                                    0
                                                    Скажите пожалуйста, на сколько перспективна разработка с использованием Flutter для UI и Kotlin для всего остального? Год назад была одна статья на эту тему, с тех пор особо материалов не видел. Имеет ли вообще эта связка смысл.
                                                      +1
                                                      Смысл есть только если часть вашего приложения имеет, допустим, сложный UI с анимацией, и вам проще это реализовать на Flutter и интегрировать это на 2 платформы, чем пытаться сделать это нативно 2 раза. Но это довольно редкий кейс, где у вас/в компании уже есть нативные приложения, есть желание/опыт работы с Flutter и т.д.
                                                      –6
                                                      Осталось только пофиксать 5000+ issues (на GitHub) и можно побеждать )))
                                                      А пока… побеждает React Native )
                                                        0
                                                        Количество issues, как и количество stars (где Flutter обошел React.Native) ни о чем не говорят. Потребности бизнеса говорят. Я вижу как бизнес, по крайней мере в Штатах, очень заинтересован во Flutter и часто выбирает Flutter вместо React.Native/Xamarin/etc. Бизнес хочет сэкономить и при этом не наступать на «грабли» кроссплатфоменной мобильной разработки.
                                                          +1
                                                          Вы сейчас о каком бизнесе говорите? Стартапы, мелкие предприятия да, но не крупные. Для крупных важна стабильность, а не хайповость
                                                            –2
                                                            Согласен, где стоимость разработки дело десятое — нативная разработка всегда будет в приоритете. Хотя это не отменяет проблему вендор-лока, уменьшение сложности продукта за счет единой кодовой базы и т.п.

                                                            Плюс, надо отметить, что в Штатах все-таки бизнес в срезе это малые и средние предприятия, в отличии от России, поэтому стоимость разработки важна.
                                                              +4
                                                              Flutter уж точно стабильнее React Native (знаю по личному опыту), плюс у него гораздо «взрослее» инфраструктура.
                                                              А по поводу того, кто выбирает — посмотрите здесь, есть ли там достаточно крупный бизнес?
                                                                0
                                                                В чём сегодня измеряется стабильность? Не прикапываюсь, просто интересно.
                                                                  0
                                                                  Я измерял в количестве багов фреймворка, с которыми встретился, за единицу времени.
                                                                    +1
                                                                    Мне кажется, что это не особо показательный критерий. Баги бывают очень разные. Один баг может стоить десять других.
                                                                    Например, количество мелких багов скорее будут отражать популярность, а не стабильность.
                                                                      0
                                                                      Речь шла о багах, с которыми я лично сталкивался при работе. Популярность тут не причём.
                                                                      Я согласен, одного моего мнения недостаточно для статистики, однако есть стойкое ощущение, что это именно так — флаттер стабильнее реакт нейтив.
                                                                      Несогласным предлагаю попробовать оба фреймворка лично — возможно, вам повезёт больше.

                                                                      Если же говорить об инфраструктуре — качество плагинов для IDE, отладчика и т.д., то тут даже опираться на ощущения не надо — у флаттера они объективно лучше.
                                                                      0
                                                                      Я измерял в количестве багов фреймворка, с которыми встретился, за единицу времени

                                                                      Это как в англоязычном высказывании — «plural of anecdote is not data». Измерять стабильность фреймворка только по себе — это совсем неправильно.
                                                                        0
                                                                        Наверное стоит прояснить — я не проводил исследования качества этих двух фреймворков, не было такой цели.
                                                                        Однако я занимался разработкой мобильных приложений с использованием обоих фреймворков достаточно длительное время и за это время у меня сложилось чёткое ощущение, что флаттер стабильнее, разрабатывать с ним удобнее, а результат, в среднем, получается лучше.
                                                                        Я могу долго (и нудно) рассказывать, почему это так, но делать этого не буду, потому что личный опыт гораздо важнее — попробуйте их сами и сделайте выводы.
                                                                    0
                                                                      0
                                                                      Я знаком с этой страничкой. Кроме того, больше года сам был разработчиком RN, потом ушёл на Flutter, поэтому опираюсь на личный опыт.
                                                                      React Native неплохая технология для своих задач, но всё ещё сырая, в отличие от Flutter.
                                                                  +1
                                                                  Все этого хотят но это не говорит о том, что технология готова для продакшна. Flutter сейчас — очень сырой продукт. В теории все классно, на практике — постоянно проблемы.

                                                                  Иногда Apple не пропускает Flutter приложения в стор — пишут что приложение не использует нативные элементы управления.
                                                                    0
                                                                    Иногда Apple не пропускает Flutter приложения в стор — пишут что приложение не использует нативные элементы управления.
                                                                    Это довольно голословно. Хотелось бы увидеть пруфы.

                                                                    Flutter сейчас — очень сырой продукт. В теории все классно, на практике — постоянно проблемы.
                                                                    Опять же, хотелось бы больше специфики. В моей практике все с точностью да наоборот.
                                                                      0
                                                                      комменты в посте про Мп медузы. мой опыт с этим МП
                                                                      1) при запуске анимация 3 кадра в сек.
                                                                      2) на 4 уровне вложенности статьи МП зависает
                                                                      3) скролл не инерционный
                                                                      0

                                                                      Смотря что считать "готовым для продакшна". У нас приложение уже полгода в продакшне, Apple ни разу не отклонила по этой причине.

                                                                      +1
                                                                      Cлайд 12 — «Apple запретил WebView»:

                                                                      Эпл никогда не использовал WebView!!! Был UIWebView, сейчас его заменяют WKWebView.

                                                                      А вообще — я за нейтив разработку для iOS :)
                                                                        0
                                                                        Согласен, не очень четко и слишком редко — там голосом проговаривал ограничение на использование и ужесточение в review в частности для e-commerce и опасность казино)
                                                                    +5
                                                                    Очень громкое название.
                                                                    Flutter побеждает ровно до тех пор, пока не требуется сделать что-то, что использует что-то более сложное, чем список товаров в приложении, подтянутый с API. Не говоря уже о том, насколько сильно Flutter отличается от нативных приложений в плане look-and-feel. За Андроид говорить не берусь, использую телефон на Android'е только как тестовое устройство, но на iOS Flutter ощущается, будто кто-то очень и очень удачно замаскировал WebView под нативное приложение, и это очень неприятно. Но буду честен, я видел множество нативных приложений, от которых у меня были похожие ощущения, и над парой из них мне даже удалось поработать.

                                                                    Не говоря уже о том, что у всех подобных кроссплатформенных библиотек всегда есть три фундаментальные проблемы:
                                                                    1. Они всегда играют в догонялки с платформой, которую они пытаются абстрагировать
                                                                    2. Они добавляют еще один весьма крупный слой, на котором может пойти что-то не так.
                                                                    3. Ограниченный выбор библиотек — некоторые находятся на очень ранней стадии развития, некоторые просто отсутствуют в силу особенностей платформы, некоторые приходится адаптировать самому, прописывая платформоспецифичный код для каждой из них (уменьшая выгоду по времени от кроссплатформенности и добавляя еще один слой, на котором может что-то пойти не так)

                                                                    Да, какому-то бизнесу Flutter подходит идеально — у них нет нужды строить хорошее приложение, и «подешевле-побыстрее» является основным критерием. Но называть бы это победой я не стал.
                                                                      –1
                                                                      Но буду честен, я видел множество нативных приложений, от которых у меня были похожие ощущения, и над парой из них мне даже удалось поработать.

                                                                      Т.е. это не проблема флаттера.


                                                                      Они добавляют еще один весьма крупный слой, на котором может пойти что-то не так.

                                                                      Один добавляют, другой могут и убрать. Например, учитывая, что Flutter, грубо говоря, берет от системы только канвас и рисует весь интерфейс на нем, приложение будет одинаково выглядеть и вести себя и на 10, и на 5 андроиде. И посколько UI слой от системы не зависит, как только новый компонент добавляется во Flutter, он становится доступным на всех версиях системы автоматически.


                                                                      Вообще, имхо, отделить UI слой от OS – это здравая идея.


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

                                                                      Ну так этот код все равно бы пришлось писать.


                                                                      Да, какому-то бизнесу Flutter подходит идеально — у них нет нужды строить хорошее приложение, и «подешевле-побыстрее» является основным критерием.

                                                                      Нативное != хорошее, подешевле-побыстрее != хуже.


                                                                      Они всегда играют в догонялки с платформой, которую они пытаются абстрагировать

                                                                      Да, здесь согласен. Это надо учитывать и решать, насколько это критично. Потому что может оказаться, что этот супер-новый компонент нативно доступен только в условном Андроиде 31, до которого в ближайшие пару лет обновятся только 5% ваших пользователей, и без костылей на предыдущих версиях его все равно не сделать.

                                                                        +4
                                                                        Т.е. это не проблема флаттера.

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

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

                                                                        С этим прекрасно справляется AndroidX. В случае же с iOS, напротив, нежелательно, чтобы системные компоненты на разных версиях iOS — как минимум выглядит неопрятно, как максимум — запутывает пользователя. Так что в данном случае Флаттер вряд ли «может и убрать».

                                                                        Нативное != хорошее, подешевле-побыстрее != хуже.

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

                                                                        Ну так этот код все равно бы пришлось писать.

                                                                        Конечно. Вот только к этому коду еще и плагин писать, и этот код можно было бы писать без оглядки на:
                                                                        а) вторую платформу
                                                                        б) объединяющего их интерфейса/плагина

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

                                                                        Я немного не про то. Скажем, в новой версии iOS поменяли то, как выглядит диалоговое окно — например, теперь оно стало шириной с весь экран, и кнопка, означающая «разрушительное» действие всегда будет помещена системой в самый конец списка кнопок. В предыдущей версии, например, было наоборот. Если вдруг разработчики флаттера сделали самописный диалог, а не просто вызов UIAlertController, я получу неконсистентное поведение — во всей системе «разрушительная кнопка» внизу, а во флаттере до обновления она все еще вверху. Чтобы это исправить, мне придется обновлять версию флаттера, и заново выпускать новую версию. А с этим обновлением я получу корректное поведение для пользователей более новой системы, но некорректное — для пользователей более старой. Не говоря уже о том, что обновление версии флаттера может нести в себе множество других сюрпризов — например, сломается другая критическая часть приложения.
                                                                          0
                                                                          В случае с флаттером же приходится стараться, чтобы оно выглядело и ощущалось как нативное.

                                                                          Я бы так не сказал. Т.е. он, конечно, подталкивает к тому, чтобы использовать везде Material Design, но база Cupertino компонентов вполне себе неплохая, и можно сделать iOS версию только с ними, и будет смотреться вполне себе нативно без всяких дополнительных усилий со стороны разработчика.


                                                                          С этим прекрасно справляется AndroidX

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


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

                                                                          А может быть и не потрачено? У нас приложение на флаттере уже полгода в production. Ничего сложного, обычное бизнес-приложение, но:


                                                                          1. Качество при переходе от 2 нативных к одному кросс-платформенному не пострадало (в большинстве случаев улучшилось).
                                                                          2. Времени мы тратим гораздо меньше.

                                                                          Конечно. Вот только к этому коду еще и плагин писать, и этот код можно было бы писать без оглядки на:
                                                                          а) вторую платформу
                                                                          б) объединяющего их интерфейса/плагина

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


                                                                          Скажем, в новой версии iOS поменяли то, как выглядит диалоговое окно

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

                                                                            +1
                                                                            Я бы так не сказал. Т.е. он, конечно, подталкивает к тому, чтобы использовать везде Material Design,

                                                                            Я бы на месте эппл разворачивал МП с material из AppStore.
                                                                              0

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

                                                                                +1
                                                                                Что не отменяет того факта, что Material Design на iPhone выглядит уродливо и абсолютно не к месту.
                                                                                  0

                                                                                  На вкус и цвет фломастеры разные. Я не фанат MD, но и отвращения он у меня не вызывает.

                                                                                    +1
                                                                                    Есть вкус, а есть Human Interface Guidelines.
                                                                                    Среди которых есть следующее:
                                                                                    Consistency
                                                                                    A consistent app implements familiar standards and paradigms by using system-provided interface elements, well-known icons, standard text styles, and uniform terminology. The app incorporates features and behaviors in ways people expect.


                                                                                    Material Design на iOS это нарушает.
                                                                                      0

                                                                                      "keep the following principles in mind" != "strictly follow principles"


                                                                                      Да, MD не использует "system-provided interface elements", но много вы знаете приложений, которые используют только "system-provided interface elements"? Блокировать их?


                                                                                      Что делать с нативным будильником? Почему он использует какие-то нестандартные кнопки вместо system-provided interface elements?


                                                                                      При этом, заметьте, флаттер предоставляет возможность использовать элементы, соответствующие HIG.


                                                                                      Так что, "не к месту" – отчасти, да, "уродливо" – вкусовщина.

                                                                      +1
                                                                      В статье много раз упомянута Dart VM в смысле, что она имеет какое то оношение к тому приложению, что исполняется у пользователя.

                                                                      Но Flutter работает иначе.

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

                                                                      При окончательной компиляции всё компилируется в native. И никакой виртуальной машины Dart и её тормозов нет у конечного пользователя.
                                                                        0

                                                                        Отсюда


                                                                        Dart VM is a virtual machine in a sense that it provides an execution environment for a high-level programming language


                                                                        Dart code can be compiled into machine code using Dart VM AOT pipeline and then executed within a stripped version of the Dart VM, called precompiled runtime

                                                                          0
                                                                          Именно так. Вообще есть замечательная картинка:
                                                                          Заголовок спойлера


                                                                          Которая показывает что подразумевают, когда говорят о Dart VM. При этом, как написано выше, даже с AOT все равно загружается stripped precompiled runtime, в котором все равно есть GC.
                                                                            0
                                                                            При этом, как написано выше, даже с AOT все равно загружается stripped precompiled runtime, в котором все равно есть GC.

                                                                            Garbage Collector неотемлимая часть нативных приложений для Android. Что такого в GC?
                                                                              0
                                                                              В статье написано «что такого в GC», что помогает Flutter: Young Space Scavenger, Idle Time GC, Sliding Compaction.

                                                                              Сама по себе GC является чем-то особенным.
                                                                          +1
                                                                          Aot не отменяет рантайм. Вся разница только в прекомпайле кода приложения. А JIT не значит медленно. Есть ряд оптимизаций, которые можно производить только в рантайме. Jitовая джава быстрее аот'а. Но это лечится профайлами
                                                                          +1
                                                                          как и все GC, GC в Dart VM имеет поколения

                                                                          Не все. Только, внезапно, generational gc имеют поколения.
                                                                          Go, например, не имеет поколений в своём GC.
                                                                          Android Runtime, хоть и generational, но не выделяет новые объекты в отдельной области памяти, а просто хранит их на стеке.

                                                                            +2
                                                                            В том-то и дело, что 500 + элементов в списке работают без тормозов как, например, в Kivy или ReactNative, а простой шейдер типа FadeTransition экранного менеджера в любом приложении Flutter безбожно тормозит! И ладно… И пусть… Пусть есть какие-то проблемы, которых в любом фреймворке с головой… Но я не понимаю, почему тогда Flutter позиционируют как самый быстрый, самый крутой, который рендерит анимации, как покурить, и в таком духе, но который не справляется с самой простой анимацией списка в пять элементов, гифку которой я привел в предыдущем сообщении, и не справляется с обычной анимацией перехода между экранами типа FadeTransition? Объясните людям…
                                                                              +1
                                                                              Согласен. Поставил новую Медузу и ужаснулся от «60» fps анимации. Хотел использовать в новом pet project, но думаю, что останусь на ReactNative.
                                                                              0
                                                                              А про веб то почему никто не спрашивает? Как там веб поживает? Можно и для сайтика и для аппы примерно одну кодовую базу для интерфейса держать?
                                                                                0

                                                                                Рано. Для веба пока – только поиграться. Но прогресс есть.

                                                                                  +1
                                                                                  Я не знаю каких-либо ограничений по виджетам, т.е. весь сет виджетов должен работать и на мобилках и вебе, но производительность в вебе далека от идеала. Хотя в этом направлении ведуться работы
                                                                                    0
                                                                                    Интерфейс делать сложно. А вот использовать Dart-овую общую прослойку для state managment/api managment для Web и Mobile — вполне реально, мы так делаем. Есть и плюсы и минусы, конечно.
                                                                                    +1

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

                                                                                      +1
                                                                                      Количество вакансий на xx:
                                                                                      flutter разработчик — 58
                                                                                      react native разработчик — 303
                                                                                      android разработчик — 1 621
                                                                                      ios разработчик — 1 488

                                                                                      Если и побеждает, то не на территориии РФ.
                                                                                        0
                                                                                        Так вопрос не в чистом количество вакансий а в приросте, я например тоже заметил что количество растет очень быстро
                                                                                          +1
                                                                                          Вы где смотрите прирост вакансий? 58 — это очень мало
                                                                                            +2
                                                                                            +1
                                                                                            Количество вакансий на xx:
                                                                                            flutter разработчик — 58
                                                                                            react native разработчик — 303
                                                                                            android разработчик — 1 621
                                                                                            ios разработчик — 1 488

                                                                                            Если и побеждает, то не на территориии РФ.


                                                                                            Знать именно конкретную технологию — это важно разве что в самом-пресамом начале карьеры. Ибо желающих возиться с тобой и тянуть твое развитие очень мало. Нужно чтобы ты сразу пришёл и смог вписаться работу.

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

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

                                                                                            И если Flutter мне позволяет повысить производительность (особенно при кросс-платформенной разработке; да и при разработке на одну платформу), то цифры вакансий значения не имеют.

                                                                                            Что до нанимаемых мною людей… Мне всегда важно было какой ты программист, а не насколько ты хорошо знаком с конкретной платформой. Разработка она, по сути, одинакова в смежных технологиях. Хороший разработчик осваивает азы Dart и Flutter за неделю после чего производоительность только растет. И уже ко второму месяцу он уже продуктивен неотличимо от того, кто работает год на этой технологии. Если это хороший разработчик, конечно.

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

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

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

                                                                                            Ну и, разумеется, в самом начале карьеры выбора у тебя меньше.
                                                                                            Однако, повторюсь, большой опыт разработки на других стеках я ставлю выше, чем маленький опыт, но на нужной мне платформе. В применении к Flutter'у: конкретно Dart+Flutter — это вовсе никакой не Хаскель — и освоить Flutter человеку с опытом совсем не сложно.

                                                                                            0
                                                                                            Интересно выяснить ответ на такой вопрос — это правда, что для сборки приложения Flutter нужно устройство с MacOs и сам Iphone?
                                                                                              0

                                                                                              Разрабатывать можно на любом – используя эмулятор Андроида. Для сборки под iOS – да, в любом случае нужен mac (iPhone не особо нужен, можно обойтись симулятором в большинстве случаев), хотя можно воспользоваться облачным решением для сборки, например, https://codemagic.io/


                                                                                              В общем, с маком будет удобнее, но в теории можно обойтись и без него.

                                                                                                0
                                                                                                Если вы хотите разрабатывать для iOS, то на любом инструменте вам понадобится Mac для сборки (либо облачные сервисы для сборки), iPhone не обязателен. Хотя те же пуши без iPhone не оттестишь, на симулятор они не приходят. Если вы хотите разрабатывать под iOS как-то несерьезно не иметь Mac и iPhone.
                                                                                                  0
                                                                                                  В одном из последних обновлений симулятора завезли что-то вроде поддержки пушей :) Правда, не полноценных: можно перетащить на симулятор специальным образом составленный JSON-файлик, и он преобразуется в пуш, который будет проброшен вашему приложению, как будто он пришёл с сервера. Но, конечно, к сожалению, подписаться на настоящие пуши и проверить, что всё работает end-to-end без устройства не получится.
                                                                                                +1
                                                                                                Бредовая философия от которой выигрывает только одно, и то в краткосрочной перспективе — кошелёк заказчика, а дальше страдают все — пользователи, заказчик, разработчики приложений.

                                                                                                Посмотрите про флаттер недавний пост от медузы и почитайте комменты.
                                                                                                  0
                                                                                                  Ребят, вопрос к Xamarin-щикам или Flutter и т.д. А как у вас обстоит дело в крашлитикой и другими аналогичными крашами? Лично у меня волосы на дыбы встают после китайских мутантов. А вы как фиксаете, получается?
                                                                                                    0
                                                                                                    В простом сравнении выглядит, что flutter заменил webView на canvas для рендера элементов, которые будут лишь мимикрировать под нативные. Как по мне, такой подход не сильно отличается от рендера элементов под webView, который в статье критикуется за ненативность, разница лишь в производительности. Недавно на хабре была статья о приложении Meduza написанном на flutter. Так вот в нём, на моём LG Q6, скроллинг очень сильно лагает и сама прокрутка выглядит ненативно, несмотря на заверения команды flutter о нативности и производительности.
                                                                                                      0
                                                                                                      говори что он побеждает, чтобы другие поверили.
                                                                                                      Недавно отписался от какой то группы в телеграме, которая приводила типа статистику, поднялись продажи на такие то товары, типа на одежду. Потом читаю новости продажи по одежде просели максимально сильно. В общем тут кто-то врет, я подумал что все таки маркетологи из этого телеграм канала, ну они писали типа на wildberries выросли продажи на 600% одежды и т.п. в общем тут из той же серии. Почему Flatter побеждает. Ну вот не знаю. Тоже к нему присматриваюсь, присматриваюсь. Но вот схожесть с React меня почему то от него отталкивает. Простите меня любители react. Я просто сторонник Ractive,Vue, и вот это вот все.
                                                                                                      Так вот, тут недавно была статья про медузу, что на флаттер написана, ну я скачал, упс, оказывается скачал старое приложение нативное, якобы. Но нативное там скорее всего только WebView остальное уже HTML, потому что тормозит оно ужасно ( ну там сверху значит, у нас вышло новое приложение, нажми чтобы скачать, ну я скачал, да, поновее. И тем самым я смог сравнить то и другое. Первое жутчайше тормозит при скролле вверх вниз. Второе на Flatter при скролле как то странно скроллится, не естественно и тоже подергиваясь, но как то более линейно чем «нативное». анимация открыти окон вроде ничего, нормально все отрабатывала, шрифты красиво, в целом все хорошо, но вот скролл какой то странный все же. Может быть конечно у них только так, но я когда первые Hello world'ы собирал, тоже не особо скоростью радовало, особенно вначале.
                                                                                                        0

                                                                                                        Еще во Flutter какой-то ад с темами. К примеру, для слайдера можно в общей теме переопределить sliderTheme, а когда это делаешь для buttonTheme, то часть работает (height), а часть нет (цвета, отступы). При этом документация на голубом глазу говорит, что можно переопределять что хочешь. И только в issue tracker-е расскажут, что есть такая давняя проблема, разрабы о ней знают, обещают большой рефакторинг, который исправит ситуацию, но в документации почему-то об этом молчат.

                                                                                                          0
                                                                                                          А чем плох кроме «тормозов» и ненативности PhoneGap? У меня два приложения на PhoneGap. Оба не тормозят вообще, одно из них карта с кэшом на Leaflet с наложенными poi и векторным слоем. Скачиваний не много: у одного чуть больше 10.000, у другого 5.000, на ненативность никто не жаловался. Всё время читаю, что надо срочно убегать с PhoneGap, но мне бы понять зачем…
                                                                                                            0
                                                                                                            Попробуйте отобразить список из 500 элементов хотя бы, чтобы не было тормозов при скроллинге, а теперь 1000, несколько тысяч. А теперь множество горизонтальных списков на одном экране, так чтобы каждый из них переиспользовал элементы друг друга (как сделано в гугл плей). Да, вы можете применить ту же технологию, что и в нативе (переиспользование элементов списка, но я думаю это уже довольно сложная задача и не факт, что будет значительно лучше).
                                                                                                            Пример с картами — это как раз та ниша, где phoneGap уместен.
                                                                                                            Для каждого инструмента своя ниша. Для приложения где оптимизация не важна эта технология вполне подходит, но для серьезного проекта есть куда лучшие варианты (Натив, Xamarin, Flutter, React Native).
                                                                                                            Извиняюсь, что пишу про тормоза, но просто это решающий момент, почему разработчикам все еще приходится писать нативно.

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

                                                                                                          Самое читаемое