在上篇文章  浅谈前端优化(一) 中提到,项目中,图片尺寸的精确匹配及资源的最大化利用,这里就具体地讲一讲如何实现。

以实际项目为例,商品列表中的图片,在代码中规定的尺寸为 350rpx * 350rpx,如下图:


代码中规定了图片的尺寸,客户端也按照规定的尺寸渲染出来,此时已经呈现给用户,一些朋友说,没有问题啊,很正常啊!那么我们再进一步剖析,如果我们将请求到的图片在浏览器中直接打开查看,效果是这样的:

图片尺寸为 620px * 620px 的高清大图,图片大小为45.1KB,加载时间为197毫秒;

但我们的实际需求是,只需要350rpx * 350rpx 大小的图片,这时候虽然能完美显示,但其实是图片缩放效果,尺寸变化,但图片大小依然是原图的45.1KB,这就造成了性能浪费,相当于用大炮打蚊子,具体优化如下:

因为之前的文章中讲过,我们在项目中期使用了CDN+对象存储,所以关于项目资源的迁移,使用的是七牛云的镜像功能,等于从我们自己的服务器上实时复制一份到七牛云服务器上,再加上我们配置了七牛云的资源专用域名,假如我们服务器上面有一张图片,名字为abc.jpg,

普通访问地址就是 http://www.360mtd.com/abc.jpg

七牛云的访问地址是 http://resource.360mtd.com/abc.jpg

使用七牛云的好处是,遍布全国的CDN服务器,访问速度比我们自己服务器快很多倍,再者,当有高并发请求时,将压力转移至七牛云,节省资源,最大的好处就是,七牛云服务器对于图片资源,有自己的优化方案:


1、七牛云CDN服务中,有 图片自动瘦身图片处理 ,经过实测,图片自动瘦身的功能做得不是很好,虽然能极大地压缩图片,但是有的图片会过度压缩,导致清晰度严重下降,模糊不清,所以彻底停用 图片自动瘦身 功能;

2、图片处理,我们的重头戏,核心功能在于,可以生产指定尺寸的图片!


接下来在图片样式中新建一个样式:



因为推荐商品的样式布局为2列,小程序的设计标准是宽度为750px,所以每一列的宽度这里取375px,最终将样式保存,按照七牛云官方的文档,比如我自定义了一个样式叫做 indexRec,且样式分隔符为*,那么某一张图片需要应用该样式,方法为:

http://resource.360mtd.com/abc.jpg*indexRec,在图片的最后加上参数,但是在实机测试中,有时候会出现部分图片不能加载的情况,因为加了图片样式名称参数,在向七牛云服务器请求的时候,还是要把图片样式名称进行转义,我猜测是在转换过程中存在BUG,导致部分图片不能按照想要的设置输出,名称最终转换的字符串为 ?imageMogr2/thumbnail/375x/blur/1×0/quality/90|imageslim,仔细看看也能理解每一个参数的意思;

最终我采用原始参数对图片进行处理,没有出现任何的BUG,由于七牛云是在项目中期使用的,要么是请求后台数据时,后台将图片路径全部拼接好返给前端,要么是前端自行处理,这里我采用自行处理的方式;

只需要在图片路径后,拼接需要处理的参数,即可得到想要的效果,这时候在浏览器中看看处理后的图片:

原图大小为45.1KB,尺寸为620px * 620px,加载时间为197毫秒

优化过后的图片大小为12.7KB,尺寸为375px * 375px,加载时间为24毫秒

图片越多,效果越明显。

当然这只是比较“死”的一种处理方式,真正灵活的方法应该为,前端在渲染图片之前,获取装载图片盒子的宽高尺寸,将尺寸发送给后端,后端编写一套图片剪裁的方法,用前端发过来的参数进行剪裁,将处理后的图片再返给前端,这样才是完整科学的流程,但无奈我们的项目一开始没有构架好,并且中期才进行补救,只能使用这种没有办法的办法。

最后想说的是,项目的架构非常重要,如果一开始能考虑到各种问题及优化,后期就不会有那么多的麻烦,就像做一件事,三思而后行,考虑清楚如何实施,怎么走,做起来自然高效快捷。虽说程序开发要的是 敏捷、快速,但有时候也需要慢下来,想清楚再做,不然后期修补的时间会多很多。

希望大家在这个快节奏的时代中,能“慢”下来。