Как стать автором
Обновить

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

Небольшая просьба: укажите, в каких попугаях нарисован последний график. А то сверху «скорость», а на графике «время» (т.е. прямо противоположное). Или хотя бы «чем больше, тем лучше», или наоборот.
Спасибо поправил. Там речь о времени

Все равно непонятки остались. В чем выражается время? Часы, дни, недели?

Как по мне (я писал и под Android, и под React Native, Flutter и iOS не пробовал), продуктивность разработки под React Native такова, что за это время в Android Studio можно в три раза больше функционала реализовать. Но это моё субъективное мнение.
Мое субъективное мнение что продуктивность зависит от прямоты рук и понимания языка /фреймворка. Пока соберется приложение из-под Android Studio (Core5/SSD/16Gb) на React Native можно уже пару-тройку компонентов и протестировать.
Мое субъективное мнение что продуктивность зависит от прямоты рук и понимания языка /фреймворка.

Ну понятно, что «кадры решают всё», но как правило, радиус кривизны рук у программистов постоянен и не особо зависит от инструмента. Неопытный программист везде мучается, опытный со всем легко разбирается. А инструмент играет большую роль. Взять тот же UI, в Android Studio вы рисуете вьюху в дизайнере, и запускаете посмотреть, по сути, один раз после того, как закончили рисовать. Под RN вы где-нибудь в VS Code описываете компоненту, запускаете, смотрите, рихтуете, перезапускаете, рихтуете, перезапускаете — и это дёрганье так продолжается до получения нужного результата. Это просто непродуктивно.
Мусье, а вы точно на Реакте пробовали?
Раскрою вам секрет, цепляетесь дебаггером к приложению и меняете стили прямо вот налету, без всяких перезапусков, как в браузере в консоли разработчика. Быстрее чем на Андроиде выходит.
Причем наибольшее преимущество получается на больших проектах, где сборка приложения занимает пару минут, а Instant Run по разным причинам не работает.
В сравнении реализации списков какая-то не полная картина:
В android нужно делать create + bind, а в flutter только create, т.к. виджеты flutter легковеснее android views. Что несколько упрощает разработку.

А что там с жором батарейки и вообще скоростью запуска и работы приложений?

Жор батарейки мною не рассматривался. Насчет скорости — разрабатываемые приложения очень маленькие. Всего 3 экрана. И разницу в скорости визуально ощутить не получилось, так как все приложения выглядят шустро. А программное измерение скорости я не производил
Как я понимаю автор топит за Flutter и пишет под Android, ничем иным объяснить график я не могу.
У других экспериментаторов таких проблем не было (https://hackernoon.com/react-native-vs-flutter-which-is-more-startup-friendly-c6e412d0b9ab, https://hackr.io/blog/react-native-vs-flutter)
Я не понял как Rx относится к многопоточности? На примере того же Свифта, если сабджект дергается не из основного потока (например делался хттп запрос) то юай так просто из него не проапдейтишь
Особенно на флаттере. Стримы кстати как и Rx там асинхронно работают, но по идее в том же потоке. В дарте для многопоточности вроде как отдельный механизм применяется, не стримы, изоляты или как то так. Но вообще посмотреть нужно, может можно для разных стрим трансформеров, или как там подобные объекты в Rx называются, задавать потоки выполнения. В нативном андроиде вроде можно было так Rx использовать, недавно смотрел видео
Если что я только учусь и сильно за искажения фактов не бейте.
Но в целом когда я с флаттером знакомился он мне своей концепцией и простотой понравился кстати.
Выдержка из статьи про RxSwift
оператор — observeOn
Указывает, на каком Scheduler должен выполнять свою работу Observer, особенно критично при работе с GUI.
example("\"observeOn\"") {
    DispatchQueue.global(qos: .background).async {
        Observable
            .of(1, 2, 3)
            .observeOn(MainScheduler.instance)
            .subscribe({ event in
                print("Main: \(Thread.isMainThread)\t\tEvent: \(event)")
            })
        Observable
            .of("A", "B", "C")
            .subscribe({ event in
                print("Main: \(Thread.isMainThread)\t\tEvent: \(event)")
            })
    }
}

Консоль:
Main: false Event: next(A)
Main: false Event: next(B)
Main: true Event: next(1)
Main: true Event: next(2)
Main: true Event: next(3)
Main: true Event: completed
Main: false Event: next(C)
Main: false Event: completed
А зачем в Реакт тянуть RX, есть там уже есть Promise и Async/Await? Просто для унификации или от нечего делать? Просто странно сравнивать скорость двух лошадей, у одной из которых к ногам привязали костыли, что бы говорить«Ну вот вы видите, не может она быстро бежать»…
А зачем в Реакт тянуть RX, есть там уже есть Promise и Async/Await?

RX вообще не связано никак с promise и async/await.

Что, серьезно? Я вот почему то думал что согласно своему описанию RXJS это «инструмент для удобного контроля последовательных действий». А если в примере автора он не для этого (из-за нежелания пользоваться встроенными механизмами) то зачем?
Зашел на reactivex.io и контроль последовательности действий там упомянут разве что между прочим.
Ну уж не знаю, не для асинхронности же его ввел автор в проект ReactNative, там как бы изначально все асинхронно. Ваши идеи зачем его добавили?
Поскольку код на реакт нейтиве не смотрел поэтому не могу ответить зачем его там ввел автор, но допустим когда я посматривал на флаттер я стримы и await всякие для заметно разного использовал. await, future не дает реактивности по факту, а Rx или даже просто стримы дают.
Цифра с тобой. мой друг :)
Прежде всего, оно дает абстракцию потока событий и механизмы для манипуляций с такими потоками.

