0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Кроссплатформенные приложения против нативных: сравнение и; выбор подходов

Статья была впервые опубликована здесь.

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

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

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

Эта статья призвана рассказать о двух подходах к разработке приложений — нативном и кроссплатформенном.

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

Выбор пути мобильной разработки

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

Одним из первых шагов на пути к цифровому успеху является решение о мобильной операционной системе – это, кстати, было не так просто десять лет назад, когда Android, iOS, Microsoft, RIM и Symbian были вполне жизнеспособными вариантами.

Сегодня выбор гораздо проще, поскольку единственными крупными игроками остаются Android и iOS, которые вместе составляют около 99% от общей доли рынка мобильных операционных систем. Согласно различным статистическим данным, Android выигрывает по количеству пользователей, но нет недостатка и в сторонниках iOS, доля которого на рынке составляет 25,75%. В то время как Google Play Store может похвастаться большим количеством приложений (2,5 млн), Apple App Store содержит более 1.8 млн приложений. Одного этого факта достаточно, чтобы показать, что ни одну из двух платформ не следует упускать из виду.

Поскольку выбор мобильной операционной системы является вопросом личных предпочтений пользователей, а не вопросом производительности или доступности, будет целесообразно в конечном итоге создать мобильное приложение как для Android, так и для iOS – и есть три способа сделать это.

Миф 1. Магия

Самый частый миф, будоражащий умы начинающих девелоперов, связан с верой в сверхалгоритмы (и сверхпрограммистов, их создавших), которые волшебным образом превращают кросс-платформенные приложения в нативные. Что-то в духе «преобразования кода JavaScript в Swift и дальнейшая компиляция уже Swift-приложения». Этот миф подогревают и сами разработчики кросс-платформенных инструментов, обещая на выходе создание «нативных приложений». И не то чтобы кто-то здесь лукавил, но богатая фантазия и непонимание базовых механизмов иногда наводят разработчиков на мысли о шаманских приемах.

Главный принцип, лежащий в основе кросс-платформенных решений, — разделение кода на две части:

  • кросс-платформенную, живущую в виртуальном окружении и имеющую ограниченный доступ к возможностям целевой платформы через специальный мост;
  • нативную, которая обеспечивает инициализацию приложения, управление жизненным циклом ключевых объектов и имеет полный доступ к системным API.

Для того чтобы связывать между собой мир «нативный» и мир «кросс-платформенный», необходимо использовать специальный мост (bridge), именно он и определяет возможности и ограничения кросс-платформенных фреймворков.

При использовании bridge производительность всегда снижается за счет преобразования данных между «мирами», а также конвертации вызовов API и библиотек.

Итак, все кросс-платформенные приложения обязаны иметь нативную часть, иначе операционная система просто не сможет их запустить. Поэтому давай рассмотрим подробнее, какие системные API и механизмы предоставляются самими iOS, Android и Windows. Переходим к следующему мифу.

Миф 2. Ненативно!

Итак, у нас есть кросс-платформенная часть приложения, живущая в виртуальном окружении и взаимодействующая с операционной системой через инфраструктуру фреймворка и мост.

Все операционные системы: iOS, Android и Windows UWP — предоставляют доступ к следующим подсистемам (наборы системных API):

  • WebView (встроенный в приложение веб-браузер) используется в гибридных приложениях на базе PhoneGap и фактически выступает средой выполнения локального веб-сайта;
  • JavaScript-движки используются в React Native и аналогах для быстрого выполнения JS-кода и обмена данными между Native и JS;
  • OpenGL ES (или DirectX) используется в игровых движках и приложениях на Qt/QML или аналогах для отрисовки интерфейса;
  • UI-подсистема отвечает за нативный пользовательский интерфейс приложения, что актуально для React Native и Xamarin.
Читать еще:  Как решить проблемы с сетью в Windows: главные утилиты консол?

Кросс-платформенные приложения имеют нативную часть и такой же полный доступ к системным API, что и «нативные» приложения. Разница в том, что вызов системного метода идет через мост и инфраструктуру фреймворка:

WebView — приложение живет в своем веб-браузере по аналогии с одностраничным веб-сайтом. Нет доступа к нативным контролам (кнопки, списки и прочее), все основано на HTML/CSS/JavaScript. С другой стороны, веб-разработчик почувствует себя как рыба в воде.

