Всем привет! Я Игорь Веденеев, руководитель отдела мобильной разработки AGIMA. Давайте немного поговорим о нативной и кроссплатформенной разработке.
Раньше ко второму я относился по большей части скептически: меня не устраивало в первую очередь качество финальных приложений.
Однако за последний год темпы развития кроссплатформенных фреймворков заставили нас пересмотреть свое мнение об этом подходе.
Поэтому давайте еще раз сравним самые популярные кроссплатформенные решения и нативную разработку.
На всякий случай
Если вы не знаете, что такое нативная и кроссплатформенная разработка:- нативная разработка (2 независимых приложения на Swift и Kotlin);
- кроссплатформенная разработка — общая кодовая база для iOS и Android (с использованием фреймворков Flutter или React Native (далее RN)).
Соответственно, один из них подходит для каждого конкретного проекта и каждой конкретной цели.
Сейчас объясню, как выбирать и на что обратить внимание.
Нативная разработка
Нативная разработка — это классический способ создания приложения для iOS и Android. Осуществляется с помощью инструментов и языков программирования, предлагаемых вендорами — Apple и Google. Языками в данном случае являются Swift (iOS) и Kotlin (Android), а в нативной разработке имеется масса инструментов для профилирования и отладки.Однако надо понимать, что в данном случае мы делаем два независимых приложения.
Они разрабатываются параллельно.
Каждое приложение может реализовать фичу по-своему, и в каждом могут быть свои ошибки.
И самое главное, нативная разработка никуда не денется: пока существуют iOS и Android, Apple и Google будут предоставлять инструменты для создания приложений.
Нативная разработка позволяет создать максимально качественное и функциональное приложение, но взамен вам придется все разрабатывать и отлаживать 2 раза и следить за тем, чтобы приложения функционально соответствовали друг другу.
На сегодняшний день это самый популярный способ создания приложений среди разработчиков.
Поэтому собрать команду, даже большую, в этом случае проще, чем для кроссплатформенной.
В первую очередь из-за количества предложений на рынке.
Плюсы и минусы нативной разработки
| + | — |
| Стабильность, предсказуемость | 2 независимых приложения |
| Производительность, плавность | Стоимость разработки и отладки |
| Меньше потребления ресурсов* | Синхронизация платформы |
| Богатые инструменты разработки | - |
| Широкий рынок разработчиков | - |
Кроссплатформенная разработка
Кроссплатформенная разработка означает, что мы используем один и тот же код как на iOS, так и на Android. По большому счету, это все то же родное приложение, но после его запуска мы сразу попадаем в мир Flutter или RN, и все происходит там.Стоит отметить, что разработка во Flutter/RN происходит быстрее.
И не только из-за того, что мы делаем 1 приложение вместо 2, но и из-за концепций создания приложений, в частности UI. Но, увы, не все так хорошо: кроссплатформенность имеет ряд проблем, на которые следует обратить внимание, прежде чем выбирать такой подход для своего приложения.
React Native и Flutter по-прежнему являются сторонними решениями с открытым исходным кодом.
Они могут содержать ошибки.
Новые возможности iOS и Android там появятся не так быстро, как в нативных решениях.
Поддержка может со временем прекратиться.
Также довольно часто вам придется полагаться на сторонние библиотеки с открытым исходным кодом, что также несет в себе риск потенциальных проблем: например, совместимости версии Flutter/RN. Вполне возможно, что необходимой библиотеки не существует в природе, и тогда вам придется реализовывать все с нуля самостоятельно.
Также вы не можете добавить расширения для приложений iOS или, например, смотреть приложение .
Это касается как Flutter, так и RN. То есть для реализации определенных функций вам придется добавлять нативный код, что приведет к смешению технологий.
Как минимум, вам нужно будет иметь в них компетентность.
Как максимум организовать перенос данных из нативного кода в кроссплатформенный и наоборот. Если в приложении много логики и есть необходимость сделать его многопоточным, это тоже будет проблемой и во Flutter, и в RN. Это возможно, но, скажем так, эти фреймворки создавались не для этого.
Также каждый из фреймворков имеет достаточно тяжелую среду исполнения, что делает кроссплатформенные приложения более ресурсоемкими и требовательными к процессору/оперативной памяти телефона.
Если приложение предполагает широкое использование аппаратных возможностей телефона и взаимодействие с ОС, то я бы тоже не советовал использовать кроссплатформенность — есть риск, что в какой-то момент либо код станет сильно запутанным, либо мы столкнёмся с ограничения одной из платформ или самого фреймворка.
Также стоит учитывать, что нам следует использовать платформо-нейтральный пользовательский интерфейс, чтобы не создавать потенциальных проблем с разным поведением на платформах и в принципе не снижать скорость разработки.
На картинке ниже показаны результаты теста с простым списком с изображениями: мы видим, что нативное приложение выигрывает безоговорочно.
Да, на новых моделях телефонов разница будет не столь существенной, но тенденция просматривается.
Другие результаты испытаний здесь .
Проще говоря, кроссплатформенность позволяет разработать приложение в кратчайшие сроки.
Лучше всего подходит для приложений среднего/малого объема услуг или демонстрации продуктов без широкого использования возможностей платформы.
То есть сделать фото на аватарку или отсканировать QR-код не составит большой проблемы, но если вы делаете приложение под камеру, то лучше рассмотреть нативную разработку.
Плюсы и минусы кроссплатформенной разработки
| + | — |
| Единая кодовая база | Потенциальные риски |
| Затраты на разработку | Ресурсоемкость |
| Скорость разработки | Не охватывает все случаи разработки |
| Охватывает большое количество случаев | Трудно найти исполнителей |
| - | Ограничения дизайна** |
React Native против Flutter
Итак, вы остановились на кроссплатформенности.Что выбрать? Я бы выбрал Флаттер.
Кажется, это многообещающая кроссплатформенная платформа.
Хотя RN — самая зрелая технология, Flutter уже ее опережает. темпы развития .
Что касается самой разработки, то на Dart можно писать более безопасный код по сравнению с JavaScript, что позволяет отловить множество ошибок еще до этапа тестирования.
| трепетать | Реагировать нативный | |
| Автор | Фейсбук | |
| Год создания | 2018 | 2015 |
| Язык | Дарт | JavaScript |
| Принцип действия | Собственный движок рендеринга Skia | Использует React, нативные компоненты вызываются из JS-кода.
|
| Функции | Типизированный язык Null Safety; потенциально меньше проблем с обновлениями ОС благодаря механизму рендеринга; флаттер паутина | Теоретическая возможность повторного использования веб-компонентов; большой рынок застройщиков (по состоянию на июль 2021 г.
); знание React для веб-разработки будет актуально |
Только вот это самая молодая технология, и поэтому найти крутых специалистов сложнее всего.
Тем не менее, как по мне, на данный момент за Flutter будущее, так что давайте за него утонем.
Хотя, если у разработчиков всё плохо и приложение готово пережить все недостатки RN, то я не вижу в нём больших проблем.
Примеры кроссплатформенных приложений
| трепетать | Реагировать нативный |
| Ригла ( Магазин приложений / Гугл игры ) | CoinBase |
| Дикси ( Магазин приложений / Гугл игры ) | самое важное |
| Свои (Россельхозбанк, маркетплейс сельхозпродукции: Магазин приложений / Гугл игры ) | Скайп |
| Мир корма( Магазин приложений / Гугл игры ) | Болт Еда |
| eBay Моторс ( Магазин приложений / Гугл игры ) | Викс |
| Альберт Хейн (голландское «Пятерка»: Магазин приложений / Гугл игры ) | Раздор |
| Яндекс.
Про ( Магазин приложений / Гугл игры ) | Тесла |
Общий
| Родной | Кросс-платформа |
| Производительность, плавность | MVP, приложения без сложной логики |
| Много логики на клиенте | Скорость и бюджет важны |
| Широкое использование возможностей платформы | Мало логики на клиенте |
| Увеличение количества функций, переход на суперприложение | Малое использование функций платформы |
| Есть ресурсы | Мы готовы терпеть просадки в плавности и скорости работы*** |
Скорость разработки
Для примера возьмем реальный проект: главную страницу одного из проектов AGIMA. На главной странице приложения можно записаться на прием к врачу онлайн, есть новости, советы и блок, посвященный одной из встроенных услуг.Теперь прикинем, сколько времени потребуется на верстку такой страницы вместе с запросами.
| Родной | Кросс-платформа |
| 64 часа (32 на платформу) | 28 часов |
Заключение
Если вы планируете многофункциональное приложение с клиентской логикой для большой аудитории, то лучше использовать нативное приложение.В остальных случаях можно рассмотреть кроссплатформенные решения.
P.S. Если я упустил какие-то плюсы и минусы обоих способов разработки, буду рад узнать о них из комментариев.
* - по сравнению с кроссплатформенными приложениями.
** - желательно использовать один и тот же нейтральный к платформе дизайн, чтобы сохранить простоту кода и скорость разработки.
*** - мое личное наблюдение; не означает, что кроссплатформенный по умолчанию тормозит, а нативный нет, но есть тенденция, что нативный работает быстрее и плавнее.
Теги: #mobile #мобильная разработка #кроссплатформенность #кроссплатформенность #native
-
Что Происходит С Оборудованием После Молнии
19 Oct, 24 -
Загадочный Случай С Фантомным Сертификатом
19 Oct, 24 -
Эффективный Вариант Собеседования
19 Oct, 24 -
Ит-Аудит
19 Oct, 24 -
Че-Мобиль: Волга-Порше Евгения Чичваркина
19 Oct, 24
