Нативные функции. Гибридная и нативная разработки: сравним? Быстрая и дешёвая кроссплатформенная разработка - миф или реальность

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

Первый вопрос, который возникнет у вас - по какой технологии разработки создавать приложение?

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

Нативный подход

Приложение разрабатывается на “родном” языке для каждой платформы: Java для Android и Objective-C / C++ для IOS.

Изначально по такому методу разработаны приложения, которые “вшиты” в устройство - будильник, браузер, галерея, музыкальный проигрыватель.

Кросс-платформенный подход

Если в нативном подходе одно и то же приложение разрабатывается отдельно и под iOS и под Android, то в кросс-платформенном подходе разрабатывается все за один раз.

Приложение сможет работать на всех платформах.

Языки программирование стандартные, как если бы вы разрабатывали сайт - HTML и CSS.

Гибридный подход

Гибридные приложения объединяют особенности нативной и кросс-платформенной разработки.

По сути, это кросс-платформенное приложение внутри “родной” оболочки.

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

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

Нативная разработка

1 Производительность и скорость

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

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

2 Пользовательский опыт

Если клиент привык к интерфейсу Android, то он будет некомфортно чувствовать себя при использовании ОС IOS. Проектирование нативного приложения даст уверенность пользователям и интуитивное понимание внешнего вида и функционала.

3 Нет ограничений

Приложение имеет полный доступ к службам и функциям смартфона (базы данных, геолокация, камера).

4 Удобство тестирования

Легко контролируется производительность приложений. Если приложение потребляет больше памяти, чем ожидалось, или больше ресурсов процессора - в процессе тестирования это сразу видно.

5 Доступность

Пользователи смогут загрузить приложение из “родных” магазинов: App Store, Google Play

6 Адаптивность

На рынке большое количество Android-устройств и приспособить дизайн макетов для всех из них эффективнее через нативную разработку.

Недостатки

1 Скорость разработки

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

2 Издержки на разработку

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

3 Обслуживание и поддержка

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

1 Скорость разработки и снижение затрат

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

2 Обслуживание и поддержка

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

Недостатки

1 Скорость разработки и снижение затра

Несмотря на то, что по идеологии разработки этот пункт отмечается как плюс, практика показывает, что имплементация под две ОС дает много багов. Это увеличивает срок на устранение ошибок. UI отображается по-разному и время на адаптацию также увеличивается.

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

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

3 Пользовательский опыт

Необходимо разработать такой интерфейс, который был бы интуитивно понятным и для пользователей iOS и для Android.

В противном случае приложение, построенное согласно Руководству ОС IOS Human Interface будет неудобным Android пользователям. И в конечном итоге вы потратите больше времени, на усовершенствование пользовательского опыта.

4 Обращение к “нейтиву”

Стандартные решения для нейтива все равно не решаются в кроссплатформенной разработке. Поэтому часто для решения функционала привлекают нативных разработчиков.

Когда кросс-платформенность выигрывает:

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

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

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

Под нативной (родной) разработкой подразумевается использование оригинальных языков и инструментов разработки мобильной операционной системы. Приложения для iOS создаются в среде разработки XCode на языках Objective-C, Swift, C и С++. Для создания приложений под Android используется среда Android Studio и язык Java. Каждая среда разработки содержит целый комплекс утилит для написания кода, проектирования интерфейса, отладки, профилирования (мониторинга) и сборки приложений. И среда, и соответствующий набор утилит созданы специально под каждую мобильную операционную систему и являются максимально удобными и мощными средствами разработки мобильных приложений.

Кроссплатформенная разработка подразумевает использование специальных утилит (фреймворков) для создания приложения на основе семейства языков JavaScript. Вся структура и логика приложения создается с помощью таких инструментов (PhoneGap, Titanium, Xamarin, Cordova и др.) на JavaScript, а затем оборачивается в нативный запускающий элемент, т.е. интегрируется в базовый проект для XCode или Android Studio. Что позволяет создавать сборки проекта с одной и той же логикой под несколько операционных систем сразу.

Ближайшая аналогия в случае с персональными компьютерами. MS Word, Skype, почтовые агенты, календари – это нативно разработанные приложения под настольную операционную систему. Все, что происходит в браузере (сайты, онлайн-редакторы текста и графики, социальные сети, чаты, форумы) – кроссплатформенные технологии.

Плюсы кроссплатформенной разработки

