Кроссплатформенные гибридные приложения (и альтернативы) заменили нативные приложения, ориентированные на производительность.

Чисто нативное приложение обычно представляет собой зависящую от платформы программу с графическим интерфейсом, которая использует собственный язык разработки и структуру графического интерфейса конкретной операционной системы. Например, Gedit — это родное приложение, поскольку оно использует C и GTK в качестве зависимостей реализации. Notepad++ — это родное приложение, поскольку оно использует C/C++ и Win32 GUI API. Эти нативные приложения также поддерживают принципы пользовательского интерфейса/UX и собственные функции, характерные для операционной системы. Таким образом, пользователи компьютеров могут легко приступить к работе и использовать эти приложения с другими встроенными собственными приложениями. Эти традиционные нативные приложения без проблем работали даже на низкоуровневом оборудовании, поскольку они не использовали промежуточные модули передачи сообщений или встроенные механизмы рендеринга/исполнения кода — они были просто двоичными файлами, которые запускали встроенные функции SDK. История одинакова как для нативной разработки настольных, так и для мобильных приложений.

Движение за разработку гибридных приложений завершило золотую эру разработки нативных приложений, но создало новый способ создания нативных кроссплатформенных приложений в рекордно короткие сроки. Кроме того, проблемы с производительностью гибридных приложений вызвали рост других типов нативных приложений, которые используют настраиваемые поверхности рендеринга и среды выполнения кода.

Давайте поговорим о падении традиционной нативной разработки приложений.

Почему нативные приложения лучше

Каждая операционная система обычно поставляется с предустановленными программами с графическим интерфейсом для общего использования. Например, Ubuntu предлагает собственный терминал, текстовый редактор, приложение настроек, файловый менеджер и т. д. Эти встроенные приложения, несомненно, следуют тем же принципам UI/UX и используют меньше места на диске, ОЗУ и вычислительной мощности ЦП благодаря превосходному программному дизайну и нативным Использование SDK. Сторонние собственные приложения также работают так же, как и встроенные приложения операционной системы. Они не будут чрезмерно использовать системные ресурсы — они используют вычислительную мощность справедливо в соответствии с функциями, которые они предлагают пользователям.

Нативные приложения хороши со всех точек зрения, ориентированных на пользователя. Они никогда не замедляют работу слабых компьютеров. Кроме того, они никогда не призывают пользователя отказаться от специфичных для операционной системы методов UI/UX. Посмотрите, как выглядит RDP Remmina (программа с собственным графическим интерфейсом) по сравнению со встроенным терминалом в Ubuntu:

Каждая мобильная операционная система также предлагает собственный SDK для разработки пакетов приложений для конкретной платформы. Например, вы можете использовать Android SDK для создания высокопроизводительных, легких и удобных мобильных приложений. Посмотрите, как версия известного медиаплеера VLC для Android реализует представление «О программе» с макетом XML:

Гибриды: нативные веб-приложения

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

Разработка гибридных приложений решила эту проблему, предложив единый SDK и язык для разработки приложений для нескольких платформ. Разработчики начали использовать Electron, NW.js, Apache Cordova и Ionic-подобные фреймворки для создания кроссплатформенных приложений с веб-технологиями. Эти фреймворки отображают основанные на HTML графические интерфейсы приложений, подобные нативным, внутри компонента веб-браузера и вызывают собственные API-интерфейсы для конкретных платформ с оболочками на основе JavaScript через интерфейсы и мосты нативного JavaScript. Посмотрите, как Skype отображает нативный экран в Ubuntu с помощью HTML:

Настольные приложения поставлялись с веб-браузером и модулем среды выполнения Node.js. Мобильные приложения использовали существующие представления браузера для конкретной платформы (например, Android Webview).

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

Восстание гибридных альтернатив

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

Flutter не использовал родные, специфичные для платформы принципы UI/UX. React Native встраивает движок JavaScript в каждое приложение и работает хуже, чем нативные приложения. Эти гибридные альтернативы, несомненно, предлагают лучшее кросс-платформенное решение для разработки, чем подход, основанный на веб-представлении, но все же не могут конкурировать с настоящими нативными приложениями с размером приложения и аспектами, подобными производительности.

Вы можете узнать, как Flutter конкурирует с разработкой гибридных приложений (Electron) из следующей истории:



Гибриды (и альтернативы) завоевали рынок программного обеспечения!

Каждая коммерческая организация пыталась выйти в Интернет, разрабатывая веб-сайты и веб-приложения. Пользователи компьютеров предпочли использовать онлайн-сервисы, а не автономные приложения. В результате веб-браузеры начали улучшаться благодаря различным функциям, ориентированным на разработчиков, таким как новые веб-API, поддержка специальных возможностей, автономная поддержка и т. д. Удобный для разработчиков JavaScript побуждал каждого разработчика использовать его для всего.

С помощью гибридных технологий разработки приложений разработчики в рекордно короткие сроки превратили свои существующие веб-приложения в настольные приложения (например, WhatsApp, Slack и т. д.). Они создали полнофункциональные кросс-платформенные настольные приложения, обернув приложения React, Vue и Svelte встроенными оконными рамами. Этот подход сэкономил тысячи часов разработчиков и затраты на разработку. В результате Electron стал современным решением для разработки настольных приложений. Затем программа-редактор кода, которая могла использовать несколько мегабайт ОЗУ и памяти, стала такой:

Обычный пользователь этого не заметит, так как каждый использует как минимум 8 или 16 гигабайт оперативной памяти. Кроме того, их устройства хранения никогда не позволяли им почувствовать тяжесть 500-мегабайтного редактора кода (Таури и Нейтралинойс решили проблему размера приложения, но они по-прежнему делают гибридные приложения).

Точно так же типичный мобильный пользователь склонен винить устройство, если приложение работает медленно. Современные пользователи часто обновляют устройства, чтобы решить проблемы с производительностью, созданные разработчиками приложений. В результате разработка гибридных приложений стала более популярной, чем разработка нативных приложений в современной индустрии разработки программного обеспечения. Кроме того, более популярными стали гибридные альтернативы (например, Flutter, React Native и т. д.).

Заключение

Среды разработки гибридных приложений и другие альтернативные среды предлагают продуктивную среду для разработчиков, предназначенную для создания кроссплатформенных приложений. Но, с точки зрения пользователя, эти подходы к разработке создают несколько скрытых проблем с производительностью и удобством использования. Современные, мощные аппаратные компоненты могут скрывать технические проблемы в этих подходах к разработке. Кроме того, эти подходы обеспечивают более продуктивную среду разработки, ориентированную на разработчиков, чем разработка нативных приложений, зависящая от платформы. Новички в программировании начали изучать разработку настольных приложений с Electron — разработку мобильных приложений с Flutter и React Native, так же, как они пропустили C как их первый язык программирования.

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

В следующей статье представлена ​​упрощенная альтернатива Visual Studio Code:



Спасибо за прочтение.

Повышение уровня кодирования

Спасибо, что являетесь частью нашего сообщества! Перед тем, как ты уйдешь:

  • 👏 Хлопайте за историю и подписывайтесь на автора 👉
  • 📰 Смотрите больше контента в публикации Level Up Coding
  • 💰 Бесплатный курс собеседования по программированию ⇒ Просмотреть курс
  • 🔔 Подписывайтесь на нас: Twitter | ЛинкедИн | "Новостная рассылка"

🚀👉 Присоединяйтесь к коллективу талантов Level Up и найдите прекрасную работу