Android Oreo 中對後台任務的限制

01-27

簡評：就是不知道對國內這麼多的第三方系統效果會怎麼樣。

最近 Android O 終於正式發布了，給我們帶來了許多的改變。今天，這裡就介紹一下 Android O 中對後台任務的限制。

大家肯定都知道 Android 的後台任務一直都是耗電大戶，比如一些應用為了實現某些功能會讓後台服務一直保持運行，這不僅會增加耗電還會影響手機的性能。因此，在 Android O 中 Google 就做了一些改進，當然也就意味著我們的後台服務不能像以前一樣自由的運行在後台了。

對服務的限制

首先是對 Service 的修改：系統不再允許後台應用創建後台服務，當後台應用中嘗試調用 startService() 方法時會拋出 IllegalStateException。

而即使是在應用前台狀態時啟動的 Service，在應用退到後台的一小段時間後（幾分鐘）也會被系統停止，當 Service 被停止時等同於 stopSelf() 方法被調用。不過綁定服務不會受此影響。

當然，官方也提供了一些更好的方法：

Scheduling jobs

使用 JobScheduler 我們可以將需要後台服務運行而時效性要求又不高的任務交給系統來管理。比如我們可以基於網路連接狀況或設備電量來決定任務是否執行，這可以讓應用的後台任務執行的更有效率。

對於 Android 5.0 以下的設備，可以使用 Firebase Job Dispatcher。

前台服務

前台服務被認為是用戶主動意識到的一種服務，因此在內存不足時，系統也不會考慮將其終止。前台服務必須為狀態欄提供通知，放在「正在進行」標題下方，這意味著除非服務停止或從前台移除，否則不能清除通知。常見的場景有文件下載和音樂播放。

在以前我們是直接調用 startForeground()，現在 Android O 中提供了新的 startForegroundService() 方法。該方法本質上和 startService() 相同，只是要求 Service 中必須調用 startForeground() ，和 startService() 相比，可以隨時進行調用，即使當前應用不在前台。

我們可以這樣來實現：

首先，調用 startForegroundService() 並傳入要執行 Service 的 Intent。這時會創建後台服務，我們需要馬上將其提升到前台。
在執行的 Service 中創建一個通知，注意優先順序需要至少是 PRIORITY_LOW。
最後在服務內部調用 startForeground(id, notification)，注意在創建服務後，有五秒鐘來調用 startForeground()，如果沒有及時調用，系統將終止 Service 並聲明應用 ANR。

把任務推遲到應用前台

如果上面介紹的都不適用於你的應用，還可以就最簡單的把任務推遲到應用回到前台的時候。

對廣播的限制

Android Oreo 中另一項是對 Broadcast Receivers 的限制。針對 Android O 的應用將無法在 AndroidManifest.xml 中為隱式廣播（隱式廣播就是一種不專門針對當前應用的廣播，比如 ACTION_PACKAGE_REPLACED）註冊 Broadcast Receiver。

對此，我們有下面的三種替代做法：

首先，並不是所有的隱式廣播都被禁止了，也有少部分例外：

如果你所用到的隱式廣播在上面的清單中，那就不需要做什麼修改。

第二，相信很多開發者都已經了解 JobScheduler 了，開發者可以通過 JobScheduler 智能的執行任務，實現和註冊隱式廣播類似的功能。比如：

當設備網路連接狀態發生變化時；
當設備進入充電狀態時；
當 Content Provider 變更時執行任務。

最後，我們還可以用 registerReceiver() 來註冊 Broadcast receiver（無論是隱式還是顯式的），並遵循 Activity 的生命周期及時的 unregisterReciever()。

注意，雖然默認情況下這些限制僅適用於針對 Android O 的應用。不過，用戶是可以從 Settings 界面為任意應用啟用這些限制的（即使應用並不是以 Android O 為目標平台）。所以，還是建議大家儘早對自己的應用做相關的修改。

原文：Exploring Background Execution Limits on Android Oreo

日報擴展閱讀：

現代 Android 開發資源匯總