用于位置跟踪的前台服务与 WorkManager

Posted 2023-04-14

【中文标题】用于位置跟踪的前台服务与 WorkManager

【英文标题】：Foreground service vs WorkManager for location tracking

【发布时间】：2021-01-20 23:26:03

【问题描述】：

假设我想构建一个应用程序，它定期请求当前位置（例如，每 10 分钟，这个数字应该是可配置的）并提交到服务器。

我知道对于这种情况，通常建议使用 Foreground Service 和 WorkManager。但是哪个更适合？以下是我的想法和疑问。

WorkManager - 主要用于保证执行的可延迟后台工作。但是我知道从 android 8 (API 26) 开始引入后台位置，并且限制位置每小时仅更新几次https://developer.android.com/about/versions/oreo/background-location-limits。因此这可能不符合要求的定期更新。

ForegroundService - 非常适合运行并需要让用户意识到的东西。出于隐私目的，建议用于这种情况（位置跟踪）。 Google 还创建了一个示例应用程序来推广这种做法https://github.com/android/location-samples/tree/master/LocationUpdatesForegroundService。

从上面的分析看来，ForegroundService 就是那个。但是我还发现WorkManager 内置支持通过androidx.work.impl.foreground.SystemForegroundService https://developer.android.com/topic/libraries/architecture/workmanager/advanced/long-running#long-running-kotlin 与ForegroundService 一起使用Worker

这让我对我应该使用什么以及 Google 对这个特定场景真正推荐什么感到困惑。

有人知道吗？

【问题讨论】：

您介意分享您的决定吗？

【参考方案1】：

如果您想以某种方式与服务通信，请使用前台服务，如果您想根据您在该工作管理器中所做的其他事情处理一些输入，则选择工作管理器。

工作经理没有选项来重新传递意图和所有其他命令，如启动粘性等...

由于工作管理器更适合与db同步数据，处理文件等。

如果您要问我，我会选择前台服务，因为您可以在清单中注册时向 xml 标记添加类型位置。

这两种解决方案都无法在 OEM 严格的电池限制条件下生存，因为 WorkManager 的工作可以推迟，如果我希望即时执行与唤醒锁相结合，我可以在前台服务中轻松完成，因为它还有一个很好用的 binder 选项用于 UI 同步。

【讨论】：

您好，您是否愿意分享您的建议，如果要求，如果操作系统终止向服务器发送定期位置更新的进程，更新也会发送到服务器以通知这已经发生，即不再接收位置更新。我认为前台服务具有更高的优先级，是的，这是维护位置更新过程的最佳方式，但是如果操作系统终止前台服务，我将如何通知服务器。

检查这一点的最佳方法是，定期向服务器发送位置更新并设置标志 hasEnded，如果始终为 false 并且后端检测到您在 30 秒内没有拨打电话，它应该发送推送通知，检查前台服务是否被终止并 ping API

您好，感谢您的建议。我希望在前台服务被杀死时会触发某种 onDestroy 事件。