前言
最近实验室的项目需要实现–在手机与单反的wifi连接之后,加载单反中的图片.这其中就涉及到我们在Android开发中经常遇到的功能-图片加载.

关于图片加载,不同程度的实现也会遇到不同程度的问题

可能起初我们只是想加载出来一张图片,这个问题很好解决.

后来我们可能还要加载大量的图片(几百KB的那种)到页面上,这个也不是很难…

但是如果想要优雅的做好符合用户体验的图片加载,如何做好缓存.下拉刷新…都是需要做的.
所以最近会写一些关于图片加载的系列博文,希望对大家有所帮助,
前两天做了一个demo,试了试加载手机里的所有图片,算作这个系列的开端.
效果图


这是加了日期分组的效果,这个我们下一篇再讲怎么把按照日期分组的.

查找手机里所有图片的 关键代码:
/**
     * 查询手机里所有的图片
     */
    public void initAllImgInThePhone() {

        String[] projection = {
                MediaStore.Images.Media.DATA,
                MediaStore.Images.Media.DISPLAY_NAME,
                MediaStore.Images.Media.SIZE
        };
        //全部图片
        String where = MediaStore.Images.Media.MIME_TYPE + "=? or "
                + MediaStore.Images.Media.MIME_TYPE + "=? or "
                + MediaStore.Images.Media.MIME_TYPE + "=?";
        //指定格式
        String[] whereArgs = {"image/jpeg", "image/png", "image/jpg"};
        //查询
        Cursor cursor = getContext().getContentResolver().query(
                MediaStore.Images.Media.EXTERNAL_CONTENT_URI, projection, where, whereArgs,
                MediaStore.Images.Media.DATE_MODIFIED + " desc ");
        List<String> dateList = new ArrayList<>();//存放图片的路径
        while (cursor.moveToNext()) {
        	String fileName = cursor.getString(cursor.getColumnIndex(MediaStore.Images.Media.DISPLAY_NAME))//获取图片名.
        	long size = cursor.getLong(cursor.getColumnIndexOrThrow(MediaStore.Images.Media.SIZE));//获取文件大小.
            byte[] data = cursor.getBlob(cursor.getColumnIndex(MediaStore.Images.Media.DATA));//图片在手机里的路径
            String dataStr = new String(data, 0, data.length - 1);//路径转换成字符串
            File file = new File(dataStr);
            long time = file.lastModified(); //记录此图片的上次修改时间
            SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd");
            String dateStr = sdf.format(time); // 2019-04-10
           
        }
    }


通过contentResolver内容提供器,轻松获得所有自己想要的格式的图片,接下来如何加载到屏幕上大家应该都知道.

在把每个图片的路径放到list中.
把list传给adapter
在adapter的onBindViewHolder中,通过图片路径加载图片到对应的ImageView中.

如果还有不清楚的地方,可以到我的仓库查看全部源码>图片加载.

(完~)

     毫无疑问，SDWebImage绝对是我们平时做项目使用频率最广的第三方框架之一，良好的封装性和性能，真的是非常优秀，最近项目中使用了这个库函数加载网络图片，但是发现了一个问题，就是有时候网速不太好，比如当前的WiFi的信号不太强，这个时候图片就会加载不出来，这个本来无可厚非，网速嘛，总是有好有坏的啊，不过当切换到比较流畅的网速的时候，比如从wifi过渡到4G,这个时候惊讶的发现，之前加载失败的图片再也没有机会重新加载出来，仔细查了下资料才发现问题的所在，我在设置加载网络图片的时候用的函数是：


  


    albumImageView.sd_setImage(with: URL.init(string:model.poster!), placeholderImage: UIImage.init(named: "img_ph_460"))，


这个时候发现，失败了就不会再加载了，除非退出应用，所有的东西重新来过一次，但是这么猛的库应该不纯在这个问题，后来查找之后才发现，SDWebImage里面有个说明，如果加载某个图片的URL失败，SDWebImage会把这个地址加入一个黑名单，后面就不会再重新加载这个URL请求，所以才会一次失败，再也没有机会，解决的办法如下，写法为：


        albumImageView.sd_setImage(with: URL.init(string:model.poster!), placeholderImage: UIImage.init(named: "img_ph_460"), options: SDWebImageOptions.retryFailed)，


即设置个option，让他加载失败的时候再次尝试，这样就解决了上述的问题

1、概述

