Смартфоны продолжают отвоевывать все больше места под солнцем не только как инструмент потребления фотографий котиков, но и в качестве рабочего инструмента. Поэтому и спрос на мобильную разработку растет. Принято считать, что тру и кул — это Objective-C/Swift для iOS и Java/Kotlin для Android. Спору нет, тру и кул, но существует большое количество реальных сценариев, в которых использование кросс-платформенных фреймворков более предпочтительно в сравнении с нативными инструментами. Подробнее под катом!
Примечание: мы продолжаем серию публикаций полных версий статей из журнала Хакер. Орфография и пунктуация автора сохранены.
Передаю слово автору.
Одни разработчики ждут от кросс-платформенных фреймворков решения всех своих жизненных проблем, другие же воспринимают их в штыки. В обоих «враждующих лагерях» есть свои заблуждения, вызванные непониманием того, как и что работает. Это подливает масла в огонь, так как вместо технических доводов в ход идут эмоции.
Также среди разработчиков, особенно начинающих, существует множество мифов о кросс-платформенных мобильных фреймворках. В нашей статье мы разберем самые популярные из них. Но для начала посмотрим на мобильную разработку глазами бизнеса, дающего деньги на весь айтишный блек-джек.
Исторически на рынке компьютеров всегда была конкуренция, и каждый производитель предоставлял оптимальный набор так называемых нативных (родных) инструментов для разработки приложений под свои операционные системы и устройства.
Нативные инструменты = предоставляются владельцем экосистемы.
Все остальные признаки «нативности» ВТОРИЧНЫ — поведение и интерфейс приложений, доступ к возможностям ОС, производительность и прочее.
К тому же практически всегда оказывалось, что нативные инструменты несовместимы друг с другом не только на уровне языков разработки, принятых соглашений и архитектур, но и на уровне механизмов работы с операционной системой и библиотеками. В результате для реализации одних и тех же алгоритмов и интерфейсов требовалось написать приложение для нескольких сред на разных языках программирования, а потом его поддерживать из расчета «одна команда на платформу». При этом возможности и внешний вид приложений на разных платформах практически всегда идентичны на 90%. Сравни ради интереса реализацию любимых программ для iOS и Android.
Второй важный момент — наличие необходимых знаний и опыта внутри команды: если их нет, то потребуется время на обучение.
Для того чтобы решить обе эти проблемы, на рынке уже давно появились инструменты кросс-платформенной разработки (не только mobile), предлагающие:
— максимизировать общую базу кода на едином языке программирования, чтобы продукт было проще разрабатывать и поддерживать;
— использовать существующие компетенции и специалистов для реализации приложений на новых платформах.
Так как языков программирования (и сред) сейчас наплодилось очень много (и специалистов, владеющих этими языками), то и инструментов для кросс-платформенной разработки существует изрядное количество. Мы в качестве примера остановимся на популярных в наших краях PhoneGap, Xamarin, React Native и Qt.
Теперь можно поговорить и о мифах.
Самый частый миф, будоражащий умы начинающих девелоперов, связан с верой в сверхалгоритмы (и сверхпрограммистов, их создавших), которые волшебным образом превращают кросс-платформенные приложения в нативные. Что-то в духе «преобразования кода JavaScript в Swift и дальнейшая компиляция уже Swift-приложения». Этот миф подогревают и сами разработчики кросс-платформенных инструментов, обещая на выходе создание «нативных приложений». И не то чтобы кто-то здесь лукавил, но богатая фантазия и непонимание базовых механизмов иногда наводят разработчиков на мысли о шаманских приемах.
Главный принцип, лежащий в основе кросс-платформенных решений, — разделение кода на две части:
Для того чтобы связывать между собой мир «нативный» и мир «кросс-платформенный», необходимо использовать специальный **мост (bridge)**, именно он и определяет возможности и ограничения кросс-платформенных фреймворков.
При использовании bridge производительность всегда снижается за счет преобразования данных между «мирами», а также конвертации вызовов API и библиотек.
Итак, все кросс-платформенные приложения обязаны иметь нативную часть, иначе операционная система просто не сможет их запустить. Поэтому давай рассмотрим подробнее, какие системные API и механизмы предоставляются самими iOS, Android и Windows. Переходим к следующему мифу.
Итак, у нас есть кросс-платформенная часть приложения, живущая в виртуальном окружении и взаимодействующая с операционной системой через инфраструктуру фреймворка и мост.
Все операционные системы: iOS, Android и Windows UWP — предоставляют доступ к следующим подсистемам (наборы системных API):
Кросс-платформенные приложения имеют нативную часть и такой же полный доступ к системным API, что и «нативные» приложения. Разница в том, что вызов системного метода идет через мост и инфраструктуру фреймворка:
WebView — приложение живет в своем веб-браузере по аналогии с одностраничным веб-сайтом. Нет доступа к нативным контролам (кнопки, списки и прочее), все основано на HTML/CSS/JavaScript. С другой стороны, веб-разработчик почувствует себя как рыба в воде.
JavaScript-движки стали популярны относительно недавно, так как в iOS подобный механизм был добавлен только в версии 7.0. Из особенностей стоит учитывать необходимость сериализации в JSON сложных структур данных, передаваемых между средами JavaScript и Native. Если коротко описать подобный класс решений, то в JavaScript-среде выполняется JS-код, управляющий нативным приложением.
OpenGL ES и DirectX являются подсистемами низкого уровня и используются для отрисовки пользовательского интерфейса в играх и, например, Qt/QML. То есть при использовании OpenGL/DirectX разработчики сами рисуют контролы и анимации, которые могут быть лишь похожи на нативные. С другой стороны, это подсистема низкого уровня с очень высокой производительностью, поэтому она используется и в кросс-платформенных игровых движках.
Все кросс-платформенные приложения имеют нативную часть, а следовательно, потенциально такой же полный доступ к системным API, что и «нативные». Также кросс-платформенные приложения собираются и упаковываются «нативными» инструментами в «нативные» установочные пакеты. Ключевой вопрос — как организовано взаимодействие между кросс-платформенной частью и нативной. Например, внутри WebView или с помощью Open GL ES / DirectX нет возможности создать пользовательский интерфейс с полностью нативным look’n’feel, но при этом есть полный доступ к GPS, Push-уведомлениям и другой функциональности. А код на JavaScript или C# вполне свободно может управлять нативным приложением и его поведением, обеспечивая полностью нативный look’n’feel.
Если резюмировать — то да, «ненативно» с точки зрения используемых инструментов разработки (не от Apple, Google). Но приложение может быть полностью нативным с точки зрения доступа к системным API и обеспечивать полностью нативный внешний вид и поведение. А мы движемся к следующему мифу.
Здесь стоит понимать, что нативные API по умолчанию костылями не считаются (хотя и здесь есть разные мнения), поэтому все негодование направлено на кросс-платформенную часть. Очевидно, что исполняющую среду (например, WebView, JavaScript-движок или Mono) костылем тоже назвать сложно — взрослые зрелые решения с длительной историей.
Похоже, что костылем называют то, как кросс-платформенная часть интегрируется с нативной. Чтобы лучше понять, как работают различные фреймворки, мы на примере PhoneGap, Xamarin, Qt и React Native рассмотрим те механизмы операционных систем, которые используются для связывания кросс-платформенной и «нативной» частей.
Начнем мы с PhoneGap. Ниже представлена верхнеуровневая архитектура приложения на базе этого фреймворка.
Приложение на PhoneGap — это по факту нативное приложение, которое в качестве единственного UI-контрола отображает WebView. Именно через него и идет взаимодействие с нативной частью. Все стандартные WebView в iOS, Android и Windows UWP поддерживают возможность добавить свои нативные обработчики для JS-свойств и методов. При этом JS-код живет в своей изолированной среде и ничего не знает о нативной части — просто дергает нужные JS-методы или меняет нужные JS-свойства. Все внутри стандартного вебовского DOM, в который просто добавляются новые элементы, связанные с нативной реализацией.
Далее рассмотрим React Native.
При создании приложений на React Native разработчику практически всегда будет необходимо реализовывать нативную часть на Objective-C, Java или C#, а само управление нативным приложением будет идти из JavaScript. По факту JavaScript-движок — это элемент WebView, который доступен отдельно. Взаимодействие идет через такой же JS-мост, как и в случае с PhoneGap. Однако в React Native JS-код управляет не вебовским DOM-деревом, а нативным приложением.
Необходимо учитывать, что из-за ограничений iOS (нет возможности реализовать JIT) код JavaScript на лету интерпретируется, а не компилируется. В целом это не особо сказывается на производительности в реальных приложениях, но помнить об этом стоит.
Теперь рассмотрим классический Xamarin.iOS и Xamarin.Android, так как Xamarin.Forms (поддерживающий Windows UWP) — это надстройка над ними.
Xamarin использует библиотеку Mono для взаимодействия с целевой операционной системой, которая позволяет вызывать нативный код с помощью механизма [P/Invoke](https://en.wikipedia.org/wiki/Platform_Invocation_Services). Он же задействуется и для общения с нативными API в iOS/Android. То есть для всех публичных нативных API-методов создаются обертки на C#, которые, в свою очередь, вызывают системные API. Таким образом, из Xamarin-приложения можно обращаться ко всем системным API.
И в завершение рассмотрим Qt, так как о нем появляется много вопросов от опытных разработчиков.
Qt — «вещь в себе», в этом есть и плюсы, и ограничения. Библиотеки Qt просто подключаются к системным API на C++, которые есть во всех операционных системах. Для отрисовки пользовательского интерфейса используются механизмы низкого уровня, но свой графический движок, поддерживающий стилизации «под нативку». При этом на Android приходится обращаться к Java API через специальный мост (JNI bridge), а для Windows UWP использовать конвертер вызовов Open GL ES в DirectX, так как Open GL недоступен для UWP.
Подведем итог: все кросс-платформенные фреймворки используют стандартные нативные возможности операционных систем, являются зрелыми, создаются опытными командами и сообществом open source при поддержке гигантов IT-индустрии. И наконец, пришло время для самого «сильного» аргумента.
Важный козырь, которым любят пользоваться в спорах о кросс-платформенных фреймворках, — низкая производительность. Опять же, смотря что с чем сравнивать и в каких попугаях считать.
Напомним, что особенность кросс-платформенных приложений заключается в параллельном существовании двух миров, связанных мостом:
Таким образом, при сравнении производительности надо учитывать скорость работы:
Если набрать в поисковике, например, react native vs swift performance, то можно посмотреть множество различных тестов, и во многих из них отмечается, что производительность резко падает при активном использовании моста, включая активное манипулирование UI из кросс-платформенного кода. Для Xamarin ситуация выглядит таким же образом — кросс-платформенная часть очень быстра и сопоставима с нативной в обработке данных, однако при использовании моста может падать производительность. Qt вообще работает на уровне С++, который быстр сам по себе. Если же рассматривать решения на базе PhoneGap, то здесь производительность будет сильно зависеть от WebView, но все же не следует активно менять UI в JavaScript-коде или проводить научные вычисления.
Медленно? Да, возможны падения производительности при неумелом взаимодействии с операционной системой через мост. Однако сами по себе кросс-платформенные миры такие же быстрые, как и нативные.
Сегодня мы рассмотрели устройство популярных кросс-платформенных мобильных фреймворков и разобрали основные мифы, которыми они окружены.
Оставайся на связи и пиши вопросы в комментариях!
Вячеслав Черников — руководитель отдела разработки компании Binwell. В прошлом — один из Nokia Champion и Qt Certified Specialist, в настоящее время — специалист по платформам Xamarin и Azure. В сферу mobile пришел в 2005 году, с 2008 года занимается разработкой мобильных приложений: начинал с Symbian, Maemo, Meego, Windows Mobile, потом перешел на iOS, Android и Windows Phone.
Статьи Вячеслава вы также можете прочитать в блоге на Medium.
Напоминаем, что это полная версия статьи из журнала Хакер.
Примечание: мы продолжаем серию публикаций полных версий статей из журнала Хакер. Орфография и пунктуация автора сохранены.
Передаю слово автору.
Одни разработчики ждут от кросс-платформенных фреймворков решения всех своих жизненных проблем, другие же воспринимают их в штыки. В обоих «враждующих лагерях» есть свои заблуждения, вызванные непониманием того, как и что работает. Это подливает масла в огонь, так как вместо технических доводов в ход идут эмоции.
Также среди разработчиков, особенно начинающих, существует множество мифов о кросс-платформенных мобильных фреймворках. В нашей статье мы разберем самые популярные из них. Но для начала посмотрим на мобильную разработку глазами бизнеса, дающего деньги на весь айтишный блек-джек.
Зачем нужны кросс-платформенные инструменты?
Исторически на рынке компьютеров всегда была конкуренция, и каждый производитель предоставлял оптимальный набор так называемых нативных (родных) инструментов для разработки приложений под свои операционные системы и устройства.
Нативные инструменты = предоставляются владельцем экосистемы.
Все остальные признаки «нативности» ВТОРИЧНЫ — поведение и интерфейс приложений, доступ к возможностям ОС, производительность и прочее.
К тому же практически всегда оказывалось, что нативные инструменты несовместимы друг с другом не только на уровне языков разработки, принятых соглашений и архитектур, но и на уровне механизмов работы с операционной системой и библиотеками. В результате для реализации одних и тех же алгоритмов и интерфейсов требовалось написать приложение для нескольких сред на разных языках программирования, а потом его поддерживать из расчета «одна команда на платформу». При этом возможности и внешний вид приложений на разных платформах практически всегда идентичны на 90%. Сравни ради интереса реализацию любимых программ для iOS и Android.
Второй важный момент — наличие необходимых знаний и опыта внутри команды: если их нет, то потребуется время на обучение.
Для того чтобы решить обе эти проблемы, на рынке уже давно появились инструменты кросс-платформенной разработки (не только mobile), предлагающие:
— максимизировать общую базу кода на едином языке программирования, чтобы продукт было проще разрабатывать и поддерживать;
— использовать существующие компетенции и специалистов для реализации приложений на новых платформах.
Так как языков программирования (и сред) сейчас наплодилось очень много (и специалистов, владеющих этими языками), то и инструментов для кросс-платформенной разработки существует изрядное количество. Мы в качестве примера остановимся на популярных в наших краях PhoneGap, Xamarin, React Native и Qt.
Теперь можно поговорить и о мифах.
Миф 1. Магия
Самый частый миф, будоражащий умы начинающих девелоперов, связан с верой в сверхалгоритмы (и сверхпрограммистов, их создавших), которые волшебным образом превращают кросс-платформенные приложения в нативные. Что-то в духе «преобразования кода JavaScript в Swift и дальнейшая компиляция уже Swift-приложения». Этот миф подогревают и сами разработчики кросс-платформенных инструментов, обещая на выходе создание «нативных приложений». И не то чтобы кто-то здесь лукавил, но богатая фантазия и непонимание базовых механизмов иногда наводят разработчиков на мысли о шаманских приемах.
Главный принцип, лежащий в основе кросс-платформенных решений, — разделение кода на две части:
- кросс-платформенную, живущую в виртуальном окружении и имеющую ограниченный доступ к возможностям целевой платформы через специальный мост;
- нативную, которая обеспечивает инициализацию приложения, управление жизненным циклом ключевых объектов и имеет полный доступ к системным API.
Для того чтобы связывать между собой мир «нативный» и мир «кросс-платформенный», необходимо использовать специальный **мост (bridge)**, именно он и определяет возможности и ограничения кросс-платформенных фреймворков.
При использовании bridge производительность всегда снижается за счет преобразования данных между «мирами», а также конвертации вызовов API и библиотек.
Итак, все кросс-платформенные приложения обязаны иметь нативную часть, иначе операционная система просто не сможет их запустить. Поэтому давай рассмотрим подробнее, какие системные API и механизмы предоставляются самими iOS, Android и Windows. Переходим к следующему мифу.
Миф 2. Ненативно!
Итак, у нас есть кросс-платформенная часть приложения, живущая в виртуальном окружении и взаимодействующая с операционной системой через инфраструктуру фреймворка и мост.
Все операционные системы: iOS, Android и Windows UWP — предоставляют доступ к следующим подсистемам (наборы системных API):
- WebView (встроенный в приложение веб-браузер) используется в гибридных приложениях на базе PhoneGap и фактически выступает средой выполнения локального веб-сайта;
- JavaScript-движки используются в React Native и аналогах для быстрого выполнения JS-кода и обмена данными между Native и JS;
- OpenGL ES (или DirectX) используется в игровых движках и приложениях на Qt/QML или аналогах для отрисовки интерфейса;
- UI-подсистема отвечает за нативный пользовательский интерфейс приложения, что актуально для React Native и Xamarin.
Кросс-платформенные приложения имеют нативную часть и такой же полный доступ к системным API, что и «нативные» приложения. Разница в том, что вызов системного метода идет через мост и инфраструктуру фреймворка:
WebView — приложение живет в своем веб-браузере по аналогии с одностраничным веб-сайтом. Нет доступа к нативным контролам (кнопки, списки и прочее), все основано на HTML/CSS/JavaScript. С другой стороны, веб-разработчик почувствует себя как рыба в воде.
JavaScript-движки стали популярны относительно недавно, так как в iOS подобный механизм был добавлен только в версии 7.0. Из особенностей стоит учитывать необходимость сериализации в JSON сложных структур данных, передаваемых между средами JavaScript и Native. Если коротко описать подобный класс решений, то в JavaScript-среде выполняется JS-код, управляющий нативным приложением.
OpenGL ES и DirectX являются подсистемами низкого уровня и используются для отрисовки пользовательского интерфейса в играх и, например, Qt/QML. То есть при использовании OpenGL/DirectX разработчики сами рисуют контролы и анимации, которые могут быть лишь похожи на нативные. С другой стороны, это подсистема низкого уровня с очень высокой производительностью, поэтому она используется и в кросс-платформенных игровых движках.
Все кросс-платформенные приложения имеют нативную часть, а следовательно, потенциально такой же полный доступ к системным API, что и «нативные». Также кросс-платформенные приложения собираются и упаковываются «нативными» инструментами в «нативные» установочные пакеты. Ключевой вопрос — как организовано взаимодействие между кросс-платформенной частью и нативной. Например, внутри WebView или с помощью Open GL ES / DirectX нет возможности создать пользовательский интерфейс с полностью нативным look’n’feel, но при этом есть полный доступ к GPS, Push-уведомлениям и другой функциональности. А код на JavaScript или C# вполне свободно может управлять нативным приложением и его поведением, обеспечивая полностью нативный look’n’feel.
Если резюмировать — то да, «ненативно» с точки зрения используемых инструментов разработки (не от Apple, Google). Но приложение может быть полностью нативным с точки зрения доступа к системным API и обеспечивать полностью нативный внешний вид и поведение. А мы движемся к следующему мифу.
Миф 3. Костыль на костыле
Здесь стоит понимать, что нативные API по умолчанию костылями не считаются (хотя и здесь есть разные мнения), поэтому все негодование направлено на кросс-платформенную часть. Очевидно, что исполняющую среду (например, WebView, JavaScript-движок или Mono) костылем тоже назвать сложно — взрослые зрелые решения с длительной историей.
Похоже, что костылем называют то, как кросс-платформенная часть интегрируется с нативной. Чтобы лучше понять, как работают различные фреймворки, мы на примере PhoneGap, Xamarin, Qt и React Native рассмотрим те механизмы операционных систем, которые используются для связывания кросс-платформенной и «нативной» частей.
Начнем мы с PhoneGap. Ниже представлена верхнеуровневая архитектура приложения на базе этого фреймворка.
Приложение на PhoneGap — это по факту нативное приложение, которое в качестве единственного UI-контрола отображает WebView. Именно через него и идет взаимодействие с нативной частью. Все стандартные WebView в iOS, Android и Windows UWP поддерживают возможность добавить свои нативные обработчики для JS-свойств и методов. При этом JS-код живет в своей изолированной среде и ничего не знает о нативной части — просто дергает нужные JS-методы или меняет нужные JS-свойства. Все внутри стандартного вебовского DOM, в который просто добавляются новые элементы, связанные с нативной реализацией.
Далее рассмотрим React Native.
При создании приложений на React Native разработчику практически всегда будет необходимо реализовывать нативную часть на Objective-C, Java или C#, а само управление нативным приложением будет идти из JavaScript. По факту JavaScript-движок — это элемент WebView, который доступен отдельно. Взаимодействие идет через такой же JS-мост, как и в случае с PhoneGap. Однако в React Native JS-код управляет не вебовским DOM-деревом, а нативным приложением.
Необходимо учитывать, что из-за ограничений iOS (нет возможности реализовать JIT) код JavaScript на лету интерпретируется, а не компилируется. В целом это не особо сказывается на производительности в реальных приложениях, но помнить об этом стоит.
Теперь рассмотрим классический Xamarin.iOS и Xamarin.Android, так как Xamarin.Forms (поддерживающий Windows UWP) — это надстройка над ними.
Xamarin использует библиотеку Mono для взаимодействия с целевой операционной системой, которая позволяет вызывать нативный код с помощью механизма [P/Invoke](https://en.wikipedia.org/wiki/Platform_Invocation_Services). Он же задействуется и для общения с нативными API в iOS/Android. То есть для всех публичных нативных API-методов создаются обертки на C#, которые, в свою очередь, вызывают системные API. Таким образом, из Xamarin-приложения можно обращаться ко всем системным API.
И в завершение рассмотрим Qt, так как о нем появляется много вопросов от опытных разработчиков.
Qt — «вещь в себе», в этом есть и плюсы, и ограничения. Библиотеки Qt просто подключаются к системным API на C++, которые есть во всех операционных системах. Для отрисовки пользовательского интерфейса используются механизмы низкого уровня, но свой графический движок, поддерживающий стилизации «под нативку». При этом на Android приходится обращаться к Java API через специальный мост (JNI bridge), а для Windows UWP использовать конвертер вызовов Open GL ES в DirectX, так как Open GL недоступен для UWP.
Подведем итог: все кросс-платформенные фреймворки используют стандартные нативные возможности операционных систем, являются зрелыми, создаются опытными командами и сообществом open source при поддержке гигантов IT-индустрии. И наконец, пришло время для самого «сильного» аргумента.
Миф 4. Медленно
Важный козырь, которым любят пользоваться в спорах о кросс-платформенных фреймворках, — низкая производительность. Опять же, смотря что с чем сравнивать и в каких попугаях считать.
Напомним, что особенность кросс-платформенных приложений заключается в параллельном существовании двух миров, связанных мостом:
- PhoneGap: HTML/JS и Native Java / Objective-C / C#;
- React Native: JS и Native Java / Objective-C / C#;
- Xamarin: Mono и Native Java / Objective-C;
- Qt: С++ и Native Java / Objective-C.
Таким образом, при сравнении производительности надо учитывать скорость работы:
- кросс-платформенной части;
- нативной части;
- моста.
Если набрать в поисковике, например, react native vs swift performance, то можно посмотреть множество различных тестов, и во многих из них отмечается, что производительность резко падает при активном использовании моста, включая активное манипулирование UI из кросс-платформенного кода. Для Xamarin ситуация выглядит таким же образом — кросс-платформенная часть очень быстра и сопоставима с нативной в обработке данных, однако при использовании моста может падать производительность. Qt вообще работает на уровне С++, который быстр сам по себе. Если же рассматривать решения на базе PhoneGap, то здесь производительность будет сильно зависеть от WebView, но все же не следует активно менять UI в JavaScript-коде или проводить научные вычисления.
Медленно? Да, возможны падения производительности при неумелом взаимодействии с операционной системой через мост. Однако сами по себе кросс-платформенные миры такие же быстрые, как и нативные.
Заключение
Сегодня мы рассмотрели устройство популярных кросс-платформенных мобильных фреймворков и разобрали основные мифы, которыми они окружены.
Оставайся на связи и пиши вопросы в комментариях!
Об авторе
Вячеслав Черников — руководитель отдела разработки компании Binwell. В прошлом — один из Nokia Champion и Qt Certified Specialist, в настоящее время — специалист по платформам Xamarin и Azure. В сферу mobile пришел в 2005 году, с 2008 года занимается разработкой мобильных приложений: начинал с Symbian, Maemo, Meego, Windows Mobile, потом перешел на iOS, Android и Windows Phone. Статьи Вячеслава вы также можете прочитать в блоге на Medium.
Напоминаем, что это полная версия статьи из журнала Хакер.
Комментарии (27)
savostin
13.03.2018 10:45+1А может уже пора «самым гигантским гигантам» Microsoft, Apple и Google (кстати, про Linux что-то в статье ни слова, его-то почему забыли? или мы про мобильную разработку сейчас?) наконец договориться на самом «низком» уровне и прийти к одному API высокого уровня? </розовые очки>
devious
13.03.2018 11:35Ну это подход «технарей», а миром ИТ (как и многими другими) правят деньги. Да и платформы все разные со своими особенностями. Да и «зачем»?
Free_ze
13.03.2018 12:35В *nix-мирке и так есть какой-никакой POSIX, остальные умышленно делают vendor-lock и кроссплатформенные инструменты для них — заноза, а не панацея. Да и сама стандартизация — это тот еще тормоз прогресса.
devious
13.03.2018 13:00А причем здесь кроссплатформенные инструменты? У них свои бизнес-задачи и своя доля рынка. Это не 100% замена стандартных инструментов от самих владельцев экосистем
Free_ze
13.03.2018 13:25А причем здесь кроссплатформенные инструменты? У них свои бизнес-задачи
Задача одна — дешево и перспективно писать прикладное ПО.
Это не 100% замена стандартных инструментов от самих владельцев экосистем
… Другое дело, что разные подходы (кроссплатформенность на уровне исходного кода, промежуточного представления или системного API) имеют свои недостатки, поэтому приходится балансировать между различными решениями.devious
13.03.2018 14:54Ведь вопрос же не в инструменте, а в команде, которая этим инструментом умеет пользоваться. Так что «занозой» что-то может быть только в том случае, если оно используется не по назначения или неопытной командой.
Кстати, POSIX и в Windows есть (сам не проверял, но тема старая): en.wikipedia.org/wiki/Windows_Services_for_UNIXFree_ze
13.03.2018 15:12Про «занозы» говорилось в комментарии про вендоров, а не про прикладных программистов)
Кстати, POSIX и в Windows есть
Подобных решений существует немало, как от MS, так и сторонних разработчиков, но все равно же это больше боль и страдания в попытке перенести непереносимое с *nix на Windows (те же Git, Docker), чем полноценные целевые платформы.
FirExpl
13.03.2018 10:48Медленно? Да, возможны падения производительности при неумелом взаимодействии с операционной системой через мост. Однако сами по себе кросс-платформенные миры такие же быстрые, как и нативные.
Я вам больше скажу, возможны падения производительности даже при неумелом использовании нативных компонентов без всяких мостов.
Вот только у меня такой вопрос к статье: а что это у вас за мобильное приложение, которое мало использует этот мост? ИМХО, но 95% того что есть на мобилках (за вычетом игр) — это всякого рода тонкие клиенты, которые так или иначе отображают контент. Т.е. основная работа это отрисовка интерфейса с красивыми анимациями и прочими свистоперделками + активное взаимодействие с сетью. Т.е. именно то, с чем у кроссплатформы проблема, ибо надо пробрасывать вызовы через мост с преобразованием данных. Дальше веселее: предположим у вас приложение, которое должно выполнять приличный кусок бизнес логики на клиенте, вот тут, казалось бы, самое оно для кроссплатформы, но тут мы можем внезапно упереться в повышенное энергопотребление и ограниченные ресурсы мобильной платформы, где каждый процент прироста производительности или экономии памяти может быть существенным, а потому самые «тяжёлые» куски всё равно будут писаться на «нативном» языке, что практически убивает идею кросплатформерной разработки.
В итоге у нас остаются игры, с которыми всё и так понятно, и приложения для которых производительность не очень важна и в целом «и так сойдёт». Другой вопрос, что «и так сойдёт» многих вполне устроит.devious
13.03.2018 11:20Странное ИМХО, если честно.
> Вот только у меня такой вопрос к статье: а что это у вас за мобильное приложение, которое мало использует этот мост?
Обычные приложения ;) Вы хоть раз писали реальные кроссплатформенные программы?
Открою вам маленький секрет. В реальных сценариях приложение ЖДЕТ и НИЧЕГО НЕ ДЕЛАЕТ основную часть времени, эпизодически реагируя на действия пользователя. И вот в этих эпизодах иногда возникает потребность обратиться к платформе — только здесь задействуется мост. И только здесь может чуть-чуть больше задействоваться процессор и как следствие батарейка. А игры тут вообще при чем? ;)FirExpl
13.03.2018 12:18+1Открою вам маленький секрет. В реальных сценариях приложение ЖДЕТ и НИЧЕГО НЕ ДЕЛАЕТ основную часть времени, эпизодически реагируя на действия пользователя.
Открою вам маленький секрет: атом на 99% (грубо) состоит из пустоты. Значит и вы на 99% состоите из пустоты, и по большому счёту вас нет. Извините, не удержался.
По сути вопроса: в реальном мире, когда приложение находится на экране мобильного, пользователь, обычно, с ним активно взаимодействует, ну там скроллит, свайпит, вот это вот всё. При этом очень много разных элементов интерфейса нужно перерисовать, предварительно рассчитав новые позиции и размеры, а так же подтянув необходимые для отображения данные. И крайне желательно, чтобы это всё не тормозило, любят пользователи чтобы всё было плавно и не приходилось ждать следующего экрана по 15 минут. И вот тут даже с нативным кодом бывает приходится помучиться, ибо когда у вас на экране много всего разного, и картинки, и текст, и тенюшки повсюду, и кнопочки с блюром, то мобильное железо может и не справиться и приходится делать разные интересные вещи. Вот сможете ли вы сделать какие-то хитрые оптимизации на своём кроссплатформерном фреймворке не залезая в нативный код? А если вам туда регулярно приходится залезать, то стоило ли вообще тогда его использовать?
И вот в этих эпизодах иногда возникает потребность обратиться к платформе — только здесь задействуется мост. И только здесь может чуть-чуть больше задействоваться процессор и как следствие батарейка.
Ага, я прям вспоминаю старое приложение фейсбука и рекомендации по использованию браузера вместо него. Вот где было торжество кроссплатформерности и «чуть-чуть больше» задействованных процессора и батарейки.
А игры тут вообще при чем? ;)
Ну, наверно при том, что это, всего лишь, самый успешный и распространённый класс кроссплатформерных мобильных приложений.devious
13.03.2018 12:23-2Что-то где-то с матчастью пробелы:
> При этом очень много разных элементов интерфейса нужно перерисовать, предварительно рассчитав новые позиции и размеры, а так же подтянув необходимые для отображения данные.
Это все обычно за вас делает ОС, а не ваш код, не важно на каком языке. Если конечно вы свои методы отрисовки и обработки скролла сделали… То это ваши проблемы.
> Ага, я прям вспоминаю старое приложение фейсбука и рекомендации по использованию браузера вместо него.
Если вы следили за развитием событий, то приложение фейсбук было сделано на HTML5 и потом сам Цукерберг признал это ошибкой.
Так в чем ваш вопрос? Я только понял, что реальной разработкой мобильных приложений, тем более кроссплатформенной, вы не занимались.FirExpl
13.03.2018 13:12+1Это все обычно за вас делает ОС, а не ваш код, не важно на каком языке.
Система за вас не делает ничего. Вы вправе доверить сие действие той или иной библиотеке, в том числе системной, однако это вовсе не означает, что она делает это оптимальным, для вашего конкретного случая, образом. Одно только количество альтернатив для NSAutoLayout говорит о многом.
Если конечно вы свои методы отрисовки и обработки скролла сделали… То это ваши проблемы.
В том-то и фишка, что это будут именно что МОИ проблемы, как разработчика. А не того эффективного менеджера, который протолкнул использование кроссплатформерного фреймворка.
Если вы следили за развитием событий, то приложение фейсбук было сделано на HTML5 и потом сам Цукерберг признал это ошибкой.
Т.е. фейсбук сделал кроссплатформерное приложение, а потом признал это ошибкой и переписал на натив, я вроде нигде не ошибся?
Так в чем ваш вопрос?
Вопрос был в оригинальном комментарии. Что у вас за мобильные приложения, которые «не взаимодействуют активно с ОС»? Они простые числа в фоне вычисляют?
Я только понял, что реальной разработкой мобильных приложений, тем более кроссплатформенной, вы не занимались.
Аргумент. Но нет, занимался и занимаюсь.devious
13.03.2018 14:25Я правильно понимаю, что вас в статье напряг момент о том, что можно с меньше или большей интенсивностью взаимодействовать с платформой через мост? То есть о том, что есть большой класс задач, которые могут быть выполенены без взаимодействия с нативкой? Парсинг, хранение и обработка данных, бизнес-логика поведения приложения (viewmodels/controllers, плюс сервисы). Это именно то, что не требует постоянной (по каждому чиху) интеграции с нативкой и живет себе комфортно в виртуальной среде, лишь изредка дергая нужные методы из операционной системы.
Или это ваши общие доводы в пользу того, что кроссплатформа должна умереть, ибо это «тормоза и костыли»? Плюс вы почему-то сваливаете в кучу все кроссплатформенные инструменты и приравниваете провал Facebook с HTML5 с проектами на Xamarin или ReactNative.
Free_ze
13.03.2018 12:41приложение, которое должно выполнять приличный кусок бизнес логики на клиенте… а потому самые «тяжёлые» куски всё равно будут писаться на «нативном» языке, что практически убивает идею кросплатформерной разработки.
Если этим нативным языком будет C, который поддерживают все платформы, то почему же убивает? Бизнес-логика — это штука в себе, платформенных зависимостей не требует.
gvp1965
13.03.2018 17:40Спасибо автору. Давно ждал. Немного «подредактировать» Заключение, немного сократить основное «тело», — и рекомендую своему начинающему руководителю для принятия решения выбора.
devious
13.03.2018 18:49Если напишите, что подредактировать и сократить — выложу обновленную версию у нас в Medium :)
Neikist
13.03.2018 20:09Совершенно не понимаю этой современной тенденции на вебовость и кроссплатформенность. Уже пришлось отказаться что от нового скайпа на десктопе, что под андроид. Из текстовых редакторов видимо придется серьезней вим осваивать, apple music под андроид тоже видимо кто то вебанутый пилил, терплю только из за широты ассортимента, иначе бы на любимой яндекс музыке оставался. Вообще замечаю что единицами приложений можно пользоваться из тех что сделаны на веб-технологиях. Даже и вспомнить то таких с ходу не могу. Да даже 1с свою платформу выпустила кроме десктопов еще и под мобилки. Естественно с кучей ожидаемых проблем. Правда они хотя бы судя по всему что то нативное использовали для разработки этой самой платформы.
Whuthering
13.03.2018 20:35Совершенно не понимаю этой современной тенденции на вебовость и кроссплатформенность.
Сейчас на рынке есть 3 распространенные мобильные платформы, и 3 распространенные десктопные платформы. Ничего личного, просто деньги — пилить 1 разработку + небольшие вариации (платформенно-специфичные вещи + адаптивный дизайн), или пилить 6 разных продуктов.
Веб-технологии в данном случае доступны уже «здесь и сейчас», и есть огромное количество специалистов, умеющих работать с ними.
По широте поддерживаемых платформ и удобству к ним подбирается только Qt (но там C++, хороших разработчиков на котором найти сложнее и дороже, чем HTML/JS), и Avalonia (но она еще слишком молода).
EnChikiben
А flutter почему не рассмотрели?
Atreides07
flutter на хайпе но еще сырой и плохо развит инструментарий и тем более вряд ли можно считать его популярным по сравнению с ReactNative или Xamarin (достаточно легко в этом убедиться если сделать поиск на любом сайте с работами). Но относительно статьи можете считать что аналогом flutter является React Native.
progn
это вовсе не аналог react native, flutter рисует интерфейс и все анимации сам, поэтому в данной статье он скорее похож на подход Qt/QML.
devious
Честно говоря, не ковырял устройство flutter, но по первому впечатлению — это верхеуровневый фреймворк (Qt низкоуровневый), работающий поверх верхеуровневых системных API для Objective C и Java. Но целом да, проблемы будут примерно те же, что с Qt/QML, но только без танцев с wrappers при доступе к нативке. Скорее всего flutter получит свою нишу для несложных информационных проектов.
progn
высокоуровневость / низкоуровневость видимо отностительна. Когда я последний раз работал с Qt (много лет назад, еще без QML) он был более чем высокоуровневый, вполне себе аналог C# с WindowsForms с кучей своих высокоуровневых либ для работы с сетью, данными и тд. Они даже свой препроцесор запилили, чтобы упростить многие вещи в С++.
Я посмотрел немного Flutter, штука забавная, в принципе там можно и с нейтив взаимодействовать достаточно плотно, удобнее чем в ReactNative и потенциально нет проблем с многопоточностью. Минусы: экзотический язык, он сам все рисует, даже системные эффекты, поэтому не будет идеального look and feel, минус также и компания разработчик, сейчас для Google это второстепенный проект, который может внезапно закрыться, хоть и ходят слухи о некой новой ОС где возможно Dart и Flutter могут играть значительную роль
devious
А почему его необходимо рассматривать? Он пока сырой и не пригоден к реальным проектам, в отличие от рассмотренных в статье фреймворков. Оно даже ReactNative тоже сыроват еще.