Гибридные приложения
Вообще, мы в 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, обработка виртуальной реальности, сложная анимация)
- Отсутствие требований к постоянному наличию интернета (приложения шагомеры, пульсомеры, игры-кликеры, органайзеры и т.д.)
Вообще, как я и писал выше, моя команда занимается разработкой гибридных приложений. Это и не случайно, ведь у бизнес-приложений нет требований ни к вычислительной мощности телефона (нагрузка не выше, чем у браузера), ни к отсутствию интернета (для того, чтобы сделать заказ в мобильном магазине в любом случае нужен интернет). Если же клиент приходит к нам с заказом игры, то, конечно же, мы отправляем его к нативщикам. Самое важное, что я рекомендую - это грамотно выбрать подход к разработке, чтобы потом не было мучительно больно за ошибки, сделанные на старте.