记一次网络判断问题

很久没更新,换新工作后一直比较忙,也没有什么好分享的新技术,就记录一次碰到的坑。

1. 一般情况下的网络判断

一般我们开发的时候都会碰到需要判断网络状态然后做不同逻辑的处理的需求。然后一般比较多的做法就是适应ConnectivityManager、NetworkInfo这些方法去判断,例如我随便去网上找一段代码


    public static boolean isAvailable(Context context){
        boolean isAvailable = false ;
        ConnectivityManager cm = (ConnectivityManager) context.getSystemService(Context.CONNECTIVITY_SERVICE);
        NetworkInfo networkInfo = cm.getActiveNetworkInfo();
        if(networkInfo!=null && networkInfo.isAvailable()){
            isAvailable = true;
        }
        return isAvailable;
    }

一般做判断确实是能判断出当前是否有网,最直接能测试到的就是你开wifi和关wifi会得到不同的结果。
但是其实这个做法并不能去适配所有的情况,比如是你的路由器开着,但是没网,实际上设备是能收到这个路由器的wifi的,只是上不了网而已。而这种情况用上边的方法就无法判断出。
其实网上很多方法能判断是否有网络,而我尝试过很多种不同的写法,都无法检测出这种情况,如果有大佬确实知道能使用Android内部的方法来判断这种情况,还请留言给我

2.使用ping

既然正常的方法我们无法使用,那就只能使用一些黑科技了,我们可以去ping一个可靠的地址来判断是否有网,毕竟我们在电脑上也经常这样做。再随意从网上找段代码抄下来

private boolean ping() {
        try {
            Process process=Runtime.getRuntime().exec("/system/bin/ping -c 4 "+"www.baidu.com") ;
            int status = process.waitFor();
            if (status == 0) {
                return true;
            } else {  
                return false;
            }
        } catch (IOException e) {
            e.printStackTrace();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        return false;
    }

大概这种写法,我没试过,但这种方法是肯定能成功的,如果不成功,去网上抄另一份代码就行。
那么问题来了,这样的方法就一定可靠吗,其实不一定可靠,比如说你得找一个可靠的ip,不然这个地址挂了的话判断就不准了。不仅如此,以我多年使用黑科技的经验,一般使用黑科技都会很多坑。

3.请求一个自家的接口

这可以算是一个用逻辑上去解决的方案,而且比ping可靠。按照这个思路去写,相信很多人都会,就请求一个自家的接口,请求成功就是正常,请求失败就没网。当然还要做更细微的判断,总不能你家接口返回500你也把它定义成没网吧。

但是一般来说,现在大多数Android开发使用的网络请求框架都是基于okhttp的。经过测试,我发现,在连上wifi但无网的情况下去请求后台接口,会花费很长时间,不会马上就给到结果。
所以我们需要去设置一个超时时间,一般okhttp设置超时时间都是在OkhttpClient中设置

OkHttpClient.Builder builder = new OkHttpClient.Builder()
                .connectTimeout(3, TimeUnit.SECONDS)
                .readTimeout(3, TimeUnit.SECONDS)

但其实经过测试你会发现,这样设置并没有效果。直到我看到了一篇文章“Okhttp解析DNS超时”,是我才学苏浅不完全熟悉网络相关的知识点,但我认为这个超时应该指的是解析DNS的超时,而不是连接的超时,尝试去写

 OkHttpClient.Builder builder = new OkHttpClient.Builder()
                .connectTimeout(3, TimeUnit.SECONDS)
                .readTimeout(3, TimeUnit.SECONDS)
                .retryOnConnectionFailure(false)
                .dns(new Dns() {
                    @Override
                    public List<InetAddress> lookup(String hostname) throws UnknownHostException {
                        if (hostname == null) {
                            throw new UnknownHostException("hostname == null");
                        } else {
                            try {
                                FutureTask<List<InetAddress>> task = new FutureTask<>(
                                        new Callable<List<InetAddress>>() {
                                            @Override
                                            public List<InetAddress> call() throws Exception {
                                                return Arrays.asList(InetAddress.getAllByName(hostname));
                                            }
                                        });
                                new Thread(task).start();
                                return task.get(3000, TimeUnit.MILLISECONDS);
                            } catch (Exception var4) {
                                UnknownHostException unknownHostException =
                                        new UnknownHostException("Broken system behaviour for dns lookup of " + hostname);
                                unknownHostException.initCause(var4);
                                throw unknownHostException;
                            }
                        }
                    }
                })

最后发现这样的做法确实有效,无网的情况确实能很快的返回结果。
所以我认为判断网络请求的操作可以结合1和3,基本能解决大部分的这类问题

4.事情并没这么简单

你以为故事到这里就结束啦?事情远没你想象的这么简单,用上面的方法,能够正常判断出有网、无网、有wifi但无网这3种情况。
但是我发现了另一种情况,我们平时有在公共场所连接过一些网络,而那些网络会要求你去输入账号密码登录校验,是否授权给你上网。
而在那种网络的情况下,依旧会存在一些概率,你请求这个你自己的接口是有网的,但是可能下一秒实际你的设备就断网了。
实际上我们要实时监听网络的改变情况,可以注册系统的一个广播进行监听,ConnectivityManager.CONNECTIVITY_ACTION这些。
但是在这类情况下断网,这些广播是没有推送给你网络状态变化的。
不止这些情况,说不定还存在更多其他的特殊情况,所以我的结论是上面的方法能解决大部分情况下的问题,但无法解决所以问题,并不是完全可靠

其他的我需要恶补这部分的知识再来更新这篇文章。

推荐阅读更多精彩内容