是否有适用于Android的设计模式，用于定义多个活动应如何访问单个服务？

Question

我正在开发一个Android数据输入应用，可将输入的数据保存到文件中。使用文件名启动Service（我们称之为FileIOService），并加载并保存从用户访问的每个Activity传递给它的数据。

我正在努力让整个应用程序尽可能健壮，目前我觉得我需要特别注意每个Activity和Service之间的互动。以下是我可以看到的问题：

• 如果Service被系统杀死，则需要重新启动并打开已打开的文件：我可以使用START_REDELIVER_INTENT处理此问题。
• 如果Activity被销毁，例如方向更改，则需要重新连接到Service。

问题是，一旦Activity启动了服务，在服务完成打开文件并为I / O请求做好准备之前还有一段时间。为了解决这个问题，在我的活动中，我有两个：

• 内部类继承ServiceConnection，其onServiceConnected()方法已完成
• 对BroadcastReceiver的匿名内部子类的私有引用，其handleMessage()方法已完成。当服务发出广播以指示它已完成打开其文件时，将调用此方法。

然后，这两种方法都会调用setUpActivity()方法从Service中提取数据。这是它开始变得难看的地方。因为onServiceConnected()可能在文件准备好进行I / O之前运行，并且handleMessage()可能会在Service未绑定到Activity时调用，所以我必须同时进行handleMessage()和onServiceConnected()设置布尔标志，以后可以在setUpActivity()中进行检查，如下所示：

if ((fileLoaded && serviceConnected))
{
    //access the file data
}

正如我所说，这感觉很丑陋，并且依赖于设置额外的布尔变量。

还有另一个问题 - 如果我的Activity启动外部Activity，就像相机应用一样，在返回我的应用后，Service和Activity可能都已被销毁（尤其是方向更改时）应用程序崩溃。

我的感觉是，我可能会遗漏一些整体模式，这些模式将定义每个Activity应该如何与Service相关联，反之亦然，同时保持强大并能够应对意外终止/重启。

Answer 1

让我们忽略这样一个事实，即我怀疑这是一个服务的有效用例（一种服务的存在只是为了读写文件？）。

  

如果服务被系统杀死，则需要重新启动并打开已打开的文件：我可以使用START_REDELIVER_INTENT处理此问题。

该服务不会“被系统杀死”。 进程被系统杀死。这将消除您的活动以及您的服务。

一个可能的例外是，如果用户从“设置”手动停止服务（并且仅服务），在这种情况下，我不知道预期的行为是什么。现在这应该是相当不常见的，特别是对于用户刚刚使用的应用程序。用户将更倾向于使用任务管理器，例如从最近任务列表中刷你的应用程序，这将消除整个过程，而不仅仅是服务。

  

如果活动被销毁，例如通过方向更改，则需要重新连接到服务。

不一定：

• 使用Application上下文（getApplicationContext()）绑定，而不是直接使用Activity绑定

• 使用保留的片段来维护配置更改中的绑定

  

我的感觉是，我可能会遗漏一些整体模式，这些模式将定义每个活动应该如何与服务相关联，反之亦然，同时保持健壮并能够应对意外终止/重启。

这是我试图完全避免绑定模式的众多原因之一。使用服务处理命令，通过startService()发送，结果（如果有）由LocalBroadcastManager或奥托，或greenrobot的EventBus，或“真实”广播Intent传递，或者可能一个Messenger。特别是当服务是IntentService时，当没有更多的工作要做时，服务会很好地清理。