Смартфоны продолжают отвоевывать все больше места под солнцем не только как инструмент потребления фотографий котиков и ххх-роликов, но и в качестве рабочего инструмента. Поэтому и спрос на мобильную разработку растет. Принято считать, что тру и кул — это Objective-C/Swift для iOS и Java/Kotlin для Android. Спору нет, тру и кул, но существует большое количество реальных сценариев, в которых использование кросс-платформенных фреймворков более предпочтительно в сравнении с нативными инструментами.

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

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

 

Зачем нужны кросс-платформенные инструменты?

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

Нативные инструменты = предоставляются владельцем экосистемы.

Все остальные признаки «нативности» ВТОРИЧНЫ — поведение и интерфейс приложений, доступ к возможностям ОС, производительность и прочее.

К тому же практически всегда оказывалось, что нативные инструменты несовместимы друг с другом не только на уровне языков разработки, принятых соглашений и архитектур, но и на уровне механизмов работы с операционной системой и библиотеками. В результате для реализации одних и тех же алгоритмов и интерфейсов требовалось написать приложение для нескольких сред на разных языках программирования, а потом его поддерживать из расчета «одна команда на платформу». При этом возможности и внешний вид приложений на разных платформах практически всегда идентичны на 90%. Сравни ради интереса реализацию любимых программ для iOS и Android.

Второй важный момент — наличие необходимых знаний и опыта внутри команды: если их нет, то потребуется время на обучение.

Для того чтобы решить обе эти проблемы, на рынке уже давно появились инструменты кросс-платформенной разработки (не только mobile), предлагающие:

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

Так как языков программирования (и сред) сейчас наплодилось очень много (и специалистов, владеющих этими языками), то и инструментов для кросс-платформенной разработки существует изрядное количество. Мы в качестве примера остановимся на популярных в наших краях PhoneGap, Xamarin, React Native и Qt.


Теперь можно поговорить и о мифах.

 

Миф 1. Магия

Самый частый миф, будоражащий умы начинающих девелоперов, связан с верой в сверхалгоритмы (и сверхпрограммистов, их создавших), которые волшебным образом превращают кросс-платформенные приложения в нативные. Что-то в духе «преобразования кода JavaScript в Swift и дальнейшая компиляция уже Swift-приложения». Этот миф подогревают и сами разработчики кросс-платформенных инструментов, обещая на выходе создание «нативных приложений». И не то чтобы кто-то здесь лукавил, но богатая фантазия и непонимание базовых механизмов иногда наводят разработчиков на мысли о шаманских приемах.

Главный принцип, лежащий в основе кросс-платформенных решений, — разделение кода на две части:

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

Для того чтобы связывать между собой мир «нативный» и мир «кросс-платформенный», необходимо использовать специальный мост (bridge), именно он и определяет возможности и ограничения кросс-платформенных фреймворков.

При использовании bridge производительность всегда снижается за счет преобразования данных между «мирами», а также конвертации вызовов API и библиотек.

Итак, все кросс-платформенные приложения обязаны иметь нативную часть, иначе операционная система просто не сможет их запустить. Поэтому давай рассмотрим подробнее, какие системные API и механизмы предоставляются самими iOS, Android и Windows. Переходим к следующему мифу.

Продолжение статьи доступно только подписчикам

Cтатьи из последних выпусков журнала можно покупать отдельно только через два месяца после публикации. Чтобы читать эту статью, необходимо купить подписку.

Подпишись на журнал «Хакер» по выгодной цене!

Подписка позволит тебе в течение указанного срока читать ВСЕ платные материалы сайта, включая эту статью. Мы принимаем оплату банковскими картами, электронными деньгами и переводами со счетов мобильных операторов. Подробнее о подписке

6 комментариев

  1. mYoda

    25.12.2017 at 13:59

    интересно. спасибо.
    сам С++ разработчик в прошлом (5 лет) под Win, потом после выхода Win10 — перешел на iOS/Swift. В портфеле конечно еще несколько языков программирования — за 8 лет в IT пришлось просто использовать много чего…
    так вот, ходят слухи уже давно что Swift якобы прикрутят к Android… ну или к какой-нить среде для кросс-платформенного программирования. Есть ли у вас информация по этому поводу?
    Что касается моего личного отношения к кросс-платформенности: я и не за и не против. Однако было бы круто «сбилдить» несколько моих iOS проектов под дроид без каких-либо усилий…

    • Вячеслав Черников

      Вячеслав Черников

      25.12.2017 at 14:38

      Про Swift — вряд ли его сами Apple или Google прикрутят к Android, там вопрос бизнесовый, а не технический. Каждый уважающий себя IT-гигант по максимуму будет развивать и поддерживать только свой технологический стек.
      Плюс вопрос же не только в языке, но и в системных API, а также сторонних библиотеках.

  2. coolmarat

    25.12.2017 at 16:41

    Современные версии Delphi тоже умеют компилировать один и тот же код под Android, IOS, Windows. Осветите и этот аспект как-нибудь…

    • Вячеслав Черников

      Вячеслав Черников

      25.12.2017 at 18:09

      И много других фреймворков тоже умеют компилировать один и тот же код под разные платформы 🙂 В статье рассмотрели только популярные фреймворки, остальной зоопарк остался за кадром, но принцип там такой. Насколько я знаю, то Delphi ближе к

    • baragoz

      25.12.2017 at 21:17

      А ты видел, сколько этот Дельфи щас стоит? 😉 http://store.embarcadero.ru/catalog/rubric/24
      Сразу не захочется…

  3. Вячеслав Черников

    Вячеслав Черников

    25.12.2017 at 18:11

    * Насколько я помню, то Delphi ближе к Qt (вещь в себе). Но не копал это направление 🙂

Оставить мнение

Check Also

Атака chaiOS выводит из строя приложение iMessage для macOS и iOS

Исследователь Абрахам Марси (Abraham Masri) обнаружил баг, получивший название chaiOS. Он …