当你上传一张较大的图片时候, 在不同的场景需要展示这张图片时, 那么你考虑过如何优化吗?还是一直都展示的原图?以及加载大图, 原图对用户的体验有什么影响? 下面在这里就提到缩略图,与原图的概念.
一般图片你上传的方式有多种,我这里用到的是通过base64将图片传到后台, 后台接收base64的值，转换为图片后存储返回存储的url.
在你上传的时候会做第一次压缩（比如说5M的图片给你压缩到2M左右,但也保证了清晰度），然后把这个称呼为上传的原图吧。然后在服务器端会再进行处理,生成其他几种尺寸的图片。即原图与缩略图. 客户端请求的时候会返回给你这两种图的路径.
那么问题来了：
什么时候加载哪种尺寸的图片呢？
假如在某个app的个人中心,你上传已一张图片当做 图像, 相信大家都知道 类似于QQ ,微信的图像展示框 都是很小的吧. 那么此时你就没有必要去展示原图了, 因为你展示成缩略图,也并不会影响到清晰度. 至于为什么. 如果需要科普PPi 的话, 请看这篇文章:
http://www.infoq.com/cn/articles/development-of-the-mobile-web-deep-concept
从 LCD显示器上一个6x6个小点排列成的矩阵(矩阵包含 红绿蓝 三色), 到不同分辨了下的展示,都介绍的非常清楚, 就类似于一篇科普文章,有兴趣的可以读一下.
言归正传, 也就是说你的小图像, 完全可以用缩略图展示 , 当你需要点击查看大图的时候,此时再去展示原图. 具体的使用, 你可以根据你的项目 自行断定. 前提是 后端 对你上传的图片做了 不同尺寸的处理.
对于加载大图的弊端:
1.原图太大，加载速度慢，浪费流量；
2.客户端渲染耗费更多的性能；
之前我一直存在一个误区, 就是当你上传完图片后,后台把 不同尺寸的图片返给你 ,那么不是更加浪费流量吗? 直接返回原图不就得了? 哈哈, 这里我再次给大家声明下, 你上传图片后, 后端把你上传的图片处理成不同的尺寸, 会返回给你一个服务器路径. 或者通俗的说, 后台给你返回了一个原图的url 和一个缩略图的url. 你不去加载显示, 它就是一串字符串. 怎么会耗性能渲染,浪费流量呢.
然后进一步的优化就是, 原图较大比较大的情况下,加载需要耗时,此时怎么处理,或者大图加载失败了怎么处理. 类似于微信,当你点击查看原图时, 首先是模糊的, 然后过了一会才变清晰. 这种处理方式就是 当你查看原图的时候, 默认先展示缩略图, 因为原图较大,加载渲染需要消耗一段时间, 等到原图加载完毕后,再进行替换,此时你看到的图片就是清晰的了. 具体的实现也相对比较简单. 体验效果会好很多.
当图片加载失败的时候,该怎么处理? IOS 用的 SDWebImage 有相关的处理. 以及前端 js 我也是通过自行百度 js处理img标签加载图片失败，显示默认图片 完美解决的.