Кроссплатформенный подход к разработке имеет следующие положительные моменты:

1. Требуется меньше ресурсов для реализации приложения сразу под несколько платформ. В этом, собственно, и суть кроссплатформенного подхода – один и тот же код работает и на iOS, и на Android. Программистов, занимающихся проектом, нужно ровно в два раза меньше. Дизайнер делает только один набор графики. Все это снижает количество рабочих часов и бюджет проекта.
   ⋅
2. Меньшее время на разработку. За счет отсутствия уникальных элементов интерфейса и более простых технологий, время на создание простых продуктов, как правило, меньше.
   ⋅
3. Упрощенный цикл обновления продукта. Если в проект нужно что-то добавить или исправить какую-то ошибку, это делается сразу для всех платформ, на которые распространяется проект.
   ⋅
4. Возможность использования мобильной версии сайта. Большинство кроссплатформенных решений используют семейство JavaScript языков. Поэтому если у вас уже есть мобильная версия сайта, значительная часть кода и материалов может быть использована в приложении без изменений.
   ⋅
5. Использование единой логики приложения. Логика, заложенная в работу приложения, будет работать гарантированно одинаково для всех платформ. Довольно часто это может являться и минусом из-за разной архитектуры операционных систем. Яркий пример – кнопка “Назад” в навигации между экранами. В Android предусмотрена аппаратная кнопка Back для этих целей. У iOS – движение пальцем от левой части экрана или же наличие кнопки в левой части навигационной панели. Если кнопку не делать вовсе, пользователи iOS не смогут вернуться назад. Если сделать, но не на том месте и выглядящую нестандартно, пользователям iOS будет непривычно и неудобно; а если сделать как в iOS, будет непривычно пользователям Android. Однако написанная и отлаженная один раз логика содержит потенциально меньшее количество ошибок и расхождений в своей работе. Поэтому вам не придется проделывать двойную и тройную работу по поиску проблем на каждой платформе.

Плюсы нативной разработки

Разработка на родных технологиях и языках под iOS и Android имеет следующие положительные моменты:

1. Скорость работы приложения.

Так как приложение создается с использованием оригинальных инструментов разработки (XCode, Android Studio), получаемый в результате компиляции проекта код является оптимальным для данной платформы. Приложение получает полную аппаратную поддержку устройства (обработка тех же изображений осуществляется отдельным процессором, специально для этого предназначенным – GPU), используется многопоточность для реализации сложных задач и загрузки контента в фоне. В процессе разработки программисты могут измерять скорость работы всех участков кода и при необходимости их оптимизировать. В их распоряжении также есть инструменты по мониторингу использования оперативной памяти, поиску возможных утечек и т.д.

2. Гибкость в реализации.

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

3. Использование последних технологий и зависимость от кроссплатформенных фреймворков.

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

⋅ 4. Легкость и качество тестирования.

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

5. Полная поддержка со стороны магазинов приложений App Store и Google Play.

Обе компании заинтересованы, чтобы пользователи получали максимально положительный опыт при использовании приложений на соответствующих платформах, который возможен на текущий момент. Это означает, что приложение должно выглядеть максимально качественно (если у экрана высокое разрешение, а изображения расплывчаты, в App Store приложение просто не пропустят), работать настолько быстро, насколько это возможно (если приложение отображает небольшой список элементов за 20-30 секунд, его так же не пропустят), и вообще все должно быть красиво и удобно. Если какие-то из этих параметров слишком низки или вообще не выполнены, приложение не пропустят в магазин. Если же они не на высоте, чего добиться с кроссплатформенными технологиями крайне сложно, а часто и невозможно в принципе, ваше приложение никогда не будет рассмотрено соответствующими компаниями для размещения в специальных рекламных разделах (Featured). Среди приложений, находящихся во Featured-разделах и App Store, и Google Play, нет ни одного, сделанного с помощью кроссплатформенных технологий. За исключением игровых проектов, в которых интерфейс не является системным.

Выводы

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

Современные игры пишутся в подавляющем большинстве на кроссплатформенных технологиях. Это сильно ускоряет разработку без ущерба для качества, т.к. в этом случае используются специальные графические фреймворки (самый популярный – Unity 3D). Если какой-то проект нужно сделать быстро для проведения каких-либо тестов, при этом ситуация требует работы проекта именно на нескольких платформах одновременно, кроссплатформенная реализация может быть оптимальным решением.

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

