案例

由于业务的需要，需求方需要实现一个大量图片同时加载的需求。在实现这个需求的过程中，可能会遇到很多的坑，这里小编也总结了一些优化方案，我们可以一起来看看。

具体场景

在描述如何解决问题，我们现在先来申明，问题是什么？ 需求的主要内容是在某个页面显示 1~1000张，200~500k大小的图。好消息是这些图片来源于本地硬盘而非网络。(否则这个问题就要变成优化网络….)

踩坑历程

由于不是纯前端的项目，笔者可以从本地文件夹中读取文件。然后一段代码劈里啪啦的就出现了。

const fileList = this.props.fileList;

return (

<div className =”list-wrApper” >

{

fileList.map((file) => {

<img className=”img-item” src= {file.src} >

})

}

< div >

)

就在笔者满心欢喜的认为这个需求基本搞定了，该去楼下加鸡腿的时候。无情的现实狠狠的抽了我一巴掌。随着网页的刷新，一张纯白的画面展示在了我的面前，然后只见图片一点一点的从上面加载出来。 我不禁陷入了沉思，是CPU跑不动道了还是内存飘了？在一想，我这电脑都这个表现，真要上线了，这客户能忍受吗？不对，就这表现，没上线前产品小姐姐就的把我ko了…

方案一 懒加载

这种场景下想必大家第一反应也是懒加载。简单介绍一下图片懒加载。常见的图片懒加载方案是指页面加载时只渲染屏幕可见区域及周围的图片。当页面滚动时再加载需要显示的图片。

出于提高效（tou）率（lan）的目的，笔者在网上找了个比较好用的懒加载库然后引入项目。然而，情况并不乐观。因为该需求场景下每一张图片的宽高都是 50*50，那么在PC端常见的 1080p 的设备上首屏需要显示的图片达到了400+张。

即便我们忽视这个问题，当用户滚动网页速度很快时图片加载的体验也是不ok的。所以懒加载并不是万能的。

方案二 预加载

首先我们要知道，在硬件性能不变且CPU调度不能更积极的前提下。理论上我们无法减少图片渲染的时间。所以我们只能想办法调整图片渲染的方式来提高用户的体验。所以我们采用预加载的方式。

const fileList =this.props.fileList;
fileList.forEach((element) = > {
	let img = new Image();
	img.src = element.src;
	img.onload = () = > {
		// 将标签插入文档流中渲染这张图
		...
	}
})

当然我们也可以使用img.decode()方法对图片进行解码，它会返回一个promise对象。

img.decode().then(() = > {
 // 将标签插入文档流中渲染这张图
 ...
})

采用了这套方案后，图片会一张又一张的加载。然而，加载的速度实在是不敢恭维。如果用户想看最后那张图片，那他只能进行长久的等待…

方案三 懒加载 + 预加载

众所周知，3 = 1 + 2。所以方案三就是方案一和方案二的结合体。首先我们加载一张图片未加载时的底图（占位）。而后我们继续采用方案二的方式进行图片逐个的预加载。当用户滚动图片时，我们便改变下一站预渲染的图片为用户可见区域的第一张。然而，情况还是不乐观。当用户的滚动条匀速直线不停的往下运动时，效果依然很差。

终结方案

综合上面几种方案，基本能优化的我们都已经优化了。那如继续何提高用户的体验呢？似乎，我们只能从图片本身去下手？

上文也提到，在我所面临的需求场景下一张图片的显示宽高为50 * 50。而图片的大小为200~500k。所以我们可以采用缩率图的方式，先渲染一张3~5k大小的缩略图，等用户点击图片查看详情时再去渲染大图。采用缩略图的情况下我们再使用方案三进行优化，性能表现几乎就可以满足这个场景下用户的需求了。

小结

文章写的可能比较粗略，我这里在总结一下：

1、需求的主要内容是从本地硬盘中读取文件，然后在页面上全部展示。

2、方法总结：先占位，后渲染；先小图，后大图。