内容提供商vs SharedUserId vs跨应用程序共享数据的全局过程

我找到了三种跨应用程序共享数据的方法。

#2和#3是相同的,因为#3(共享进程)需要#2( sharedUserId )。

您还错过了所有其他形式的标准Android IPC,包括:

• 启动活动
• 正在启动服务
• 绑定到服务
• 发送广播

我不知道什么时候该用

普通应用程序开发人员应使用#1( ContentProvider )或者我上面概述的其他标准Android IPC机制之一。您无法控制用户何时更新应用程序,使用正式的IPC会强制应用程序之间进行明确的分离,迫使您仔细考虑API合同、API版本控制和相关问题。

sharedUserId 对于设备制造商来说,共享流程确实存在,应用程序是预先安装的,然后通过固件更新进行统一更新。就个人而言,我建议设备制造商在大多数情况下也使用标准IPC。例如,如果应用程序A直接修改应用程序B的文件,应用程序B如何发现?如果应用程序B覆盖了应用程序A的更改,因为应用程序B不知道这些更改,该怎么办?在计算机编程的许多其他领域,我们已经摆脱了让多个应用程序的多个进程直接与其他文件协同工作的局面。

哪个效率更高?

在这种情况下,效率不应该是一个问题,因为您应该不经常使用这些技术中的任何一种。如果你有两个应用程序需要经常相互通信,那么你真的有一个应用程序,你应该这样实现它。