Смартфоны продолжают отвоевывать все больше места под солнцем не только как инструмент потребления фотографий котиков и ххх-роликов, но и в качестве рабочего инструмента. Поэтому и спрос на мобильную разработку растет. Принято считать, что тру и кул - это Objective-C/Swift для iOS и Java/Kotlin для Android. Спору нет, тру и кул, но существует большое количество реальных сценариев, в которых использование кросс-платформенных фреймворков более предпочтительно в сравнении с нативными инструментами.

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

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

Зачем нужны кросс-платформенные инструменты?

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

Нативные инструменты = предоставляются владельцем экосистемы.

Все остальные признаки «нативности» ВТОРИЧНЫ - поведение и интерфейс приложений, доступ к возможностям ОС, производительность и прочее.

К тому же практически всегда оказывалось, что нативные инструменты несовместимы друг с другом не только на уровне языков разработки, принятых соглашений и архитектур, но и на уровне механизмов работы с операционной системой и библиотеками. В результате для реализации одних и тех же алгоритмов и интерфейсов требовалось написать приложение для нескольких сред на разных языках программирования, а потом его поддерживать из расчета «одна команда на платформу». При этом возможности и внешний вид приложений на разных платформах практически всегда идентичны на 90%. Сравни ради интереса реализацию любимых программ для iOS и Android.

Второй важный момент - наличие необходимых знаний и опыта внутри команды: если их нет, то потребуется время на обучение.

Для того чтобы решить обе эти проблемы, на рынке уже давно появились инструменты кросс-платформенной разработки (не только mobile), предлагающие:

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

Так как языков программирования (и сред) сейчас наплодилось очень много (и специалистов, владеющих этими языками), то и инструментов для кросс-платформенной разработки существует изрядное количество. Мы в качестве примера остановимся на популярных в наших краях PhoneGap, Xamarin, React Native и Qt .

Теперь можно поговорить и о мифах.

Миф 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.

Кросс-платформенные приложения имеют нативную часть и такой же полный доступ к системным 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 и обеспечивать полностью нативный внешний вид и поведение. А мы движемся к следующему мифу.

Миф 3. Костыль на костыле

Здесь стоит понимать, что нативные API по умолчанию костылями не считаются (хотя и здесь есть разные мнения), поэтому все негодование направлено на кросс-платформенную часть. Очевидно, что исполняющую среду (например, WebView, JavaScript-движок или Mono) костылем тоже назвать сложно - взрослые зрелые решения с длительной историей.

Похоже, что костылем называют то, как кросс-платформенная часть интегрируется с нативной. Чтобы лучше понять, как работают различные фреймворки, мы на примере PhoneGap, Xamarin, Qt и React Native рассмотрим те механизмы операционных систем, которые используются для связывания кросс-платформенной и «нативной» частей.

Начнем мы с PhoneGap. Ниже представлена верхнеуровневая архитектура приложения на базе этого фреймворка.

Приложение на PhoneGap - это по факту нативное приложение, которое в качестве единственного UI-контрола отображает WebView. Именно через него и идет взаимодействие с нативной частью. Все стандартные WebView в iOS, Android и Windows UWP поддерживают возможность добавить свои нативные обработчики для JS-свойств и методов. При этом JS-код живет в своей изолированной среде и ничего не знает о нативной части - просто дергает нужные JS-методы или меняет нужные JS-свойства. Все внутри стандартного вебовского DOM, в который просто добавляются новые элементы, связанные с нативной реализацией.

При создании приложений на React Native разработчику практически всегда будет необходимо реализовывать нативную часть на Objective-C, Java или C#, а само управление нативным приложением будет идти из JavaScript. По факту JavaScript-движок - это элемент WebView, который доступен отдельно. Взаимодействие идет через такой же JS-мост, как и в случае с PhoneGap. Однако в React Native JS-код управляет не вебовским DOM-деревом, а нативным приложением.

Необходимо учитывать, что из-за ограничений iOS (нет возможности реализовать JIT) код JavaScript на лету интерпретируется, а не компилируется. В целом это не особо сказывается на производительности в реальных приложениях, но помнить об этом стоит.

Теперь рассмотрим классический Xamarin.iOS и Xamarin.Android, так как Xamarin.Forms (поддерживающий Windows UWP) - это надстройка над ними.

