不会做动画的前端不是好开发

题图：byclick_vision from Instagram

今天推送一篇前端雄文，读了这篇文章，你会有一种前端已经上了天的感觉，甚至有可能忘记催我写 。不过这篇不是我亲手所写，而是我的一位老朋友的团队成员给 MacTalk 写的。我的老朋友叫恩阳，阿里高 P，非常高，他最知名的地方并不是技术好，管理团队牛逼，而是常年以一辆马二在杭州余杭地区纵横驰骋，天下闻名。可惜，最近他换了两辆豪车，一下子变得无趣了很多。

续彬是恩阳的同事，是我的朋友，也是阿里的技术专家，他最近在我的「攻城狮群」做了一次前端技术的分享，我建议他写一篇相关技术的文章，也就是今天的成文 —— 前端里的高级动画技术。

他的简介如下：

邓红春，在阿里的花名是续彬，现在负责天猫互动团队的终端技术，包括了 Web 前端以及 Native 客户端开发。我在08年刚毕业那会做了一段时间的 PHP + Mysql，做得比较杂，之后很长一段时间专注于前端开发。2010年加入了腾讯专业写 Javascript，再到2012年加入天猫一直到现在，这7年的时间内我一直聚焦在用户体验这件事情身上。

以下是正文。

前言

至从有了前端开发这个概念以来，其实这个岗位所做的事情都是围绕着人机交互来开展的，主要包括展示信息给用户看，然后获取用户的意图并做出响应（本文提到的前端主要是指大部分人认为的 Web 前端，其实 iOS 和 Android 的客户端开发本质上讲也是完成类似的工作，但技术栈还是不一样，而且拥有更多的底层能力，所以我用客户端便于区分，后面会提到，所以提前说明一下）。

随着终端设备以及业务的快速发展，前端工程也越来越复杂，所以分工也进一步精细化，有侧重做工具化与模块化架构的，有侧重无线体验或者 Web 与 Native 融合方面的，也有侧重复杂的商家后台或者数据可视化的，甚至有部分公司把 HTML+CSS 与 JS 的工作也分开的，所以出现了不同前端工程师会有不一样的侧重点。

在这种大背景下，提出『不会做动画的前端不是好开发』的论点显然是很难站住脚的，因为动画仅仅是前端技术的一部分，很多人在其他前端领域也做出了很高的成就。但是，作为一个多年从事于互动领域的我来说，写这样标题的文章出来其实是有私心的，因为我们的业务有越来越高的动画类需求，而在动画方面能紧跟技术趋势的优秀前端实在是比较难找，希望通过这么一篇文章，让那些想在动画方面有些提升的朋友有所帮助。

一、为什么前端的动画需求越来越强烈

本文讨论的主题是动画，是属于刚刚所说的展示以及响应，也就是输出的那部分，我认为一个高质量的动画在很多情况下都能大大提升用户的视觉体验，前提是使用得当并把握好度，理由如下：

1、更形象化的表现力。因为人们的现实世界就是动态的，有时候用静态的图片与文字很难把场景描述清楚，比如我们要展示狂欢的节日氛围。所以，天猫双 11 的狂欢城与晚会的页面就用了大量的动画来表现；

2、更自然的过渡效果。一个有趣的 loading 能缓解用户在等待响应过程中的焦虑情绪，就像是在等待上菜时可以看看京剧表演一样。而且，即便是性能 DIAO 炸天的 iPhone7plus，也有很多赏心悦目的界面切换动效。

3、更具互动性。这个不想多解释，试想一下一个一动不动树立在你面前的人和一个扭动身姿而且做出丰富表情的美女哪个更让你想有进一步交互？

所以，只要恰当的用好动画这个技能，能在非常多场景上大大提升用户体验，进而让用户更有参与感。在竞争激烈的互联网行业，好的体验能为业务带来巨大价值。比如，如果用户能在手机上和一件商品进行很好的交互，而不再只是看静态的图文详情，那用户会更乐意去体验它，从而提升购买转化率等等。

随着硬件与底层系统的发展，用户的终端对动画的表现能力越来越强，所以将会有更多的场景大量使用动画，从 2D 到 3D、从虚拟到现实，对前端团队的要求也越来越高，不再是能用 jQuery 的 animate 或者 Css 的 transition 做个 loading 可以了的时代了。

二、实现动画的方法

讲了这么多背景与趋势，下面进入正题，那前端可以使用哪些技术来实现动画呢？

