android 5.0 以上监听网络变化

2018-01-12 11:17:39来源:https://www.jianshu.com/p/ca1d927ab119作者:珠穆朗玛小王子人点击

分享

前言#

大家好,大概有一个多月没有更新博客了,我是干什么去了呢?很明显,程序员当然要加班……这一次跟大家分享一下新项目的一些心得。


监听网络变化在开发中是经常用到的,例如我们断网有一些友好的提示,或者根据不同的网络更改一些加载策略,例如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,此时网络是连接的状态:




image

一打开demo,我们立刻就得到了onAvailable的回调,意思就是网络目前可用,这一点比广播强多了,因为我们已启动还要单独处理一次,而通过回调的方式,可以立刻得到当前的状态。


2、然后我们手动关闭网络:




image

哎?没有onLosing的回调,只看到了onLost,说明我们手动关闭网络连接是一个很粗暴的行为,就像官方注释上写的,如果是一个生硬的断开,他可能不回调。


3、最后我们再次连接网络:




image

这次的回调就比较多了,首先是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,这个需要手动申请,千万别忘了。





最新文章

123

最新摄影

闪念基因

微信扫一扫

第七城市微信公众平台