Xamarin использует библиотеку Mono для взаимодействия с целевой операционной системой, которая позволяет вызывать нативный код с помощью механизма P/Invoke . Он же задействуется и для общения с нативными API в iOS/Android. То есть для всех публичных нативных API-методов создаются обертки на C#, которые, в свою очередь, вызывают системные API. Таким образом, из Xamarin-приложения можно обращаться ко всем системным API.

И в завершение рассмотрим Qt, так как о нем появляется много вопросов от опытных разработчиков.

Qt - «вещь в себе», в этом есть и плюсы, и ограничения. Библиотеки Qt просто подключаются к системным API на C++, которые есть во всех операционных системах. Для отрисовки пользовательского интерфейса используются механизмы низкого уровня, но свой графический движок, поддерживающий стилизации «под нативку». При этом на Android приходится обращаться к Java API через специальный мост (JNI bridge), а для Windows UWP использовать конвертер вызовов Open GL ES в DirectX, так как Open GL недоступен для UWP.

Подведем итог: все кросс-платформенные фреймворки используют стандартные нативные возможности операционных систем, являются зрелыми, создаются опытными командами и сообществом open source при поддержке гигантов IT-индустрии. И наконец, пришло время для самого «сильного» аргумента.

Миф 4. Медленно

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

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

• PhoneGap: HTML/JS и Native Java / Objective-C / C#;
• React Native: JS и Native Java / Objective-C / C#;
• Xamarin: Mono и Native Java / Objective-C;
• Qt: С++ и Native Java / Objective-C.

Таким образом, при сравнении производительности надо учитывать скорость работы:

• кросс-платформенной части;
• нативной части;
• моста.

Если набрать в поисковике, например, react native vs swift performance, то можно посмотреть множество различных тестов, и во многих из них отмечается, что производительность резко падает при активном использовании моста, включая активное манипулирование UI из кросс-платформенного кода. Для Xamarin ситуация выглядит таким же образом - кросс-платформенная часть очень быстра и сопоставима с нативной в обработке данных, однако при использовании моста может падать производительность. Qt вообще работает на уровне С++, который быстр сам по себе. Если же рассматривать решения на базе PhoneGap, то здесь производительность будет сильно зависеть от WebView, но все же не следует активно менять UI в JavaScript-коде или проводить научные вычисления.

Медленно? Да, возможны падения производительности при неумелом взаимодействии с операционной системой через мост. Однако сами по себе кросс-платформенные миры такие же быстрые, как и нативные.

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

Вы знаете что такое нативное приложение?

Для пользователя нативными являются приложения, которые требуют установки. В целом, это верно, как и то, что такие приложения разрабатываются специально под мобильные платформы (iOS, Android, Windows Phone). Поэтому от разработчика требуются навыки программирования в конкретной среде разработки (xCode для iOS, eclipse для Android).

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

Веб-приложения отличаются от нативного приложения

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

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

Так что проще веб-приложениями называть все, что принято называть онлайн-сервисами. Веб-приложением может называться еще и то, что когда-то делалось на флэше, а теперь – на HTML5.

Гибридные приложения

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

Что выбрать? нативное приложение, гибридное или веб?

Разработка гибридного приложения дешевле и быстрее, чем создать нативное приложение. А пользователи разницы все равно не заметят. Поэтому гибридные технологии наиболее популярны. Несмотря на всю эту многосложность определиться с выбором технологии для разработки приложения очень просто. Если ваше приложение никак не может работать без нативных функций мобильных устройств, если очень важна высокая скорость обработки данных (игры, соцсети, геолокация), то лучше чем нативное приложение ничего не найти. Когда скоростью работы можно пренебречь, подойдет гибридное приложение. Веб-приложение стоит делать, когда пользователю от вас не нужно ничего, кроме информации, которую он мог бы получить с телефона при наличии интернета.

Следующее высказывание с легкостью может прозвучать от того, кто только что начал изучать Titanium:

JavaScript?! Как Phonegap? Не, я лучше сделаю нативное приложение.

Разумеется, у меня были подобные беседы с клиентами, когда я был фриланс-разработчиком на Titanium. И уж конечно, как Developer Advocate, я частенько слышу это когда начинаю объяснять Titanium разработчикам, которые ищут кросс-платформенное решение для создания приложений.

Titanium !== HTML

