當應用在後臺運行時，仍然會占用系統的內存。如果在後臺運行的應用比較多，並且用戶正在玩遊戲或者看視頻的時候，那麽很容易會導致系統卡頓。為了提升用戶體驗，Android O增加了對後臺應用的限制。這篇文章將介紹系統對後臺應用運行的限制，以及開發者應該如果修改應用以適應這個限制。
在Android系統中，很多應用和服務是可以同時運行的。比如說，用戶可以在壹個窗口中玩遊戲，在另壹個窗口中瀏覽網頁，同時使用第三個應用來聽音樂。同時運行的應用越多，系統的負載就越大。如果又有其他的應用或者服務在後臺運行的話，那麽又會增加系統的負載，最後導致系統卡頓，影響到用戶體驗，比如正在播放的音樂會突然停止。
為了減少系統卡頓，Android O限制那些用戶不再直接交互應用的運行。針對targetSdkVersion是Android O的應用，Android增加了以下兩種方式的限制：
大多數情況下，應用可以使用 JobScheduler 的Jobs來繞開上述的限制。即使應用沒有處於運行狀態，應用可以安排 JobScheduler 的Jobs來執行什麽工作，系統會在不影響用戶體驗的情況下，調度這些Jobs的運行。
後臺服務會占用系統資源，這個會導致糟糕的用戶體驗。為了解決這個問題，Android O對應用的後臺服務增加了壹堆的限制。註意這些限制僅僅是針對targetSdkVersion為Android O的應用，targetSdkVersion為25或者以下的應用不受影響。
系統會區分前臺和後臺應用。當滿足以下任意壹個條件時，系統判定應用是前臺的：
以上條件都不滿足，那麽應用就被系統認為是後臺應用。
前臺應用可以自由地運行前臺和後臺服務。當應用進入後臺之後，它仍然有幾分鐘的時間窗口來啟動和運行服務。當這個時間窗口到期時，應用就進入空閑狀態，系統將停止應用的後臺服務運行，這個操作和服務的 Service.stopSelf() 方法被調用類似。
某些情況下，後臺應用會被臨時加入到白名單中運行幾分鐘。應用在白名單中時，它可以啟動服務而不受限制，並且後臺服務也被運行。當需要處理對用戶可見的任務時，應用將被添加到白名單中，比如：
大多數時候，妳的應用都可以用 JobScheduler 替換掉後臺服務。比如，CoolPhotoApp需要檢查用戶是否接收到好友分享的圖片，即使應用不在前臺運行。按照之前的做法，應用需要使用後臺服務去執行這個任務。升級到Android O後，開發者需要用按壹定周期運行的Job替換掉後臺服務來執行，查詢服務器，完成後退出。
在Android O之前，創建壹個前臺服務的通常做法是先創建壹個後臺服務，然後將其提升到前臺 。但這個做法到了Android O已經失效了。Android O提供了另外壹個方法[ NotificationManager.startServiceInForeground() ]( /reference/android/app/NotificationManager.html#startServiceInForeground(android.content.Intent , int, android.app.Notification))，來創建前臺服務。用這個方法創建的新服務永遠不會進入後臺，所以不會受到後臺服務的運行限制。
如果應用註冊了廣播，那麽只要有廣播發送，應用的廣播接收器就會自動運行，占用系統資源。當很多應用都註冊了某個系統事件廣播時，那麽就會出現性能問題，因為當系統事件觸發廣播時所有的應用的接收器在很短的時間內都會被順序運行，這樣就會影響用戶體驗。為了解決這個問題，Android 7.0增加了對廣播的限制。Android O進壹步加強了這個限制。
大多數情況下，應用之前註冊的隱式廣播可以用功能類似的 JobScheduler 的job替代。比如，壹個社交圖片類- -應用經常會在設備充電時，清除使用過程中產生的數據。該應用會在Manifest註冊ACTION_POWER_CONNECTED廣播，當接收到這個廣播是，執行清理的工作。升級到Android O時，應用需要刪除註冊的這個廣播，然後使用壹個清理的job，這個job會在設備空閑並且充電時自動觸發執行。
有壹部分隱式廣播是不受這個限制的，應用可以繼續在Manifest中註冊使用，不管應用的targetSdkVersion是多少。這部分不受限制的廣播，可以查看 Implicit Broadcast Exceptions 。
上面介紹的這些變化不會影響到targetSdkVersion是25或者以下的應用 。但是如果應用是targetSdkVersion是Android O對應的API級別，需要修改應用以遵守這些新的限制。
如果應用在空閑狀態仍然在運行後臺服務，那麽妳需要替換掉這些後臺服務。可以采用如下的方案：
檢查在Manifest註冊的廣播，替換掉隱式廣播：