1、对程序员而言最省事的就是视频或者 gif 图片了，而且目前在很多情况下也在广泛使用，优点是对业务方来说没有太多限制，沟通成本低，缺点是在色彩、透明度的表现力上不如 PNG，而且交互性差，不过也可以通过碎片组装的创新方式达到可以互动的效果；

2、又爱又恨的 Flash，具备成熟易用的 IDE 与强大的 ActionScript，简直就是为动画而生，而且兼容 IE。可是依赖插件、耗资源、安全性等问题让它在手机端几乎寸步难行，我想这个技术其实已经没有再考虑的必要了；

3、通过 JS 改变 Dom 节点的 css 属性应该是集开发成本低、兼容性好、具备互动性，加上 PNG 图片很好的色彩与透明度的表现力基本能满足很多动画需求，也是目前大部分前端使用的方法。但是在复杂的大场景中性能较差，并不是特别流畅，而且也解析 3D 模型；

4、Canvas 的到来仿佛是上帝为前端同学提供了神来之笔，而且是众多大厂推崇的官方标准，不需要插件，浏览器内核支持，可以绘制各种图形以及具备高性能的图片渲染能力，而且能比 flash 更好的与页面中其他元素交互等等，但纯手工编写 canvas 程序的成本其实较高（原因可以 google），动画实现起来较为繁琐，但可以通过封装一些方法进行解决；

5、大厂对 WebGL 的支持相当于为前端的那支神来之笔赋予了新的魔法，在 Canvas 的基础之上增加了 OpenGL ES 的 3D 绘制能力，并且能开启硬件 3D 加速渲染，让前端动画的世界充满了更多想象的空间，天猫双 11 狂欢城、年货节以及众多 AR 项目中已经在大规模尝试基于 Web3D 的渲染技术。

三、动画渲染技术的趋势。

可见，随着技术的发展，实现动画的方式有非常多，大家可以根据自己的业务与团队情况选择合适的方式进行开发，但为了给用户带来更极致、更创新的体验，需要我们掌握这些技术以便在需要的时候能马上实施。

具备更强表现力与想象空间的 Canvas+WebGL 显然是未来的大趋势，iOS 与 Android 对 WebGL 的支持越来越完善，目前已经能覆盖 80% 的手机用户了，而且很多 APP 的 WebView 底层做了很多优化，加上硬性的发展，覆盖率会持续升高。

随着 AR/VR 等虚拟技术以及硬件的发展，扁平化设计的小潮流逐步向更具景深感、立体感、动力惯性等物理效果发展，因为这才是更真实的世界，三维动效已经成为了大趋势，3D 模型会成为前端团队很难逃避的内容。

虽然本文主旨就是围绕着 Web 前端开发来讲的，然而客户端开发其实也有些同学也在做动画相关的一些事情，而且拥有更极致的性能与兼容性的表现，但也有开发成本高、无法开放、依赖发版、热更新有局限等问题，所以会更偏向于日常的标准化产品，如手游或者日常 APP 中的一些转场效果。当然，有些 Native 的渲染引擎在通过一系列设计与封装，在跨平台和热部署方面也取得了不错的进展。

由于 Canvas 和 WebGL 属于世界公认的 Web 标准，所以除了在开发成本、跨终端、热部署、开放性等方面拥有绝对优势之外，也具备活跃的生态和大量的储备开发力量，底层 runtime 不断在优化的情况下，将能满足快速的业务发展诉求。

所以，不管是 Native 前端还是 Web 前端，在动画方面都在快速发展，就像在 web 中可以选择多种渲染技术一样，采用 Native 还是 web 也要根据业务与团队情况进行选择。由于我们团队的业务量较大，而且需要为不同的品牌商甚至不一样的商品进行个性化开发，同时需要运行在不同的 APP 和不同类型的设备里面，长远来看，我个人更看好 Web 渲染技术的发展，而我们团队的客户端同学我会更倾向于更多的底层建设与更多的创新。从天猫近一两年的实施来看，我更加坚信这个方向，所以，接下来我会继续回到 Web 层面展开分享。

四、多实践才能出精品

高质量的动画包括几个要素：

需要如丝般顺滑的流畅体验，考核指标是 FPS 性能；

覆盖用户更多的场景，考核指标是设备兼容性；

逼真或者赏心悦目的渲染效果，如 3D 材质、色彩、粒子等；

