Может ли приложение работать в нескольких процессах?
Что проверяют
Знаете ли вы, как Android раскладывает компоненты по процессам и что ломается, когда процессов больше одного. Следом обычно спрашивают, почему после выноса сервиса в отдельный процесс «сломался синглтон» и дважды инициализировалась аналитика.
Как отвечать
По умолчанию все компоненты приложения живут в одном процессе, названном по applicationId. Атрибут android:process задаётся в манифесте у <activity>, <service>, <receiver> и <provider> и выносит конкретный компонент в свой процесс. У <application> он только меняет процесс по умолчанию.
:remote: имя с двоеточием даёт приватный процесс, доступный только вашему приложению;- имя без двоеточия: глобальный процесс, который могут делить приложения с общим Linux-пользователем и одной подписью.
Что меняется для кода. У каждого процесса своя виртуальная машина ART и своя куча: статические поля и синглтоны не общие, Application.onCreate() вызывается в каждом процессе. Тяжёлую инициализацию ограничивают проверкой имени процесса через Application.getProcessName() (API 28+). SharedPreferences между процессами не синхронизируются, MODE_MULTI_PROCESS давно устарел. Для DataStore есть MultiProcessDataStoreFactory, у Room enableMultiInstanceInvalidation().
Общение идёт через Binder: bound service с Messenger или AIDL, ContentProvider, broadcast. Данные сериализуются через Parcelable, а буфер транзакций Binder около 1 МБ на процесс, поэтому крупный объект в интенте приводит к TransactionTooLargeException.
Когда это оправдано: плеер или загрузчик, который должен пережить падение UI, нативная библиотека с риском краша, изоляция тяжёлой по памяти работы.
Где спотыкаются
Выносят работу в отдельный процесс, чтобы разгрузить главный поток. Для этого хватает фонового потока или корутины, а у нового процесса свой главный поток и лишние мегабайты памяти.
Держат общее состояние в синглтоне. После выноса сервиса он видит свою копию объекта, и данные «теряются» без единой ошибки.
Не учитывают, что система завершает процессы независимо, по их важности. Фоновый процесс сервиса могут убить, пока UI жив, и код должен переживать разрыв Binder-соединения.