Что такое кросс платформа
Что такое кроссплатформенность
16 ноября 2017 Опубликовано в разделах: Азбука терминов. 10601
На что влияет кроссплатформенность сайта
На смартфоне, работающем на базе Android. аналогичная страница выглядит так:
Ozon.ru одинаково выглядит и работает на Windows и Android. Это пример кроссплатформенного ресурса.
Учитывайте при верстке, что посетители заходят с разных устройств и не забывайте следить, чтобы:
Как достигается кроссплатформенность сайта
Кроссплатформенность достигается несколькими путями:
Используйте кроссплатформенность языков программирования
Кроссплатформенные языки типа C, С++, Free Pascal имеют специальные механизмы для адаптации кода под другую платформу. Это очень удобно, поскольку требует переписывания не всего кода, а лишь его фрагментов.
Сделайте кроссплатформенный интерфейс
При работе с устройствами на разных платформах стандартные элементы интерфейса могут искажаться, поэтому используется либо стандартная схема расстановки элементов управления, либо самоадаптирующийся интерфейс.
Ведите разработку в кроссплатформенных средах
Адаптируйте код
Если у вас есть нескольких версий одного кода, адаптированных под разные платформы, время на обработку сократится. Вы можете менять только необходимые элементы кода. Например, браузер Mozilla Firefox имеет разные наборы иконок под разные ОС.
Адаптивный веб-дизайн
Это автоматическая адаптация сайта под устройства с разным размером экрана. Не нужно разрабатывать мобильную версию или специальный комплект иконок.
Существует несколько вариантов адаптации:
Плюсы адаптации сайта для SEO:
Adaptivator.ru работает с наиболее популярными моделями гаджетов и помогает адаптировать сайт под их размеры.
Кроссбраузерность сайта
Проверка на кроссплатформенность
Тесты на кроссплатформенность показывают, как отображается сайт на разных устройствах и указывает на ошибки в коде.
Инструмент Microsoft Expression Web SuperPreview позволяет сравнивать выбранные участки страниц в разных браузерах и операционных системах и показывает различия в отображении элементов анализируемых страниц.
Помимо этого, Microsoft Expression Web SuperPreview позволяет сравнивать проект сайта с тем, что получилось в процессе разработки и исправлять обнаруженные ошибки в верстке.
– Широкая семантика.
– Высокий CTR.
– Тщательная минусовка.
– Только целевые заходы.
Кросс-платформенная разработка. Преимущества
Что такое кросс-платформенная разработка?
Эта концепция относится к разработке мобильных приложений, которые могут быть использованы на нескольких мобильных платформах. В деловом мире растет BYOD (Bring Your Own Device) тенденция. BYOD подход применим к сотрудникам, приносящим свое личное мобильное устройство на рабочее место, вместо использования настольных компьютеров или предоставленных компанией мобильных устройств для доступа к приложениям и корпоративным данным. Из-за BYOD компаниям стало необходимо разрабатывать собственные мобильные приложения и отправлять их на множество различных устройств, которые используют разные операционные системы.
Однако, кросс-платформенная разработка имеет несколько недостатков. Во-первых, мобильные операционные системы часто обновляются, а это значит, что приложения должны быть также обновлены для совместимости с новой системой. Во-вторых, рендеринг при кросс-платформенной мобильной разработке может занимать больше времени, так как каждой операционной системы требуется отдельная среда исполнения.
В идеальном сценарии эти приложения работают в нескольких ОС с одной кодовой базой.
Существует 2 типа кросс-платформенных приложений:
1. Собственные (Xamarin, Marmelade)
2. Гибрид ‘HTML5’ (ReactNative, Mobile Angular UI)
Собственные кросс-платформенные приложения
Однако можно использовать API (Application Programming Interface), предоставляемые собственным SDK, на других языках программирования, которые не поддерживаются поставщиком ОС. Так создаются ”кросс-платформенные» приложения.
Как правило, сторонний поставщик выбирает язык программирования и создает единый API поверх пакетов SDK, предоставляемых различными поставщиками ОС. Используя этот унифицированный API, можно поддерживать несколько операционных систем с единой кодовой базой. Сторонний поставщик предоставляет набор инструментов, которые обрабатывают процесс создания собственного пакета приложений для iOS и Android из одной кросс-платформенной кодовой базы.
Поскольку конечное приложение по-прежнему использует собственные API, кросс-платформенные приложения могут достичь хорошей производительности без видимого отставания для пользователя.
Гибрид ‘HTML5’ с кросс-платформенных приложений
Большинство мобильных приложений во многом зависят от серверных веб-служб. Грубо говоря, в мобильных приложениях, особенно в области автоматизации бизнес-процессов, почти 60% кода связаны с взаимодействием с сервером. Это огромный выигрыш, так как код пишется только один раз.
iOS, Android и Windows Phone имеют очень продвинутый компонент браузера в своих SDK. Например, в некоторых случаях, используя компонент WebView, программисты могут использовать стандартные веб-технологии HTML5 для разработки и программирования частей своего приложения. Таким образом, приложение состоит по крайней мере из собственного фрейма и HTML/JavaScript, выполняемых в WebView, поэтому они называются “гибридными”. Функции приложения, которым требуются входы датчиков, такие как геолокация, камера или функции более низкого уровня, такие как доступ к файловой системе, обычно используют некоторый мост JavaScript-native, предоставляемый гибридной платформой приложений.
Выгоды внедрения кросс-платформенных приложений
· При тщательном планировании, около 50-80% кода можно использовать повторно для реализации на разных платформах
· Такая разработка имеет больше преимуществ в обслуживании
· Модульные тесты пишутся один раз для общего кода
· Не нужно изучать специфические языки программирования, а можно использовать те, которые уже имеются в арсенале разработчиков
· Кросс-платформенные приложения идеально подходят для автоматизации бизнес-процессов, где время развертывания и эффективность использования является критичными вопросами
Как выбрать мобильную кросс-платформу в 2021 году
Новый развивающийся бизнес зачастую в первую очередь ориентируется на мобильные технологии: социальные сети, необанкинговые решения, приложения для электронной коммерции, такси и другие. Новый бизнес ориентирован на экономическую эффективность, поэтому переход на кросс-платформенность для разработки мобильного приложения кажется правильным выбором. Посмотрим, что будет в 2021 году и как выбрать правильную технологию.
Познакомимся с Женей
Евгения — солюшн-архитектор. Она должна решить, как построить новое мобильное приложение для изучения английского языка не носителями: людьми из Турции, Италии или России. Давайте посмотрим, как Женя подходит к этой задаче.
Приложение должно включать в себя богатую анимацию, уметь воспроизводить и записывать аудио, показывать видео с субтитрами, а также статические и динамические изображения.
В компании — владельце приложения также ожидают, что разработкой будет заниматься единая команда — как для Android- и iOS-приложений, чтобы свести к минимуму усилия по передаче знаний и максимизировать скорость команды. В будущем также планируют запустить веб-приложения. А еще в компании хотели бы упростить будущий найм.
Прогрессивные веб-приложения
Женя начинает свои исследования. Она гуглит «мобильные веб-приложения» и находит статью. В ней упоминаются «Прогрессивные веб-приложения» (PWA). Что это такое?
Прогрессивные веб-приложения — это, по сути, веб-сайты, которые используют специальные API для доступа к определенным возможностям устройства. Эти API позволяют получить доступ к памяти на устройстве, интегрируются с Push Notifications (на Android) и, что самое важное, работать в отдельной вкладке браузера. Еще их можно установить на устройство «иконкой», как настоящее приложение. Звучит неплохо! Давайте посмотрим на плюсы и минусы PWA:
Кроссплатформенность — это круто
Ни для кого не секрет, что сегодня мобильные игры очень популярны. Возможность написать одну из таких игр есть у каждого разработчика, даже начинающего. Часто возникает вопрос с выбором платформы. Конечно, хочется, чтобы игра была сразу везде: на iOS и Android, на WP7 и MeeGo, на десктопе и в браузере. И чтобы все это можно было лекго реализовать с помощью бесплатных инструментов.
В этой статье я расскажу вам, как сделать основную часть кода платформонезависимой, а для остального использовать удобные средства разработки для каждой конкретной платформы.
Цель игры, изображенной на рисунке выше — успеть попасть по яблоку, пока оно летит вниз. Со временем количество яблок увеличивается, и не пропускать их становится все сложнее. Яблоки падают под произвольным углом, вращаясь и реалистично отскакивая от границ благодаря физическому движку Box2D. Игра будет запускаться на Android, платформах с поддержкой Qt (Symbian, Maemo, MeeGo, Windows, Linux, Mac OS X) и в браузере Google Chrome.
Выбор удобных инструментов
Так как основную часть кода я буду писать на чистом С++ (почему, читайте в конце статьи), IDE для этого подойдет любая. Я выберу Qt Creator, хотя ничего не мешает мне использовать Microsoft Visual Studio или Eclipse, например.
Для платформы Android я остановлюсь на библиотеке libgdx. С ее помощью легко можно рисовать текстуры, проигрывать звуки и делать другие необходимые вещи.
В качестве инструмента для разработки игры на десктопе я возьму Qt. Я давно знаком с этой библиотекой, и она не перестает меня радовать. При использовании Qt я также получу приятный бонус в виде поддержки мобильных операционных систем Symbian, Maemo и MeeGo.
Также специально для этой статьи я с помощью HTML5, javascript и Google Native Client сделаю так, чтобы игра запускалась в браузере Google Chrome. Я буду использовать HTML5 Canvas и Audio, и вы увидите, насколько это легко и просто.
Реализация логики не сложная, поэтому я не буду писать о ней (желающие могут взглянуть на код). Вместо этого я сконцентрируюсь на том, как заставить игру работать на всех операционных системах.
Абстрагируемся от конечной платформы
Как я уже говорил, основная часть кода будет общей для всех платформ. Назовем ее «движок». Мне нужно будет решить две задачи. Первая — вызов методов движка на каждой платформе:
Для этого движок предоставит платформам следующий интерфейс:
Вызовы обработчиков рисования и ввода на различных платформах будут вызывать методы из класса Application, например, при использовании Qt это будет выглядеть так:
На Android выйдет немного сложнее, потому что из Java нужно попасть в C++:
После этого в C++ вызываются соответствующие методы:
При использовании Native Client в браузере из javascript нельзя напрямую обращаться к С++, вместо этого надо отправлять сообщения модулю, например, строки:
В С++ сообщения анализируются, и в зависимости от содержания вызывается тот или иной метод:
В итоге движку не важно, из какой платформы был вызов, он абстрагировался от этого. Но он знает, что произошло касание экрана в точке (x, y) или пришло время для обработки физики и вывода изображений на экран.
Обратное взаимодействие
Вторая задача — обратное взаимодействие движка с платформой:
Это нужно для того, чтобы движок командовал, когда выводить изображения и текст на экран, проигрывать звук, вибрировать. Для этого все платформы должны реализовать общий интерфейс. Назовем этот интерфейс Platform:
На уровне движка я не привязываюсь ни к какой конкретной платформе, я не загружаю картинки или аудио файлы, вместо этого я использую числовые идентификаторы. Когда я хочу вывести изображение на экран, или проиграть звук, я делаю следующее:
Таким образом движок абстрагируется от деталей реализации различных операций на каждой платформе. Привожу для наглядности диаграмму классов:
Сложно ли все это сделать? Вы убедитесь в том, что нет. Время, конечно, придется потратить, но в большинстве случаев им можно пренебречь в сравнении со временем, потраченным на программирование логики приложения. Я приведу код для платформ Android, Qt и Native Client для каждой необходимой операции:
Рисование изображения, Android (libgdx):
Рисование изображения, Qt:
Рисование изображения, javascript (HTML5 Canvas):
Рисование текста, Android (libgdx):
Рисование текста, Qt:
Рисование текста, javascript (HTML5 Canvas):
Проигрывание звука, Android (libgdx):
Проигрывание звука, Qt:
Проигрывание звука, javascript (HTML5 Audio):
Вибрация, Android(libgdx):
При реализации для Android придется немного повозиться с вызовом java кода из C++ — один раз получить ID нужных java методов:
и потом вызывать их:
Нетривиальная ситуация и с Native Client — нужно отправлять сообщения из С++ кода в javascript:
И в javascript эти сообщения парсить:
Результат
Эта простая игра называется «Поймай яблочко». Предлагаю запустить и попробовать продержаться пару минут, у меня вначале не получалось:
— Native Client версия (убедитесь, что у вас последняя версия браузера Google Chrome, и Native Client включен в about:plugins и about:flags). Размер исполняемого файла nexe — 4.2Мб для 32-битных систем и 4.9Мб для 64-битных, при медленном соединении придется немного подождать;
— Windows версия — для тех, кто не любит Google Chrome.
Игра прекрасно запускается на Android эмуляторе и моем LG Optimus. Та же ситуация с Qt Simulator (скриншот с Nokia N9 в самом начале темы).
Код можно взять тут, я думаю, он может пригодиться кому-нибудь, особенно участки, которые отвечают за связку Java и C++, javascript и C++ (если по этому поводу у вас возникнут вопросы — задавайте, не стесняйтесь, с удовольствием отвечу).
Зачем все это?
Многие из вас подумают, зачем писать велосипед? Если есть Marmalade или Unity, например. Есть, но они стоят денег, да и зачем такие тяжеловесы для простой 2D игрушки? Некоторые говорят также, что Qt заводится на Android и iOS, но на самом деле на Android не очень так заводится, без звука и OpenGL, а на iOS так вообще, только ролики на YouTube. Мне очень нравится Qt, и я надеюсь, что в недалеком будущем приложения для iOS и Android можно будет писать так же просто, как сейчас для MeeGo, но пока лучше пользоваться другими инструментами для этих платформ.
Преимущества
Используя подход, описанный в этой статье, вы не привязаны к платформе, вы можете использовать те инструменты, которые хотите, а в последующем легко их менять. На десктопе — Qt или GTK, на Android — libgdx или AndEngine, на iOS — cocos2d, выбор за вами. Можете вовсе отказаться от движков, используя API, предоставляемое платформой. Большую часть времени вы можете писать и отлаживать код в вашей любимой IDE на великом и могучем C++.
Недостатки
Недостатки, конечно, тоже есть, например, вы не сможете пользоваться готовыми UI компонентами — вам нужно будет реализовать их на C++. Либо выносить UI часть приложения в каждую платформу. Также вам обязательно придется тесно познакомиться с каждой платформой, но как показывает практика, полностью уйти от этого знакомства никогда не удается.
Натив или кроссплатформа? Детальный разбор простым языком
Немного знаний терминологии не повредит, чтобы иметь больше совместного контекста. Постараюсь не быть занудой.
SDK — software development kit — инструментарий разработчика. Говорят например, — AppStore SDK — набор инструментов для реализации платежей и подписок в приложении. Или Android SDK — совокупность более мелких SDK для разработки под всю платформу.
API — это программный интерфейс, (тяжело объяснять простыми словами оказывается). Руль — физический интерфейс к колёсам, коробка передач — к двигателю, мы дергаем за них, чтобы машинерия внутри сделала для нас более сложную работу через простой для восприятия интерфейс. Программные интерфейсы — наборы функций, объектов, используя которые программисты выполняют сложную работу более простыми действиями.
Поскольку сухой разбор преимуществ и недостатков той или иной технологии — пустая трата времени, будем честны, из любой технологии можно сделать какашку и конфетку, вопрос лишь какой ценой, поэтому для развития осознанного понимания, зайдем чуть издалека.
Так или иначе, клиент любого бизнеса, пожелавшего открыть для себя вожделенную айтишечку, доступен через 3 окошка:
Также мы не рассматриваем устройства носимой электроники, интернета вещей, экранов холодильников, различных embedded систем — уж очень они специфичны.
На заре широкого коммерческого успеха мобильных гаджетов, некто по фамилии Джобс, отстаивал идею о том, что персональный смартфон — это всего лишь окошко к всемирной паутине, которое всегда с собой. Круто же звучит! Вот что он говорил:
Полноценный движок Safari уже присутствует внутри iPhone. То есть, вы можете создавать изумительные Web 2.0 и Ajax приложения, которые выглядят и ведут себя так же, как родные программы iPhone. И они способны прекрасно взаимодействовать с его сервисами: звонить, отправлять электронные письма, разыскивать местоположение в Google Maps. И знаете, что? Для этого не нужен SDK! У вас уже все есть для написания невероятных приложений для iPhone, если вы знаете, как создавать программы, используя современные веб-стандарты.
Есть предположение, что изменить взгляд Джобсу помог Джонни Айв, убедив его в том, что устройства эппл без нативных сторонних приложений не будут доступны для создателей контента, плюс от этого платформа потеряет эксклюзивность. В тоже время, в кулуарах Гугл зрел андроид и у менеджмента не было особого мнения на этот счет.
Собственно, к чему эта лирика. Исторически, мы имеем два основных способа доставки приложения пользователю:
-Нативное приложение — созданное с использованием инструментов разработки вендоров: Apple/Google и распространяемое через магазины приложений. Для разработки под Apple актуальны технологии: UIKit, SwiftUI + богатый iOS SDK, язык программирования Swift (и для особых случаев старичок Objective-C)Для Андроид соответственно — Android SDK, Jetpack Compose, языки: Java 8, Kotlin
Веб-приложение, использующее браузер в качестве среды выполнения и ограниченного доступа к ресурсам девайса (я специально не называю веб-приложение сайтом, так мы в терминах отделяем статические странички от динамичных, наполненных различной бизнес-логикой, приложений). К ним же относятся так называемые WebView — приложения, обернутые тонким слоем нативного кода, использующего SDK браузера для открытия веб-приложения, также распространяются через сторы.На ладан дышащие представители этого вымирающиего семейства — Apache Cordova и Ionic. Они не скрывают свое основное назначение — быстрое прототипирование приложений. Для них актуальны классические веб технологии — HTML, CSS, Javascript. Сюда же попадают поделки из no-code конструкторов типа GlideApps и его аналогов.
Оба подхода стоят диаметрально противоположно друг другу по ряду критериев:
Промеж первых двух, с недавних пор, расположись гибридные технологии, которые в настоящий момент чаще всего подразумеваются как кроссплатформенные:
Гибридные, компилируемые в нативный код — приложения написанные с использованием сторонних инструментов разработки, языков программирования, которые имеют свой набор библиотек, связывающих программные интерфейсы платформенных SDK с собственными интерфейсами или полностью заменяющие их.
Типичные представители этого семейства: React Native, Native Script, Electron.
Пока мы не убежали далеко, хочу немного шокировать нетехническую публику — самая кроссплатформенная технология, он же язык программирования, внимание, — C++! Та-да-а-ам! И как ни странно, он очень широко используется для создания полностью нативных кроссплатформенных модулей. Никаких компромиссов! Только хардкор! Ведь наши приложения, это не только кнопочки и списки. Обработка сотен точек на картах, базы данных с особыми возможностями синхронизации совместного доступа к данным, криптография, доставка и обработка видео в реальном времени, ежесекундные данные котировок, которые мы хотим доставлять молниеносно для десятков биржевых тикеров одновременно и многое другое. Никто не пишет эту логику дважды или трижды под каждую платформу.
Главный вопрос при выборе технологии (безотносительно иных бизнес целей) — опыт какого качества мы хотим подарить пользователю. И вот несколько критериев, влияющих на пользовательский опыт:
Говоря образно, по степени абстрактности к конечной мобильной платформе, технологии можно разделить так:
Кроссплатформенные технологии, в первую очередь, хотят завлечь нас преимуществами единой кодовой базы. С этим трудно спорить:
Сравните 2 кусочка кода, описывающих карточку с картинкой:
Команды нативных разработчиков часто разбавляют C/C++ программистами. Они пишут кроссплатформенные модули для разных задач в основном не связанных непосредственно с бизнес логикой.
На старте с нуля ему нет равных в качестве продукта к скорости разработки. 2-3 разработчика способны наковырять безумное количество фич в кратчайшие сроки и выпустить продукт. При этом look-and-feel, производительность будут более чем приемлемыми. Большое количество библиотек решат множество задач типовой функциональности. Я бы назвал flutter серебряной пулей, но. надо кое-что иметь в виду.
Технология предназначена для создания UI! Как и язык программирования Dart.
Выдержка из википедии в доказательство о том, что есть флаттер на самом деле:
Flutter is an open-source UI software development kit created by Google.
Разработка с этим SDK мне всегда напоминала письмо из Простоквашино:
На личном опыте проверено, что в процессе развития продукта скорость нативной разработки со временем возрастает, а кроссплатформенной убывает. Это обусловлено тем, что в начале требуется больше усилий для сборки архитектуры и наработке кода для 2х проектов, нежели для одного. Пока умудренные в особенностях своих платформ, кодеры скрупулезно собирают базовые джентельменские наборы для любого нативного приложения, их коллеги по кроссплатформенному цеху возможно уже готовятся выпускать MVP. Всё меняется на зрелой стадии продукта.
Вот список бед на кроссплатформе, которые на поздней стадии сожрут больше денег, чем на старте:
Дайте знать, если хотите продолжение про KMM и Xamarin, жду вас и ваши мнения в комментариях!
Канала в телеге нет, но если что, пишите в личку