Планирование процессов Android
Я пытаюсь получить лучшее понимание, чтобы я мог оценить влияние надежности от потенциальных проблем взаимодействия при создании приложения / службы Android. Я хотел бы выяснить, как определяется приоритет процесса. Различия в приоритетах между службами и действиями и если планировщик обрабатывает их приоритет по-разному. По сути, я пытаюсь получить четкое представление о том, какова вероятность того, что деятельность или служба будут лишены мошеннических процессов из другого приложения (или даже ядра Linux).
Есть ли у кого-нибудь хорошие ссылки, которые вы могли бы порекомендовать... Мои поиски пока не сильно возросли.
Спасибо!
Редактировать: Моя проблема касается времени процессора, а не ресурсов памяти (ресурсы памяти хорошо описаны в документации Android). Еще раз спасибо!
3 ответа
В следующем списке представлены различные типы процессов в порядке важности (первый процесс наиболее важен и убит последним):
- Процесс переднего плана
- Видимый процесс
- Процесс обслуживания
- Фоновый процесс
- Пустой процесс
Примечание: Android ранжирует процесс на самом высоком уровне, который может, исходя из важности компонентов, активных в данный момент в этом процессе. Например, если процесс размещает службу и видимую активность, процесс оценивается как видимый процесс, а не как процесс службы.
Отсюда ссылки Процессы и потоки
РЕДАКТИРОВАТЬ:
Понимание приоритетов приложений и состояний процессов
Порядок, в котором процессы уничтожаются для восстановления ресурсов, определяется приоритетом размещенных приложений. Приоритет приложения равен компоненту с наивысшим приоритетом.
Там, где два приложения имеют одинаковый приоритет, процесс с более низким приоритетом будет длиться дольше. На приоритет процесса также влияют межпроцессные зависимости; если приложение зависит от поставщика услуг или контента, предоставляемого вторым приложением, вторичное приложение будет иметь по крайней мере такой же высокий приоритет, как и приложение, которое оно поддерживает.
Все приложения Android будут работать и оставаться в памяти до тех пор, пока система не будет нуждаться в ресурсах для других приложений.
Важно правильно структурировать приложение, чтобы его приоритет соответствовал выполняемой им работе. Если вы этого не сделаете, ваше приложение может быть убито, пока оно находится в середине чего-то важного. Следующий список детализирует каждое из состояний приложения, показанных на рисунке, объясняя, как состояние определяется составляющими приложения:
Активные процессы Активные (на переднем плане) процессы - это те приложения, на которых размещаются компоненты, взаимодействующие в данный момент с пользователем. Это процессы, которые Android пытается поддерживать, восстанавливая ресурсы. Обычно таких процессов очень мало, и они будут убиты только в крайнем случае.
Активные процессы включают в себя:
1.Деятельность в "активном" состоянии; то есть они находятся на переднем плане и отвечают на пользовательские события. Вы будете более подробно изучать состояния активности позже в этой главе.
2.Деятельность, Сервисы или Широковещательные Приемники, которые в настоящее время выполняют обработчик события onReceive.
3.Услуги, которые выполняют обработчик событий onStart, onCreate или onDestroy.
Видимые процессы Видимые, но неактивные процессы - это те, которые содержат "видимые" действия. Как следует из названия, видимые действия видимы, но они не находятся на переднем плане и не реагируют на пользовательские события. Это происходит, когда действие только частично скрыто (не полноэкранным или прозрачным действием). Обычно видимых процессов очень мало, и они будут убиты только в экстремальных обстоятельствах, чтобы активные процессы могли продолжаться.
Запущенные процессы процессов Процессы размещения служб, которые были запущены. Службы поддерживают текущую обработку, которая должна продолжаться без видимого интерфейса. Поскольку Сервисы не взаимодействуют напрямую с пользователем, они получают немного более низкий приоритет, чем видимые Действия. Они по-прежнему считаются приоритетными процессами и не будут уничтожены, если не нужны ресурсы для активных или видимых процессов.
Фоновые процессы Хостинг процессов. Действия, которые не отображаются и у которых нет запущенных служб, считаются фоновыми процессами. Как правило, будет большое количество фоновых процессов, которые Android будет уничтожать, используя шаблон "видел первым убитым" для получения ресурсов для процессов переднего плана.
Пустые процессы Чтобы повысить общую производительность системы, Android часто сохраняет приложения в памяти после того, как они достигли конца своего срока службы. Android поддерживает этот кэш, чтобы улучшить время запуска приложений при их повторном запуске. Эти процессы обычно убиваются по мере необходимости.
Для получения дополнительной информации посмотрите здесь (я нашел в этом блоге) Управление памятью в Android
РЕДАКТИРОВАТЬ:
I think Android is basic Linux so, whatever scheduler works for Linux is same in Android.
Разница между планировщиком Android и планировщиком Linux
Планировщик - 5 файлов - Ядро Android также содержит небольшие изменения в планировщике процессов ЦП и алгоритмах учета времени. Мы не знаем историю этих изменений, и влияние не было очевидным на основании беглого осмотра.
Процесс Preemption:
Как уже упоминалось, операционная система Linux является преимущественной. Когда процесс входит в состояние TASK_RUNNING, ядро проверяет, является ли его приоритет выше приоритета выполняющегося в данный момент процесса. Если это так, планировщик вызывается, чтобы выбрать новый процесс для запуска (предположительно, процесс, который только что стал работоспособным). Кроме того, когда временной интервал процесса достигает нуля, он прерывается, и вызывается планировщик для выбора нового процесса.
Политика планирования в действии
Рассмотрим систему с двумя выполняемыми задачами: текстовым редактором и видеокодером. Текстовый редактор связан с вводом / выводом, потому что он тратит почти все свое время на ожидание нажатия клавиши пользователя (независимо от того, насколько быстро пользователь печатает, он не такой быстрый). Несмотря на это, когда он получает нажатие клавиши, пользователь ожидает, что редактор ответит немедленно. И наоборот, видеокодер привязан к процессору. Помимо чтения потока необработанных данных с диска и последующей записи полученного видео, кодировщик все свое время проводит, применяя видеокодек к необработанным данным. Он не имеет каких-либо жестких временных ограничений на время его запуска - если он начал работать сейчас или через полсекунды, пользователь не мог сказать. Конечно, чем раньше он закончится, тем лучше.
В этой системе планировщик предоставляет текстовому редактору более высокий приоритет и больший временной интервал, чем у видеокодера, потому что текстовый редактор является интерактивным. В текстовом редакторе доступно множество временных интервалов. Кроме того, поскольку текстовый редактор имеет более высокий приоритет, он может вытеснять видеокодер при необходимости. Это гарантирует, что текстовый редактор способен реагировать на нажатия клавиш пользователя немедленно. Это в ущерб видеокодеру, но поскольку текстовый редактор работает только с перерывами, видеокодер может монополизировать оставшееся время. Это оптимизирует производительность обоих приложений.
Android в этом отношении немного отличается от обычной системы Linux. Android влияет на планирование двумя вещами: "хороший" уровень процесса / потока и cgroups.
"Хороший" уровень процесса влияет на нормальную "справедливую" политику планирования Linux; потоки, которые имеют более высокую точность, будут запускаться реже, чем потоки с меньшей полезностью. В ситуации, когда у вас есть один поток с приоритетом "по умолчанию" (как определено в Process.THREAD_PRIORITY_DEFAULT
) будет запускаться значительно чаще, чем те, которые имеют фоновый приоритет (или Process.THREAD_PRIORITY_BACKGROUND
).
Теоретически это может гарантировать, что потоки переднего плана / пользовательского интерфейса не окажут значительного влияния на фоновую работу... однако на практике этого недостаточно. Подумайте, есть ли у вас 10 фоновых потоков, все они хотят работать, но один приоритетный поток управляет пользовательским интерфейсом. Это все еще может привести к заметному влиянию на поведение потока переднего плана.
Чтобы решить эту проблему, Android также использует Linux cgroups простым способом для создания более строгого планирования переднего плана и фона. Группа переднего плана / по умолчанию позволяет планировать поток как обычно. Фоновая cgroup, однако, применяет ограничение только в несколько небольших процентов от общего времени ЦП, доступного для всех потоков в этой cgroup. Таким образом, если этот процент равен 5%, и у вас есть 10 фоновых потоков, все из которых хотят работать, и один поток переднего плана, то вместе 10 фоновых потоков могут брать не более 5% доступных циклов ЦП от переднего плана. (Конечно, если ни один поток переднего плана не хочет запускаться, фоновые потоки могут использовать все доступные циклы ЦП.)
Android неявно перемещает потоки между стандартными и фоновыми группами, когда вы используете свои открытые API для установки приоритета потока. Таким образом, если вы установите приоритет потока Process.THREAD_PRIORITY_BACKGROUND
или больше, вы также будете помещать поток в фоновую группу. Установите это Process.THREAD_PRIORITY_DEFAULT
и это будет в cgroup по умолчанию.
Из-за этого, следуя обычному соглашению о размещении фоновых рабочих потоков в фоновом приоритете, вы можете быть уверены, что они не нарушат ваш поток пользовательского интерфейса переднего плана.
Кроме того, Android также переместит все потоки процесса в фоновую группу для процессов, которые, как он знает, не важны для пользователя. Любой фоновый процесс или сервисный процесс имеет свои потоки, помещенные в фоновую группу, независимо от того, запрашивали ли отдельные потоки приоритет приоритетного планирования.
Да, ваш процесс может быть голодным.
Android использует Linux 2.6 для управления ресурсами на низком уровне. Linux 2.6 использует многоуровневые очереди обратной связи в качестве алгоритма планирования. Это благоприятствует процессам, связанным с вводом / выводом, и процессам с коротким циклом (идеально подходит для телефонов для быстрого реагирования / взаимодействия). Это, однако, означает, что процессы с интенсивным использованием процессора и процессы с низким приоритетом рискуют стать голодными. Я не уверен, что в Linux 2.6 периодически повышается приоритет ожидающих процессов, поэтому они в конечном итоге будут обслуживаться, что позволит избежать голодания.
Реально, однако, вам не нужно беспокоиться об этом, так как вы будете либо активным активом, либо сервисом, оба из которых имеют относительно высокие приоритеты, как показывает предыдущий ответ.