Комментарии 26
Работа с камерой и отпечатками пальцев в RN нормально реализована, с чего вдруг там риски?
Еще 2 года назад все работало отлично, не думаю что что то поменялось.
Splash screen это вообще на уровне native настраивается, что вы за бред пишите?
«При использовании React Native верстку на iOS и Android нужно проводить одновременно»… а что, во Flutter/native/web она сама волшебным образом встанет как надо? Странная логика
Статья написано тем кто мало понимает в том о чем пишет.
Еще 2 года назад все работало отлично, не думаю что что то поменялось.
Splash screen это вообще на уровне native настраивается, что вы за бред пишите?
«При использовании React Native верстку на iOS и Android нужно проводить одновременно»… а что, во Flutter/native/web она сама волшебным образом встанет как надо? Странная логика
Статья написано тем кто мало понимает в том о чем пишет.
Добрый день. Риски в RN связаны с нативными библиотеками и могут проявляться, например, при работе с разными версиями ОС и моделями телефонов.
Да, как мы и пишем, в Splash screen отрисовка происходит нативно, все верно.
Если в вашем проекте нет необходимости строго соблюдать стили Android и iOS, вы можете ограничиться одним вариантом верстки. Если дела обстоят наоборот, придется повозиться с каждым вариантом отдельно. Один и тот же код верстки на RN может по-разному работать на iOS и Android, поэтому в процессе верстки нужно смотреть, как все работает на обеих платформах.
Да, как мы и пишем, в Splash screen отрисовка происходит нативно, все верно.
Если в вашем проекте нет необходимости строго соблюдать стили Android и iOS, вы можете ограничиться одним вариантом верстки. Если дела обстоят наоборот, придется повозиться с каждым вариантом отдельно. Один и тот же код верстки на RN может по-разному работать на iOS и Android, поэтому в процессе верстки нужно смотреть, как все работает на обеих платформах.
Если «Splash screen отрисовка происходит нативно» то зачем о возможных проблемах с нам у RN? Там нет RN / Flutter кода, это делается в AndroidManifest / LaunchScreen.xib, не вводите в заблуждение.
«Риски в RN связаны с нативными библиотеками и могут проявляться, например, при работе с разными версиями ОС и моделями телефонов»… так риски с RN или с нативными библиотеками? Сборка андроид приложения сейчас тоже напоминает танцы с бубном, когда начинаются конфликты зависимостей
«Риски в RN связаны с нативными библиотеками и могут проявляться, например, при работе с разными версиями ОС и моделями телефонов»… так риски с RN или с нативными библиотеками? Сборка андроид приложения сейчас тоже напоминает танцы с бубном, когда начинаются конфликты зависимостей
https://github.com/react-native-community/react-native-camera/issues
Проблем много. Недавно была создана задача о том, что компонент вообще не поддерживает новые версии андроида.
Я сам за гибридную разработку, но, как написано в статье, в тех случаях, когда стабильность не сильно важна.
Для полной картины сравнения нативной и гибридной разработки неплохо был бы добавить и Kotlin Multiplatform. Технология хоть и совсем новая, но зато позволяет создавать нативные для платформы приложения и иметь единую базу кода для основной логики.
Это было бы не совсем корректно. React Native и Flutter позволяют создавать приложения от начала и до конца, включая UI и его поведение. Kotlin Multiplatform хорош для общей бизнес-логики для нескольких платформ, но UI и UX реализации ему нужны сторонние. Например, нативные или интеграция с Flutter
Да, абсолютно верно, но мне как и некоторым другим людям из комментариев, не хватило вариантов совмещения нативной и кроссплатформенной разработки. Вроде здесь говорится вообще о разработке приложений в целом, а не только про UI и даются рекомендации по выбору технологического стека. Так что упомянуть другие варианты, как мне кажется, не лишнее.
А Вы рассматривали вариант без крайностей native ИЛИ гибрид? На данный момент я участвую в разработке приложения, где наиболее используемые экраны где нужны анимации и производительность пишем native. А все остальные делаем во flutter. И на этот формат мы переходим постепенно из двух полностью нативных разработок (iOS + Android)
Да, предложенный вами вариант подходит для некоторых кейсов, совмещение нативной и кроссплатформенной разработки возможно. Как правило, кроссплатформенная разработка служит для того, чтобы снизить затраты на проект. При выборе способа разработки мы учитываем несколько взаимосвязанных критериев, таких как сроки и бюджет, задачи конкретного приложения, наличие специалистов. В статье мы описали решения, которые выбирали для отдельных кейсов – это не «серебряная пуля» и единственно верный гайд для разработки.
В чём проблема написать часть приложения (ту, где RN / Flutter не справятся) в Native? Зачем полностью отказываться от кроссплатформы, только потому, что не хватает какого-то функционала, если эта проблема легко решается?
Зависит от задачи и от количества итогового платформозависимого кода.
Проблема задачи в том, что RN и Flutter основаны на подходе bridge-коммункации. Сам по себе этот bridge зачастую медленный. Он достаточно быстр для взаимодействия с большинством компонент, но при большой нагрузке может стать бутылочным горлышком.
Плюс если есть требования к размеру приложений (например, нужен Instant Apps) или к его взаимодействию с пользователем (например, управление на Apple TV и Android TV), то кроссплатформенные фреймворки сегодня не смогут предоставить подходящего решения.
Проблема в количестве платформозависимого кода состоит в том, что если его доля в проекте переваливает за 40-50%, то встает вопрос о надобности кроссплатформенного фреймворка в принципе. Соотношение время-деньги-качество получается уже не таким вкусным в сравнении с нативной разработкой. То есть две команды нативных разработчиков обойдутся дороже, но с реализацией справятся быстрее, а итоговое решение будет более отзывчиво себя вести и (при желании заказчика) соответсвовать гайдлайнам (что позволит привлечь или удерживать часть аудитории за счет привычного UX).
В итоге время здесь часто более важный фактор чем деньги. Раньше выйдешь на рынок- отхватишь больший кусок.
Проблема задачи в том, что RN и Flutter основаны на подходе bridge-коммункации. Сам по себе этот bridge зачастую медленный. Он достаточно быстр для взаимодействия с большинством компонент, но при большой нагрузке может стать бутылочным горлышком.
Плюс если есть требования к размеру приложений (например, нужен Instant Apps) или к его взаимодействию с пользователем (например, управление на Apple TV и Android TV), то кроссплатформенные фреймворки сегодня не смогут предоставить подходящего решения.
Проблема в количестве платформозависимого кода состоит в том, что если его доля в проекте переваливает за 40-50%, то встает вопрос о надобности кроссплатформенного фреймворка в принципе. Соотношение время-деньги-качество получается уже не таким вкусным в сравнении с нативной разработкой. То есть две команды нативных разработчиков обойдутся дороже, но с реализацией справятся быстрее, а итоговое решение будет более отзывчиво себя вести и (при желании заказчика) соответсвовать гайдлайнам (что позволит привлечь или удерживать часть аудитории за счет привычного UX).
В итоге время здесь часто более важный фактор чем деньги. Раньше выйдешь на рынок- отхватишь больший кусок.
По react native было бы корректно упоминуть Expo. Много модулей, поддержка iOS, Android, Web (бэта) платформ. А ещё есть React Native for Windows от MS. В итоге за RN — больше платформ.
Действительно, Expo – один из вариантов создания кроссплатформенного приложения, он подходит для реализации микрофункциональных фич и их демонстрации клиенту в качестве прототипа. Однако, есть свои ограничения. Начало проекта на Expo с последующим переходом на native может повлечь за собой ряд проблем, от верстки до замены вшитых библиотек Expo на нативные библиотеки.
Что касается React Native for Windows, в этой статье мы не акцентировали внимание на разработке десктопных приложений. В целом, библиотеки windows и web пока достаточно сырые, но в долгосрочной перспективе могут получить должную поддержку.
Что касается React Native for Windows, в этой статье мы не акцентировали внимание на разработке десктопных приложений. В целом, библиотеки windows и web пока достаточно сырые, но в долгосрочной перспективе могут получить должную поддержку.
Не очень понятно зачем нужна замена Expo библиотек на Native при выходе и проблемы с версткой — тот же самый RN
После eject из Expo нам просто пришлось компилировать приложение самим, так, как мы бы это делали бы на изначально чистом RN. При этом разработку по прежнему оставили в Expo, просто мокаем некоторые нативные вызовы в случае работы в Expo — очень все таки удобно QA и фичи показывать.
Ни о какой замене верстки или библиотек речи не идет, непонятно откуда это.
После eject из Expo нам просто пришлось компилировать приложение самим, так, как мы бы это делали бы на изначально чистом RN. При этом разработку по прежнему оставили в Expo, просто мокаем некоторые нативные вызовы в случае работы в Expo — очень все таки удобно QA и фичи показывать.
Ни о какой замене верстки или библиотек речи не идет, непонятно откуда это.
Автор с первых строк не совсем корректно сравнивает нативную разработку и ее преимущества с широкой экосистемой кросс-платформенной разработки. И это печально.
Сразу разделите гибридные решения на основе WebView (Phonegap/Cordova, Ionic) от гибридных решений типа React Native, Flutter, Xamarin. Это технически абсолютно разные направления. Одинаковые только концептуально (один код — разные платформы).
Во вторых — сервер здесь не при чем. Приложения нативные или гибридные — все они работают offline. Это изначально условие для любых приложений, которое может нарушаться только концептуально (например, Инстаграмм или Фейсбук или остатки на складе в реальном режиме времени).
Итак, для начала стоит ответить на простой вопрос: в чем отличие <View /> в React Native от нативного UIView в iOS и View в Android? (подсказка: Ни в чем. <View /> трансформируется в UIView или во View в зависимости от платформы)
Поэтому сравнивать UI сделанный в React Native с UI сделанный в XCode или Android Studio нельзя. Это одно и тоже (по качеству, производительности, кастомизации). И это касается всех элементов. Нет, правда всех. React Native даже Date Picker отображает, путем вызова конструктора нативного picker для каждой платформы. А Animate API, direct manipulation, useNativeDriver? Удивительно, но на уровне платформ разницы тоже нет. Да, создание компонента прилетело из декларативного описания, но компонент-то нативный и анимация тоже. И еще вопрос на засыпку, кто сегодня не выдумывает колеса или не использует решения с декларативным описанием интерфейса, вместо drag and drop в среде разработки?
Если копнуть глубже, там где требуется нативный код, то да — надо писать исключительно для платформы, нативно. Когда мы говорим «глубже», это глубже, чем камера, файловая система, отпечатки пальцев, карты. Короче это не простой доступ к hardware, с которым ни у React Native ни у Flutter вопросов нет. Даже Phonegap/Cordova давно решили эти проблемы с нативными плагинами (с переменным успехом и стабильностью), но не решили проблемы с производительностью WebView.
Ни RN ни Flutter не считают прямой доступ к нативному API за bad practices там, где это действительно необходимо и дают все инструменты для этого, не ограничивая. Зато reusable-код штампованной бизнес-логики впечатляет настолько, что даже <Button /> и <ButtonIOS /> на каждом шагу не очень расстраивают. Даже OpenGL в React Native и нативной разработке — это одна библиотека и частота кадров будет зависеть только от того, как быстро работает логика в каждом фрейме (и вот только здесь-то JS в виртуалке может уступить нативному коду).
Приведите один пример из своего опыта, где «глубже» это действительно что-то за рамками простого доступа hardware, карт? Может быть, сложная обработка изображений за границами популярных фильтров? Про UI уже сказал выше, повторюсь — не сравнивайте, это одно и тоже.
Сразу разделите гибридные решения на основе WebView (Phonegap/Cordova, Ionic) от гибридных решений типа React Native, Flutter, Xamarin. Это технически абсолютно разные направления. Одинаковые только концептуально (один код — разные платформы).
Во вторых — сервер здесь не при чем. Приложения нативные или гибридные — все они работают offline. Это изначально условие для любых приложений, которое может нарушаться только концептуально (например, Инстаграмм или Фейсбук или остатки на складе в реальном режиме времени).
Итак, для начала стоит ответить на простой вопрос: в чем отличие <View /> в React Native от нативного UIView в iOS и View в Android? (подсказка: Ни в чем. <View /> трансформируется в UIView или во View в зависимости от платформы)
Поэтому сравнивать UI сделанный в React Native с UI сделанный в XCode или Android Studio нельзя. Это одно и тоже (по качеству, производительности, кастомизации). И это касается всех элементов. Нет, правда всех. React Native даже Date Picker отображает, путем вызова конструктора нативного picker для каждой платформы. А Animate API, direct manipulation, useNativeDriver? Удивительно, но на уровне платформ разницы тоже нет. Да, создание компонента прилетело из декларативного описания, но компонент-то нативный и анимация тоже. И еще вопрос на засыпку, кто сегодня не выдумывает колеса или не использует решения с декларативным описанием интерфейса, вместо drag and drop в среде разработки?
Если копнуть глубже, там где требуется нативный код, то да — надо писать исключительно для платформы, нативно. Когда мы говорим «глубже», это глубже, чем камера, файловая система, отпечатки пальцев, карты. Короче это не простой доступ к hardware, с которым ни у React Native ни у Flutter вопросов нет. Даже Phonegap/Cordova давно решили эти проблемы с нативными плагинами (с переменным успехом и стабильностью), но не решили проблемы с производительностью WebView.
Ни RN ни Flutter не считают прямой доступ к нативному API за bad practices там, где это действительно необходимо и дают все инструменты для этого, не ограничивая. Зато reusable-код штампованной бизнес-логики впечатляет настолько, что даже <Button /> и <ButtonIOS /> на каждом шагу не очень расстраивают. Даже OpenGL в React Native и нативной разработке — это одна библиотека и частота кадров будет зависеть только от того, как быстро работает логика в каждом фрейме (и вот только здесь-то JS в виртуалке может уступить нативному коду).
Приведите один пример из своего опыта, где «глубже» это действительно что-то за рамками простого доступа hardware, карт? Может быть, сложная обработка изображений за границами популярных фильтров? Про UI уже сказал выше, повторюсь — не сравнивайте, это одно и тоже.
Даже реализация доступа hardware не так уж проста. В частности, в flutter для взаимодействия с нативной частью нужно создавать каналы для передачи данных и дублировать сущности в нативной части. Хорошо, когда есть библиотека, в которой это сделано. Однако, не всегда это возможно. Бывает, что на каких-то устройствах обнаруживаются баги. Бывает, что функциональность не в полной мере соответствует потребностям. Аналогично с RN: что-то работает на iOS, но не работает на Android – и наоборот. Кроме того, есть разница в производительности. Чем больше анимированных элементов на экране, тем ниже производительность (или потребуется дополнительное время, чтобы сделать все без тормозов)
Насколько я знаю из собственного опыта, баги на разных устройствах и разных версиях платформ обнаруживаются не только в библ. для RN/Flutter но и в нативной разработке и тут даже разраб. под отдельную платформу приходится туго (больше касается android). Возникает дилемма: наполнить код if/else для каждой версии или слегка «забить» на пользователей старых версий. В кроссплатформ. разработке аналогично поступают и разработчики библ. Ну, обобщая — это общий вопрос.
Разница в производительности? Логика, UI? На вопрос «Чем больше анимированных элементов на экране, тем ниже производительность» попробуйте сами ответить с оглядкой на то, что в итоге происходит рендеринг нативных компонент, не важно RN/Flutter или сборка со среды разработки Android Studio / XCode. Ну, полно сравнительных тестов и результат таков, что даже RN где-то выигрывает (при этом процент прироста настолько мал, что можно пренебречь). Смысла нет сравнивать нативные UI, один из которых построен декларативно, другой — «нативно» drag&drop в среде разработки.
Разница в производительности? Логика, UI? На вопрос «Чем больше анимированных элементов на экране, тем ниже производительность» попробуйте сами ответить с оглядкой на то, что в итоге происходит рендеринг нативных компонент, не важно RN/Flutter или сборка со среды разработки Android Studio / XCode. Ну, полно сравнительных тестов и результат таков, что даже RN где-то выигрывает (при этом процент прироста настолько мал, что можно пренебречь). Смысла нет сравнивать нативные UI, один из которых построен декларативно, другой — «нативно» drag&drop в среде разработки.
Со всем выше согласен, кроме разницы работы UI. RN по факту всегда медленнее на списках и сложных экранх из-за реализации рендера, а именно -> основный поток JS, который и запросы кидает, и бизнес логику, и рендеры запускает -> все рендеры идут в shadow dom, который еще и сравнивает, а не изменилось ли что? -> только потом идет нативный рендер. Как не трудно догодаться именно проброс из JS в shadow DOM является бутылочным горлышком всей системы. Особенно, если при открытии экрана происходит догрузка данных, после чего, появление новых элементов происходит с анимациями — это 100% тормаза на Android, iOS с этим справляется на много лучше, как и во всем RN, кстати.
p.s. сам уже 2.5 года пишу на RN, на данный момент приложение с 350к+ уникальных пользователей в месяц (iOS и Android)
p.s. сам уже 2.5 года пишу на RN, на данный момент приложение с 350к+ уникальных пользователей в месяц (iOS и Android)
О списках спорить не буду, тем более нагруженный рендер позиции может быть причиной тормозов и трудно представить, что его можно вынести за мост на нативную сторону. Правда, в документации RN указывается на асинхронный рендер и связанное с этим поведение и выгоды (пробелы при очень быстром скролле, сам скролл без тормозов).
Основной поток JS должен заниматься запросами и бизнес логикой, перед этим запустив анимацию. Если анимация нативная (Animated), то ей все равно, чем занимается основной поток JS. Запустите анимацию с usingNativeDriver и заблокируйте основной поток JS и увидите, что анимация не прерывается.
С Shadow DOM уже заинтересовали и тут вопрос — React Native использует Shadow DOM? Это же не React в среде DOM, как тогда? Если есть пруфы буду рад почитать.
Мы можем миновать state в узких местах и избежать сравнивания дерева, React Native дает инструменты для этого.
Понять из-за чего происходят тормоза при дозагрузке данных на Android, поможет только отладка и счетчики произв. Уверен, что при передаче анимации и запросов в БД на нативную сторону проблема начинает проявляться уже там. И тут надо подумать о принудительных задержках, например, дождаться запуска анимации, затем делать запросы и т.д.
Буду благодарен, если поделитесь ссылкой на приложение :)
Основной поток JS должен заниматься запросами и бизнес логикой, перед этим запустив анимацию. Если анимация нативная (Animated), то ей все равно, чем занимается основной поток JS. Запустите анимацию с usingNativeDriver и заблокируйте основной поток JS и увидите, что анимация не прерывается.
С Shadow DOM уже заинтересовали и тут вопрос — React Native использует Shadow DOM? Это же не React в среде DOM, как тогда? Если есть пруфы буду рад почитать.
Мы можем миновать state в узких местах и избежать сравнивания дерева, React Native дает инструменты для этого.
Понять из-за чего происходят тормоза при дозагрузке данных на Android, поможет только отладка и счетчики произв. Уверен, что при передаче анимации и запросов в БД на нативную сторону проблема начинает проявляться уже там. И тут надо подумать о принудительных задержках, например, дождаться запуска анимации, затем делать запросы и т.д.
Буду благодарен, если поделитесь ссылкой на приложение :)
Странный у вас график в Google трендах: якобы в 2016 году и ранее flutter был популярнее React Native. Странный, потому что первый выпуск, согласно википедии, был в 2017 году.
Слово-то популярное, стоило бы уточнить область применения при запросе.
Слово-то популярное, стоило бы уточнить область применения при запросе.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Нативная разработка, React Native и Flutter: критерии выбора