簡評：就是不知道對國內這麼多的第三方系統效果會怎麼樣。
最近 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 開發資源彙總
