Как система определяет, какой процесс умрет первым в Anroid

Механизм определения приоритета завершения процессов в Android

В Android нет единого "первого" процесса для завершения. Решение принимается динамически системой ActivityManagerService (AMS) на основе комплексной оценки приоритетов всех запущенных процессов. Это иерархическая система, где ключевую роль играет важность процесса для пользователя и системы.

Иерархия приоритетов процессов (Process Priority Hierarchy)

Система ранжирует процессы по убыванию важности:

1. Foreground Process (Процесс переднего плана):

    *   Процесс, с которым пользователь взаимодействует в данный момент (Activity в состоянии `Resumed`).
    *   Процесс, удерживающий `BroadcastReceiver`, выполняющий `onReceive()`.
    *   Процесс, выполняющий callback-метод жизненного цикла Service (`onCreate()`, `onStart()`, `onDestroy()`).

1. Visible Process (Видимый процесс):

    *   Процесс, не находящийся на переднем плане, но всё ещё видимый пользователю (Activity в состоянии `Paused`).
    *   Пример: активность, частично перекрытая диалоговым окном или прозрачной активностью.

1. Service Process (Процесс сервиса):

    *   Процесс, в котором выполняется Service, запущенный методом `startService()` и не отнесённый к более высоким категориям.
    *   Пример: фоновая загрузка файлов или воспроизведение музыки.

1. Cached Process (Кэшированный процесс):

    *   Процесс, не являющийся активным для пользователя (Activity в состоянии `Stopped`), но сохранённый в памяти для возможного быстрого перезапуска.
    *   Внутри этой категории также есть градация. Система поддерживает **Least Recently Used (LRU) список** кэшированных процессов.

1. Empty Process (Пустой процесс):

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

Алгоритм принятия решения (OOM Killer)

Когда системе срочно требуется память (ситуация Out Of Memory), в дело вступает низкоуровневый механизм Linux OOM Killer. Но Android модифицирует его работу, используя вычисленное значение oom_adj_score (или oom_score_adj в новых версиях ядра). Чем выше этот score, тем вероятнее будет завершён процесс. AMS напрямую влияет на этот параметр, устанавливая его в зависимости от категории процесса.

// Упрощённая логика присвоения oom_adj (актуально для старых версий)
// В современных версиях используются oom_score_adj и cgroups.
switch (processCategory) {
    case FOREGROUND_APP:
        oom_adj = 0; // Наименьший приоритет для убийства
        break;
    case VISIBLE_APP:
        oom_adj = 100;
        break;
    case SERVICE:
        oom_adj = 500;
        break;
    case CACHED_APP:
        oom_adj = 900; // Наибольший приоритет для убийства
        break;
}

Критерии внутри одной категории

Если в одной категории (особенно Cached) находится несколько процессов, система использует дополнительные факторы для выбора "кандидата":

• Время последней активности: Первыми убиваются процессы, которые дольше всего не использовались (LRU-принцип).
• Потребление ресурсов: Процесс, потребляющий больше памяти или CPU в фоне, имеет более высокие шансы быть завершённым.
• Зависимости: Если процесс B является клиентом процесса A (например, связан через Content Provider или Bound Service), система может рассмотреть их как группу.

Практический пример и рекомендации для разработчика

Представьте сценарий: работает мессенджер (Foreground), карты в видимом режиме (Visible), музыкальный сервис (Service) и несколько свёрнутых приложений (Cached). При нехватке памяти:

1. Система никогда не убьёт мессенджер первым.
2. Она начнёт с наименее недавно использованных кэшированных процессов.
3. Если памяти всё ещё мало, может быть завершён процесс музыкального сервиса (но только после всех кэшированных).
4. Процесс карт будет завершён одним из последних.

Для разработчика это означает:

• Минимизируйте работу в фоне. Используйте WorkManager или JobScheduler для отложенных задач, которые не критичны к времени.
• Освобождайте ресурсы. Корректно реализуйте onTrimMemory() и onLowMemory() в компонентах, чтобы освободить кэши, изображения, когда система сигнализирует о нехватке памяти.
• Используйте foreground services для важных операций. Для задач, которые пользователь явно ожидает (например, загрузка файла), запускайте Foreground Service с персистентным уведомлением. Это повышает приоритет процесса до уровня, близкого к Visible.
• Не злоупотребляйте связями между процессами (Binding), так как это может повысить их общий приоритет и удержать в памяти дольше необходимого.

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