Glide作为Google推荐的一套快速高效的图片加载框架，有很多人都在使用，我也不例外。不过在项目的需求中，难免会遇到一个这样的需求：在非WiFi环境下，需要手动点击才能下载图片。 

这初步实现起来是很简单的，但一些细节却不好解决。比如，在使用移动数据的情况下，我不能去自动加载图片，但已经缓存过的图片我们得让他自动显示出来。这个时候我们会发现，Glide没有直接的、明确的接口去立马判断某图片（Url等）是否已经缓存了。 

为了实现这个功能，我们就只能自己去Glide的缓存目录寻找那图片是否已经缓存下来了，但Glide缓存文件名字是不会是Url或图片文件名，因此我们得采取一些其他手段。

若我的思路中有如何错误，欢迎指正。

另外，在此感谢郭神的Glide解析，为我解决这个问题提供帮助（博客指路：Android图片加载框架最全解析（三），深入探究Glide的缓存机制）



2、实现

（PS. 以下代码是对在非WiFi环境下，需要手动点击才能下载图片这一需求的完全实现）



（1）、初步的判断



    /**
     * 加载图片
     *
     * @param context      加载这个行为所处的Activity或Fragment
     * @param url          图片的网址
     * @param imageView    加载到哪个ImageView上
     * @param widthPixels  图片的宽
     * @param heightPixels 图片的高
     */
    public static void loadNetworkImage(final Context context, final String url, final ImageView imageView, final int widthPixels, final int heightPixels) {
        if (isLoadFailed(imageView)) { // 判断是否是正在加载中的ImageView
            return;
        }
        imageView.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                if (isLoadFailed(imageView)) { // 判断是否加载失败
                    loadImage(context, url, imageView, widthPixels, heightPixels);
                } else if (!isLoading(imageView) && sOnImageViewClickListener != null) { // 判断是否加载中 与 是否有设置监听
                    sOnImageViewClickListener.onClick(v);
                }
            }
        });
        if (AppUtil.loadIsManualLoadPhotoInNotWiFi(context) && !NetworkUtil.isWifi()) { // 判断用户是否开启了 在非WiFi环境下，需要手动点击才能下载图片，后在判断是否处于WiFi中
            loadCacheImage(context, url, imageView, widthPixels, heightPixels);
            return;
        }
        loadImage(context, url, imageView, widthPixels, heightPixels);
    }

这里的第一个if判断是为了不让ImageView在RecyclerView等控件中，应滑动关系而不断刷新布局而设定的，避免多次对同一控件调用加载图片。

中间的OnClickListener自然是为了让图片加载失败后可以重新加载，或者是给用户手动点击加载而用，其中里面第二个if判断是为了解决在加载成功后，还需要对图片控件进行点击，从而进行其他逻辑（如QQ里对加载完成的图片进行查看大图）。

这里需要注意，在每个Activity或Fragment被销毁的时候，需要清空正在加载中的图片集合与置空图片点击监听，避免出现问题。置空代码与判断代码如下：



    /**
     * 正在加载中的控件集合
     */
    private static Set<ImageView> sImageViews = new HashSet<>();

    /**
     * 加载失败所显示的图片
     */
    private static Drawable sErrorImg = ViewUtil.getDrawable(R.mipmap.img_default);

    /**
     * 判断图片是否加载失败
     */
    private static boolean isLoadFailed(ImageView imageView) {
        return sErrorImg.equals(imageView.getDrawable());
    }

    /**
     * 判断图片是否在加载中
     */
    private static boolean isLoading(ImageView imageView) {
        return sImageViews.contains(imageView);
    }

    /**
     * 取消所有图片加载，并置空监听
     */
    public static void clearLoadingImg() {
        for (ImageView imageView : sImageViews) {
            Glide.clear(imageView);
        }
        sImageViews.clear();
        sOnImageViewClickListener = null;
    }

（2）、判断图片是否已经缓存了



    private static void loadCacheImage(Context context, String url, ImageView imageView, int widthPixels, int heightPixels) {
        // 寻找缓存图片
        File file = DiskLruCacheWrapper.get(Glide.getPhotoCacheDir(context), 250 * 1024 * 1024).get(new OriginalKey(url, EmptySignature.obtain()));
        if (file != null) {
            loadImage(context, url, imageView, widthPixels, heightPixels);
        } else {
            imageView.setImageDrawable(sErrorImg);
            sImageViews.remove(imageView);
        }
    }

