- PVSM.RU - https://www.pvsm.ru -

HTML5 в мобильной разработке — что выбрать?

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

Устоявшиеся мнения о преимуществах кросс-платформенной разработки с использованием HTML5 или Native SDK:

HTML5

  • Лёгкое вхождение для веб-разработчиков
  • Дешево в разработке
  • Большое покрытие (браузер сейчас есть везде)
  • Единая база кода

При помощи таких средств как, например, Cordova, на HTML5 можно создавать гибридные приложения (которые размещены не в интернете, а в нативном контейнере). Такие приложения совмещают перечисленные выше плюсы и посредством плагинов позволяют выйти за пределы браузера, осуществляя тесную интеграцию с возможностями устройств. Гибридные приложения можно публиковать и распространять через AppStore, Google Play и другие магазины приложений.

Native

  • Нативные ощущения и внешний вид
  • Интеграция с аппаратной частью без ограничений
  • Интеграция с софт частью (например, вызвать твиттер или Facebook из приложения)
  • Нет привязки к браузеру
  • Полноценные IDE для разработки и отладки приложений

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

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

HTML5 в мобильной разработке — что выбрать?

В 1995 году в нашем распоряжении был Mac OS, Windows 95 и Linux. Для каждой из операционных систем было свое программное обеспечение, но мысли о кросс-платформенности уже появлялись.

В 1996 году Sun Microsystems выпустила продукт под названием Java. Этот продукт имел высокий уровень абстракции для написания единого кода под разные ОС. Это была уже, действительно, кросс-платформенность в том виде, в котором мы привыкли её видеть. Но UI был одинаковый для каждой из систем.

Далее был этап развития, в течение которого возникали сущности, реализующие определённые уровни кросс-платформенной абстракции такие как WebKit, OpenGL, git и т.д. Это были стандарты, которые следовало использовать при написании приложений. UI мог отличаться в каждой системе, но тот же OpenGL был одинаков.

Параллельно активно развивалось и веб-направление. Вначале это были статические страницы, связанные ссылками. Но достаточно скоро в них стало появляться все больше динамики. Внедрение технологии AJAX и почтового клиента GMail (как первого полноценного и достаточно сложного веб приложения) заставило говорить о Web 2.0.

Единственное, что могло приостановить это нашествие — Flash и Silverlight. Которые так же, как и новорождённый HTML5, решали одну проблему — написание полноценного “толстого” клиента в браузере.