其实这三者之间存在一定的矛盾，需要根据需求去平衡，做出一些取舍。但其实老板也业务方是不太喜欢取舍的，都能达到那是最好，所以作为技术人我们必须要有追求极致的钻研精神，下面我通过一些案例来分享一下我们是怎么做的。

先看一下效果，如下是 2014 和 2015 年的双 11 狂欢城的页面（gif 太大只给 url 吧）：

做这个项目的时候，要同时满足业务与性能的要求，还是面临这不少挑战的：

1、图片多：100 多个品牌 logo，还有场景地皮

2、动画多：大量精灵动画，每个至少 3 帧

3、场景大：在手机上共有连续 8 屏的超长页面

所以这个页面将消耗大量内存与 GPU 资源，通过 Dom 实现会非常卡，所以我们选择了 canvas 进行实现，每年都会做一系列优化措施，比如：

1、除了 CDN+ 客户端预加载等常规缓存机制之外，我们在页面的运行时进一步做了 Canvas Cache，使用一个额外的 Canvas 来保存已经绘制过的内容，下一次使用的时候直接从这个 Canvas 上读取，这样就可以大大减少 Canvas 的绘制次数，例如原先首屏绘制次数约为 75 左右，使用 cache 后的次数约为 28，减少了 62.67%。

2、为了减少地皮图片的数量，2015 年的狂欢城我们与设计师沟通后决定尝试一下，使用地皮拼合的方案，重复使用一些图片进行对地皮的组装，由于图片的内存占用是根据图片尺寸转换为 2 的 N 次方，然后计算大小，所以图片尺寸越大占用内存可能导致指数级增长，狂欢城中的图片都是小图 (地图区块都是 256 以下，其他基本上也是 512 以下)，所以内存占用上会小很多。

3、通过 Hybrid 接口获取硬件信息（内存、GPU、屏幕等）判断如果是低端机器，我们采用非高清图片以及 Dom 的渲染方式进行优雅降级。

五、大胆尝试不断突破，3D 与 AR 时代的来临带来新的挑战

再来看看基于 WebGL 的 Web3D 案例，如下是 2016 年狂欢城项目：

当时我们希望通过 3D 为用户带来全新的视觉体验，但由于场景还是非常大，如果所有元素全部采用模型的话那面数将面临巨大的性能挑战。承载着众多品牌商的流量入口的业务压力下，我们和设计师经过大量的测试与探讨，最终实现了一个滚筒 + 纸片风的效果。过程中也尝试了用 CSS3 和 cavans 模拟 3D 来实现，但有各种闪烁以及卡顿问题，最终还是基于 WebGL 的 3D 图形进行实现的。说实话，从效果上讲我们并不是非常满意，毕竟做了一些妥协，但从技术上讲，是一次非常大的突破。

2017 年货节我们再一次挑战 Web3D 的极限，用更加有冲击力的体验展现过年的快乐氛围，拉近消费者与品牌之间的距离，我们设计了一个全模型的场景来构建，如下：

这个场景的模型有 30M，通过 WebGL 渲染出来之后就有些卡顿了，我们决定把更多的资源让给互动的主题内容，而不是场景，所以把外围场景转化成了一张全景图：

然而输出的全景图我们不打算放在一个球体上。因为有曲面就会有变形，但是天空部分因为是纯色，所以这部分形变是看不太出来的。可是如果这部分形变作用在建筑上就会非常明显。所以我们把球形换成一个「压扁柿饼形状」

最终我们实现的效果如下（其实摄像机可以做更多变换，有做导演的赶脚了）：

可见，这时候的动画开发，除了考虑对图片的处理之外，还有模型文件的处理以及摄像机的使用。

说完从 2D 到 3D，再分享一下从虚拟到现实的动画应用，也就是我们所说的 AR（增强现实），如下是天猫 AR 业务里面的两个案例（一个是天猫互动 2015 年初首次尝试，一个是近期我们的合作伙伴使用天猫的接口实现的）:

本文先不讨论 AR 的识别与跟踪算法，但对需要与算法对接的动画渲染技巧要求会更高，要与摄像头里面的现实场景混合在一起面临两个主要的新挑战：