这里就是这个需求中最大的难点了，如何去判断Glide已经缓存了该图片。

通过阅读、分析Glide的源码（也可以选择去看郭神的Glide解析，网址也在上面发了），我们可以知道，Glide对其缓存Key的构建是比较复杂的，有着十多个参数。但我们也会发现，Glide所缓存的原图的Key实际用到的参数只有两个url和signature，而大多数情况下，signature只会是个空值。因此，我们只需要想办法把url转化成Glide的缓存Key就大功告成了。 

不过通过源码我们也知道，原图的缓存Key类——OriginalKey是缺省的，也就是所，我们这些外部应用是无法使用。于是我就采用了一种取巧的方法，直接将Glide的这个类复制到自己的项目里，该类代码如下：



    /**
     * Glide原图缓存Key
     */
    private static class OriginalKey implements Key {

        private final String id;
        private final Key signature;

        private OriginalKey(String id, Key signature) {
            this.id = id;
            this.signature = signature;
        }

        @Override
        public boolean equals(Object o) {
            if (this == o) {
                return true;
            }
            if (o == null || getClass() != o.getClass()) {
                return false;
            }

            OriginalKey that = (OriginalKey) o;

            return id.equals(that.id) && signature.equals(that.signature);
        }

        @Override
        public int hashCode() {
            int result = id.hashCode();
            result = 31 * result + signature.hashCode();
            return result;
        }

        @Override
        public void updateDiskCacheKey(MessageDigest messageDigest) throws UnsupportedEncodingException {
            messageDigest.update(id.getBytes(STRING_CHARSET_NAME));
            signature.updateDiskCacheKey(messageDigest);
        }
    }

这类里有两个参数，第一个就是我们图片的Url，第二个则是签名，用于方面标识图片是否需要更新的，而这里，我是直接选择调用EmptySignature.obtain()，传入一个空签名。 

在得到原图的缓存Key之后，我们就只需要得到Glide的磁盘缓存了。

通过DiskLruCacheWrapper.get(File directory, int maxSize)方法，我们就可以得到Glide的磁盘缓存对象DiskCache了（在这里建议传入Glide的缓存目录与250M。虽说Glide有进行判断，如果缓存对象以存在就直接把已存在的返回过来，但为了避免出现什么莫名的异常，就按着Glide源码里的调用方式使用）。 

接着通过DiskCache.get(Key key)方法去获得缓存图片文件。

在找到缓存文件后为什么不直接使用缓存文件加载呢，则是为了避免Glide的二次缓存。我具体的Glide加载图片方法都是用的同一个，里面都是设定进行缓存，如果这里传入的是缓存文件，就会导致二次缓存，浪费！



（3）、具体的Glide加载图片方法



    private static void loadImage(final Context context, Object url, final ImageView imageView, int widthPixels, int heightPixels) {
        DrawableRequestBuilder<Object> builder = Glide.with(context)
                .load(url)
                .placeholder(sLoadingImg)
                .error(sErrorImg)
                .diskCacheStrategy(DiskCacheStrategy.SOURCE) // 设置磁盘缓存只缓存原图
                .skipMemoryCache(false) //进行内存缓存
                .centerCrop();
        if (widthPixels != 0 || heightPixels != 0) {
            builder.override(widthPixels, heightPixels);
        }
        builder.into(new GlideDrawableImageViewTarget(imageView) {
            @Override
            public void onLoadStarted(Drawable placeholder) {
                super.onLoadStarted(placeholder);
                Animation rotationAnimation = AnimationUtils.loadAnimation(context, R.anim.rotate_loading);
                imageView.startAnimation(rotationAnimation);
                sImageViews.add(imageView); // 将其添加到 正在加载中的控件集合 中
            }

            @Override
            public void onLoadFailed(Exception e, Drawable errorDrawable) {
                super.onLoadFailed(e, errorDrawable);
                removeViewInLoadingSet();
            }

            @Override
            public void onResourceReady(GlideDrawable resource, GlideAnimation<? super GlideDrawable> animation) {
                super.onResourceReady(resource, animation);
                removeViewInLoadingSet();
            }

            /**
             * 将 已加载完成/加载失败的控件 从 正在加载中的控件集合 中移除
             */
            private void removeViewInLoadingSet() {
                imageView.clearAnimation();
                sImageViews.remove(imageView);
            }
        });
    }

