Android 服务中的LocationManager和网络

我在这个项目上工作，我需要位置更新和数据上传，即使主应用程序不在前台。我正在考虑将所有位置和网络功能放在一个服务中（为了论证起见，是XService），并在同一进程中使用广播在活动（Main）和XService之间进行通信（其他应用无法访问）

我尚未编写代码，但工作流程如下：

1。主-开始。在onCreate中，启动一个新线程，并在其上 实例化并绑定XService
2。主-登录屏幕。获取数据， 将其打包成一个Intent并广播到XService
3。X服务-- 接收广播，解包意图。设置套接字和数据流。安装程序 LocationManager用于更新。向主广播网络正在运行 准备好的每次LocationManager更新时上载数据
4.Main——接收到网络就绪广播后，准备初始化和广播的意图
5。XService—接收 初始化请求广播、解包、执行网络任务， 广播回应
6。根据用户要求重复广告 交互和任何定时更新
x。主--注销时， 向XService广播
x+1。XService--将注销信息发送到 服务器，关闭套接字，向Main广播它正在退出 优雅地，然后停止self（）
x+2主-完成注销 程序

我的主要问题是——这是正确的方式吗

---

另一个问题是：当XService向Main广播位置更新，但Main停止（即不在前台运行）时会发生什么？我假设，由于Main处于停止状态，所以Main上的BroadcastReceiver没有实例化，因此广播基本上什么也不做。这种未接收到的广播对X服务或进程/设备的总体影响（或不影响，视情况而定）？

这是有意义的。我的建议是在主线程上启动服务，然后在服务类中形成新线程。这将很好地打包服务，这样您就不必生成线程来使用它，您可以直接调用它

如果Main停止，广播发送消息，则消息丢失。您希望通过在OnStart注册接收者和在OnStop取消注册来避免这些问题。您可以在服务本身中保存活动可能需要知道的任何相关信息

---

Messenger类是广播接收器的替代品。（）

Re:Thread in Service代替Main:建议不错，谢谢。它肯定会使跟踪线程变得更容易。我想你的意思是我应该在桌面上注销接收器（而不是启动）。当活动启动时，它可以向服务请求所需的信息。Messenger类看起来很有趣。我还需要做更多的研究，看看它是否更适合我的需要。啊，是的，这就是我的意思。是的，messenger类非常棒，我在这个应用程序中使用了它，在这个应用程序中，我不断使用服务中的位置数据更新活动。您是否计划使用更新的位置API，如locationServices或locationClient（现已弃用）？实际上，我的应用程序是互联网隐私研究的一部分，因此参与计算的各方越少，我就越容易分析数据。因此，我将使用普通的android.location库和类，这样我就不必在我的研究中考虑Google Play服务（包含位置服务）。