requestForLocationupdates 是 Android 中的阻塞调用吗？
我想每 5 分钟更新一次位置，直到应用程序的生命周期为止。我知道如何更新位置。我想知道 requestForLocation 是否是阻塞调用。
我可以在 Service 类中执行此操作，但 Service 仅在主线程上运行，并且 Service 也可以随时被系统停止。我不希望这种情况发生。位置更新应该一直有效，直到应用程序进入内存为止。如果应用程序本身被杀死，那么显然服务也会被杀死。
实施这个的方法应该是什么？
I want to update the location every 5 mins till the lifecycle of the application. I know how to update the location. What I want to know is whether the requestForLocation is a blocking call or not.
I can do this in Service class but Service is run on main thread only and also Service can be stopped by the system anytime. I do not want this to happen. The location update should work till the application is in memory. If the application itself is killed then obviously the Service also gets killed.
What should be the approach for implementing this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
Android 中没有名为
requestForLocation()或requestForLocationUpdates()的方法。如果您指的是requestLocationUpdates()，那么这不是阻塞调用。用户和操作系统有权随时终止您的服务。在这种情况下，这是一件好事，因为您提出的计划浪费了 RAM，却没有任何好处。
使用
AlarmManager和类似于我的LocationPoller，这样您就可以获取您的位置数据，用它做一些事情，然后关闭直到下一个周期到来。另外，请允许您的用户配置轮询周期，包括“不轮询”选项。
There is no method named
requestForLocation()orrequestForLocationUpdates()in Android. If you meanrequestLocationUpdates(), this is not a blocking call.Users and the OS have the right to terminate your service whenever they wish. In this case, it's a good thing, because your proposed plan wastes RAM for no benefit.
Use
AlarmManagerand a service akin to myLocationPoller, so you can get your location data, do something with it, and shut down until the next period comes around.Also, please allow your users to configure the polling period, including an option for "do not poll".
由于某种原因，这个
requestLocationUpdates()调用确实会阻塞，至少在我测试的手机品牌中是这样。修复它的方法是使用它的重载之一。请参阅另一篇文章中的答案。For some reason this
requestLocationUpdates()call is really blocking, at least in the phone brands that I tested. The way to fix it is to use one of its overloads. Please see this answer in another post.