1、除了虚拟的那部分动画需要足够的流畅之外，还要随着现实场景的变化而变化，摄像头的方位或者识别物本身可能都在高频晃动，所以虚拟物体怎么与摄像头以及算法进行绝对同步呢？实际上是非常难做到的，而且如果使用 Web 的方式进行渲染，问题会更大，因为摄像头与算法层通常是在客户端，部分算法能力可能在服务端。在摄像头获取图像，到算法计算，再到显示摄像头图像，最后到渲染反馈，任何一个环节都会有时间消耗，需要设计一个巧妙的同步机制才能让整个 AR 体验更加的顺畅，不然就会容易抖动。

2、在 AR 的场景中比在纯虚拟的场景中，对材质与光照的要求更加的强烈，因为如果渲染效果不真实，就算动画与跟踪做得再流畅也会出现格格不入的情况。

由于篇幅有限，更多的技术细节就不进行展开了，看到这里，你应该清楚自己是不是一个会做动画的前端了。

六、需要一套适合你的工具箱

开头有提到，自己完全手工去基于原生接口开发动画的成本还是比较高的，所以需要把通用的能力沉淀下来，为开发者提供更高效的开发体验，这样大家才能更专注于业务本身，避免很多重复劳动。所以，最省心的做法就是选择一个现成的产品进行使用，但前提是需要选择合适的，早期有 Egret、Pixi、unity、Cocos、three.js 等相关的动画引擎的产品，大家可以自己的需求进行选择。当然，如果发现没有非常适合的，可以选择进行扩展或者自己研发，以便满足自己团队的业务需要。

在 2014 年阿里选择了自研一个叫 Hilo 的引擎，其实根本原因是我们没找到一个适合电商业务的，否则可能就用了，就不会有今天的 Hilo，主要原因有：

1、性能要求高。天猫和淘宝大部分互动页面都是运行在 APP 中的 webkit 的 webview 容器中，而且和复杂的业务混合在一起，要求足够小、轻量、高性能；

2、需要易上手、易扩展。电商类业务开发节奏非常快，不能有太高的学习成本，也需要大型游戏的那么多功能，只要有极致的渲染以及物理能力即可，其他的可以根据情况选择性扩展，同时需要与其他业务保持同样的开发语言，而不是 TypeScript 或者其他脚本；

3、兼容性要求高。对于阿里的用户体量来说，10% 的用户就已经是很大一批用户了，所以对 IE 以及低端手机的支持不能完全不考虑；

4、开放性与安全性。

经过多年的实战，Hilo 支持了阿里很多动画相关的业务，比如上面提到的多年双 11 狂欢城，并行成了很多周边工具，天猫互动团队在 2016 年决定对 Hilo 进行开源，希望给有需要的团队多一个选择，其主要特点有：

1、极简内核，2D 部分已经开源（），压缩后只有24KB；

2、采用前端工程师熟悉的 JS 标准语法，支持 ES6，支持 CommonJS/AMD/CMD/Standalone 引用方式；

3、支持 Webgl/canvas/weex/dom/flash 五种渲染模式，能兼容更多的运行环境；

4、充分的 API 与 UI 测试，安全稳定；

5、使用 Yeoman 脚手架，可以快速生成一个动画应用；

6、无缝衔接的丰富工具集（DragonBones 骨骼系统、TiledMap 地图编辑器、ChipmunkJS 物理系统、粒子编辑器、Flash&AE IDE 插件等等）；

所以，Hilo 除了支持大场景的互动页面之外，像如下这些简单的动画都是可以由工具直接导出为 Hilo 动画做成的（可交互可控制的 Canvas 动画，非 GIF）

上文提到了很多 3D 和 AR 项目，也沉淀出了 Hilo3D，目前正在阿里集团内测，感兴趣的朋友可以到 github 提 issue，Hilo3D 的主要特点有：

1、沿用 Hilo2D 的设计风格与开发方式，极简 + 易上手

2、支持 glTF 模型，提供在线格式转化器

3、聚焦在渲染效果、性能、兼容性三方面

是不是有了适合你的工具箱就能放心大胆的走天下了呢？引用我常说的一句话，那就是「巧妇难为无米之炊」，技术再牛，没有原材料也是「英雄无用武之地」。所以还需要关注怎么提升模型素材的生产效率，降低业务落地成本，这部分内容下次有时间再分享。

结语

回到标题那个问题，是不是不会做动画的前端就不是好开发呢？显然太过绝对，如果说是，那肯定会被骂。不过我觉得能精通动画技术并与时俱进的前端开发肯定会很受欢迎，因为你是离用户最近的贴心人。

最后推荐一下Hilo，以前我就推荐过，现在越来越成熟了。