В версии ОС «Аврора» 5.2 наш браузер получает долгожданную поддержку Progressive Web Apps (PWA) - технологии, которая позволяет веб-приложениям выглядеть и работать как полноценные нативные приложения.
Казалось бы, в результате пользователь видит лишь простую иконку в общем списке приложений, но на деле реализация PWA требует тесной интеграции браузерного движка с самой операционной системой. Именно о технических подробностях этой интеграции, а также о внутреннем устройстве PWA в целом, я и хочу рассказать в этой статье.
Меня зовут Тимур Валеев, я руковожу командой, которая занимается развитием браузера для ОС «Аврора», и сегодня мы разберем, как это было реализовано.
Что такое PWA
Progressive Web App это веб-сайт, который выглядит и ведет себя как обычное приложение, установленное на ваше устройство (смартфон, планшет).
По сути, это продвинутый веб-сайт, который:
Имеет свою иконку на рабочем столе.
Запускается в отдельном окне без элементов браузера, таких как адресная строка.
Может работать без интернета, благодаря JavaScript Service Worker скрипту, который решает загружать данные с сети или из кеша.
Шлет нотификации и получает push-уведомления.
Все волшебство PWA прописано в файле manifest.json. Этот JSON-документ задает:
Название приложения (полное и короткое)
URL-адрес стартовой страницы (
start_url)Набор иконок для разных разрешений
Цвета темы (чтобы слиться с системой)
Режим отображения (полноэкранный, отдельное окно и т.д.)
В то время как manifest.json определяет внешнюю интеграцию приложения с системой, другой ключевой компонент это Service Worker, который превращает стандартный веб-сайт в полнофункциональное PWA-приложение. Service Worker работает как интеллектуальный фоновый процесс: он обеспечивает автономную работу через продвинутое кеширование ресурсов, динамически управляет сетевыми запросами, выбирая между свежими и сохранёнными данными, поддерживает фоновые операции вроде синхронизации и обрабатывает push-уведомления даже при закрытом приложении. Именно благодаря Service Worker'у PWA получает многие преимущества нативных приложений, сохраняя при этом гибкость и кросс-платформенность веб-технологий.
Как Аврора Браузер "готовит" PWA
Поскольку наш браузер построен на базе Chromium Embedded Framework (CEF), интегрированного через WebView API, процесс установки PWA представляет собой чёткий конвейер взаимодействия между этим движком и компонентами ОС. Давайте разберём его по шагам.
1. Обнаружение и загрузка манифеста
Через WebView API браузер обнаруживает, что веб-сайт является PWA (имеет манифест и обслуживается по безопасному протоколу HTTPS). После этого он делегирует CEF-движку задачу по скачиванию файла manifest.json.
2. Парсинг и валидация
Загруженный манифест передаётся в PwaManager - специальный модуль браузера, который отвечает за:
Разбор данных JSON.
Валидацию обязательных полей.
Нормализацию путей к ресурсам (например, иконкам).
Общую подготовку данных к установке.
3. Загрузка ресурсов
PwaManager, используя WebView API, поручает CEF-движку скачать все необходимые изображения (иконки для разных разрешений экрана), указанные в валидированном манифесте.
4. Установка в систему- ключевой этап интеграции
После успешной загрузки всех ресурсов «Аврора Браузер» через D-Bus API передаёт готовый пакет данных в Application Manager - системный компонент ОС «Аврора». Именно Application Manager формирует из полученных данных полноценный пакет приложения.
5. Управление и обновление
Для проверки, установлено ли то или иное PWA, браузер использует D-Bus API. Этот же интерфейс является ключевым и для процесса обновления: встроенный механизм PWA в браузере периодически проверяет наличие обновлений манифеста или ресурсов (например, иконок) и через D-Bus API взаимодействует с Application Manager, чтобы инициировать обновление установленного пакета приложения в системе.
Визуализируем процесс:
Изоляция приложений и отличие от Android
В Android PWA живут внутри браузера и разделяют с ним общее хранилище (кэш, куки) и сервис-воркеры. В «Авроре» мы пошли другим путём: каждое установленное PWA запускается в полностью изолированном контейнере.
Такой подход, как и у любой архитектурной модели, имеет свои сильные и слабые стороны.
Плюсы изоляции:
Раздельный кэш и данные: Каждое PWA имеет собственные, изолированные хранилища cookie, кэша и данных. Это означает, что если вы очистите историю или данные основного браузера, это никак не затронет ваши PWA-приложения — их информация останется в полной безопасности.
Приложения в песочнице: Данные и сессии разных приложений строго разделены. Это полностью исключает риск нежелательных пересечений или утечки информации между вашими PWA.
Минусы (куда без них):
Цена изоляции: Главный компромисс — это потребление ресурсов. Поскольку каждому PWA выделяются собственные процессы (как браузерный, так и для рендеринга), это приводит к более высокому потреблению оперативной памяти и нагрузки на CPU по сравнению с общей моделью.
Еще немного визуализации:
С какими сложностями мы столкнулись и как решали
Спецификация W3C Web App Manifest задаёт рамки, но многие поля опциональны, а поведение браузеров частично расходится. В реальном мире это приводит к разношёрстным манифестам. Самые типичные кейсы:
Отсутствует или некорректен start_url. Часто поле не задано вовсе или задаётся как "."/"/". Мы вычисляем надёжный дефолт - нормализованный URL исходной страницы (база без query/fragment) и используем его как точку входа.
Непредсказуемые пути к иконкам. Иногда путь к иконкам не указан или встречаются относительные пути вроде "../content/i/icon.png", которые автор рассчитывал относительно HTML-страницы, а не манифеста. Мы применяем «лестницу разрешения» URL: относительно URL манифеста → относительно базового URL сайта → попытка из каталога манифеста → резервный /favicon.ico.
Пустые или «полупустые» манифесты. Попадаются и абсолютно пустые {}, и минимальные наборы без необходимых для установки в ОС данных (имя приложения/иконки).
Проблема с обновлением. Даже Google признает, что обновление PWA - больная тема (см. их документ "Predictable Web App Updating"). Разработчики часто не понимают, как оно должно работать.
Мы используем связку строгая валидация + безопасные эвристики. Проверяем синтаксис и минимально достаточный набор полей для установки в ОС (это не «обязательные по стандарту», а прагматичный минимум для корректного пользовательского опыта). Нормализуем и вычисляем start_url, если он не задан или некорректен, разрешаем пути к иконкам по ступеням. В случае недостаточности данных мы прекращаем установку и сообщаем причину.
Для обновлений (по мере внедрения) используем предсказуемые правила сравнения артефактов манифеста и ресурсов, опираясь на практики из сообщества. Это не «обход стандарта», а попытка обеспечить совместимость с реальными манифестами, оставаясь в рамках спецификации и добавляя понятные дефолты там, где она допускает вариативность.
PWA в Авроре - это только начало
Поддержка Progressive Web Apps в Aurora Browser 5.2 - важный шаг к открытой и современной экосистеме приложений. Мы соединили мощь веба с удобством нативной интеграции, подготовившись к реалиям интернета, где идеальные манифесты - редкость.
Что в планах? Улучшение логики обновлений, поддержка push сообщений, расширение поддержки современных Web API и дальнейшая работа над балансом между изоляцией и потреблением ресурсов. PWA в Авроре пока еще не выросло из пеленок, но скоро им предстоит взрослеть и выйти в реальный мир!
И в конце небольшой бонус, скриншоты реальных приложений PWA в ОС Арора 5.2.
1. Диалог установки PWA. Кнопка "Установить" появляется в адресной строке Aurora Browser.
2. Оповещение о том, что приложение было успешно установлено
3. Первый запуск приложения и запрос необходимых разрешений.
4. Установленные PWA в сетке приложений. После установки PWA получает иконку, как нативное приложение
5. Splash screen следует за рекомендациями backgound_color PWA manifest-а.
6. Обложки запущенных PWA приложений на рабочем столе Авроры
7. Запущенное приложение. PWA работает без интерфейса браузера - только чистый интерфейс приложения.
В заключение
Реализация полноценной поддержки PWA в «Аврора Браузере» оказалась задачей куда более комплексной, чем просто следование спецификации. Нам потребовалось создать мост между веб-технологиями и нативной операционной системой. Эта работа - лишь один из шагов в большом пути. Мы будем и дальше развивать поддержку PWA, следить за стандартами и улучшать производительность Аврора Браузера и приложений.
