Когда я должен использовать каждый из различных типов обмена сообщениями Android?

Это довольно открытый вопрос, но позвольте мне попытаться описать, как мне кажется, что взаимодействие между приложениями и внутри приложения работает лучше всего.

Одним из ключевых аспектов обмена сообщениями Android является концепция того, что все компоненты приложения слабо связаны. Поскольку все приложения выполняются в отдельном процессе, и одно «приложение» может фактически состоять из нескольких приложений (отвечающих за предоставление различных действий или служб), все методы обмена сообщениями основаны на идее маршалинга сообщений через границы процесса.

Намерения

Предпочтительный метод обмена сообщениями: всегда старайтесь использовать намерение, когда это возможно. Это наиболее «родной» способ передачи сообщений в Android.

Преимущества

Использование намерений для обмена сообщениями поддерживает свободную привязку компонентов приложения, позволяя беспрепятственно передавать сообщения между несколькими приложениями. Интенты широко используются в основной системе для запуска действий и служб, а также для широковещательной рассылки и приема системных событий.

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

Недостатки

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

Application Class

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

Преимущества

Расширяя класс Application (и реализуя его как Singleton), вы получаете объект, который будет существовать всякий раз, когда существует какой-либо из компонентов вашего приложения, обеспечивая централизованное место для хранения и передачи сложных объектные данные между компонентами приложения.

Недостатки

Этот метод ограничивает обмен сообщениями между компонентами в рамках одного приложения.

Привязка службы, IPC и AIDL

Привязка к службе позволяет вам получить доступ к ее методам и обмениваться объектами с этим. AIDL - это способ определения того, как сериализовать объект в примитивы ОС, чтобы его можно было упорядочить через границы процесса, если Служба, к которой вы привязываетесь, работает в отдельном приложении.

Преимущества

Когда вы привязываетесь к Сервис, у вас есть доступ к нему, как если бы это был объект в вызывающем классе. Это означает, что вы можете выполнять методы в Сервисе и обмениваться с ним богатыми объектами.

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

Недостатки

Создание классов AIDL для IPC - это немного лишняя работа, а привязка создает дополнительные зависимости между службами и действиями, которые могут затруднить очистку ядра ресурсов, когда другие приложения испытывают нехватку ресурсов.

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

Сокеты

Если вы ' Если вы используете сокеты для связи внутри или между приложениями, работающими на одном устройстве, это либо потому, что другого пути нет, либо вы где-то упустили трюк. Если ваши сообщения уходят с устройства, сокеты - хорошая и быстрая альтернатива. Если вы остаетесь на устройстве, скорее всего, Intents или IPC будут лучшим вариантом.