android - 远程服务有多糟糕？

Question

我正在考虑在我的应用程序中使用远程服务，但我在 this thread 中的 CommonsWare 答案中看到了(和其他线程)远程服务似乎有很多缺点/问题，比如浪费 CPU、内存和电池生命周期。这让我犹豫了。所以我想先由这里的专家运行我的想法:

问题 #1:鉴于我的应用程序(如下)，您认为使用远程服务是个坏主意吗？或者，这是正确的方法？

我的应用程序有两个部分，一个在 PC 上运行的 Wi-Fi 客户端，一个在 Android 上运行的 Wi-Fi 服务器。它们通过Socket来回传输位于SD存储卡中的应用程序数据文件。 Android 应用程序有超过 48,000 行代码，我会说相当大。当它启动时，它会自动启动服务。然后该服务创建一个单独的线程，该线程调用 ServerSocket.accept() 来监听线路。用户可以按 PC 上的按钮启动文件传输，即使 Android 应用程序未运行。

我了解服务的生命周期独立于 Activity ；我不介意用户是否可以通过设置终止应用程序和服务——他终止了它，他将不得不再次启动应用程序以启动服务器。他选择了杀死它，他将自己开始。

但是如果Android系统在用户不知情的情况下杀死了进程怎么办？在这种情况下，用户不知道 Wi-Fi 服务器已死，当他在 PC 上单击按钮时会收到错误消息。因此，我希望即使进程被系统杀死，服务器也能继续运行。因此，我认为远程服务就是答案。或者，是吗？

问题 #2:如何在应用和远程服务之间建立简单的单向通信？

两者之间的唯一通信是应用程序需要知道服务的状态，比如它是否正在监听套接字，或者它是否仍在运行等。如果死了，用户可以从应用程序的用户界面重新启动它。

不想用AIDL，好像有点大材小用；全局变量不起作用，因为它们不在同一个进程空间中；甚至 Application 单例似乎也不起作用。所以现在我正在考虑使用共享首选项，或者在内部存储中创建一个文件。我还没来得及试验这些想法，但它们行得通吗？如果没有，还有更好的主意吗？

感谢您阅读本文!

Answer 1

1. 远程服务与普通服务类似。唯一的区别(我猜)是它可以从其他应用程序和服务访问(它是一个导出服务)。因此，如果您希望多个应用程序可以访问您的服务，那么您可以将其设为远程。但就您而言，我认为您可以只为您的应用程序提供服务。为了让您的服务保持运行，您应该查看前台服务。它们是普通服务，它们只是通过命令startForeground启动的。这些服务android系统会尽可能长时间地保持运行。

2. 实际上，您的情况不是单向的。你向你的服务询问状态，服务应该询问。如果您不选择远程服务，那么在您的应用程序中您可以只调用服务方法 ( extending Binder class )。对于远程服务，我认为您可以使用两个 Messengers 或 AIDL。