3

Кроссплатформенные фреймворки vs. native-инструменты. Что выбрать для разработки мобильных приложений?

Данил Смакотин
5 мая 2012 года

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

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

  • Appcelerator Titanium. Синтаксис — JavaScript. Поддерживаемые платформы — iOS, Android, BlackBerry
  • PhoneGap. Синтаксис — JavaScript, HTML5, CSS. Поддерживаемые платформы — iOS, Android, webOS, Symbian, BlackBerry, Windows Phone 7, Bada
  • Rhodes. Синтаксис — Ruby, HTML5. Поддерживаемые платформы — iOS, Android, Windows Mobile, BlackBerry, Windows Phone 7
  • MonoTouch. Синтаксис — C#. Платформы — iOS, Android, Windows Phone 7. Платный

Посмотрим, что это такое и с чем это едят.

Appcelerator Titanium

Несмотря на то, что Titanium предоставляет для разработки язык JavaScript, он не использует для контроля над приложениями веб-браузер, а весь User Interface является нативным. Построение приложения состоит из трех концептуальных шагов:

  1. Прекомпиляция. Роль прекомпилятора Titanium заключается в оптимизации JavaScript кода: сокращение количества пробелов, размера символов и т. д. и создание иерархии зависимостей всех API функций, используемых в проекте
  2. Front-end компиляция. Ее роль заключается в генерации соответствующего платформе нативного кода и, если это необходимо, создании нативного проекта и построении специфичного кода, необходимого компилятору данной платформы.
  3. Компиляция платформой и упаковка. Каждая из платформ имеет набор соответствующих инструментов (например, Xcode для iOS) для окончательной компиляции приложения. После компиляции приложения упаковывается либо для запуска на эмуляторе, либо для тестирования на устройстве, либо для распространения.

Кроме того, немаловажным является тот факт, что Titanium позволяет расширять имеющиеся возможности, написанием сторонних модулей на языках Objective-C и C для iOS и на языке Java для Android. В частности, это значит, что если какой-то класс не портирован в Titanium API из iOS SDK, то у разработчика есть возможность сделать это самому, если, конечно, он владеет языком Objective-C.

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

PhoneGap

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

Подобно Titanium, у PhoneGap-разработчиков есть возможность расширять возможности фреймворка. Здесь это называется плагинами, которые пишутся на нативном языке для каждой платформы. Т. е. теоретически можно и в PhoneGap-приложении добиться нативного интерфейса, написав плагин для этих целей, правда работать будет он уже не кроссплатформенно и затраченные на это усилия, вряд ли, будут оправданы с коммерческой точки зрения.

Rhodes и MonoTouch

По поводу этих двух фреймворков ограничусь лишь тем, что Rhodes больше похож на PhoneGap, тем, что интерфейс описывается с помощью HTML, а логика на скриптовом языке (в данном случае, Ruby, но при этом возможность использования JS-DOM-фреймворков, таких как SenchaTouch и JQuery Mobile тоже есть). При этом Rhodes предоставляет дополнительные средства для нужд корпоративных приложений, на разработку которых в основном и рассчитан.

А вот MonoTouch больше похож на Titanium, поскольку C# испольуется в нем, как обертка классов и методов (в том числе и UI) Cocoa Touch, но MonoTouch гораздо ближе к Objective-C, чем Titanium. Здесь даже можно использовать Interface Builder — средство, встроенное в xCode, позволяющее создавать интерфейс с помощью GUI и связывать его с кодом.

По каким критериям оценивать?

