Поставщик контента против SharedUserId против глобального процесса для обмена данными между приложениями - PullRequest
Новая
       10

Поставщик контента против SharedUserId против глобального процесса для обмена данными между приложениями

0 голосов
/ 05 мая 2018

Я нашел три способа обмена данными между приложениями.

1. Контент-провайдер

2. SharedUserId -При объявлении одного и того же общего идентификатора пользователя для нескольких приложений они могут получать доступ к ресурсам друг друга (полям данных, представлениям и т. Д.). предоставленные заявки подписываются тем же сертификатом.

3. Глобальный процесс -Поставить компонент одного приложения в отдельный процесс с помощью android: атрибут процесса и процесс именования, начинающийся со строчной буквы, и другой компонент другого приложения в отдельном процессе с тем же именем, что и отдельный процесс первого применения. Теперь эти компоненты могут обмениваться данными.

Я не понимаю, что использовать, когда или что более эффективно?

1 Ответ

0 голосов
/ 05 мая 2018

Я нашел три способа обмена данными между приложениями.

# 2 и # 3 одинаковы, поскольку # 3 (общий процесс) требует # 2 (sharedUserId).

Вы также пропустили все другие формы стандартного Android IPC, в том числе:

  • начало деятельности
  • стартовые услуги
  • привязка к услугам
  • отправка трансляций

Я запутался, что использовать, когда

Обычные разработчики приложений должны использовать # 1 (ContentProvider) или один из других стандартных механизмов Android IPC, которые я описал выше. Вы не контролируете, когда пользователи обновляют приложения, и использование формального IPC обеспечивает четкое разделение между приложениями, заставляя вас продумывать такие вещи, как контракты API, управление версиями API и связанные с этим проблемы.

sharedUserId и общие процессы действительно существуют для производителей устройств, где приложения предварительно устанавливаются, а затем обновляются в унисон через обновление прошивки. Лично я рекомендую производителям устройств использовать стандарт IPC для большинства сценариев. Например, если приложение A изменяет файлы приложения B напрямую, как приложение B узнает? Что если приложение B затем перезапишет изменения в приложении A, поскольку приложение B не знает об этих изменениях? Во многих других областях компьютерного программирования мы избавились от того, чтобы несколько процессов из нескольких приложений работали с файлами друг друга напрямую.

что эффективнее?

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

...