是否将TileService视为前台进程

Question

在Android O中，我们有一些新的background limitations。例如，我们只能通过Context.registerReceiver方法注册隐式广播。当系统终止我们的过程时（例如由于内存不足），注册的接收器也将被销毁。

为了减少系统杀死我们进程的可能性，我们必须告诉系统此进程仍然在前台。根据{{​​3}}，如果满足以下任何条件，则认为app位于前台：

  

  
• 无论活动是开始还是暂停，它都有可见的活动。
  
• 它有前台服务
  
• 另一个前台应用程序通过绑定到其中一个服务或使用其中一个内容提供程序连接到应用程序。例如，如果另一个应用程序绑定到它，应用程序就在前台：      
    
  1. IME
    
  2. 壁纸服务
    
  3. 通知听众
    
  4. 语音或文字服务
    
  

如果这些条件都不成立，则认为应用程序在后台。

Android N中引入的TileService（用于快速设置磁贴）怎么样？当我们在mainfest文件中注册TileService为ACTIVE_TILE时，系统不会在每次切片可见时绑定服务（如此documentation中所述），因此我们的服务绑定到另一个应用，面对系统过程。

我的应用程序（只要将图块添加到快速设置窗格中）被视为前台应用程序吗？这样会很好，因为我不需要使用这种方法的持久通知，但用户可以在后台发送我的应用程序（通过删除磁贴）

Answer 1

  

我的应用程序（只要将图块添加到快速设置窗格中）也被视为前台应用程序吗？

不正常。引用您链接到的文章：

  

重要的是要注意，当用户未查看磁贴时，您的TileService肯定会被解除绑定（并销毁） - 不要认为您的服务将在{{1}之外存在} / onStartListening()一对方法。

因此，大多数情况下，您的服务将被解除绑定并被销毁。

  

每次瓷砖变得可见时，系统都不会绑定服务（如本文所述）

我的猜测是你指的是这些段落：

  

在主动模式下，您的onStopListening()仍然会被TileService和onTileAdded()绑定（对于点击事件）。但是，在您调用静态onTileRemoved()方法之后，唯一一次收到onStartListening()的回调。然后，您可以在收到TileService.requestListeningState()的回调之前准确更新您的磁贴一次。这为您提供了一种简单的一次性功能，可以在数据发生变化时更新您的磁贴，无论磁贴是否可见。

     

由于每次瓷砖变得可见时都不必绑定活动切片，因此活动切片更适合系统健康。构建活动切片意味着每次快速设置面板变为可见时系统需要绑定的进程较少。 （当然，系统已根据可用内存等限制了绑定onStopListening()的数量，但到那时你已经接近内存颠簸的边界 - 而不是你想要的位置。）

我希望有某种超时机制：如果你打电话给TileServices，那么不要在X秒内更新磁贴，你将使用requestListeningState()来调用。聆听状态不耐用;它只适用于一次更新。因此，系统应该期待及时更新。我将测试这个场景，如果onStopListening()可以无限期地绑定，我将提交错误报告，因为这会浪费系统资源。