Должен ли я расширить класс Binder или использовать Messenger?

Question

В моем приложении я разработал так, чтобы в нем была Служба, которая постоянно получает данные (по уважительной причине, от некоторых датчиков) и предоставляет их двум клиентам:

• Активность пользовательского интерфейса для отображения текущих данных
• Еще одна служба, которая регистрирует данные

В любой момент могут быть запущены оба или один из этих клиентов.

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

Документация Android для этого говорит, что я должен расширить класс Binder или использовать Messenger, если я хочу получить доступ к сервису из другого процесса.

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

Спасибо

Answer 1

Android документация ясно говорит
Расширение класса Binder
Если ваша служба является частной по отношению к вашему собственному приложению и работает в том же процессе, что и клиент (что является общим) , вам следует создать свой интерфейс, расширив класс Binder и вернув его экземпляр из onBind (). Клиент получает Binder и может использовать его для прямого доступа к общедоступным методам, доступным либо в реализации Binder, либо даже в Сервисе. Это предпочтительный метод, когда ваш сервис является просто фоновым рабочим для вашего собственного приложения. Единственная причина, по которой вы не будете создавать свой интерфейс таким образом, заключается в том, что ваша служба используется другими приложениями или в разных процессах.

Использование мессенджера
Если вам нужен ваш интерфейс для работы с различными процессами , вы можете создать интерфейс для службы с помощью Messenger. Таким образом, служба определяет обработчик, который отвечает на различные типы объектов сообщения. Этот обработчик является основой для Messenger, который затем может делиться IBinder с клиентом, позволяя клиенту отправлять команды службе, используя объекты Message. Кроме того, клиент может определить Messenger самостоятельно, чтобы служба могла отправлять сообщения обратно. Это самый простой способ выполнения межпроцессного взаимодействия (IPC), потому что Messenger помещает все запросы в один поток, так что вам не нужно разрабатывать свой сервис как поточно-ориентированный.

Таким образом, наилучшим вариантом является использование службы путем расширения класса IBinder, когда эта служба является локальной службой . Когда обе службы создаются с использованием Messenger и AIDL, они являются удаленными службами .

Answer 2

предпочтительное решение imrankhan (Binder), похоже, работало, но в итоге я выбрал Messenger, так как на практике я нашел это решение более гибким и логичным для кодирования.