前言#
大家好，大概有一个多月没有更新博客了，我是干什么去了呢？很明显，程序员当然要加班……这一次跟大家分享一下新项目的一些心得。
监听网络变化在开发中是经常用到的，例如我们断网有一些友好的提示，或者根据不同的网络更改一些加载策略，例如wifi看视频，非wifi则会有一个提示，还有极个别更恶心的偷摸的在后台给你下各种安装包，是谁我就不一一列举了。
在5.0以前，我们都是广播BroadcastReceiver，注册跟网络变化相关的广播，然后判断是连接还是断开，这种做法非常方便，但是随着安卓的版本迭代，在权限上越来越谨慎，广播的方式就显得不太优雅。
打个比方，之前就是拿个大喇叭，在大街上各种喊，就好像逛地摊，各种商品的吆喝声混在一起，需要你自己去分辨哪些是你想要的信息，而且又显得很不安全，万一卖的商品比较隐私呢，大家都是很低调的人。
所以在安卓5.0以上终于对网络的监听进行了优化，那就是通过Callback回调的方式，这种开发模式是不是很常用？例如监听下载进度，我只需要三个回调：下载成功，下载失败，下载的进度变化，这种回调方式针对性强，耦合性低，非常方便，和广播相比，就好像我们是一个订购了服务，需要的东西自动上门，very good。
废话铺垫了这么多，下面就是一个实战demo。
正文#
public class MainActivity extends AppCompatActivity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) {
ConnectivityManager connectivityManager = (ConnectivityManager) getSystemService(Context.CONNECTIVITY_SERVICE);
// 请注意这里会有一个版本适配bug，所以请在这里添加非空判断
if (connectivityManager != null) {
connectivityManager.requestNetwork(new NetworkRequest.Builder().build(), new ConnectivityManager.NetworkCallback() {
/**
* 网络可用的回调
* */
@Override
public void onAvailable(Network network) {
super.onAvailable(network);
Log.e("lzp", "onAvailable");
}
/**
* 网络丢失的回调
* */
@Override
public void onLost(Network network) {
super.onLost(network);
Log.e("lzp", "onLost");
}
/**
* 当建立网络连接时，回调连接的属性
* */
@Override
public void onLinkPropertiesChanged(Network network, LinkProperties linkProperties) {
super.onLinkPropertiesChanged(network, linkProperties);
Log.e("lzp", "onLinkPropertiesChanged");
}
/**
* 按照官方的字面意思是，当我们的网络的某个能力发生了变化回调，那么也就是说可能会回调多次
*
* 之后在仔细的研究
* */
@Override
public void onCapabilitiesChanged(Network network, NetworkCapabilities networkCapabilities) {
super.onCapabilitiesChanged(network, networkCapabilities);
Log.e("lzp", "onCapabilitiesChanged");
}
/**
* 在网络失去连接的时候回调，但是如果是一个生硬的断开，他可能不回调
* */
@Override
public void onLosing(Network network, int maxMsToLive) {
super.onLosing(network, maxMsToLive);
Log.e("lzp", "onLosing");
}
/**
* 按照官方注释的解释，是指如果在超时时间内都没有找到可用的网络时进行回调
* */
@Override
public void onUnavailable() {
super.onUnavailable();
Log.e("lzp", "onUnavailable");
}
});
}
}
}
}
这就是今天的全部代码了，上面已经有了响应的注释，但是还是不够便于我们理解，接下来就仔细的研究一下：
1、首先我们打开app，此时网络是连接的状态：
一打开demo，我们立刻就得到了onAvailable的回调，意思就是网络目前可用，这一点比广播强多了，因为我们已启动还要单独处理一次，而通过回调的方式，可以立刻得到当前的状态。
2、然后我们手动关闭网络：
哎？没有onLosing的回调，只看到了onLost，说明我们手动关闭网络连接是一个很粗暴的行为，就像官方注释上写的，如果是一个生硬的断开，他可能不回调。
3、最后我们再次连接网络：
这次的回调就比较多了，首先是onAvailable，显示网络可用，然后是onCapabilitiesChanged，说此时网络的连接能力发生了第一次变化，估计是连接中把，再然后是onLinkPropertiesChanged，说明连接的属性已经发生了变化，此时应该获得了ip地址等信息，最后又回调了onCapabilitiesChanged，那么应该是网络进度到可用的状态。
总结#
我没有模拟出onLosing和onUnavailable的场景，至少说明他俩的出现的概率现在已经不高了，我们已经通过注释简单理解了他俩的场景，这里就不做深入研究了。
通过刚才的实验，我们得出了一下结论：
1、要想监听网络的连接和断开，应该在onAvailable和onLost中，他们一定会成对出现。
2、其他的几个回调使用场景会少一点，并且onCapabilitiesChanged会回调多次，所以使用它时我们要慎重，避免重复的操作，但是可以保证最后一次回调，网络的连接一定是连接成功的。
OK，从这个小小的变化，我们看到了安卓在慢慢变得更好，使用起来更简洁更优雅，这也加大了某些素质低的厂商想尽办法后台干点坏事的行为。
今天就到这里，有什么问题大家一起留言讨论~
补充#
1、记得申请权限：
<uses-permission android:name="android.permission.CHANGE_NETWORK_STATE" /> <uses-permission android:name="android.permission.WRITE_SETTINGS" />
尤其是WRITE_SETTINGS，这个需要手动申请，千万别忘了。
