前段时间上线了全息机器人项目，线上访问可直接在手机百度 APP 中语音搜索 百度神灯 即可（请在wifi环境下访问）。项目部分截图如下：

通过部分截图可以看出，这个项目主要是两部分，一部分正常的动画引导页面（前四个截图所示），另外一部分是全息播放页面（最后一个截图所示）。其中动画引导页面共有十一个，全息播放页面有四个，进入每个全息页面前都会一些动画引导的页面。

这篇文章主要从 方案制定，遇到的问题以及应对方法 等方面来对项目中这两部分做一个介绍。

正常动画部分

方案制定

在没有老旧 IE 的情况下，做动画的选择是比较多的，SVG，CSS3，CANVAS 等等。最开始拿到这个项目的时候，结合这三种各自的特点，最终选择了主要动画由 CANVAS 来实现，具体原因如下：

制作“雪碧图”一般是前端优化的重要一步，主要作用当然就是减少HTTP请求数。但是由于传统方法的雪碧图制作和维护成本都极高，加之现代浏览器支持的并发数也不断提高，所以很多人开始质疑做这项工作的必要性。但并发支持度变高，并不代表无限支持，网页首屏需要加载十几张图片资源还是很常见，再算上js、css以及一些数据的ajax请求，HTTP数上五十也是轻轻松，于是，用户体验就不那么好了。所以，这个工作不能省，但是开发成本又不得不考虑，于是，"雪碧图自动化"是自然而然就会产生的想法。

先看下雪碧图的发展历史:

原文：Responsive Images in Practice

作者：Eric Portis

译者注：感谢米粽、我佛山人和otakustay为译文提出的宝贵意见。

魔鬼因一切我们享受的东西而惩罚我们。

—阿尔伯特·爱因斯坦

图片已经占了 Web 内容的 62%，而且我们每天都在制造更多。如果所有图片内容都能被好好加以利用那的确很赞。但是对小屏或低分辨率屏来说，其中大部分数据都被浪费了。

为什么？尽管 Web 设计初衷是让所有人能通过任何途径来访问，但直到最近，设备的碎片化才迫使业界全面转向了响应式设计。我们在进行响应式设计时，内容可以优雅且高效地流入任何设备。这说的是除了位图以外的所有内容。位图是固定分辨率的。而且他们的容器——敬爱的 img 和它那孤零零的 src——没有任何适配能力可言。

设计师们面临这样一个苏菲的选择¹：让页面在有些情况下变模糊，还是在所有情况下变慢。大多数人倾向于后者，给所有人发送能适配最大、最高分辨率屏幕的图片。浪费啊。

但是！经过三年的辩论，我们有了一些新的标记来解决响应式图片这个问题：