Каждый раз при сравнении с Phonegap (Cordova), Ionic и чем-либо еще, я начинаю мотать головой, махать руками и громко кричать о том, что в Titanium нет HTML.

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

Но при общении с клиентами или людьми, не очень подкованными в техническом плане, для которых JavaScript вызывает ассоциации с этими технологиями, представление HTML как просто еще одного технического термина не всегда помогает. Кроме того, определение Titanium как чего-то, чем он не является, не совсем правильно.

Что ты имеешь в виду под «Нативной» разработкой?

В ответ я стал спрашивать:

А что делает приложение нативным?

Может быть, то что…

• Разработчик использует предоставленные Apple, Google и Microsoft инструменты?
• Разработчик использует стандартный для платформы язык?
• Приложение использует строительные блоки (API), которые предоставляет платформа?
• Приложение работает так, как ожидает пользователь на этой платформе?

После короткого разговора о том, чего, по их мнению, JavaScript предложить не может, чаша весов всегда склонялась к четвертому пункту. Это подтверждает опрос в Твиттере , который я недавно провел.

Что такое хороший User Experience?

Итак, что же значит соответствующий платформе UI и UX? Ну, в первую очередь то, что мы не печемся о технологии, только о том, что она нам дает; Как приложение выглядит и чувствуется пользователем. Во вторую то, что поведение приложения зависит от платформы.

Выглядит и ведет себя ожидаемо

iOS, Android и Windows имеют различные требования к дизайну (iOS , Android ,Windows) и если вы опираетесь на них, ваше приложение более предсказуемо и следовательно, проще в использовании.
Отличный пример – TabGroups. На Андроиде они, как правило, встроены в Action Bar и будут прокручиваться если их много. На iOS Tab Bar расположен внизу и если у вас больше пяти табов, то пятый будет вести на экран выбора нужного таба. На Windows Pivot Tabs работают почти как на Андроиде, но выглядят немного по-другому, они не являются частью Command Bar, который расположен внизу экрана.


Так что технология, которая используется для разработки нативного приложения, не должна иметь собственные UI контролы, вместо этого она должна использовать те, которые предоставлены платформой.
В Titanium есть кросс-платформенные API почти для всего, и он всегда переводит их в платформенные UI-компоненты. Например, Ti.UI.TabGroup даст вам результат как на картинке выше, но напишете вы при этом один код (Alloy):
Tab A Tab B Tab C
Для тех API, которые представлены не во всех платформах, мы используем пространства имен, например, Ti.UI.Android.CardView .

Единство API там, где это возможно, платформо-зависимые API – там, где нет. Всегда с уважением к целевой платформе.

Чувствуется ожидаемо

Но есть еще один, менее заметный фактор, который влияет на UX. Взаимодействие с приложением должно вызывать правильные чувства. Здесь мы имеем в виду, что время реакции и визуальный отклик такие, какие вы ждете от платформы.
Исторически этот момент всегда был большой проблемой для кросс-платформенной разработки. Все решения так или иначе имеют некий уровень абстракции над платформенными API. Это потенциальное узкое место. В Titanium мы посвятили массу времени оптимизации. Возьмите например, ListView , он может быть на 60% более отзывчивым, чем его предок, TableView .
В приложениях, которые используют HTML, это продолжает быть проблемой. Плоский интерфейс сделал все для того, чтобы такие приложения выглядели хорошо, но не нужно быть семи пядей во лбу, чтобы заметить разницу в том, как UI реагирует на взаимодействия. Часто он просто «не такой», и вот в чем задача UX: сделать его «таким».

Как достичь классного UX?

Кроме всего прочего, вам нужно классный разработчик. Плохие приложения можно и в XCode со Swift сделать, так что без сомнения, вы можете сделать его и с помощью любой (кросс-платформенной) технологии. Используйте нужные платформо-зависимые UI компоненты в нужных местах, избегайте утечек памяти, пишите чисто и с умом.
Плюс ко всему, используйте имеющиеся в вашем распоряжении строительные блоки, не имитируйте их. Помните, Titanium !== HTML и наши 4 пункта списка. Мы с уверенностью полагаем, что для нативного UX нужно использовать нативные UI и системные API. Для достижения пункта №4 нужно выполнить пункт №3.
Вот поэтому Facebook отказался от HTML приложений и создал React Native.
И да, у нас в Titanium это было с 2009.
Code Strong, Code Native… In JavaScript!