webp是个啥，这里就不多余介绍了，不了解的可以到百科里看一下这个词条。在APP内去支持webp相对来说容易的很多，只需要引入webp编解码的包即可。但是在前端M页上去主动支持webp就比较费劲些了，看到的一个方案是借助WebAssembly或webp.js解码，实际效果未去尝试，、在加载列表流时会不会存在性能问题😀，个人觉得有些得不偿失（特殊场景除外）。
    安卓由于是Google亲生的，很早之前就已经支持webp了（从2011年发布4.0开始）。不过随着webp的影响不断在扩大，系统的升级支持的设备越来越多了。其中最重要的一点是，iOS也终于也开始支持webp（safari-14-release-notes）。
    image.png
    关于iOS系统占有率，苹果开发者网站上有每日的数据：https://developer.apple.com/support/app-store/
    image.png
    那么我们就要针对不同的设备，图片服务器要支持通过图片的地址上配置参数（或其他的方式）来返回是哪种图片格式（eg. xxxx.png?t=webp、xxxx.png?t=jpg），这里就需要前端来做逻辑上的处理了：判断当前环境是否支持webp，支持的话加上参数t=webp，否则的话就不作操作。那如何判断呢？
    在网上找到的大概率是这样的：
    image.png
    这个代码在基于Chromium实现的浏览器上检测没啥问题（Android的Webview[4.0-~]源码层支持这里除外），但是在其他非“Chromium内核”的浏览器上可能就好使了。比如在火狐上执行这段代码：
    image.png
    MDN上也有描述，只表述了在Chrome上这个type值才支持：
    image.png
    这里还有个小插曲，后面会提到。
    那有没有其他更准确的的方式来判断呢，答案是肯定的。在其官网上，就有一段现成的检测的js代码：
    image.png
    通过这段代码，可以检测出当前浏览器对webp的支持情况：有损的、无损的、带透明度的、带动画的（类似gif的）。在使用的过程中需要注意的点，这个检测过程是异步的。
    把这个代码跑个demo，在iOS 14系统上看一下效果：
    image.png
    发现目前是iOS14上不支持无损的webp格式。当时就有个一个想法，是不是因为不支持无损的webp才导致的toDataURL的检测方式不生效，去尝试了下是结果是False。ps.当时想当然的认为canvas.toDataURL(type, encoderOptions)的encoderOptions默认值是1（实际默认值 0.92），才有了这个小插曲。后面也试了火狐，结果和iOS14上一致的。所以到这里推荐大家使用官方推荐的方式来检测是否支持webp。
    后面想了想，为什么还会有会使用toDataURL的方式，可能是因为一来逻辑简单，在着是因为同步的方式能更快获取结果，其他的可能是因为那时iOS14、火狐还不支持webp，后面随着系统、软件更新支持了，这种方式因为先入为主就一直留存着了。