Полемика на тему мобильных приложений
Введение
Мобильные приложения и HTML5 – две самые популярные технологии на сегодняшний день, и они во многом пересекаются. Веб-приложения работают в мобильных браузерах, а также могут быть переупакованы в виде нативных приложений на различных мобильных платформах. Поскольку разработчикам приходится поддерживать множество платформ, а мобильные браузеры становятся все мощнее, HTML5 становится все популярнее как решение, позволяющее написать код один раз и использовать его на разных платформах. Но действительно ли это возможно? Есть веские причины для создания нативных приложений, и многие разработчики выбирают именно этот путь. В этой статье сравниваются нативные приложения и веб-приложения.
Разнообразие функций
Преимущество: нативные объявления могут больше
Функциональность мобильного приложения можно разделить на две части: работа самого приложения и его интеграция с экосистемой устройства. Например, в Android это виджеты и уведомления. Нативная реклама отлично подходит для обеих целей.
С точки зрения удобства использования приложения, нативные приложения могут делать больше. Они могут легко обрабатывать события пролистывания и даже мультитач на платформах, которые это поддерживают. Обычно они реагируют на нажатие физических кнопок, например кнопки поиска или регулировки громкости. Они также могут использовать аппаратные компоненты, например GPS и камеру. Кроме того, с разрешения пользователя некоторые платформы предоставляют неограниченный доступ к операционной системе. Попробуйте определить уровень заряда батареи с помощью HTML5!
Но дело не только в удобстве использования приложения. Операционная система, такая как Android, предоставляет приложениям различные способы взаимодействия с пользователями и, по сути, с другими приложениями. На главной странице есть активные виджеты. Уведомления, которые появляются в строке состояния устройства. И у вас есть намерения, которые позволяют вашему приложению объявить о себе как о предоставляющем общую услугу, которая может время от времени требоваться другим приложениям.
Контраргумент: нативные функции можно дополнить, а веб-технологии развиваются очень быстро
Это правда, что многие функции в приложении просто недоступны для приложения HTML5. Независимо от того, насколько хороши ваши навыки веб-фу, если ваше приложение застряло в песочнице без API камеры, оно не будет делать снимки в ближайшее время! К счастью, вам не нужно быть в этой песочнице. Если вам действительно нужно, чтобы ваше веб-приложение делало фотографии, вы можете создать нативное приложение со встроенным веб-представлением, которое обеспечивает большую часть пользовательского интерфейса. Именно так работает фреймворк PhoneGap с открытым исходным кодом: он заполняет пробел, предоставляя нативные функции в виде веб-сервисов, которые веб-представление вызывает с помощью стандартного сетевого API. При создании такого гибридного приложения вы также можете подключиться к функциям платформы, таким как виджеты, уведомления и намерения.
Создание гибридного приложения (нативного и веб-приложения) вряд ли можно назвать идеальным решением. Это усложняет работу и применяется только к веб-приложениям, упакованным как нативные приложения, а не к традиционным сайтам, доступ к которым осуществляется из мобильного браузера. Но, возможно, скоро это не понадобится. Веб-стандарты быстро развиваются, и современные мобильные браузеры не отстают от них. Например, офлайн-хранилище, геолокация, графика на холсте, воспроизведение видео и аудио поддерживаются большинством современных смартфонов. Начиная с Android 3.1, поддерживается даже камера, то есть можно делать фотографии и снимать видео, используя веб-стандарты. Последняя версия браузера iOS поддерживает WebSocket для двусторонней потоковой передачи, а также определение ориентации устройства.
В целом мобильные технологии развиваются. Но интернет тоже развивается, и очень быстро. Только среди браузеров для компьютеров есть пять основных поставщиков, которые развивают стандарты и добавляют функции с молниеносной скоростью. Хотя перенос этих функций на мобильные устройства – непростой процесс, многие из них уже появились в мобильных браузерах.
Нативные приложения развиваются быстро, но веб-приложения не отстают.
Эффективность
Плюс: нативные приложения работают быстрее
Нативные приложения не сталкиваются с ограничениями среды выполнения веб-приложений. Они работают на низком уровне и могут использовать такие ускорители производительности, как ускорение графического процессора и многопоточность.
Контраргумент: сегодня среды выполнения веб-приложений работают намного быстрее, и большинству приложений такая скорость не нужна.
Сказать, что за последние годы интернет стал быстрее, – значит не сказать ничего. V8, движок JavaScript, поставляемый с Chrome, стал важным шагом в повышении производительности веб-страниц, и с тех пор он стал только быстрее:
Движки графического рендеринга также ускорили работу в интернете, и теперь начинает происходить аппаратное ускорение. Посмотрите, насколько быстрее работает canvas с аппаратным ускорением:
Кроме того, новый 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, то для поддержки iOS вам придется полностью переписать его на Objective C. Разработайте веб-приложение один раз, и оно будет работать на Android и iOS, не говоря уже о WebOS, BlackBerry, Windows Mobile и… ну, по крайней мере, такова теория. На практике вам придется настраивать вещи для каждой платформы, если вы действительно хотите получить правильный опыт. Но это приходится делать и для нативных приложений, поскольку существует множество версий мобильных операционных систем и устройств.
Хорошая новость заключается в том, что "фрагментация" всегда была такой в Интернете, и существуют хорошо известные методы борьбы с ней. Самое главное, что принцип прогрессивного улучшения побуждает разработчиков сначала ориентироваться на базовое устройство, а затем добавлять уровни потрясающих функций, специфичных для платформы, там, где они доступны. В этом также помогает определение функций, а в настоящее время у нас есть поддержка библиотек, таких как Modernizr, для поддержки адаптивного веб-дизайна. При разумном использовании этих методов вы можете расширить охват до подавляющего большинства устройств, даже старых "функциональных телефонов", даже таких форм-факторов, как часы и телевизоры, независимо от марки и ОС. Посмотрите демонстрацию нескольких интерфейсов на конференции Google I/O 2011, где мы ориентировались на разные форм-факторы (кнопочный телефон, смартфон, планшет, компьютер, телевизор) с общей базой кода логики и разметки.
Внешний вид
Преимущество: нативные объявления соответствуют внешнему виду платформы
Одной из определяющих особенностей любой платформы является ее внешний вид и ощущение. Пользователи ожидают, что элементы управления будут представлены единообразно и будут работать одинаково. Некоторые идиомы различаются в зависимости от платформы. Например, что происходит, когда пользователь выполняет долгое нажатие (удерживает палец на элементе в течение нескольких секунд)? У каждой платформы есть свои стандарты, и вы не сможете удовлетворить их все с помощью одного приложения HTML5.
Кроме того, внешний вид платформы определяется ее нативной библиотекой программного обеспечения, виджеты которой инкапсулируют тот внешний вид, который ожидают пользователи. Вы получаете много ожидаемого внешнего вида и поведения "бесплатно", просто используя нативный инструментарий.
Контраргумент: у веб-интерфейса есть свой стиль, и вы можете настроить его для платформ, которые вас больше всего интересуют.
Как объяснялось в предыдущем разделе, способ веб-разработки заключается в том, чтобы написать базовую версию «один размер подходит всем», а затем постепенно улучшать ее. Хотя улучшение обычно основано на функциях, вы также можете улучшить его, ориентируясь на те платформы, которые вас больше всего интересуют. Это своего рода "обнаружение браузера", которое иногда не одобряется веб-сообществом, в основном потому, что существует очень много возможных браузеров. Но если вы рассматриваете две или три платформы с очень высоким приоритетом и готовы приложить дополнительные усилия, чтобы конкурировать с нативными альтернативами, это может быть правильным решением.
Что касается базовой версии, у веб-страниц есть свой внешний вид, и можно даже сказать, что у каждой мобильной платформы есть свой "веб-стиль", определяемый браузером по умолчанию и средой выполнения. "Веб-стиль" может быть удобен для пользователей и позволяет добиться большей согласованности с браузером для компьютера, а также с другими устройствами, с которыми может работать пользователь. Кроме того, есть много успешных приложений, которые не поддерживают нативный внешний вид. Это, безусловно, относится к играм (следует ли ваша любимая мобильная игра внешнему виду и поведению вашей мобильной ОС?), и даже к более традиционным приложениям, например, посмотрите на более популярные нативные клиенты Twitter на выбранной вами платформе, и вы увидите широкий спектр работающих механизмов пользовательского интерфейса.
Оптимизация для рекомендаций и поиска
Аргумент: нативные приложения проще найти
В последние годы механизмы распространения приложений, такие как Android Market и Apple App Store, стали невероятно популярными и являются основной движущей силой всей мобильной индустрии. Любой разработчик может отправить свое нативное приложение на торговую площадку, где пользователи смогут найти его, просматривая каталог, выполняя поиск или получая рекомендации. Кроме того, если вы все сделали правильно, то восторженные отзывы и высокие оценки убедят пользователей нажать заветную кнопку "Установить".
Контраргумент: на самом деле веб-приложения проще найти
Интернет – это, пожалуй, самая доступная среда из всех, что когда-либо существовали. URL – это уникальный идентификатор для всего, что когда-либо было опубликовано в интернете, включая приложения, размещенные на стандартных сайтах. Поисковые системы упрощают поиск такого контента, а другие сайты могут ссылаться на него, включая каталоги веб-приложений, похожие на мобильные торговые площадки. Любой пользователь может поделиться веб-приложением с друзьями, просто отправив им ссылку по электронной почте или в социальной сети. Ссылки также можно отправлять в SMS-сообщениях. Пользователи мобильных устройств смогут нажимать на них и запускать приложение в браузере.
У нас пока нет таких же торговых площадок, где пользователи могут оценивать приложения и оставлять комментарии, но и это меняется. Читайте дальше…
Монетизация
Пункт: нативную рекламу можно монетизировать
"Шестилетний ребенок создал приложение во время обеденного перерыва и продал миллион копий по три доллара за штуку". Такие заголовки сейчас не редкость, поэтому неудивительно, что разработчики всех мастей стремятся монетизировать свои приложения. Мобильные платформы предлагают разработчикам несколько способов взимать плату за свои приложения. Самый простой – разовый платеж, который навсегда разблокирует приложение. На некоторых платформах также предлагаются механизмы платежей в приложениях и подписки, и они тесно интегрированы в согласованный и безопасный механизм. Эти новые способы оплаты позволяют разработчикам превратить популярное приложение в долгосрочный источник дохода.
Помимо платежей в приложении, вы можете монетизировать его с помощью традиционных веб-моделей, таких как реклама и спонсорство.
Контраргумент: монетизация в интернете всегда была возможна, и сейчас возможностей становится все больше
Интернет не стал бы двигателем современной индустрии, если бы не было широких возможностей для заработка. Хотя прямые механизмы оплаты по факту использования пока не получили широкого распространения, в различных нишах решения "программное обеспечение как услуга" на основе подписки действительно стали жизнеспособными. Примеры: приложения Google, продукты 37Signals и платные версии различных почтовых сервисов. Кроме того, прямые платежи – не единственный способ заработка на веб-приложениях. Это интернет-реклама, партнерские ссылки, спонсорство, перекрестное продвижение других продуктов и услуг.
Тем не менее, веб-разработчики, читая заголовки, могут испытывать зависть. Но как быть веб-разработчикам, если в магазинах приложений нельзя публиковать URL? Для этого создайте нативное приложение-оболочку. Для каждой платформы, на которую вы хотите настроить таргетинг, создайте пустое нативное приложение, которое содержит только веб-просмотр. В веб-представление вы встраиваете настоящее приложение. Затем вы просто отправляете эти приложения на различные торговые площадки (и, надеюсь, наблюдаете, как поступают деньги!). Сегодня на основных торговых площадках, вероятно, существуют сотни, если не тысячи, веб-приложений, некоторые из которых настолько хитро ассимилированы, что мы даже не знаем, что это веб-приложения.
Недостаток заключается в необходимости кросс-компиляции для каждой платформы. В этом случае вам поможет фреймворк, например PhoneGap. Более того, сейчас разрабатываются такие веб-сервисы, как PhoneGap Build и Apparatio. Укажите этим сайтам на свой репозиторий кода, и вы получите приложение для Android, приложение для iOS и так далее… готовые к отправке в соответствующие магазины. Вам не нужно устанавливать нативные SDK на свой компьютер. Всё, что вам нужно для создания всех этих нативных приложений, – это редактор кода и веб-браузер.
Будут ли торговые площадки когда-нибудь поддерживать веб-приложения напрямую, без всех накладных расходов на их нативную упаковку? Пока неясно. Мы знаем, что в прошлом году Google запустила интернет-магазин Chrome. И хотя он предназначен только для компьютеров, он вызвал интерес у других поставщиков браузеров и в целом является частью тенденции к созданию каталогов веб-приложений, включая некоторые попытки, ориентированные на мобильные устройства. Концепция интернет-магазина пока находится на ранней стадии развития, но уже сейчас можно сказать, что у нее есть будущее.
Выводы
Было бы здорово объявить здесь победителя, но сейчас явного победителя нет. Некоторые приложения лучше всего подходят для нативных, а некоторые лучше всего подходят для Интернета. Веб-стек, возможно, имеет больший импульс, но с точки зрения возможностей и качества исполнения нативные приложения также быстро развиваются. И пока веб-технологии не станут первоклассными гражданами в большинстве мобильных ОС, нативные приложения всегда будут важным фактором.
В этой статье упоминаются гибридные приложения, которые могут стать лучшим компромиссом для некоторых разработчиков: веб-просмотр, где это возможно, и нативные компоненты для конкретной платформы, где это невозможно.
Если вы выберете веб-путь, помните о веб-стандартах и принципе прогрессивного улучшения. Веб – это технология, которая позволяет охватить множество устройств и операционных систем. Называйте это как хотите – фрагментацией или разнообразием, – но веб-технологии принимают это, и вы, разработчики, можете извлечь выгоду из всего, что уже было создано.