Да, использование rx исключительно для запросов к бэкэнду неоправдано, и async/await куда проще. Но запросами к бэкенду модель в сложном приложении не ограничивается.
Всякому инструменту свое применение…
RX далеко не всегда оправдан даже самим разработчиками ReactiveX.
image
Табличка тут немного кривая: для Asynchronus Multiple Value есть AsyncIterable. А Observable применимо для push-based потоков независимо от их синхронности.

Observable — это просто двойственная к Iterable конструкция со всеми вытекающими.
С асинхронностью это никак не связано все, а правильный аналог в первой колонке — это Get vs OnNext() (= Set)

надо бросать тяжёлые препараты :)
Cпасибо за статью, интересно узнать про результат, сравнительные характеристики готовых приложений?
Так как приложения очень маленькие — скорость их работы визуально одинакова. Сначала я думал сравнить сколько будут весить Apk для Android. Но сравнивать размеры тоже было некорректно, т.к.:
1)В React Native был добавлен Realm, нативная часть которого очень утяжелила Apk.
2)В Android я запихнул кучу библиотек, без которых я считаю, как “истинный Android разработчик“, приложению не обойтись.

И всё-таки, шёпотом, вне зачёта, сколько вышло?

в копилку для Flutter:
встроенного в AS редактора UI нет, но есть такой проектик flutterstudio
(спасибо GDGNN и лично Саше Денисову, за то что показал).
Возможно в скором времени это и в студию внесут)
который опять ни в чем кроме хрома не работает?

Я не в курсе) не проверял. В хроме работает и норм.

Возможно, глупый вопрос. При выключении экрана или увода в фон приложения таймер стопорится в каком-то приложении? Давно смотрел Cordova, а там webview, и внутренний JS таймер то ли стопорился совсем, то ли сильно замедлялся.

Тут нужно обратить внимание: при уходе в фон убивается процесс приложения или нет. В ios процесс убивается у свернутого приложения, через некоторое время. И убийство процесса никакой из вариантов не переживет. А если рассматривать ситуацию сворачивания в Android до момента убийства процесса, то Flutter нормально работает и время не останавливается. А в React Native таймер зависает
Я реализовывал таймер через RxJs interval
 this.subscription = interval(1000)
            .pipe(take(list.length))
            .subscribe(a => {
                this.timer.show(list[a])
            })