В результате, HTML5 обрёл свою нишу. Этому способствовал ряд факторов:

  • открытая платформа
  • не все веб-разработчики хотели учить другие языки разметки и языки программирования (Flex+ActionScript у Adobe и XAML+C# у Microsoft);
  • Flash и Silverlight не предоставляли качественного кросс-платформенного решения. В Linux возникали постоянные проблемы с поддержкой Flash, а реализация Silverlight от Mono отставала. Отказ от поддержки Flash на мобильных платформах (iOS, и позднее Android) породили высказывания “Flash умер”.

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

Так, примерно с 2005 года браузеры стали ещё одним уровнем кросс-платформенности. Такие приложения как Google Maps, GMail и Facebook стали использоваться всё активнее. Оказалось, что очень удобно работать в браузере на любой операционной системе и нет необходимости устанавливать дополнительное десктопное ПО.

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

  • Для каждой из OС отдельное приложение, написанное по своим правилам.
  • Единый код, единый UI, рантайм прослойка (как, например, Java или Silverlight).
  • Общие спецификации, UI нативный для каждой из систем (например, OpenGL).
  • Приложения в браузере.

Возникает вопрос, можно ли применить данную градацию для мобильной разработки?
Если писать нативно, то попадаем в первый пункт когда для каждой мобильной ОС полностью свой код и свой UI. Любое приложение нужно будет переписать под каждую платформу.

Естественно, что в такой ситуации возникли решения для оптимизации разработки под различные платформы, при единой базе кода. Такими решениями на данный момент являются:

  • HTML5-фреймворки
  • Платформы с собственным рантаймом: например, AS3 Adobe AIR, .NET Xamarin
  • Трансляторы и кросс-компиляторы, например Appcelerator Titanium

Эти решения покрывают 2-4 пункт градации десктопных приложений под различные платформы. Рассмотрим каждое подробней.

AS3 Adobe AIR

AIR наиболее похож на Java и предоставляет свой рантайм для десктопа и мобильных приложений. Конечно, можно отслеживать, на каком устройстве мы запустили, и принудительно выставлять соответствующий UI. Но, в большинстве случаев, приложения имеют единый UI. Типичное AIR приложение — это игра, например, Angry Birds. Есть и бизнес приложения, например Photoshop Touch.

.NET Xamarin

.NET Xamarin приближен к нативной разработке, (например, мы можем использовать дизайнер интерфейсов Xcode), но при этом разработка может вестись в Mono Develop и Visual Studio. Данное решение успешно демонстрирует кросс-платформенность C#. Производительность приложений не уступает уровню нативных. Но UI под каждую из платформ необходимо писать отдельно.

HTML5 фреймворки

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

Звучит отлично, но мир жесток, и чудес не бывает. Семь лет активной пропаганды и развития HTML5 дали свои плоды (хорошую инфографику можно посмотреть на Хабре [2]). Мы можем найти примеры качественных гибридных HTML5 приложений:

  • Приложение Touralot [3] от разработчика KnockoutJS для iOS, собранное при помощи PhoneGap и использующее Azure Mobile Services.
  • Быстрый Facebook [4] от Sencha
  • Приложение Fly Delta [5] с миллионом установок для клиентов Delta Airlines
  • Приложение tradeMonster [6], ставшее поводом для обсуждения на techcrunch [7]

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

  1. Производительность UI
    • Манипуляции с UI работают в один поток (хотя для логики приложения можно использовать Web Workers).
    • Большое потребление памяти, т.к. кроме кода приложения необходимо запускать WebView.
    • Скорость исполнения JavaScript невысока.
    • Работа с DOM потребляет много ресурсов.
  2. Нет унификации платформ
    • Доминирует WebKit, но существует Windows Phone, в котором необходимо поддерживать IE. Другие игроки, такие как Mozilla, тоже пытаются выйти на рынок [8].
    • Каждая платформа предоставляет свои размеры экранов для телефонов и планшетов.
    • Разные требования к UI на каждой из платформ. И, естественно, баги платформы, не зависящие от багов конкретного фреймворка.
  3. Чужеродность UI
    • Приложение — всего лишь HTML-страница.
    • Sencha Touch, jQuery Mobile не похожи на нативные приложения.
    • Имитации UI страдают эффектом “зловещей долины” [9], иногда этот эффект проявляется со временем и зависит от частоты использования приложения
  4. Отсутствие средств разработки и отладки “из коробки”
    • HTML5 позиционируется как средство, которое вы можете использовать в вашем окружении разработки. Но, на самом деле, отладка HTML5 приложения на устройстве не самый простой процесс. Нативные средства, AIR и Xamarin предлагают полноценные IDE для разработки и отладки.
  5. Ограниченный доступ к аппаратным возможностям
    • набор PhoneGap плагинов из коробки скудный, а разработка своего равноценна разработке с использованием Native SDK

Таким образом, мобильные HTML5 приложения имеют много рисков при разработке. Но и возможности покрытия устройств велики. PhoneGap предоставляет доступ к аппаратным возможностям устройств, предоставляя мостик между браузером и реальным устройством. В сети можно найти много статей по данному вопросу, хороший пример интересного и развёрнутого обзора — "почему мобильные веб приложение такие медленные? [10]".

Когда стоит использовать HTML5

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

Что на самом деле?

Вот результаты опроса, который я провел в рамках недавней статьи [11] (проголосовало 507 человек):
HTML5 в мобильной разработке — что выбрать?

  • Нативные средства под каждую из платформ 46%(287)
  • AS3 Adobe AIR 15%(96)
  • HTML5 фреймворки 30%(186)
  • .NET Xamarin 9%(56)

(как вы заметили, ChartJS [12] отлично подходит не только для визуализации котиков [13])

Очевидно, ниша HTML5 разработки под мобильные платформы не пуста. Мы в DevExpress [14] решили реализовать вариант с HTML5, и о результатах уже был пост [15].

Мы выпустили фреймворк для разработки мобильных приложений PhoneJS [16]. На данном этапе развития технологий HTML5 имеет некоторые ограничения. Наше решение тоже не попадает в область чудес, но часть проблем мы преодолели, а часть готовимся решить. Мы работаем над устранением основной причины по которой разработчики скептически относятся к HTML5 приложениям — производительность UI.

Мы предлагаем реализацию хорошей идеи. Используй свои знания в HTML5 для создания мобильных приложений под все платформы, возьми PhoneJS, добавь PhoneGap, и всё заработает. Один раз под все устройства. Принимаем плюсы и минусы HTML5, и кроме этого решаем часть задач, которые HTML5 не решает по умолчанию.
HTML5 в мобильной разработке — что выбрать?
Так мы берём на себя заботу об UI, а пользователь пишет UI-independent логику, которая на 99% не зависит от браузера. Фактически пользователь пишет приложение, а фреймворк делает так, чтобы под каждой платформой оно смотрелось максимально нативно, в соответствии с требованиями платформы. Естественно, могут возникать некоторые проблемы в производительности, но если приложение решает ваши задачи и вы заплатили за его разработку и поддержку в 10 раз меньше чем за нативное, то такое решение выгодно.

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

Отличной иллюстрацией использования нашего фреймворка могло бы быть приложение для таксопарка или авиаперевозчика, решившего следовать тенденциям BYOD [17]. Приложение должно работать на большом спектре устройств и быть достаточно удобным как внутри компании, так и снаружи. При этом приложение будет клиентской частью общей системы которая уже существует в компании. Уже упомянутое приложение Fly Delta [18] — хорошая иллюстрация.

Это пример задачи, которую проще и дешевле решить при помощи PhoneJS [16]. Исходя из своего опыта, вы можете легко расширить сферу применимости, при этом сэкономить деньги и время.

В заключение необходимо добавить тот факт, что количество мобильных платформ растет. Появляются и закрепляют свои позиции новые платформы Firefox OS [19], Tizen от Samsung [20]. Гибридные приложения на HTML5 — хорошее средство для создания действительно мультиплатформенных приложений. Эти факты вселяют уверенность в то, что данное направление будет развиваться, особенно, в сфере бизнес приложений.

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

Автор: SeOd

Источник [21]


Сайт-источник PVSM.RU: https://www.pvsm.ru

Путь до страницы источника: https://www.pvsm.ru/javascript/38492

Ссылки в тексте:

[1] досадные недоработки: https://www.destroyallsoftware.com/talks/wat

[2] можно посмотреть на Хабре: http://habrahabr.ru/post/162387/

[3] Touralot: http://blog.stevensanderson.com/2013/03/13/touralot-an-ios-app-built-with-phonegap-knockout-and-azure-mobile-services/

[4] Быстрый Facebook: http://www.sencha.com/blog/the-making-of-fastbook-an-html5-love-story

[5] Fly Delta: https://play.google.com/store/apps/details?id=com.delta.mobile.android

[6] tradeMonster: https://play.google.com/store/apps/details?id=com.om.mobile

[7] techcrunch: http://techcrunch.com/2013/07/07/debunking-some-myths-about-native-and-html5-hybrid-apps/

[8] пытаются выйти на рынок: http://habrahabr.ru/post/185340/

[9] эффектом “зловещей долины”: http://ru.wikipedia.org/wiki/%D0%97%D0%BB%D0%BE%D0%B2%D0%B5%D1%89%D0%B0%D1%8F_%D0%B4%D0%BE%D0%BB%D0%B8%D0%BD%D0%B0

[10] почему мобильные веб приложение такие медленные?: http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/

[11] недавней статьи: http://habrahabr.ru/post/184232/

[12] ChartJS: http://chartjs.devexpress.com/

[13] визуализации котиков: http://habrahabr.ru/company/devexpress/blog/185210/

[14] Мы в DevExpress: http://www.dxrussia.ru/

[15] результатах уже был пост: http://habrahabr.ru/company/devexpress/blog/182134/

[16] PhoneJS: http://phonejs.devexpress.com/

[17] BYOD: http://en.wikipedia.org/wiki/Bring_your_own_device

[18] Fly Delta: https://play.google.com/store/apps/details?id=com.delta.mobile.android&hl=en

[19] Firefox OS: https://developer.mozilla.org/en/docs/Mozilla/Firefox_OS

[20] Tizen от Samsung: https://www.tizen.org/

[21] Источник: http://habrahabr.ru/post/186050/