天猫双11前端分享系列（五）：解密2015狂欢城

[maisui99]

性能

Canvas Cache

Canvas Cache就是使用一个额外的Canvas来保存已经绘制过的内容，下一次使用的时候直接从这个Canvas上读取，这样就可以大大减少Canvas的绘制次数，例如原先首屏绘制次数约为75左右，使用cache后的次数约为28，减少了62.67%，在三四环会更明显，因为没有动画，所有内容都可以cache。

实测设备越低端性能提升越明显，下面是一个页面在不同平台下的消耗时间对比：

设备	不使用cache	使用cache	比值
PC	16ms	14ms	87.5%
Moto X	75ms	56ms	74.67%
Moto G	246ms	127ms	51.62%
iPhone5	170ms	45ms	26.47%

从结果看效果还是很明显的，而且这个只是缓存了6次绘制的结果，实际使用中会缓存个数约为50左右，效果会更明显。

一开始使用一个Canvas直接缓存所有内容，后来发现Canvas大小是有限制的，然后就实现了一个自动切片成多个Canvas Cache的方案，这套cache方案后面会集成到Hilo中。

Hilo 定制优化

针对Canvas的最主要优化方案就是尽量减少Canvas API的调用，在对狂欢城做了大量profile后，发现Hilo中每次drawImage都会调用ctx.save();ctx.translate(x, y);ctx.drawImage(...);ctx.restore();，这里Hilo主要是为了保证在所有情况(例如缩放，旋转等)下均不出错，所以才这样处理，但是再狂欢城中并不需要做旋转等复杂的变换，所以将这里的绘制直接改为使用ctx.drawImage来实现。这样可以节省大量运行时间，因为在狂欢城基本上全是图片！

实测性能提升非常明显，下面是消耗时间对比：

设备	优化前	优化后	比值
PC	30ms	15ms	50%
Moto X	138ms	76ms	55.07%
Moto G	435ms	216ms	49.66%
iPhone5	225ms	152ms	67.56%

视窗内渲染，懒加载及加载限流

• 视窗内渲染，就是只渲染可视区域的元素，以减少绘制消耗
• 懒加载，就是图片资源一开始是不加载的，在用户滚动到附近区域的时候才加载，减少网络请求
• 加载限流，由于使用懒加载机制，当用户快速滑动到比较远的区域时，会瞬间触发大量资源的加载，这个时候会发现页面变得非常卡，加载完成后变好了，所以就使用了限流的方案，限制同时只能加载4个图片，并实时调整加载顺序，优先加载用户当前可见区域的图片

  地皮拼合绘制场景

• 使用地皮拼合的方案减少了很多图片资源，因为大量图片是重用的
• 由于图片的内存占用是根据图片尺寸转换为2的N次方，然后计算大小，所以图片尺寸越大占用内存可能导致指数级增长，狂欢城中的图片都是小图(地图区块都是256以下，其他基本上也是512以下)，所以内存占用上会小很多

  低端设备降级

在低端设备上使用1倍图片，减少内存占用，并且不显示动画。

开发效率

• 前期开发了一个地图编辑器，用于编辑地图，因为地图布局变化过好几次，有了这个还是节省了很多时间的
• PC & 无线大量逻辑共用，大大减少了开发成本。
• 自动化，因为在PC和无线都有高清(2倍)和普通两种方案，所以图片总共会有4种尺寸，而大部分图片都是一样的，这样如果让设计师导出4种尺寸的话，将会是巨大的工作量，而且要更换素材(很频繁)也会发现很麻烦。所以写了一个自动处理图片的gulp任务，可以自动生成多种尺寸的图片，然后压缩、上传到cdn，最后生成一个imgs.js的文件，使用只需要依赖这个js，然后以原始文件名引用即可，非常方便快捷，大大减少了维护大量图片的工作量。
• 同样less中的图片也是使用上面的自动化的结果进行转换的，使用方式很简单background-image: cdn-url('island-brand-bg-pc.png');这样最后会变成background-image: url('//gw.alicdn.com/tfscom/TB1urfGKXXXXXXBaXXX_pYDSXXX-937-595.png');，这样写less的时候就不需要关心图片地址问题，图片上传问题，图片压缩等问题。

  感悟

• 自动化是好东西，能大大减少工作量

  天猫前端团队招聘

如果你看了这篇文章，对加入天猫前端团队有意向的，可以发简历到join-tmallfe@list.alibaba-inc.com，招聘要求见：https://job.alibaba.com/zhaopin/position_detail.htm?positionId=3504