UNPKG

@~lisfan/vue-upyun-image-format

Version:

vue过滤器插件-又拍云图片处理工具:默认以指定的策略规则进行了处理优化

143 lines (104 loc) 6.69 kB
# vue-upyun-image-format ## vue过滤器插件-又拍云图片处理工具:默认以指定的策略规则进行了处理优化 [API documentation](https://lisfan.github.io/vue-upyun-image-format/) ## Feature 特性 - 利用又拍云的图片处理服务,提供最适当的图片默认优化策略 ## Detail 详情 - 图片优化依赖了又拍云的处理服务,相应的图片处理规则请参考[又拍云文档](http://docs.upyun.com/cloud/image/#webp) - 根据当前设计稿和设备物理分辨率缩放比,及设备的DPR值,计算出实际的图片尺寸 - 由于 [NetworkInformation API](https://developer.mozilla.org/en-US/docs/Web/API/NetworkInformation)支持力度差,所以需要外部额外传入一个获取网络制式的方式(比如平台入口是微信或支付宝的) - 使用格式:`<img :src="图片地址 | image-format([sizeOrConfig],[scale = 'both'],[format],[quality],[otherRules])" />` ## Install 安装 ```bash npm install -S @~lisfan/vue-upyun-image-format ``` ## Usage 起步 ```js import Vue from 'vue' import VueUpyunImageFormat from '@~lisfan/vue-upyun-image-format' // 注册指令 // 以下是默认值 Vue.use(VueUpyunImageFormat, { debug: true, // 开启调试模式 maxDPR: 3, // (>=4)g网络或者'unknow'未知网络下,DPR取值的最大数 draftRatio: 2, // UI设计稿尺寸与设备物理尺寸的比例 scale: 'both', // 又拍云图片尺寸缩放方式,默认宽度进行自适应,超出尺寸进行裁剪,若自定义尺寸大于原尺寸时,自动缩放至指定尺寸再裁剪 quality: 90, // 又拍云jpg格式图片压缩质量 rules: '', // 又拍云图片处理的其他规则 minWidth: global.document.documentElement.clientWidth * global.devicePixelRatio / 2, // 默认值是(当前设备的物理分辨率 * 当前实际设备像素比的) 二分之一 networkHandler() { // 获取网络制式的处理函数,如果实在不知道怎么获取,建议返回4g return '4g' } }) ``` ```html <!-- 无作何参数:使用原尺寸,内部使用默认优化策略,转换为jpg,压缩90%,并启用渐进载入 --> <img :src="imageSrc | image-format"> <!-- 使用原尺寸,转换为png,并启用png压缩优化算法 --> <img :src="imageSrc | image-format('200x300',null,'png')"> <!-- 裁剪为500宽500高的尺寸,转换为jpg,压缩80% --> <img :src="imageSrc | image-format('500',null,null,80)"> <!-- 使用宽高适应缩放方式,以最小边为准,转换为jpg,不压缩质量 --> <img :src="imageSrc | image-format('500x100','fwfh',null,100)"> <!-- 以字典方式进行配置 设置宽度为400px,不进行渐进载入,转换为jpg,压缩质量为50% --> <img :src="imageSrc | image-format({ size:'400', scale:'both', progressive:false, quality:50, })"> <!-- 使用默认配置,但配置了一些其他规则:增加水印,你好 --> <img :src="imageSrc | image-format(null,null,null,null,'/watermark/text/5L2g5aW977yB')"> ``` ## 附:又拍云图片处理的研究报告 **注1:该测试是建立在使用又拍云的图片处理服务的,所以其他场景下结果会有不同,不要沿用** **注2:本测试只考虑了图片的容量对加载速度的影响,并不考虑因图片格式的不同,而造成的浏览器渲染图片速度的问题** **注3:但可能存在的一个规则是:图片数量级越多,图片容量越小,最终的渲染总时间消耗越少** ### 静态图源(`png/jpg/webp`)的对比( 同一图源,相同尺寸下 ) 1. 未使用任何优化的情况下 - png > 无损webp > jpg > 有损webp 2. 使用压缩优化(`compress/true`)的情况下:压缩后的png比未压缩优化约65%,压缩jpg比未压缩优化约5% - png > 无损webp > 压缩png > jpg > 压缩jpg > 有损webp 3. png设置了压缩优化后(`compress/true`) - png -> png压缩算法,容量优化约65% 4. png转jpg,png转webp - png -> jpg,容量优化约70% - png -> webp,容量优化约95% 5. jpg转webp - jpg -> webp,容量优化约80% 6. jpg设置了压缩质量(`quality/<number>`)后 - jpg 90%的质量下,容量优化35% - jpg 80%的质量下,容量优化约60% 7. png、webp、jpg图片质量相较时(纯肉眼判断) - jpg格式的色彩饱和度最好,饱满靓丽 - png和webp饱和度质量相差无几,整体偏灰,饱和底下降会比较明显 - webp如果细看会有模糊感,细节会丢失 - jpg在压缩质量90%情况下细节还原度还挺高,压缩质量80%的情况下细节丢失度还是挺严重的,但总体细节还原还是比webp好 - 所以针对于大尺寸图片,在质量和容量双重保证的情况下使用jpg格式,而对于小尺寸图片,则优先使用webp格式 ### 动态图源(gif/动态webp)的对比( 同一图源,相同尺寸下 ) 1. 未使用任何优化的情况下 - 无损动态webp > gif > 有损动态webp 2. gif转无损webp,gif转有损webp, - gif -> 无损webp,容量增长约10% - gif -> 有损webp,容量优化约80% 3. gif转换为有损webp,并没有明显的不适感 ## 实行约定(也是该插件的内部默认优化策略) ### 图片格式 默认情况下,根据浏览器对webp特性的支持情况,图片格式会按照以下不同的场景转换成webp或jpg - (静态,支持webp,图片宽小于设备物理分辨率*dpr的2分之1时),格式化为webp格式(又拍云api: `/format/webp`) - (静态,支持webp,图片宽大于设备物理分辨率*dpr的2分之1时),格式化为jpg格式(又拍云api: `/format/jpg`- (静态,不支持webp),格式化为jpg格式(又拍云api: `/format/jpg`- (动态,支持动态webp时),格式化为webp格式(又拍云api: `/format/webp`- (动态,不支持动态webp时),格式化为gif格式,不作变动 ### 图片质量 - 图片格式为 jpg 格式时,使用90%压缩质量(又拍云api: `/quality/90`- 图片格式为 png 格式时,使用压缩优化(又拍云api: `/compress/true`- 图片格式为 webp 格式时,使用有损webp - 图片格式为 gif 格式时,不作变动 ### 图片尺寸 默认宽度进行自适应,超出尺寸进行**裁剪**,若自定义尺寸大于原尺寸时,自动缩放至指定尺寸再裁剪(又拍云api: `/both/宽x高`### 其他优化 图片格式为 jpg 格式时,启用模糊到清晰的**渐进加载**效果(又拍云api: `/progressive/true`### 注意点 图片格式为 jpg 格式时,同时使用**渐进加载****压缩优化**会有冲突,具体表现:渐进加载是一个从灰阶图片到彩色图片的渲染