такой код в моем презентере. Именно в такой реализации таймер стопится. После вопроса я специально запустил приложение и проверил.
Приведенную вами библиотеку я не рассматривал. Но видно, что либа строит мост в native и там уже реализуется таймер. Понятное дело, мне ничто не мешает сделать foreground service в Android, запустить в нем таймер и общатьсяс c js через мост, даже без использование либы. И такой таймер на родных прошивках в Android убиваться не будет в принципе.
То что я писал это про выполнение JS
Пардон, а что, Флаттер как то по другому реализует таймеры, не через foreground service? Всякому инструменту свое место, и в 99% ситуаций таймеру не нужна работа в фоне.
Я понимаю что вы фанат Флаттера, но хотелось бы больше объективности.
Во Flutter при той же реализации что и в React — Native c помощью Rx не стопиться
Вот какая реализация во флатере
  subscription = new Observable<ModelTimer>.fromIterable(list)
        .interval(new Duration(seconds: 1))
        .listen((modelTimer) =>

Я объективно ответил на комментарий — проверив, запустив разработанные приложения
Давайте что бы не разводить срач
  1. в ReactNative не работает Ваша реализация таймеров на RxJS
  2. в ReactNative успешно работают таймеры / процессы в фоне при помощи сторонних модулей


Ведь можно так написать, а не «в React Native таймер зависает». Тут кстати вопрос к Flatter, он все таймеры выносит в foreground service Android или как то сам принимает решения.
Rx использует таймеры из стандартной библиотеки без каких-то особых хитростей. Так что правильно писать вот так:

в ReactNative не работает setInterval

В активити Cordov'ы на onPause стопорятся таймауты WebView. Таймеры не работают в фоне.
Спасибо за статью! Очень хотелось бы все же узнать выводы, хотя бы в комментах :) Пусть это и будет с призмы личного опыта. И почему в выборку не попал популярный ionic?
1)Почему не попал ionic? Потому что, лично для меня, были интересны React Native и Flutter
2)Главное для меня при разработке приложений — это их поддерживаемость. Да, я понимаю, что кроссплатформа быстрее и кажется на первый взгляд выгоднее для бизнеса. Но в долгосрочной перспективе, по моему мнению, она себя не окупит, так как все равно придется писать мост к нативу, когда нужно будет писать что-то специфическое под платформу. Хотя, если я буду писать домашний проект, я склонюсь к Flutter.
По поводу скорости загрузки: специально создавал одинаковые приложения-пустышки для Android с использованием Xamarin, Flutter и Native. Оба кроссплатформенных проиграли на старте в разы. Потом, в работе, особой разницы не заметил.
-Товарищ несите отвертку! — Мне нужно забить гвоздь

По своему опыту, могу сказать, разработка на кросс платформе занимает в разы больше времени и да и поддерживать это все…, короче для себя экономической выгоды не увидел
Условно, написав за месяц приложение(а 70% времени это бизнес логика) для заказчика под андроид, создать тоже самое на ios займает ~неделю.

+Бизнесу постоянно в голову приходят новые свистелки-хотелки, используя натив я уверен, что задача будет реализована и за вменяемое время.

По моему мнению кросс-платформа подходит если:
Пишите собственную лабуду из разряда «Пацаны смотри, че запилил»
Клепаете на заказ 100500 приложений из разряда «Загрузить данные с сервера и нарисовать список»
Создаете приложения из разряда «Ну хотя б раз рекламу посмотри и можешь удалять»
Также склоняюсь к мнению что на данный момент инструменты разработки мобильных кросс платформенных приложений все еще на стадии развития. Да и разработчики ios и Android особо то и не спешат создать совместными усилиями качественную кросс платформенную среду. Вместо этого они, напротив, еще больше плодят языки/инструментарии.
Если посудить, что выбрать новичку в и начать изучать: нативные (native Android и ios), гибридные (Cordova, Phonegap), или кросс платформенные (React Native, Flutter, Xamarin)? Что более приемлемо с точки зрения затраченных усилий и полученных навыков? Для изучение кросс платформенных иснтрументов нужно затратить такое усилие, которое сопоставимо с изучением основ разработки для Android. Да плюс к тому же, для комфортной разработки на кросс платформенных иснтрументах нужны базовые навыки и знания основ разработки для Android и ios. Если нужно создать простое приложение без затрат значительных усилий, то выбор очевиден — Cordova и Phonegap. Получается, учитывая что разработка для ios затратно финансово (нужна машина на MacOS) и у ios меньшая доля рынка, оптимальная стратегия — выбрать либо native Android либо гибридные.
А я для своих домашних приложений запускаю на андроиде обычные extends Thread из Java. Вроде работает.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.