JavaScript-движки стали популярны относительно недавно, так как в iOS подобный механизм был добавлен только в версии 7.0. Из особенностей стоит учитывать необходимость сериализации в JSON сложных структур данных, передаваемых между средами JavaScript и Native. Если коротко описать подобный класс решений, то в JavaScript-среде выполняется JS-код, управляющий нативным приложением.

OpenGL ES и DirectX являются подсистемами низкого уровня и используются для отрисовки пользовательского интерфейса в играх и, например, Qt/QML. То есть при использовании OpenGL/DirectX разработчики сами рисуют контролы и анимации, которые могут быть лишь похожи на нативные. С другой стороны, это подсистема низкого уровня с очень высокой производительностью, поэтому она используется и в кросс-платформенных игровых движках.

Все кросс-платформенные приложения имеют нативную часть, а следовательно, потенциально такой же полный доступ к системным API, что и «нативные». Также кросс-платформенные приложения собираются и упаковываются «нативными» инструментами в «нативные» установочные пакеты. Ключевой вопрос — как организовано взаимодействие между кросс-платформенной частью и нативной. Например, внутри WebView или с помощью Open GL ES / DirectX нет возможности создать пользовательский интерфейс с полностью нативным look’n’feel, но при этом есть полный доступ к GPS, Push-уведомлениям и другой функциональности. А код на JavaScript или C# вполне свободно может управлять нативным приложением и его поведением, обеспечивая полностью нативный look’n’feel.

Если резюмировать — то да, «ненативно» с точки зрения используемых инструментов разработки (не от Apple, Google). Но приложение может быть полностью нативным с точки зрения доступа к системным API и обеспечивать полностью нативный внешний вид и поведение. А мы движемся к следующему мифу.

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

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

Мы уже писали и не устанем повторять: перед тем как инвестировать в разработку мобильного продукта, будьте на 100% уверены, что он вам необходим и органично вписывается в бизнес-процессы.

Вот вы провели исследование, все посчитали, распланировали и знаете наверняка, что мобильные устройства — один из ключевых каналов для вашего бренда. Через него вы гарантированно улучшите качество сервиса для текущих пользователей, и привлечете новых клиентов, которых до этого по той или иной причине отпугивало отсутствие доступа к продукту/услуге с мобильного устройства.

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

  • Нативное приложение разрабатывается с нуля специально под конкретную платформу. От выбора платформы (iOS, Android) зависит набор иснтрументов и язык, на котором приложение будет написано (Objective C для iOS, Java для Andriod).
  • Гибрид предполагает наличие уже готового html шаблона, к которому добавляется интерфейс, позволяющий открывать его как мобильное приложение.
  • Кроссплатформенная разработка стремится сделать большую часть кода приложения не зависящей от дальнейшего выбора платформы.

Native (англ. «родной») — в переносном смысле естественный для данной среды. Например, политкорректное обращение к индейцам: Native Americans.

Не слушайте знакомых, которые «кажется когда-то что-то делали для смартфонов», не верьте разработчикам — они, как любой нормальный человек, предвзяты. Лучше сядьте со своей командой маркетинга и бизнес стратегирования, определите сроки, посчитайте бюджет и сами примите решение, а потом уже ищите нужного подрядчика — спеца по выбранному типу «мобильности».

Слона лучше есть по частям, и сложные решения становятся значительно проще, если их разбить предварительно на несколько вопросов:

Насколько важны интерактивные элементы интерфейса?

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

На каких платформах/типах устройств должно работать?

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

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

Насколько критичны затраты на публикацию и продвижение через магазин приложений?

Если для Google Play правила не так строги, то быстро пройти модерацию в App Store почти искусство. Тут и заранее нужно знать, каким нормам должно соответствовать приложение, как оно работает с личными данными (влияет даже то, насколько очевиден и легкодоступен для пользователя значок лицензионного соглашения; политика Apple строга — человек должен точно знать, как будет использована его личная информация). Как следствие, процедура согласования может затягиваться и даже потребовать изменений в интерфейсе уже готового приложения. Решений несколько: идти в агентство, которое уже умеет общаться с модераторами маркетов, или, если нет острой необходимости и желания работать с такими сложностями, отказаться от идеи публикации приложения в магазине (а значит автоматически выбрать мобильную веб-версию сервиса).

Читать еще:  Почему не работает камера в Скайпе (9 основных причин)

Будем продавать контент через приложение?

