一般監聽網路變化是在 AndroidManifest 中註冊 BroadcastReceiver 來實現。 targetSdkVersion 升級到 24 後，發現靜態註冊廣播的方式要被取消了。

Declaring a broadcastreceiver for android.net.conn.CONNECTIVITY_CHANGE is deprecated for apps targeting N and higher. In general, apps should not rely on this broadcast and instead use JobScheduler or GCMNetworkManager.  
 

Android 7.0 為了後臺優化，推薦使用 JobScheduler 代替 BroadcastReceiver 來監聽網路變化。（地址）

手上暫時沒有 Android 7.0 的手機， 於是用 6.0 來測試了一下， 同時用 JobScheduler 和 BroadcastReceiver 監聽網路變化。 斷網後重新連線， BroadcastReceiver 收到系統通知後，JobScheduler 可能 10 秒內都接收不到事件，基本沒有實時性。

不過官方文件裡還有另一種方案，用 ConnectivityManager.NetworkCallback 來監聽網路。測試了一下，實時性和 BroadcastReceiver 一致。

BroadcastReceiver 會接收所有網路變化，具體狀態需要自己判斷。NetworkCallback 介面更加友好了，例如只監聽網路連線恢復。

ConnectivityManager connectivityManager = (ConnectivityManager) getSystemService(Context.CONNECTIVITY_SERVICE);

connectivityManager.requestNetwork(new NetworkRequest.Builder().build(), new ConnectivityManager.NetworkCallback
 
() {  
        @Override public void onAvailable(Network network) {
            super.onAvailable(network);
        }
    });

除錯時發現呼叫 requestNetwork 在 Android 6.0 系統出現許可權導致的崩潰，查了一下原來是個系統 Bug， Android 6.0.1 已修復。 那麼實際使用的話，還是得再將相容版本上升到 7.0 才行。

最後對於相容性：

1. 可以通過動態註冊 BroadcastReceiver 繼續使用。
2. 也可以判斷 API 24（N） 以上用 NetworkCallback， 低版本用 BroadcastReceiver。

另外， JobScheduler 的使用場景主要是優化後臺任務啟動時機，比如喚醒資料同步這種非實時性的後臺任務。 前臺執行時還是不適合用 JobScheduler 訂閱系統變化。