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

К нам на оценку ТЗ часто приходят запросы на бизнес-приложения, в которых одно из главных требований - это натив. При этом большинство клиентов не могут объяснить ни обоснованность применения именно натива, ни что это такое вообще. Сложилось ощущение, что это требование приходит от некого знакомого программиста, который не учитывает стоимость и бизнес-логику, то есть такого адепта чистого кода. Чтобы всё-таки разобраться что такое натив, что такое гибрид и в каком случае что выбрать я решил написать эту статью.

Вообще, мы в Bright Mobile специализируемся на сложных серверных бизнес-приложениях, например, аналоги Авито, youdo, мобильные магазины, социальные сети и т.д. Анализируя ТЗ пришли к выводу, что в 95% случаев натив не то что не нужен, но даже вредит проекту. И сейчас я расскажу почему.

Но, сначала, давайте пройдём по общим характеристикам.

Любой многопользовательский сервис состоит из клиентских приложений и серверной части. Если смотреть совсем широко, то туда ещё подключаются сайт, телефония, api сторонних проектов, но для того, чтобы сравнить натив с гибридом нам это не нужно, поэтому рассмотрим самый простой вариант:

На стороне клиентской части располагается приложение iOS или Android, а со стороны сервера, собственно, серверное ПО и админка для управления данными.

Вот теперь мы подходим к отличиям. А отличия заключаются в том, какой объём функционала несёт клиентская часть, а какой серверная. Непонятно? Давайте начнём с определений

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

Нативное приложение можно сравнить с приложениями для ПК. Купили MS Word, скачали установщик на компьютер, установили его и пользуетесь. По большому счёту вам уже без разницы есть интернет или нет - программа запускается с вашего ПК. Тут тоже самое - скачали со сторов, установили и весь функционал доступен с вашего телефона. То есть приложение скачивается "от и до" и, если это не заложено логикой приложения, интернет ей не нужен. Самый простой пример - это одиночные игры. Скачал и играешь.

Гибрид - это скорее подход к программированию, чем какой-то особенный вид приложения. Его принцип заключается в том, что всё что можно (читай "все функции не связанные с железом") программируется на стороне сервера, а на стороне клиента остаётся только необходимый минимум. Если рассматривать типовой мобильный магазин, то GPS и функция отображения данных будет на стороне приложения, а каталог, карточки товаров и т.д. будут грузиться с сервера.

Давайте для примера рассмотрим как бы в гибриде и нативе выглядела наша платформа для создания сервиса поиска исполнителей "Сервис ПИ". Красным выделено то, что нужно делать на стороне приложения для телефона, а зелёным - на стороне сервера.

В нативе:

В гибриде:

Как видно из картинок единственная разница между нативом и гибридом - это объём функционала, который реализуется на стороне телефона. Но есть большое "НО". Весь "зелёный" функционал, который мы в гибриде перенесли на сервер делается 1 раз для обеих платформ, а красный - для каждой платформы пишется отдельно. Давайте разберём какие из этого можно сделать финансовые выводы.

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

• Java-программист для андройда
• Objective-C/Swift-программист для айоса
• php-программист для сервера. Можно, конечно брать python-разработчика, но для чего он конкретно здесь, непонятно, поэтому, ориентируемся на php, т.к. он более дешёвый.

Нужно учитывать, что Андройд и айос программисты в среднем стоят примерно в два раза дороже php.

При полностью нативной разработке мы заплатим программистам приложений за полный функционал, а в случае гибрида только за нативные функции (отмечено красным). Оставшийся же функционал будет реализовывать php-шник. Причём, нативщики будут делать это всё и для iOS и для Android отдельно, а при гибриде php-шник делает эти экраны один раз для обеих систем. Получается, что почти двукратная работа выполняется специалистами, которые в 2 раза дороже. Путём не хитрых вычислений приходим к тому, что полностью нативное приложение будет стоить ~4 раза выше гибридного. Это, конечно, зависит от того какие нативные функции нужны в приложении и как они применяются, но при стандартном бизнес-приложении (GPS, камера, интернет) экономия в 3-4 раза.

Конечно же, у натива преимущества вытекают из той же концепции:

• "тяжёлые" вычисления, которые нужны на стороне телефона (например, работа с 3D, обработка виртуальной реальности, сложная анимация)
• Отсутствие требований к постоянному наличию интернета (приложения шагомеры, пульсомеры, игры-кликеры, органайзеры и т.д.)

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