TileService是否被视为前台进程？

Question

在 Android O 中，我们有一些新的后台限制。比如说，我们只能通过 Context.registerReceiver 方法注册隐式广播接收器。当系统杀死我们的进程（例如因为内存不足）时，已注册的接收器也将被销毁。

为了减少系统杀死我们的进程的机会，我们必须告诉系统这个进程仍然处于前台。根据文档，如果以下任何一项为真，则认为应用程序处于前台：

• 它有一个可见的活动，无论该活动是启动还是暂停状态。
• 它有一个前台服务
• 另一个前台应用程序连接到该应用程序，即通过绑定到其服务之一或使用其内容提供程序之一。例如，如果另一个应用程序绑定到其：
  
  1. IME
  2. 壁纸服务
  3. 通知监听器
  4. 语音或文本服务

如果上述条件都不成立，该应用程序将被视为在后台运行。

那么，在Android N中引入的快速设置瓷砖TileService呢？当我们在清单文件中将TileService注册为ACTIVE_TILE时，系统不会每次瓷砖变得可见时都绑定服务（如文章所述），因此我们的服务会绑定到另一个应用程序，实际上是系统进程。

那么，只要瓷砖添加到快速设置窗格中，我的应用程序是否被视为前台应用程序？这很好，因为我不需要使用持久通知，并且用户仍然可以将我的应用程序发送到后台（通过删除瓷砖）。

- Cilenco

Answer 1

只要将瓷砖添加到快速设置窗格中，那么我的应用程序就被视为前台应用程序吗？通常不是这样的。引用您链接的文章中的话：“重要的是要注意，当用户未查看瓦片时，您的TileService将大多数情况下是未绑定（和销毁）-不要假设您的服务在onStartListening() / onStopListening()方法之外是活动的。”因此，大部分时间，您的服务将未绑定并且已销毁。系统并不会每次瓦片出现时都绑定服务（如本文所述）。我猜您指的是以下段落：“在活动模式下，您的TileService仍将绑定到onTileAdded()和onTileRemoved()（以及单击事件）。但是，只有在调用静态TileService.requestListeningState()方法后才会回调onStartListening()。然后，您可以在接收到onStopListening()的回调之前仅更新您的瓦片一次。这使您能够轻松地一次性更新您的瓦片，无论瓦片是否可见。由于活动瓷砖不必每次瓷砖变为可见状态时都绑定，因此活动瓷砖对于系统健康状况更好。构建活动瓷砖意味着系统需要绑定的进程较少，每次快速设置面板变为可见。 （当然，系统已经限制基于可用内存等因素的已绑定TileServices的数量，但到那时，您已经接近内存抖动的边界-这不是您想要的地方。）”我期望有一种超时机制：如果调用了requestListeningState（），则在X秒内不更新瓦片，您将使用onStopListening()被调用。监听状态不耐久；它仅存在一个更新中。因此，系统应该按时期望更新。如果可以无限期地绑定TileService，则会浪费系统资源，我将测试此场景并提交错误报告。

- CommonsWare

---

使用TileService相比前台服务有什么优势？ - IgorGanapolsky

实际上，我发现TileService的一个优点是它会在设备启动时自动启动。我们无法使用前台服务来做到这一点。只有WorkManager可以做到。 - IgorGanapolsky

@IgorGanapolsky：“我们无法使用前台服务来完成这个任务” - 您可以使用“ACTION_BOOT_COMPLETED”接收器来启动前台服务。 - CommonsWare

据我上次检查，一个“Service”无法显示“Dialog”。它可以启动一个对话框主题的“Activity”。如果“Activity”出于某种原因需要与“Service”交互，则应绑定到该“Service”，以防止“Service”被销毁。可能有一些限制会阻止这样做，但我目前想不到任何限制。 - CommonsWare

@CommonsWare 这是针对 TileService 特定的。https://developer.android.com/reference/android/service/quicksettings/TileService#showDialog(android.app.Dialog) - tom-pratt