最后这里就是Glide加载的具体实现了，里面我通过GlideDrawableImageViewTarget对加载状态进行监听，设置加载中的动画。

到此，整个需求就完成了。

游戏延迟飙升，图片刷不出来，视频加载中，wifi又双叒gg了
很可能是wifi掉速了......
我的wifi，已经卡掉了
别人的wifi
各种各样的眼花缭乱的路由器型号带有N300、AC1200、AC2100、AX3600、AX6000等字样的路由器，到底哪些是自己的菜呢？
支持wifi6的设备越来越多了，到底要不要买单，哪些是坑爹货，怎样选择适合自己的路由器呢？
这篇科普向的文章带你一探究竟。
----------写在前面----------
本文旨在介绍关于wifi协议和wifi协议速度这种比较冷门的理论知识。
不推荐路由器，如果大家对什么路由器感兴趣的话，相信随意一搜就能看到一堆专业或非专业的测评，得到自己的满意答案。
本人才疏学浅，如有错误请批评指正。
----------下面是目录----------
一、谈谈wifi的频段----2.4和5G?
二、谈谈wifi的协议速度----N300、AC1200、AC2100、AX3600和AX6000?
三、总结一下wifi的协议----802.11?
四、谈谈平民法拉利-AX200
----------正式开讲----------
一、wifi的频段----2.4和5G
我们常看到手机、路由器上介绍的有5G wifi，莫非和5G有什么联系？
我们查一下百科，得知5G wifi有两层意思，一是第五代wifi，另一层是工作频率是5GHz
5G Wi-Fi的诞生很好解决WiFi面临的问题，首先它运行在5GHz以上的高频段，宽带能提高到40MHz甚至80MHz或更高，传输速度最高提升到了1Gbps，每秒可以传输约125MB的内容。
5G Wi-Fi就是第五代Wi-Fi技术的简称。Wi-Fi技术诞生于1997年，至今已经发展到了第五代。当年第一代Wi-Fi标准出现的时候，受到工艺和成本的限制，芯片的工作频率只能固定在2.4GHz，最高传输速率只有2Mbps。
接下来，我们查一下5G，就是第五代移动通信技术，属于蜂窝网络的技术。看来这俩确实不是一个东西，虽然刚好都叫5G，很迷惑。
我们知道，在5G的前面技术是工作在2.4G频段上，它为什么发展到第五代要重起炉灶呢？
2.4G wifi存在以下问题
1.带宽低，因为2.4GHz工作频率在2.4～2.483GHz频段，因为工作频率低，所以传输的信息量较少，带宽不高。
2.干扰强
笔者写这篇文章的时候在一个7层高的老旧小区(30楼的高楼就不说了)，随手一搜就是一片wifi，相互干扰，这样会产生更多的噪音，干扰频段相近的wifi。
5G wifi因为穿墙能力弱+信道多+使用的人少，干扰什么的，不存在的
3.其他干扰
因为2.4G是通讯的标准，所以除了wifi其他的通信也使用2.4G，蓝牙和无线鼠标会强烈干扰2.4Gwifi。笔者记得第一个手机红米2A，用蓝牙耳机听歌的时候，连wifi上网就想砸手机。
USB3.0也会干扰2.4G wifi，有同学玩mac使用USB3.0的win to go启动win，然后用win运行百度云(因为OSX的东西更新的不勤快)，结果由于2.4G和USB3.0强烈干扰导致下载没有网速............
5G wifi也有缺点，因为工作频率高，所以穿墙能力不如2.4G，不过这也是能保持5G信道干净的一个因素。
二、wifi的协议速度
虽然清楚自己家里的网不可能有这么快，但是毕竟这个值确实是能体验到的网络带宽的上限，而且一定程度上反映了wifi信号的质量。但也希望能辩证、理性的看待这个数字。
如何看待家用路由器的无线速率超过有线？​www.zhihu.com
暂时不考虑，我们来讨论一下N300、AC1200、AC2100、AX3600和AX6000这些数值是怎么来的。
我们搜一下N300，数据来自腾达N300V2
无线速度300M，那么叫N300没问题，IEE 802.11n那一堆是个什么鬼？
802.11n增加了对于MIMO的标准，使用多个发射和接收天线来允许更高的数据传输率，并使用了Alamouti于1998年提出的空时分组码来增加传输范围。
802.11n支持在标准带宽（20MHz）上的速率包括有（单位Mbit/s）：7.2, 14.4, 21.7, 28.9, 43.3, 57.8, 65, 72.2（短保护间隔，单数据流）。使用4xMIMO时速度最高为300Mbit/s。
802.11n也支持双倍带宽（40MHz），当使用40MHz带宽和4*MIMO时，速度最高可达600Mbit/s。
我们再问个问题，MIMO是个什么鬼？再百度一下？
多进多出（MIMO）是为极大地提高信道容量，在发送端和接收端都使用多根天线，在收发之间构成多个信道的天线系统。
原来就是多天线增加带宽的意思。还是1+1=2的那种
真的是俩天线？那么我们算一下，单天线带宽是150M，也就是说运行在双倍带宽40MHz下。
我们查一下其他的网络标准，得知IEEE802.11n、IEEE802.11g、IEEE802.11b是无线网络标准
IEEE802.3是有线以太网(10M)、IEEE802.3u是百兆以太网，没错这玩意就是个百兆有线。
但是也有例外，例如小米路由器4C，这货是四天线的2X2的N300，同理单通道150M，不知道该怎么吐槽。
同理我们看一下ac1200，2.4G是双天线的802.11n，5G是双天线的802.11ac
300+867=1200，老铁666，好吧约等于1200
我们再看一下某米ac2100路由器
同样的单通道433，四通道堆到1733
我们查一下某ac网卡，贴上嘤特尔9560ac的参数
https://www.intel.cn/content/www/cn/zh/products/wireless/wireless-products/dual-band-wireless-ac-9560.html​www.intel.cn
发现最高支持到1733的速率，两根天线，单通道速率应该是867M,很显然这个应该是双倍带宽的802.11ac。所以连接某米的4X4的1733的速率还是867M，两个1733的放到一块白瞎东西。
三、总结一下wifi的协议
在上面我们提到了两个东西，一个是频段，一个是协议，其实还有一个因素，协议带宽。
上文我们也提到了，单通道802.11n在20MHz下的工作速率是72M，而双倍频宽（40MHz）的工作速率是150M，翻了一倍。同理嘤特尔9560ac在双天线下就实现了别人四根天线的带宽，靠的也是翻倍的频率宽度。下面我总结一下传输协议和频宽对带宽的影响。
当然，这些协议并不一定都能工作在特定的频段，比如802.11ac就不能工作在2.4G下，802.11n最大的频宽是40MHz
不过我查了半天资料貌似也没什么用，别人已经把计算方法都写出来了，不过很难看懂
wifi6速率对照表及计算方法_qq_40048544的博客-CSDN博客_wifi6速率对照表​blog.csdn.net
https://cn.ui.vmall.com/thread-1349237-1-4.html​cn.ui.vmall.com
四、谈谈平民法拉利-AX200
直接贴上嘤特尔AX200的参数，两根天线，在5Ghz 的160Mhz下能达到2.4Gbps的传输速率。最重要的是这货在前期便宜的令人发指，60多都能买一片。后来涨价了，不知道牙膏厂是不是前期贴着本卖，名声打出来了之后就偷偷涨价..........
不管怎样，我两年前200多买的伊拉克成色的拆机的BCM94352HMB哭晕在厕所。
https://ark.intel.com/content/www/us/en/ark/products/189347/intel-wi-fi-6-ax200-gig.html​ark.intel.com
其实在wifi6也就是802.11ax的协议下，AX200也是能够达到主流的旗舰水平，估计也没几个OEM会做四天线的160Mhz的玩意。因为在wifi5时代做四天线的产品就没几个，很多5G wifi的产品甚至没有支持802.11ac(没错就是你，红米4高配版)，一票的产品也是5G单天线的802.11ac，所以按照之前的尿性，以及有AX200作为标杆，我可以预言(其实已经是这个样子了)，双天线、160Mhz的ax网卡将成为wifi6的主流。
所以选购路由器的时候就应该合理避坑，至少在参数上避坑，AX1800绝对是坑爹货，至于AX6000就是4天线的AX3000了，看自己的设备能不能达到这个规格再买，毕竟实在是太贵了。
反面教材例如
小米：AX5、AX1800
tp-link：AX1800
阿苏斯：RT-AX56u
正面教材
华为：AX3、AX3Pro、荣耀路由器3
tp-link：AX3000
小米：AX3600，红米AX5
阿苏斯：随便买
暂时写这么多，想到再更，欢迎评论区留言讨论