Здесь мы снова возвращаемся к тому, что все ключевые решения по архитектуре и виду вашего приложения закладываются уже на этапе разработки бизнес-модели и схемы монетизации. У Apple достаточно жесткие ограничения относительно того, что может продаваться внутри приложения; так называемые real good (продукты питания, мебель) под запретом. Реализовать функцию корзины и оплаты покупки можно в практически любом приложении, но с позиции технологий будут существенные различия: для гибридных и кроссплатформенных приложений придётся использовать сторонние инструменты + адаптировать их под свои задачи, что не гарантирует надежности и безопасности транзакций. Нативные приложения могут использовать сертифицированные инструменты для соответствующей платформы (опять же важно помнить про ограничения на тип продаваемых товаров и внимательно изучить требования платформы).

Необходим ли доступ к доп.функциям и датчикам устройства?

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

Нужен ли оффлайн режим?

Сложно сходу придумать в качестве исключения гибридное приложение, которое сумело бы адекватно работать в офф-лайне (то есть адекватно выполнять нужные пользователю функции, а не мигать табличкой «пожалуйста, подключитесь к интернету»). Для комфортной работы без доступа к интернету подходят только нативные решения.

Планируется ли выпуск новых версий?

В гибридной и кроссплатформенной разработке рано или поздно для расширения функционала потребуется использовать сторонние решения. Это может быть чревато тем, что при выходе новой версии или важного апдейта операционной системы (iOS, Andriod) ваше приложение перестанет адекватно функционировать и нужно будет либо ждать, пока сторонние разработчики самостоятельно выпустят соответствующее обновление, либо переделывать самостоятельно, и в том и другом случае стабильность и качество под угрозой.

Например, подобные проблемы часто возникают, если приложение работает с данными (в особенности, если хранить их приходится прямо на устройстве пользователя, а не в облаке), или при важных обновлениях систем безопасности. Плюс нативой разработки в том, что можно во-первых, заранее запланировать обновления на несколько версий вперед и добавлять новые/убирать не нужные функции в каждой новой версии, не переделывая с нуля всю систему; во-вторых, быстро выпустить новую версию с учетом изменений в платформе (если речь не идет о масштабной смене парадигмы, как было, например, с переходом от iOS6 к iOS7, радикально отличавшейся от предыдущей версии).

Какой бюджет?

Последний, но крайне важный для любого бизнеса вопрос. Как правило натив стоит дороже. Да, исключения бывают, если сроки поджимают и нужен минимальный функционал. Однако если кто-то обещает «полноценное приложение гораздо дешевле», приготовьтесь к тому, что придется платить трижды. Второй раз — уже другому агентству, а третий — маркетинговый бюджет, чтобы вернуть разочаровавшихся в сервисе клиентов.

Александр Чернышев,
директор производства Improve Digital:

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

Инвестиции в нативное приложение 100% оправданы в случае:

  • Если нужно выпустить приложение только под одну платформу.
  • Если необходимо внедрить функционал специфичный для платформы, например, in app. Может начаться пляска с костылями, которая потратить огромное кол-во времени и сил.
  • Если нужно постоянно обновлять приложение относительно платформы (новый iOS или Android — сразу новое приложение). Часто обновления движков запаздывают по отношению к обновлению платформ.
  • Если обновление платформы содержит что-то, что полностью несовместимо с движком.

Наше мнение субъективно и может не совпадать с мнением других игроков на рынке, и это нормально — во-первых, каждой задаче свои инструменты, во-вторых, лучше работать с тем, что больше всего нравится тебе и в чем ты гарантированно разбираешься лучше других. You have been warned

Ответы на эти вопросы помогут сформировать видение и понимание того, каким должно быть ваше мобильное решение, что в разы упростит поиск и дальнейшую коммуникацию с подрядчиком — вы уже точно будете знать, кого искать и что он должен будет сделать.

Читать еще:  Программы для веб ос. Операционная система в браузере: пять лучших WebOS. Проблемы и вопросы по LG Smart TV

Резюме

Best design is transparent. Следуя этой логике, конечному пользователю глубоко безразлично, что внутри у приложения, если оно решает его задачу быстро и без проблем. Выбор подхода зависит от того, как вы хотите организовать процесс «за кулисами», в конце концов вам и вашим разработчикам жить с этим. Лично нам ближе всего нативная разработка. В ней мы видим больше всего плюсов: нет проблем с совместимостью, простота и легкость поддержки и обновления, наконец, минимум сторонних решений, а значит и причин для конфликтов, сбоев и непредвиденных проблем.

