一个初级前端工程师的自我修养

　　前言

　　优化！ 又是优化！

　　切图崽们作为整个web应用的纽带，连接着用户行为和机器性能。 而 优化 的最终意义，在于在这两者之间取得一个最佳的平衡点。

　　对于图片资源的加载来说，更是如此。 今天我们就来简单说说，项目开发中常见的图片加载优化方式。

　　预加载

　　1.遮罩大法

　　我们都知道， window.onload 实际上是 DOMContentLoaded 事件完成的回调，只是完成了DOM树的构建。 诸如Css的渲染以及页面内图片等资源的下载不一定完成了。所以如果此时呈现页面，页面会非常难看。

　　为了解决这个问题，为了从设计和行为的角度提高用户体验， 我们可以在图片等重要资源完全下载完之前，对页面加上较为美观的遮罩，并且弹出loading提示告知用户资源正在loading.等到图片完全加载完，才移除遮罩和加载动画 .

　　具体的实现思路如下：

　　window.onload调用之后，先弹出蒙板加上loading动画用来提示用户正在loading中

　　对页面中需要预加载的IMG元素进行下载 var img = new Image（）； img.src="xx.jpg"

　　图片下载完成会有一个onload的回调 img.onload = function（）{…}

　　在这个回调中移除loading动画以及遮罩

　　这样就可以给用户带来顺滑如丝般的操作体验了，再也不用担心用户看到那些正在下载的未显示完全的丑的要死图片了。

　　我们的口号是： 要么就不给你看，要么就给你看最好的应用场景： 请在”首屏中存在图片的动画，或者和你对接的UI设计师极其强势”的情况下使用

　　2.有码大法

　　有码大法和遮罩大法略微有区别，具体实现思路如下：

　　首先对你需要预加载的图片准备两张，一张是高清一张低清。 比如girl_hd大小为60kb. 另一张是girl, 大小是6kb.

　　html页面中需要预加载的image标签的src地址写的是低清的地址

　　因为低清图很小，很快就能被加载出来。

　　window.onload调用之后，获取页面需要高清替换的img的src（girl.jpg），以此src为基准拼接字符串（+’_hd.jpg’）获得高清图的地址（girl_hd.jpg），然后用下载该高清图 var img = new Image（）； img.src=“girl_hd.jpg”

　　图片下载完成会有一个onload的回调 img.onload = function（）{…}

　　回调中替换掉页面中img的src, 所以现在页面上的image标签为

　　我们的口号是： 想看无码高清，请先看有码低清应用场景： 请在”首屏中出现大量图片，且尺寸都不小”的情况下使用

　　懒加载

　　如果你仔细看了上面预加载的思路，一定往我脑袋上拍砖： 遮罩大法也好，有码大法也好，这并没有提高项目的加载速度啊，最后该下载的图片还不是得下载。 没错，懒加载只是改变了用户的操作感受，实际上项目的加载速度并没有提高。 但是，现在要说的懒加载，可是实实在在的提高了项目的加载速度哦。

　　什么是懒加载，一句话来解释， 就是 图片按需加载 .

　　大家一定刷过微博，微博的照片墙就是懒加载的最佳示例。一开始显示的照片并不多，只有用户下拉，拉到底部的位置， 照片墙才会被拉长，新的图片才会被加载。

　　操作思路：

　　监听 滚动条scroll 事件（当然 touchmove 事件也可以）

　　每次事件触发的时候，判断当前照片墙的位置

　　如果照片墙已经被刷到了底部某个临界位置点

　　Js下载新出现的图片， var img = new Image（）； img.src="xx.jpg"

　　下载完成有一个onload的回调 img.onload = function（）{…}

　　在下载完成的回调中向页面中插入已经下载好的图片

　　当然，根据项目不同，会有各种各样的懒加载方式。但核心是不变的： 即页面初始加载的时候，只加载满足用户需求的最小数量的资源 . 拿照片墙举例，可能用户的微博里有500张照片，如果你在页面加载的时候就加载500张，用户会卡到爆炸（因为后台一直处于图片下载状态）。 如果页面加载的时候只初始加载20张图片，其他的图片通过用户自己的操作（滚动下拉），来按需加载，会极大提升项目运行的流畅程度。

　　结语

　　虽然预加载还是懒加载实现原理都非常简单，给我的启示确是巨大的：

　　预加载 除了改善用户的操作感受，其深层次的核心其实在于： 对资源进行碎片化加载 , 即预加载其实可以出现在任何时间段，当用户鼠标很长时间没移动的时候，我可不可以偷偷下载两张图片？在用户目前没有进行大量运算操作的时候，我可不可以偷偷下载两张图片？当用户当前在一个很精简的登陆界面的时候，我可不可以偷偷下载他登陆成功跳转到的页面的几张图片？等等等等

　　懒加载 的深层次核心在于： 按需 , 按需这个词已经被深深刻在我脑子里了。 现在回想起来，很多很多优化方式都是围绕着按需来展开的。 按需加载Js , 按需加载图片 等等

　　首先，我们必须保证项目第一时间的加载速度，能让用户在最短的时间内看到页面和内容。

　　其次，尽量保证当前页面的精简程度，不去做无意义的加载。 只有当用户真正需要时，我们才展现给他。

　　各自的优缺点在于：

　　预加载：

　　优点：如果提前下好了图片，等到这张图片需要用到时，可以秒开。

　　缺点：下载图片的时候会影响项目的加载完成时间，会影响项目运行的流畅程度

　　懒加载在于：

　　优点： 保证用户加载的项目是最精简的，最快的， 所下载资源是最少的

　　缺点： 如果用户的操作触发了懒加载，那么需要等待资源下载到完成的时间，同时资源下载期间，操作流畅度降低

　　说到底，项目的优化是没有银弹的，这一部分的高效很可能导致另一部分的低效。A项目的优化方法照搬来B项目可能一文不值。所以我们切图崽们能做的，就是深刻理解这些技术的原理，并且在项目中吸收经验，只有深刻地理解了各项技术的优劣，只有深刻的理解了用户的需求以及行为习惯，才能针对特定的项目，特定的场景，进行最适合的处理。