TileService被視爲前臺進程

Question

在Android O中，我們有一些新的background limitations。例如，我們只能通過Context.registerReceiver方法註冊隱式廣播。當系統殺死我們的進程時（例如由於內存不足），註冊的接收器也將被銷燬。

爲了減少系統殺死我們進程的機會，我們必須告訴系統這個過程仍然處於前臺。按照documentation一個應用程序被認爲是在前臺如有下列情況爲真：

• 它有一個明顯的活動，該活動是否已啓動或暫停。
• 它有一個前臺服務
• 另一個前臺應用程序通過綁定到其中一個服務或通過使用其中一個內容提供程序連接到應用程序。例如，應用程序是在前臺，如果另一個應用程序綁定到其：
  1. IME
  2. 壁紙服務
  3. 通知監聽
  4. 語音或文本服務

如果這些條件都不是真的，則應用程序被認爲是在後臺。

那麼在Android N中引入的TileService（用於快速設置瓷磚）呢？當我們在mainfest文件中註冊TileService爲ACTIVE_TILE時，系統在每次可見圖塊時都不綁定服務（如此article中所述），因此我們的服務綁定到另一個應用程序，面對系統進程。

那麼我的應用程序（只要將圖塊添加到快速設置窗格中）視爲前景應用程序？這將是很好的，因爲我不需要這種方法的持續通知，但用戶可以在後臺發送我的應用程序（通過刪除瓦片）

Answer 1

所以是我的應用程序（只要該圖塊被添加到快速設置窗格）被視爲前臺應用程序？

不正常。引用你鏈接到相應的文章： - 不要以爲你的服務一定會健在

請注意，您TileService將主要肯定是綁定（和銷燬），當用戶不在觀看瓷磚是非常重要的在onStartListening()/onStopListening()之外的一對方法。

因此，大多數情況下，您的服務將被解除綁定並銷燬。

：

---

系統不會每次（如本文中提到的）瓷磚變得可見時間

我的猜測是，你指的是這些段落綁定服務

在活動模式下，您的TileService仍將綁定爲onTileAdded()和onTileRemoved()（以及點擊事件）。但是，只有在您撥打TileService.requestListeningState()靜態方法後，才能回撥到onStartListening()。在收到onStopListening()的回調之前，您將可以更新您的瓷磚一次。這使您可以輕鬆實現一次性更新，無論瓷磚是否可見，數據更改時都可以更新瓷磚。

由於每當瓦片變得可見時活動瓦片不必被綁定，活動瓦片對系統健康狀況更好。構建活動拼貼意味着每次快速設置面板變得可見時系統需要綁定的進程就會減少。 （當然，該系統已經限制了基於可用內存等結合TileServices量，但那時你已經存儲器中顛簸的邊境附近 - 不是你想成爲）

我會預計會出現某種超時機制：如果您撥打requestListeningState()，則不要在X秒內更新磁貼，否則將撥打onStopListening()。聽音狀態不耐用;它只能用於一次更新。所以，系統應該及時地預測更新。如果TileService可以以這種方式無限期地綁定，我將測試這個場景並提交一個錯誤報告，因爲這是對系統資源的浪費。