Светлое завтра.

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

Понравилась статья? Поделитесь с коллегами и друзьями:

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

Быстрая и дешёвая разработка кроссплатформенных приложений — миф или реальность

Кроссплатформенная разработка мобильных приложений обходится дешевле, что объясняется меньшими объёмами работ относительно нативной разработки. Но и здесь есть свои подводные камни, разглядеть которые можно, только поняв принципы ценообразования.

Всегда нужно помнить, что время и стоимость регулируется сложностью и уровнем качества выполнения задачи. Допустим, что для разработки кроссплатформенного продукта у нас есть один специалист, который знает HTML, CSS, JavaScript и имеет опыт работы в PhoneGap. Один специалист — это одна абстрактная единица ресурса (допустим, один ).

Для работы над нативным приложением таких ресурсов требуется два — iOS и Android. В итоге, для завершения нативного проекта требуется два , для завершения кроссплатформенного — полтора.

Справедливым будет вопрос: «Как так — полтора? Почему не один?» Увы, на практике кроссплатформенное приложение, хорошо работающее на iOS, будет плохо работать на Android — у всех браузерных движков своя специфика, и как следствие, оптимизацию под Android может уйти ещё половина .

Исходя из вышесказанного, был произведен расчёт стоимости мобильной разработки в случае нативного и кроссплатформенного подходов, представленный в двух таблицах. Результаты в таблице 1 отталкиваются от средней почасовой ставки фрилансеров из баз freelansim.ru и fl.ru в рублях, в таблице 2 — средней почасовой ставки фрилансеров и студий из международной базы upwork.com в долларах.

Польза для бизнеса

В бизнесе решающую роль зачастую играет метрика TTM (time-to-market). Быть впереди и внедрять новые функции в свой продукт быстрее конкурентов сразу на обеих платформах – об этом с самого начала задумывается любая компания-лидер. Кроссплатформенные фреймворки позволяют это достигать и, как очевидный бонус, получать снижение затрат на разработку на каждом этапе. По нашим подсчетам – разработка на Flutter позволяет снижать общую стоимость разработки продукта на 25-30%.

Миф 1. Магия

Самый частый миф, будоражащий умы начинающих девелоперов, связан с верой в сверхалгоритмы (и сверхпрограммистов, их создавших), которые волшебным образом превращают кросс-платформенные приложения в нативные. Что-то в духе «преобразования кода JavaScript в Swift и дальнейшая компиляция уже Swift-приложения». Этот миф подогревают и сами разработчики кросс-платформенных инструментов, обещая на выходе создание «нативных приложений». И не то чтобы кто-то здесь лукавил, но богатая фантазия и непонимание базовых механизмов иногда наводят разработчиков на мысли о шаманских приемах.

Главный принцип, лежащий в основе кросс-платформенных решений, — разделение кода на две части:

  • кросс-платформенную, живущую в виртуальном окружении и имеющую ограниченный доступ к возможностям целевой платформы через специальный мост;
  • нативную, которая обеспечивает инициализацию приложения, управление жизненным циклом ключевых объектов и имеет полный доступ к системным API.

Для того чтобы связывать между собой мир «нативный» и мир «кросс-платформенный», необходимо использовать специальный мост (bridge), именно он и определяет возможности и ограничения кросс-платформенных фреймворков.

При использовании bridge производительность всегда снижается за счет преобразования данных между «мирами», а также конвертации вызовов API и библиотек.

Итак, все кросс-платформенные приложения обязаны иметь нативную часть, иначе операционная система просто не сможет их запустить. Поэтому давай рассмотрим подробнее, какие системные API и механизмы предоставляются самими iOS, Android и Windows. Переходим к следующему мифу.

Вячеслав Черников — руководитель отдела разработки компании Binwell. В прошлом — один из Nokia Champion и Qt Certified Specialist, в настоящее время — специалист по платформам Xamarin и Azure. В сферу mobile пришел в 2005 году, с 2008 года занимается разработкой мобильных приложений: начинал с Symbian, Maemo, Meego, Windows Mobile, потом перешел на iOS, Android и Windows Phone.

Статьи Вячеслава вы также можете прочитать в блоге на Medium.

Напоминаем, что это полная версия статьи из журнала Хакер.

Ссылка на основную публикацию
Статьи c упоминанием слов:

Adblock
detector