使用SharedReferences在两个独立的Android应用程序之间共享数据

Android设备上将同时运行两个独立的应用程序。我们负责App1。以下是Android设备上将发生的事情：

将首先启动App1，然后启动App2

App1将显示包含消息的文件列表

当App2启动时，它将向App1发送一条“连接”消息

App1将允许用户从列表中选择一个文件

当用户按下“运行”按钮时，App1将开始每隔3秒向App2发送消息

App2将在收到每一条消息后发回一条消息

App1将读取App2发送的每条消息并将其记录到文件中

App1发送的最后一条消息将导致App2将断开连接发送回App1

负责App2的小组希望使用SharedReferences来完成这一切。如果我们这样做，我们需要使用什么来确定App2消息何时处于共享首选项中，以便App1可以读取它

负责App2的小组希望使用SharedReferences来完成这一切

这不是一个好主意。引述：

注意：当前此类不支持跨多个进程使用。这将在以后添加

---

即使共享首选项可以在进程之间共享，请参见@commonware answer。。 那么，对于您描述的问题来说，这似乎是最糟糕的设计解决方案。 事实上，它闻起来像个可怕的主意，我相信最终它无论如何都不会起作用

说SharedReferences是android中不同应用程序/进程之间通信的解决方案，就像完全忽略所有android API和核心组件一样

SharedReferences不被设计为进程之间的某种消息队列。 甚至都不接近

android为不同应用程序之间的通信和数据共享提供了更加优雅的解决方案

例如：

远程服务绑定app1启动app2可以绑定到的服务 当某些事件发生时，从一个应用程序向另一个应用程序发送广播，并使用BroadcastReceiver从另一个应用程序接收广播 app1可以实现并公开可从app2访问的ContentProvider 还有更多

我建议您在决定如何实现应用程序之前，最好先了解android的核心组件服务、广播接收器、活动、内容提供商。 我无法想象，如果不使用上述至少3种方法，就可以创建一个功能良好的应用程序。 你可以通过阅读Android开发者入门指南中的第一页来改变这一点-

链接：

---

正如好未来所说，在两个进程中使用共享偏好进行通信是不好的，IPC进程间通信，在Android中使用服务是实现两个Android进程之间完全控制的更好解决方案。下面是一个关于如何在音乐播放器及其客户端中使用IPC的示例。

您有什么建议，请记住这两个应用程序在不同的软件包中？@user2584082：我首先要求这些团队解释为什么这些应用程序是独立的符合用户的利益，以及为什么它们通过尝试每三秒通信来不断耗尽电能符合用户的利益。假设有理由对此表示怀疑，我会使用实际的进程间通信：广播意图、通过startService向服务发送命令等。其他答案列出了许多可能性。@Commonware根据facebook聊天和facebook应用程序，知道应用程序如何向聊天应用程序共享登录信息吗？谢谢