Android 7.0监听网络变化（转载）

一般监听网络变化是在 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 订阅系统变化。

   转载地址：http://blog.csdn.net/hqiangtai/article/details/53228510  （若是侵犯博主权益，联系鄙人，鄙人一定立即删除）