Дискуссия о мобильных приложениях
Введение
Мобильные приложения и HTML5 — две самые популярные технологии на данный момент, и между ними много общего. Веб-приложения работают в мобильных браузерах, а также могут быть переупакованы как нативные приложения для различных мобильных платформ. Благодаря широкому спектру поддерживаемых платформ и огромным возможностям мобильных браузеров, разработчики обращаются к HTML5 как к решению типа «напиши один, запускай во многих». Но действительно ли это жизнеспособно? Есть веские причины для перехода к нативным приложениям, и очевидно, что многие разработчики действительно выбирают этот путь. Эта статья посвящена дискуссии о преимуществах нативных приложений перед веб-приложениями.
Богатство возможностей
Суть в том, что нативные технологии могут сделать больше.
Функциональность мобильных приложений можно разделить на два аспекта: удобство использования самого приложения и его интеграция в экосистему устройства. Например, для Android это могут быть такие функции, как виджеты и уведомления. Нативные приложения превосходят другие по обоим параметрам.
С точки зрения пользовательского опыта, нативные приложения могут предложить больше. Они легко обрабатывают события свайпа, даже мультитач, для тех платформ, которые его поддерживают. Обычно они могут реагировать на нажатия физических клавиш, таких как кнопка поиска и регуляторы громкости в Android. Они также могут получать доступ к аппаратному обеспечению, например, к GPS и камере. А с разрешения пользователя некоторые платформы предоставляют неограниченный доступ к операционной системе. Попробуйте определить, сколько заряда батареи осталось, с помощью HTML5!
Однако дело не только в работе внутри приложения. Операционная система, такая как Android, предоставляет приложениям различные способы взаимодействия с пользователями и, собственно, с другими приложениями. У вас есть активные виджеты на главной странице. У вас есть уведомления, которые отображаются в строке состояния устройства. И у вас есть интенты, которые позволяют вашему приложению заявлять о предоставлении общей услуги, которая может время от времени потребоваться другим приложениям.
Контраргумент: Встроенные функции можно расширять, и веб-технологии всё равно догоняют.
Действительно, многие функции приложения просто недоступны для HTML5-приложений. Какими бы вы ни были опытны в веб-разработке, если ваше приложение застряло в «песочнице» без API камеры, оно вряд ли сможет делать снимки в ближайшее время! К счастью, вам не обязательно находиться в этой «песочнице». Если вам действительно нужно, чтобы ваше веб-приложение делало фотографии, вы можете создать нативное приложение со встроенным веб-представлением, которое обеспечивает основную часть пользовательского интерфейса. Именно так работает фреймворк с открытым исходным кодом PhoneGap: он заполняет этот пробел, предоставляя нативные функции в виде веб-сервисов, которые веб-представление вызывает с помощью стандартного сетевого API. При создании такого гибридного приложения вы также можете подключаться к функциям платформы, таким как виджеты, уведомления и интенты.
Создание гибридного приложения — нативного и веб-приложения — вряд ли является идеальным решением. Оно усложняет задачу и применимо только к веб-приложениям, обернутым в нативные приложения, а не к традиционным веб-сайтам, доступ к которым осуществляется через мобильный браузер. Но, возможно, в ближайшее время это будет не нужно. Веб-стандарты быстро развиваются, и современные мобильные браузеры не отстают. Например, офлайн-хранилище, геолокация, графика на холсте и воспроизведение видео/аудио широко поддерживаются современными смартфонами. Даже камера начинает получать поддержку — начиная с Android 3.1, можно делать фотографии и снимать видео, используя веб-стандарты. А новейший браузер iOS поддерживает WebSocket для двусторонней потоковой передачи, а также определение ориентации устройства.
В целом, мобильные устройства развиваются. Но и веб-технологии тоже развиваются, и очень быстро. Только среди настольных браузеров пять основных производителей постоянно совершенствуют стандарты и добавляют новые функции с молниеносной скоростью. Хотя перенос этих функций на мобильные устройства — непростая задача, многие из них уже появились в мобильных браузерах.
Развитие нативных приложений быстро меняется, но веб-технологии сокращают отставание.
Производительность
Суть в том, что нативная версия работает быстрее.
Нативные приложения не сталкиваются с барьером, характерным для веб-среды выполнения. Они работают практически на аппаратном уровне и могут использовать преимущества таких средств повышения производительности, как ускорение с помощью графического процессора и многопоточность.
Контраргумент: Сегодня веб-среды выполнения намного быстрее, и большинству приложений такая скорость всё равно не нужна.
Было бы преуменьшением сказать, что веб-пространство за последние годы стало быстрее. V8, движок JavaScript, поставляемый с Chrome, стал значительным шагом вперед в повышении производительности веб-сайтов на момент своего запуска, и с тех пор он только ускоряется:
Движки графического рендеринга также ускорили работу веб-сайтов, и теперь начинает появляться аппаратное ускорение. Взгляните на прирост скорости, обеспечиваемый аппаратным ускорением холста:
Кроме того, новый API Web Workers делает возможной многопоточность, а современные веб-разработчики могут также использовать ряд оптимизированных по производительности библиотек и хорошо изученных методов оптимизации производительности. Хотя большинство из них изначально разрабатывались для настольных веб-приложений, они по-прежнему актуальны для мобильных устройств, и в последнее время мобильным приложениям уделяется все больше внимания, например, у эксперта по производительности Стива Саудерса есть страница, посвященная инструментам повышения производительности для мобильных устройств .
Не все достижения в разработке для настольных компьютеров пока добрались до всех мобильных платформ, но тенденции указывают на то, что это происходит. Важно также отметить, что большинство мобильных приложений — это не передовые 3D-игры, а в основном информационные сервисы: новости, почта, расписания, социальные сети и т. д. Посетите несколько сайтов со своего мобильного устройства, например, Gmail, Amazon, Twitter, и вы убедитесь, что производительность мобильного веб-браузера более чем достаточна. Что касается игр, то базовые игры уже можно создавать с помощью 2D-холста, а WebGL начинает появляться на мобильных устройствах — см. Firefox 4. Пока он не получит широкого распространения, существует растущее семейство фреймворков, которые компилируют приложения WebGL в нативные приложения, способные использовать преимущества OpenGL, например, ImpactJS .
Опыт разработчика
Суть в том, что разработку нативных приложений проще.
Нативные приложения используют надёжные языки программирования (например, Java, Objective C, C++), разработанные для создания сложных приложений и имеющие проверенную репутацию. API-интерфейсы были разработаны с нуля для поддержки конкретной платформы. Отладка приложений может быть легко выполнена в эмуляторах настольных компьютеров, которые обеспечивают максимально точное отображение целевого устройства.
Особенно сложной задачей веб-разработки является огромное разнообразие браузеров и сред выполнения. Когда ваше приложение запускается, нет никакой гарантии, что функция X будет доступна. И даже если она доступна, как браузер её реализует? Стандарты допускают различные интерпретации.
Контраргумент: Веб-разработка зачастую проще, особенно если она ориентирована на несколько устройств.
Давайте сначала разберемся с основными технологиями. Действительно, веб-стандарты изначально разрабатывались в эпоху, когда веб был в первую очередь ориентирован на документы, а не на приложения, и JavaScript создавался и развертывался всего за 10 дней! Но они оказались гораздо более функциональными, чем предполагалось — веб-разработчики научились использовать сильные стороны и справляться с недостатками, а шаблоны масштабируемого проектирования теперь понятны. Более того, стандарты не стоят на месте, и такие инициативы, как HTML5, CSS3 и EcmaScript Harmony, улучшают опыт разработчиков. Выбор между C++, Java и JavaScript — это вопрос спорный, и он также зависит от вашей устаревшей кодовой базы. Но сегодня мы, безусловно, можем включить JavaScript в число серьезных претендентов.
Обратная сторона фрагментации браузеров/сред выполнения заключается в том, что все эти среды уже существуют. Разработайте Android-приложение на Java, и вам придётся полностью перенести его на Objective C для поддержки iOS. Разработайте веб-приложение один раз, и оно будет работать на Android и iOS, не говоря уже о WebOS, BlackBerry, Windows Mobile и… ну, по крайней мере, такова теория. На практике вам придётся подстраивать всё под каждую платформу, если вы действительно хотите получить качественный пользовательский опыт. Но это придётся делать и в нативных приложениях, для большинства мобильных операционных систем — существуют разные версии и разные устройства.
Хорошая новость в том, что «фрагментация» всегда была таковой в интернете, и существуют хорошо известные методы борьбы с ней. Самое важное — принцип прогрессивного улучшения побуждает разработчиков сначала ориентироваться на базовое устройство, а затем добавлять специфичные для платформы функции там, где они доступны. Принцип определения функций также помогает, и сегодня у нас есть поддержка библиотек, таких как Modernizr, для поддержки адаптивного веб-дизайна. При грамотном использовании этих методов вы можете расширить охват на подавляющее большинство устройств, даже на старые «кнопочные телефоны», даже на такие форм-факторы, как часы и телевизоры, независимо от производителя и ОС. Вспомните нашу демонстрацию многопользовательского интерфейса на Google IO 2011, где мы ориентировались на различные форм-факторы (кнопочный телефон, смартфон, планшет, настольный компьютер, телевизор) с общей кодовой базой логики и разметки.
Внешний вид и тактильные ощущения
Суть в том, что нативные приложения соответствуют внешнему виду и функциональности платформы.
Одной из определяющих особенностей любой платформы является её внешний вид и удобство использования. Пользователи ожидают, что элементы управления будут представлены единообразно и будут управляться одинаково. Существуют определённые правила, которые различаются от платформы к платформе, например, что происходит, когда пользователь выполняет «длительное удержание» (удерживает элемент на несколько секунд)? Платформы имеют стандартные правила для таких действий, и невозможно удовлетворить все эти потребности с помощью одного HTML5-приложения.
Кроме того, внешний вид платформы определяется собственной программной библиотекой платформы, виджеты которой воплощают в себе тот внешний вид, которого ожидают пользователи. Вы получаете большую часть ожидаемого внешнего вида «бесплатно», просто используя собственный инструментарий.
Контраргумент: У веб-сайтов есть свой собственный внешний вид и стиль, и вы также можете настраивать веб-интерфейс для тех платформ, которые для вас наиболее важны.
Как объяснялось в предыдущем разделе, подход к веб-разработке заключается в создании базовой версии, подходящей для всех случаев, а затем в её постепенном улучшении. Хотя улучшение обычно основано на новых функциях, вы также можете улучшить её, ориентируясь на те платформы, которые для вас наиболее важны. Это своего рода «определение браузера», которое иногда не одобряется веб-сообществом, в основном из-за огромного количества возможных браузеров. Но если вы считаете две или три платформы очень важными и готовы приложить дополнительные усилия, чтобы конкурировать с нативными альтернативами, это может быть оптимальным решением.
Что касается базовой версии, то у веб-интерфейса есть свой собственный внешний вид и стиль, и можно даже сказать, что каждая мобильная платформа имеет свой собственный «веб-стиль», устанавливаемый браузером по умолчанию и средой выполнения веб-приложений. «Веб-стиль» может быть вполне удобен для ваших пользователей и, по сути, позволяет добиться большей согласованности с работой веб-браузера на настольных компьютерах, а также на других устройствах, с которыми может работать пользователь. Кроме того, существует множество успешных приложений, которые и так не очень поддерживают нативный внешний вид и стиль. Это, безусловно, верно для игр (соответствует ли ваша любимая мобильная игра внешнему виду и стилю вашей мобильной ОС?), и даже для более традиционных приложений, например, посмотрите на более популярные нативные клиенты Twitter на вашей платформе, и вы увидите широкий спектр механизмов пользовательского интерфейса в действии.
Обнаруживаемость
Суть в том, что нативные приложения проще найти.
Механизмы распространения приложений, такие как Android Market и Apple App Store, в последние годы пользуются огромной популярностью и являются движущей силой всей мобильной индустрии. Любой разработчик может разместить свое нативное приложение на торговой площадке, где пользователи могут найти его, используя сочетание просмотра, поиска и рекомендаций. Более того, если вы все сделали правильно, высокие оценки и комментарии убедят пользователей нажать на столь важную кнопку «Установить».
Контраргумент: На самом деле, веб-приложения найти проще.
Интернет, пожалуй, является самым доступным для поиска средством коммуникации из когда-либо созданных. В простом URL-адресе (по крайней мере, теоретически) содержится уникальный идентификатор всего, что когда-либо было опубликовано в сети, включая любые приложения, размещенные на стандартных веб-сайтах. Поисковые системы позволяют легко обнаружить, что контент и другие веб-сайты могут ссылаться на него, включая каталоги веб-приложений, аналогичные мобильным маркетплейсам. Действительно, любой человек может поделиться веб-приложением со своими друзьями, просто разместив ссылку на него в электронных письмах и сообщениях в социальных сетях. Ссылки также можно отправлять в SMS, где пользователи мобильных устройств смогут перейти по ссылке и запустить приложение в браузере своего устройства.
У нас пока нет таких же площадок, где пользователи могли бы оценивать приложения и оставлять комментарии, но и это меняется. Читайте дальше…
Монетизация
Суть в том, что нативные продукты можно монетизировать.
«Шестилетний ребенок создает приложение во время обеденного перерыва и продает миллион копий по 3 доллара каждая». Такие заголовки сейчас встречаются очень часто, поэтому неудивительно, что разработчики, как крупные, так и мелкие, ищут способы монетизации своих приложений на мобильных платформах. Мобильные платформы предлагают разработчикам несколько способов напрямую взимать плату за свои приложения. Самый простой — это разовый платеж, позволяющий разблокировать приложение навсегда. На некоторых платформах также предлагаются механизмы внутриигровых платежей и подписки, которые тесно интегрированы в единую, безопасную систему. Эти новые формы оплаты позволяют разработчикам превратить хитовое приложение в долгосрочный источник дохода.
Помимо платежей через приложение, вы можете монетизировать его с помощью традиционных веб-моделей, таких как реклама и спонсорство.
Контраргумент: Монетизация в интернете всегда была возможна, и возможности для этого постоянно растут.
Интернет не был бы двигателем современной индустрии, если бы не существовало множество возможностей для заработка. Хотя прямые механизмы «оплаты за использование» еще не получили широкого распространения, существуют различные ниши, где решения «программное обеспечение как услуга» на основе подписки действительно стали жизнеспособными. Примерами являются Google Apps, линейка продуктов 37Signals и премиум-версии различных почтовых сервисов. Кроме того, прямые платежи — не единственный способ получить прибыль от веб-приложений. Существуют онлайн-реклама, партнерские ссылки, спонсорство, перекрестное продвижение других продуктов и услуг.
Тем не менее, вполне естественно, что веб-разработчик, читая заголовки, испытывает некоторую зависть к получаемым доходам. Вы не можете отправить веб-адрес на нативные торговые площадки, так что же делать веб-разработчику? Он создает нативное «приложение-оболочку» — для каждой целевой платформы он создает пустое нативное приложение, которое просто содержит веб-представление. Веб-представление — это место, куда вы встраиваете настоящее приложение. Затем вы просто отправляете эти приложения на различные торговые площадки (и, будем надеяться, наблюдаете, как текут деньги!). Вероятно, сегодня на основных торговых площадках существуют сотни, если не тысячи, веб-приложений, некоторые из которых настолько хитро интегрированы, что мы даже не знаем их веб-версий.
Недостатком является необходимость кросс-компиляции под каждую платформу. Вот где может помочь существующий фреймворк, такой как PhoneGap. Более того, разрабатываются веб-сервисы, такие как PhoneGap Build и Apparatio. Направьте эти веб-сайты на свой репозиторий кода, и вы получите Android-приложение, iOS-приложение и так далее… готовые к отправке в соответствующие магазины. Не нужно устанавливать нативные SDK на свой компьютер; все, что вам нужно для создания всех этих нативных приложений, — это редактор кода и веб-браузер.
Будут ли когда-нибудь магазины приложений напрямую поддерживать веб-приложения, без всех сложностей, связанных с их нативной оберткой? Пока это неясно. Мы знаем, что Google представил Chrome Web Store в прошлом году, и хотя он предназначен только для настольных компьютеров, магазин вызвал интерес у других производителей браузеров и в целом является частью тенденции к созданию каталогов веб-приложений, включая некоторые попытки, ориентированные на мобильные устройства. Концепция веб-магазина находится на ранней стадии развития, но признаки многообещающие.
Выводы
Было бы неплохо объявить победителя, но на данный момент явного лидера нет. Некоторые приложения лучше подходят для нативных платформ, а другие — для веб-приложений. Веб-технологии, пожалуй, набирают обороты, но с точки зрения возможностей и качества выполнения нативные приложения тоже быстро развиваются. И пока не наступит время, когда веб-технологии станут первостепенными для большинства мобильных ОС, нативные приложения всегда будут оставаться важным фактором.
Один из методов, упомянутых в этой статье, — это гибридные приложения, и для некоторых разработчиков это может быть лучшим компромиссом: веб-представление там, где это возможно, и платформенно-специфичные нативные компоненты там, где это невозможно.
Если вы всё же выберете веб-разработку, помните о веб-стандартах и принципе прогрессивного совершенствования. Веб — это технология, которая умеет адаптироваться к множеству устройств и операционных систем. Независимо от того, называете ли вы это «фрагментацией» или «разнообразием», веб это принимает, и вы, разработчики, можете извлечь пользу из всего существующего опыта.