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

Вариант, который мы оценивали,

  • Создание доверенного веб-приложения
  • Использование фреймворка-обертки типа ionic/Cordova/Capacitor
  • Начните рассматривать веб-приложение как веб-представление для приложения.

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

Надежное веб-приложение

Доверенное веб-приложение представляет собой простое прогрессивное веб-приложение, но оно завернуто в настраиваемую вкладку Chrome, поскольку оно заключено в настраиваемую вкладку Chrome, оно дает огромные преимущества в скорости страницы, пользовательская вкладка значительно быстрее, чем веб-представления и обычный веб-браузер, поэтому Приложение будет более производительным по сравнению с браузером Chrome, который представляет собой обычные веб-страницы, и приложением, основанным на веб-представлении.

Создание доверенного веб-приложения довольно просто, и создание приложения займет не более нескольких часов. Google продолжает обновлять код оболочки, чтобы обеспечить все больше и больше функций.

Когда проходить TWA

  • Меньший размер (облегченное приложение)
    Приложение очень удобно, так как его размер намного меньше 2 МБ, что является преимуществом для недорогих телефонов.
  • Время выхода на рынок
    Если у вас есть готовое веб-приложение и вы хотите, чтобы оно было развернуто как можно скорее, тогда TWA очень удобен, так как установка всего приложения занимает всего несколько часов.
  • Минимальная частота сбоев приложения
    Поскольку приложение не содержит большого количества нативного кода и удобно с минимальными возможными показателями сбоев.
  • Частые обновления
    TWA решает главную проблему традиционного приложения, связанную с необходимостью обновления конечным пользователем, поскольку приложение полностью создается из веб-приложения, а приложение не требуется явное обновление пользователя, если не добавлен какой-либо SKD.

Когда не следует использовать TWA

  • Доступно только для Android
    На момент написания статьи концепция TWA существовала только для Android, хотя я читал несколько блогов, в которых говорилось, что Apple думает о расширении поддержки для них, но это может занять некоторое время.
  • Необходимость встроенных функций
    Когда вашему приложению требуется доступ к собственным функциям, таким как акселерометр, камера и т. д.
  • Нативные реализации SDK
    Когда вам требуется много SDK в ваших приложениях, это становится неуправляемым, поскольку TWA не обеспечивает никакого моста между собственным кодом и веб-кодом, что затрудняет обмен данными между ними. .

Фреймворк типа Ionic/Cordova/Capacitor

Эти фреймворки созданы для облегчения подхода к гибридным приложениям, что означает, что вы запускаете веб-приложение внутри собственной оболочки. Проще говоря, эти фреймворки были созданы с мыслью, что веб-код будет включен в приложение, а затем он будет выполняться в среде-оболочке. специально для платформы, чтобы конечный пользователь мог иметь внешний вид самой платформы, например, слайдер будет выглядеть как слайдер Android, а в IOS он будет выглядеть как слайдер IOS. Чуть глубже можно понять архитектурную схему Cordova.
Cordova — первая, вышедшая на рынок в тройке выше, но конденсатор разрабатывается только командой ionic.

Когда переходить на фреймворк

  • Доступ к собственным API
    Если у вас есть веб-приложение и вы хотите использовать собственные API для камеры, Bluetooth и т. д., такие платформы обеспечивают превосходную и простую интеграцию.
  • Использование как нативного, так и веб-представления
    Если у вас есть вариант использования, когда вы хотите использовать собственный код вместе с веб-представлением, это прекрасная возможность для вас использовать эти платформы.
  • Напишите один раз, используйте дважды (Android и IOS)
    Ionic придерживается гибридного подхода, который позволяет создавать два разных пакета для двух разных платформ.

Немного проблем с фреймворками

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

Веб-приложение как веб-страница

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

Когда следует переходить на веб-просмотр

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

Когда стоит воздержаться от веб-просмотра

  • Производительность
    Снижение производительности является одним из самых больших узких мест, которые возникают в приложении, веб-представления не являются суперпроизводительными по своей природе, и в этом случае конечный пользователь может получить неаккуратный пользовательский интерфейс.
  • Отсутствие собственного доступа к API
    Веб-представления не обеспечивают доступ к собственному API, поэтому во всех случаях, когда требуется собственный API, это определенно не рекомендуемый подход, например, приложению требуется доступ через Bluetooth. и веб-просмотр акселерометра не сможет обеспечить требуемую поддержку.

Что ж, это было почти все для просмотра с высоты птичьего полета для моих читателей. Я, конечно, планирую более подробные статьи для TWA и Ionic.