Планирование Android-процессов

Я пытаюсь получить лучшее понимание, поэтому я могу охватить влияние надежности потенциальных проблем взаимодействия при создании приложения android для Android. Я хотел бы выяснить, как определяется приоритет процесса. Различия в приоритете между службами и действиями и если планировщик рассматривает свой приоритет по-разному. В основном я пытаюсь понять, насколько вероятно, что активность или услуга голодают от изгоев от другого приложения (или даже ядра Linux).

Есть ли у кого-нибудь хорошие ссылки, которые вы могли бы порекомендовать... Мои поиски еще не появились.

Спасибо!

Изменить: моя забота касается обработки времени/планирования процессора, а не ресурсов памяти (ресурсы памяти хорошо описаны в документации по Android.) Еще раз спасибо!

Ответ 1

В следующем списке представлены различные типы процессов в порядке важности (первый процесс наиболее важен и последний убит):

  • Передний процесс
  • Видимый процесс
  • Сервисный процесс
  • Фоновый процесс
  • Пустой процесс

Примечание.. Android оценивает процесс на самом высоком уровне, который он может, основываясь на важности компонентов, которые в данный момент активны в этом процессе. Например, если процесс содержит службу и видимую активность, процесс оценивается как видимый процесс, а не процесс обслуживания.

Здесь ссылаются Процессы и потоки

EDIT:

Общие сведения о приоритетах приложений и состояниях процессов

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

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

Все приложения для Android будут работать и в памяти, пока система не будет нуждаться в ресурсах для других приложений.

Важно правильно структурировать ваше приложение, чтобы гарантировать, что его приоритет подходит для его работы. Если вы этого не сделаете, ваше приложение может быть убито, пока оно находится в середине чего-то важного. Следующий список описывает каждое из состояний приложения, показанное на рисунке, объясняя, как состояние определяется компонентами приложения, содержащими его:

Активные процессы. Активными (передними) процессами являются те хостинг-приложения с компонентами, которые в настоящее время взаимодействуют с пользователем. Это те процессы, с помощью которых Android пытается реагировать, возвращая ресурсы. Как правило, очень мало таких процессов, и они будут убиты только в крайнем случае.

enter image description here

Активные процессы включают в себя:

1. Деятельности в "активном" состоянии; то есть они находятся на переднем плане и отвечают на пользовательские события. Вы более подробно изучите состояния активности позже в этой главе.

2.Activities, Services или Broadcast Receivers, которые в настоящее время выполняют обработчик события onReceive.

3.Услуги, выполняющие обработчик события onStart, onCreate или onDestroy.

Видимые процессы Видимые, но неактивные процессы - это те, которые содержат "видимые" действия. Как видно из названия, видимые действия видны, но они выступают на переднем плане или отвечают на пользовательские события. Это происходит, когда активность только частично закрывается (не полноэкранным или прозрачным действием). Как правило, очень мало видимых процессов, и их можно убить только в экстремальных обстоятельствах, чтобы активные процессы продолжались.

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

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

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

Подробнее см. здесь (я нашел в этом блоге) Управление памятью в Android

EDIT:

I think Android is basic Linux so, whatever scheduler works for Linux is same in Android. 

Разница между планировщиком Android и планировщиком Linux

Scheduler - 5 файлов. Ядро Android также содержит небольшие изменения в планировщике процессов процессора и алгоритмах учета времени. Мы не знаем историю этих изменений, и влияние не было очевидно на основе беглого исследования.

Приоритет процесса:

Как уже упоминалось, операционная система Linux является превентивной. Когда процесс переходит в состояние TASK_RUNNING, ядро ​​проверяет, превышает ли приоритет приоритет текущего выполняющегося процесса. Если это так, планировщик вызывается, чтобы выбрать новый процесс для запуска (предположительно, процесс, который только что стал исполняемым). Кроме того, когда временной интервал процесса достигает нуля, он выгружается, и планировщик вызывается для выбора нового процесса.

Политика планирования в действии

Рассмотрим систему с двумя выполняемыми задачами: текстовым редактором и видеокодером. Текстовый редактор связан с I/O-привязкой, потому что он тратит почти все свое время, ожидая нажатия клавиш пользователя (независимо от того, насколько быстро пользователь набирает, это не так быстро). Несмотря на это, когда он получает нажатие клавиши, пользователь ожидает, что редактор немедленно ответит. И наоборот, видеокодер связан с процессором. Помимо чтения исходного потока данных с диска и последующего написания результирующего видео, кодер тратит все свое время, применяя видеокодек к необработанным данным. У него нет сильных временных ограничений при запуске - если он запустился сейчас или через полсекунды, пользователь не мог сказать. Конечно, чем раньше он заканчивается, тем лучше.

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

Ответ 2

Android в этом отношении немного отличается от обычной Linux-системы. Есть две вещи, которые использует Android для воздействия на планирование: процесс/поток "хороший" уровень и группы.

Процесс "хороший" уровень влияет на нормальную "справедливую" политику планирования Linux; нити, которые имеют более высокую привлекательность, будут выполняться реже, чем потоки с более низкой привлекательностью. В ситуации, когда у вас есть один поток с приоритетом по умолчанию (как определено в Process.THREAD_PRIORITY_DEFAULT), будет работать значительно чаще, чем те, с приоритетом фона (или Process.THREAD_PRIORITY_BACKGROUND).

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

Чтобы решить эту проблему, Android также использует Linux-группы простым способом для создания более строгого плана перед фоновым планированием. CGroup foreground/default позволяет планирование потоков как обычно. Однако фоновая группа применяет предел только небольшого процента от общего времени процессора, доступного для всех потоков в этой группе. Таким образом, если этот процент составляет 5%, и у вас есть 10 фоновых потоков, которые все хотят запустить, а одна нить переднего плана, 10 фоновых потоков вместе могут принимать не более 5% доступных циклов ЦП с переднего плана. (Конечно, если ни одна передняя нить не хочет запускаться, фоновые потоки могут использовать все доступные циклы ЦП.)

Android неявно перемещает потоки между группами по умолчанию и фоном, когда вы используете свои общедоступные API, чтобы установить приоритет потока. Таким образом, если вы установите приоритет потока Process.THREAD_PRIORITY_BACKGROUND или больше, вы также поместите поток в фоновую группу. Установите его Process.THREAD_PRIORITY_DEFAULT, и он будет включен в группу по умолчанию.

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

Кроме того, Android также будет перемещать все потоки в процессе в фоновой cgroup для процессов, которые, как он знает, не являются критическими для пользователя. Любой фоновый процесс или сервисный процесс имеет свои потоки, помещенные в фоновую группу, независимо от того, запросили ли отдельные потоки приоритет планирования переднего плана.

Ответ 3

Да, возможно, чтобы ваш процесс был голоден.

Android использует Linux 2.6 для управления ресурсами на низком уровне. Linux 2.6 использует многоуровневые очереди обратной связи в качестве своего алгоритма планирования. Это способствует процессам с привязкой к вводу/выводу и коротким процессам пакетной обработки (идеально подходит для телефонов для оперативного реагирования/взаимодействия). Однако это означает, что процессы с интенсивным процессором и процессы с низким приоритетом могут стать причиной голода. Я не уверен, что Linux 2.6 периодически увеличивает приоритет процессов ожидания, поэтому в конечном итоге они будут обслуживаться, тем самым избегая голода.

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