Пользователь должен иметь возможность вызывать столько приложений сколько ему нужно, не испытывая замедления в работе. Это тот случай, когда система должна заниматься всем этим, улучшая работу пользователя, особенно, на мобильных устройствах.
Когда начиналась работа над Ubuntu Touch, главным в работе разработчиков был просто запуск системы на популярных мобильных платформах. Затем сфокусировались на использовании аппаратного ускорения для прорисовки UI, декодирования медиа и доступ с сенсорам устройства.
Теперь разработчики думают о новой модели работы приложений, которая будет сильно интегрирована с операционной системой Ubuntu Touch.
С точки зрения пользователя и разработчика цели такие:
- Обеспечить в новой модели место для процедур установки, выполнения, удаления приложений.
- Обеспечить безопасность на всех этапах, подразумевая что приложения могут быть зловредными.
- Работа многозадачности должна оставаться прозрачной для пользователя и не требовать мыслить категориями запущена или не запущена программа.
- Новая модель должна быть простой для разработки приложений на сколько это возможно.
С точки зрения системы цели такие:
- Глубоко интегрировать новую, ограничивающую модель с операционной системой.
- Позволять системе агрессивно управлять потреблением ресурсов приложениями.
- Новая модель должна одинаково хорошо работать в новом объединённом мире Убунту, от десктопа до мобильных платформ, от серверов до ТВ.
Каждый пункт в списке не прост сам по себе, но они ещё связаны с друг другом, а некоторые конфликтуют с друг другом. Связать их воедино - вот задача!
Мобильные устройства обладают ограниченными по сравнению с десктопом ресурсами: CPU, системная память, GPU, видеопамять, а так же питание от батареи против постоянного подключения к сети.
Запущенные приложения конкурируют между собой за эти ограниченные ресурсы, пытаясь максимально их использовать. А пользователь в этот момент ожидает от системы плавной и долгой работы приложений от батареи. Но никто не вправе требовать от человека заниматься управлением процессами или строить в своей голове план наилучшего использования ресурсов для приложений. То есть управление процессами и работа многозадачности в новой модели должны быть прозрачны для пользователя.
Решение проблем должно вписываться в рамки:
- Жизненный цикл приложений должен быть прост. Другими словами, изменения в конечном автомате состояний процесса должны быть минимальными насколько возможно, чтобы обеспечить разумное и надёжное поведение в будущем.
- Убунту движется в сторону объединения всех аппаратных платформ под своим единым началом, поэтому новая модель должна быть адаптирована для работы в различных ситуациях: от мобильных телефонов, планшетов до классических десктопов. Все различия между устройствами не должны касаться разработчиков. Приложения вместе системой должны уметь переходить от одного варианта использования к другому. В будущем, устройства типа 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.
Немає коментарів:
Дописати коментар