В чем разница LiveData и Binder для передачи данных из сервиса в активность

Что проверяют

Понимаете ли вы, что это инструменты разного уровня, а не две альтернативы. Binder это механизм, через который активность получает доступ к сервису, LiveData это способ наблюдать за данными с учётом жизненного цикла. Следом спрашивают, что делать, если сервис живёт в другом процессе.

Как отвечать

• Binder: основа IPC в Android. Сервис возвращает IBinder из onBind(), активность вызывает bindService() и получает его в ServiceConnection.onServiceConnected(). Для сервиса в том же процессе хватает локального биндера: наследник Binder с методом, возвращающим сам сервис, дальше обычные вызовы. Для другого процесса нужен AIDL или Messenger, данные сериализуются через Parcel;
• LiveData: держатель значения, который доставляет обновления только активным подписчикам (STARTED и RESUMED) и сам снимает их, когда владелец уничтожен. Работает только внутри процесса, через границу процесса его не передать;
• как они сочетаются: в локальном сценарии сервис хранит LiveData или StateFlow, активность через биндер получает ссылку на сервис и подписывается. Биндер здесь канал доступа, а LiveData канал обновлений;
• современный вариант: часто биндинг не нужен вовсе. Сервис и ViewModel работают с общим репозиторием из DI (Hilt), сервис пишет в StateFlow, экран собирает его через repeatOnLifecycle(Lifecycle.State.STARTED). Если сервису нужен собственный жизненный цикл, подходит LifecycleService.

У Binder есть важное ограничение: буфер транзакций около 1 МБ на процесс, общий для всех текущих вызовов. Крупные данные через него не передают, иначе получите TransactionTooLargeException; их кладут в файл, базу или SharedMemory.

Где спотыкаются

Говорят, что Binder подходит для больших объёмов данных. Всё наоборот: лимит в мегабайт на процесс заканчивается быстро.

Не вызывают unbindService() в onStop() и получают утечку ServiceConnection с предупреждением в логе.

Ждут onServiceDisconnected() после unbindService(). Он приходит только при неожиданной гибели процесса сервиса, при штатной отвязке не вызывается.