Попробуем выделить наиболее важные критерии при выборе интструмента для разработки мобильных приложений и проранжировать по ним средства разработки. Для сравнения возьмем наиболее популярную платформу iOS и нативное средство Objective-C с iOS SDK и 2 фреймворка: Appcelerator Titanium и PhoneGap

  1. Нативность. Показатель достаточно важный, и его важность только растет со временем, потому что мобилильные ОС развиваются очень быстро и глупо не пользоваться теми возможностями, которые предоставляет каждая из них. По этому показателю выигрывает, безусловно Titanium, но оба фреймворка проигрывают iOS SDK, которым вынуждены пользоваться
  2. Производительность. Безусловным лидером и тут является iOS SDK. Titanium, конечно, уступает ему, но за счет того, что все элементы интерфейса в итоге становятся теми же, что и в Objective-C выигрывает у PhoneGap, который проигрывает по производительности, за счет того, что весь интерфейс помещается в webView и при серьезных объемах данных этот интерфейс заметно подтормаживает. Также стоит отметить, что очень сложно застваить работать Titanium и PhoneGap-приложения долго без crashes. Видимо, это связано с тем, что освобождение памяти реализовано в них совсем не идеально. Утешает лишь то, что разработчики постоянно их совершенствуют и исправляют ошибки
  3. Кроссплатформенность. Тут уже уверенно лидирует PhoneGap с 7 платформами. Titanium — 3 платформы (правда, как он работает с BlackBerry мало кому известно). Ну, а iOS SDK на то и iOS SDK
  4. Скорость разработки. Здесь все совсем не очевидно. На первый взгляд кажется, что в порядке убывания скорости это выглядит вот так: PhoneGap, Titanium, iOS SDK. Однако это верно для самых простых приложений, с увеличением сложности проекта картина меняется прямо пропорционально и для сложных проектов мы получаем все наоборот: iOS SDK, TItanium, PhoneGap. Аргументация этого тезиса заключена в следующих двух пунктах
  5. Разнообразие возможностей. Первое место у iOS SDK, второе я бы отдал Titanium — за счет того, что он поддерживает меньше платформ — методов и свойств у классов предоставляется больше, кроме того есть классы, работающие только с iOS, либо только с Android, предоставляя специфические возможности платформ. Но как только их станет не хватать — разработчику придется писать модули (а в случае с PhoneGap — плагины) — а для этого ему придется изучить Objective-C, после чего, вполне возможно, что он захочет переписать проект именно на нем
  6. Средства отладки. Отладчик в Xcode основан на GDB, кроме того в Xcode есть много дополнительных средств, таких как zombie objects, которые позволяют отследить ошибки освобождения памяти и масса возможностей в Instruments, который с четвертой версии встроен в Xcode. В Titanium уже около года назад — с выходом Titanium Studio — появился свой отладчик, который, однако, позволяет увидеть стек вызовов только JS-кода, поэтому причины ошибок, которых предостаточно, допущенных разработчиками Titanium, понять иногда бывает крайне сложно и на это уходит уйма времени. Средства отладки PhoneGap еще более скромны, в частности, нет таких возможностей, как точки останова и трассировка стека
  7. Документированность. Первое место — у iOS SDK. Второе можно отдать PhoneGap, так как многие из возможностей Titanium не документированы совсем, правда оправданием этому служит то, что доступен для скачивания проект Kitchen Sink, в котором реализовано все, что можно сделать с помощью Titanium

Ниже представлена сводная таблица соревнований (кликабельно).

Что чему подходит

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

PhoneGap

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

Titanium

Приложение весьма похоже на то, для которого наиболее подходящее средство — это PhoneGap, но в отличии от него, в нем важна поддержка только наиболее популярных платформ, таких как iOS и Android, при этом приложение должно выглядеть нативно и для той и для другой платформы. Приложение также не хранит больших объемов данных, но должно выполнять с ними операции средней сложности и, возможно, работать в offline-режиме, если приложение взаимодействует с сервером.

Нативные средства разработки

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

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

3 комментариев к записи «Кроссплатформенные фреймворки vs. native-инструменты. Что выбрать для разработки мобильных приложений?»

  1. Дмитрий,

    Появилась еще одна альтернатива для .NET разработчиков — Ubiq Mobile.

    Приложения работают под Android, iOS, Windows Phone и на старых Java телефонах и коммуникаторах. Быстрая кросс-платформенная .NET разработка. Не требует особых навыков разработки мобильных приложений. Есть готовые шаблоны и компоненты. В основе — облачная архитектура.

    Краткий обзор «How to create simple UbiqMobile application» — http://ubiqmobile.com/create-simple-ubiqmobile-application/

    How it works: http://www.youtube.com/watch?v=VydBF3Th1RY

  2. Кристи,

    интересный обзор кроссплатформенной разработки) хоть и спорный) как продолжение дискуссии, очень интересная статья от супер опытного программиста: http://www.issoft.by/kakoj-metod-razrabotki-mobilnyx-prilozhenij-vam-podxodit/

  3. Intechcore,

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

Оставить комментарий