Авторские статьи

Новая модель работы приложений в Ubuntu.


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

Когда начиналась работа над Ubuntu Touch, главным в работе разработчиков был просто запуск системы на популярных мобильных платформах. Затем сфокусировались на использовании аппаратного ускорения для прорисовки UI, декодирования медиа и доступ с сенсорам устройства.

Теперь разработчики думают о новой модели работы приложений, которая будет сильно интегрирована с операционной системой Ubuntu Touch.

С точки зрения пользователя и разработчика цели такие:

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

С точки зрения системы цели такие:

  • Глубоко интегрировать новую, ограничивающую модель с операционной системой.
  • Позволять системе агрессивно управлять потреблением ресурсов приложениями.
  • Новая модель должна одинаково хорошо работать в новом объединённом мире Убунту, от десктопа до мобильных платформ, от серверов до ТВ.

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

Мобильные устройства обладают ограниченными по сравнению с десктопом ресурсами: CPU, системная память, GPU, видеопамять, а так же питание от батареи против постоянного подключения к сети.

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

Решение проблем должно вписываться в рамки:

  • Жизненный цикл приложений должен быть прост. Другими словами, изменения в конечном автомате состояний процесса должны быть минимальными насколько возможно, чтобы обеспечить разумное и надёжное поведение в будущем.
    состояния linux процессов
  • Убунту движется в сторону объединения всех аппаратных платформ под своим единым началом, поэтому новая модель должна быть адаптирована для работы в различных ситуациях: от мобильных телефонов, планшетов до классических десктопов. Все различия между устройствами не должны касаться разработчиков. Приложения вместе системой должны уметь переходить от одного варианта использования к другому. В будущем, устройства типа Ubuntu Edge, которые в руках человека работают как мобильная система, а в док-станции как десктоп, потребуют умения переключаться между разными моделями.

Модель жизненного цикла приложения.

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

Конечный автомат процессов

Состояния:

  • В фокусе (Focused): приложение видимо пользователю, гарантировано будет работать и будет обеспечено всеми ресурсами.
  • Не в фокусе (Unfocused): приложению не гарантируется работа, то есть циклы CPU и GPU могут быть не предоставлены. Политика вольна начать перевод процесса в любое состояние из Не запущено. В сценарии мобильная платформа приложение не видно пользователю.
  • Убит (Killed): процесс приложения удалён из памяти.
  • Остановлен (Stopped): процессу послан сигнал SIGSTOP.
  • Без состояния (Stateless): процесс был убит с помощью SIGKILL без сохранения своего состояния. Способ сбросить состояние приложения.

Прозрачный жизненный цикл программы тогда может пониматься так. Приложения должны уметь сохранять (и впоследствии воссоздавать) своё состояние, до перехода в не запущено. Это показано пунктирными линиями на диаграмме. Всем переходам предшествует уведомление приложения, что оно вот-вот будет остановлено или убито. Своё состояние приложение может сериализовать в "архивный" файл на некоторый период. После чего приложение реально попадёт в не запущено. Когда приложение "воскреснет", Ubuntu восстановит состояние приложения из "архивного" файла. На диаграмме видно, что если политика управления жизненным циклом будет работать, то для убитых и остановленных программ нужно сохранять их состояние.

Что решает модель управления жизненным циклом программы?

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

Политики управления жизненным циклом программы.

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

Поведение классического десктопа так же легко описать и создать для него политику. Текущая политика, используемая в Ubuntu Desktop, никогда не срабатывает при переходе из состояния запущено в не запущено и не ограничивает приложение в ресурсах, когда оно не в фокусе пользователя.

Политика v1.0 для мобильных платформ определена как очень строгая. Всем приложениям не в фокусе не гарантируется что они останутся в состоянии запущено и не начнётся их переход в не запущено для агрессивной экономии ресурсов. Уже сегодня приложениям не в фокусе посылается SIGSTOP для остановки, а в дальнейшем, при не хватке памяти, приложения будут убиваться до того, как за них возьмётся OOM Killer.

Почему так строго? Ресурсы мобильных платформ относительно скудны и управлять ими нужно более эффективно, не отдавая на откуп кривонаписанным программам-пожирателям-памяти.

Смысл в строгой политики управления жизненным циклом программы.

Было множество дискуссий между разработчиками по поводу такой строгой политики v1.0 для начального старта и её различных сценариев использования. Большинство ситуаций легко разрешимы если логика приложения разделена на движок (engine) и графическую часть (UI).

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

Как работает эта строгая политика v1.0 в Ubuntu Touch? Система обеспечивает набор системных услуг, которые охватывают основные сценарии работы пользователя типа таких:

  • Воспроизведение музыки в фоне.
  • Скачивание чего-либо в фоне.
  • Сигнализация и уведомления о назначенных встречах.

С политикой v1.0 сторонние приложения не смогут устанавливать свои фоновые сервисы (движки). Однако Ubuntu Touch предоставит механизм, который будет передавать движки программ системе для выполнения их в фоне, что и позволит сторонним приложениям не в фокусе работать в фоне и выводить запланированные события.

Дополнительные материалы:
Mir наступил в Ubuntu 13.10.
Ubuntu Desktop обновляется поэтапно.
Представлен новый механизм обновления Ubuntu Touch.

Дата последней правки: 2013-10-02 08:52:57

RSS vasilisc.com   


Разделы

Главная
Новости
Ворох бумаг
Видео Linux
Игры в Linux
Безопасность
Статьи об Astra Linux
Статьи о FreeBSD
Статьи об Ubuntu
Статьи о Snappy
Статьи об Ubuntu Phone
Статьи о Kubuntu
Статьи о Xubuntu
Статьи о Lubuntu
Статьи об Open Source
Карта сайта