我正在尝试制作一个在100％的时间内运行后台的优化应用程序。 它接收位置更新并将其发布到服务器。
我想知道我是否按照自己应有的方式做事。
此时我的应用程序有一个使用LocationServices API的requestLocationUpdates服务。 它会累积位置并尝试将它们发送到服务器。
如果没有其他位置待处理，此服务将自行终止。
此外，每次唤醒此服务都会发出警报。
因此，下次服务唤醒时，请启动新的GooglePlayServices会话并再次接收位置。
据我所知，使用pendingIntents更适合非托管位置跟踪，但我仍然认为需要后台服务及时上传位置。
- 我应该停止使用提醒报警服务吗？
- 有没有办法在没有用户干预/活动的情况下开始请求位置更新？
- broadcastReceiver是否能够管理网络发布等繁重的工作？
从谷歌locationServices doc获得this：
public abstract PendingResult<Status> requestLocationUpdates
(GoogleApiClient client, LocationRequest request, PendingIntent
callbackIntent)
使用指定的回调请求位置更新 的PendingIntent。
此方法更适用于后台用例 用于接收位置更新，即使应用程序已被杀死 系统。为此，请使用PendingIntent进行启动 服务。对于前台用例，LocationListener版本 建议使用方法，请参阅requestLocationUpdates（GoogleApiClient， LocationRequest，LocationListener）。
提前致谢
答案 0 :(得分：2)
有没有办法在没有用户干预/活动的情况下开始请求位置更新？
是的，您可以使用指定的频率创建设置警报的好方案。即使应用程序无法正常工作，您的警报也会唤醒设备，接收位置然后发送到服务器。完成工作后，设备再次休眠。请查看此project，这是来自commonsguy的超级方案。
broadcastReceiver是否能够管理网络发布等繁重的工作？
是的，确实如此，您可能会将位置发送到服务器。
我应该停止使用提醒报警服务吗？
取决于您的跟踪风格。请考虑示例
对于第一个示例，您可能会设置重复闹钟，然后唤醒设备，接收和发送位置，最后允许设备休眠（10分钟）。在这种情况下，您必须停止跟踪（位置服务，网络操作）的所有内容
但在第二个例子中，你不能用较低的频率设置闹钟，如5秒。你应该有不停止后台服务（理论上）并以5秒的间隔发出位置请求。在这种情况下，您不应该停止诸如（唤醒设备，位置请求，网络操作）之类的资源。最后用户卸载应用程序： - ）
下划线，请关注commonsguy＆＃39; project