标签:
PC端,触屏版:
前端JS方案——利用img标签加载一张base64的WebP图片,在img标签的onload事件中判断该图片是否具有宽高的属性,若有表示支持webP,若没有表示不支持webP。后台判断方案——判断浏览器请求头Accept是否支持WebP,返回是否支持的标示给前台。
以上两种方案中,前端方案为佳,当JS被禁止的时候,可以使用后台判断方式执行判断。附上JS代码截图
iOS独立版:
用户直接拉取WebP格式的图片(如果CDN有存储),下载完成后在前端实时转码(前端开发的WebP sdk),将WebP图片转换为jpg或png图片。展示给用户的是普通图片。
这样做的好处在于下载WebP的时候节省了带宽,虽然在转码的时候会耗时,但是由于下载时间缩短中和了转码的时间,所以用户基本感觉不出来差别。我们在不延长用户等待时间的同时缩小图片体积,节省了带宽。
安卓独立版:
后台判断用户机器系统,当系统版本大于4.0的时候返回支持WebP标示(因为其原生支持),前端拉取图片时后台会根据这个标示决定使用原格式图片还是WebP格式的图片。
对于不支持WebP的浏览器,可根据是否支持WebP的判断来拉取jpg或者png图片,也可以使用flash作为载体来加载WebP图片(空间相册兼容低端浏览器方案) 。
PC和webview方案中,用户若想将图片另存为本地(可能本地不支持WebP预览展示),可在用户右击“另存为”的时候,绑定右击事件,加载当前WebP图片对应的jpg图片,然后直接下载jpg图片(空间相册方案) 。
虽然这样的做法会导致多加载一张图片,但是由于只在右击时候触发加载,而且用户右击“另存为”的行为较少,消耗可不计。
标签:
原文地址:http://www.cnblogs.com/zhishaofei/p/4191418.html