动画的现状(2014)

在后Flash时代里，Flash动画是很少见的。于是对手机和台式机来说，CSS动画就很快变成了增进用户界面友好性的平台，并且已经存在强大的JavaScript类库来处理复杂的交互动画。伴随着太多的“CSS动画 VS JavaScript动画”混战而来的是，一个全新并且专门为web动画而生的API终于诞生啦，这件事可能会促使CSS和JavaScript两大阵营联合。

2014年对web动画来说，是激动人心的一年，也是铭记辞不达意和错误信息的一年。在2014年里，我有机会去环游世界来探讨在用户界面和设计中使用动画。我遇见过并且采访过许多使用过并支持CSS和JavaScript的人。随后通过采访许多开发人员，设计师和浏览器生产商，我发现一个科技与人类的故事正娓娓道来。

你将阅读到的以下内容包含纯理论研究，并且你可以找到关于web动画面向对象的官方解释。

Flash时代可能成为历史，但是web动画的时代已经开启

自从Flash时代以来，认为动画不仅仅是要强调调色的这种想法已经变成一种潮流，一次“闪现”的头脑风暴，经常是给人一种不好的感觉，就像一个很讨厌的闪烁标签，除非我们想展示的东西仅仅是屏幕的复本，否则动画仍然是我们的朋友。

对用户界面设计师来说，动画强调层次，人际关系，结构，起因和影响。调查重返90年代早期论证动画帮助人们理解屏幕上发生什么。动画可以将应用app状态联系在一起并且也可以使为大脑GPU工作的可视化皮质处于卸载状态。

对交互设计师来说，大到平板电脑上的视频游戏，小到仪表盘上的图形等复杂的视觉是一定要使用动画来将所有的帧衔接起来。即使我们想在Internet上实现类似的复杂特效，我们还是仍然要使用动画。

难过的是，我们已经在运动设计比赛中落后啦，随着使用动画来让用户受益的产品越来越成功，竞争对手的那些静止且滥用特效的产品将会失败。事实就是如此，原生的app应用正在击垮远离互联网的裤子行业。app应用开发工程师从一开始将动画元素加入到产品设计中，如Flinto和Mitya等原型工具，然后在工作流程中具体化。

但是情况貌似正慢慢好转，IOS Sarari团队指出，CSS动画以及转型规范使得网站在用户界面和用户体验方面能够表现得和IOS应用一样好。即便是Google已经注意到这些，在它的 Material Design指南中指出，将动画前端化和中间化，出于使用动画和转换的目的，我们还是应该注意什么东西该做，什么东西不该做。

在应用更新迭代和设备生态系统中，动画自然而然成为下一步计划。动画使得数字世界对不同年龄段的用户将变得更加直观和有趣。并且只要我们的设备运行GPU，动画将不会消逝。

让所有的东西动起来

从动画的本质来看，动画仅仅是时间和速度以一定速率在改变的可视化载体。所有的动画可以概括为三种类型：

静态化的动画是指没有分支和任何逻辑，从一个起点运动到一个终点。这种动画可以用CSS单独实现,正如CSS载入动画的丰度证实。

最简单的状态化的动画形式需要boolean值的输入——一次点击打开菜单然后一次点击关闭菜单，例如——在两种不同到状态下实现运动效果。在CSS动画的范畴内，通过运用和移除类样式，目前已经有JavaScript框架实现。

动态化的动画可以有许多的动画效果，这取决于用户的输入和其它的变量因素。动态化的动画使用它本身的逻辑来决定自己如何运动和终点在哪里。动态化的动画可以根据你刷卡的速度来推测在你手指后面拖拽一张卡片，或者随着新的数据进入动态改变图像。在处理动画的今天，用工具实现的动态化的动画是最复杂的一类动画。

状态多元化 != 动态化的动画

"机智的"CSS开发者可能指出，只要有足够的状态，CSS动画非常像动态化的动画。从一点上来说这是正确的。但是真正的动态化动画有很多你可以提前使用的终态。

想象一下，不大的载入进度条，(主要)是利用百分比实现"丰满度"且拥有不同类样式的像素点，然后组成数以百计的CSS直线，而不是提及JavaScript就意味着必须触及DOM来更新类样式和改变浏览器重绘的次数。因此，我们非常清楚要单独用JavaScript编写一个高性能的动态加载器。

CSS动画声明:除了少量的伪类样式，例如:hover和:target，可以接受不是来自用户也不是来自用户周围上下文环境的文本。确实只能让作者(CSS动画)告诉它该做什么，并且不能对新的用户输入或者环境的改变做出响应。没有办法来新建一个"能够在你的鼠标处于页面的中部做这件事情否则做那件事情"的CSS动画，CSS不能提供分类的逻辑。

当CSS1.0开发者需要逻辑，他们经常通过CSS方法来声明类样式，然后通过JavaScript来处理需要应用声明的样式的逻辑。例如像AngularJS框架支持这种声明，然后许多UI交互设计师很轻易适应少量类似“loading”，“open”和“selected”的样式声明。这些动画也会减弱在老的浏览器的表现力，提供需求比较大且能够支持CSS动画和动画转换的UX驱动。

(正因为)交互设计师经历过不同的CSS动画时代，(所以清楚地知道)，CSS动画实现起来太苛刻，可能导致开发人员不能实现想实现的特效。另外需要为客户端要求兼容更多浏览器的可靠动画买单；所以，许多交互设计师和他们的工作室已经做了许多聪明的开发人员所做的事情：依据自己的工作进程，来编写复用度高的类库。类似这些类库，像GSAP和Velocity类库对大众来说很容易获得到而且很容易被发展。但是有很多人不会对外界发布，因为创建类库的个人或者团队没有时间或者没有钱来支持开源的项目。

这是我听了一遍又一遍的深深的令人焦急的故事，并且表明许多开发人员正在重复造轮子，但是并没有将web向前推进。这里没有足够的被认为"nice to have"的需求来支持许多的竞争对手。为了生存，很容易看到像GSAP类库如何被商业化，或者如何像Velocity类库被赞助。

由于Flash能够让交互设计师和UI设计师构建出通用且能够适应多种多样环境的动画以及能够提供简化它们的工作流程,就此而言Flash做了一件伟大的事情。但是自从Steve Jobs宣布2010年以后Iphone将不再支持Flash，许多正式的且具有丰富开发经验的Flash开发人员已经陷入被弃用的境地。现在，相比较而言，web设计师这整个一代人在一起交流时，并不知道这些可能性和我们所面临的挑战(当提升动画的复杂度时)。

但是这些事情即将焕发生机。

网页动画API：一个最伟大的且你从来没有听过的API

这个web动画API是一个按照W3C标准且为CSS动画和SVG动画提供统一的语言，为开发者调试开启浏览器的动画引擎。API包括以下内容：

1. 提供一个动画引擎API，使得我们可以开发更多基于浏览器的动画工具并且让动画类库性能提升；
2. 提供(限定)动画自己的多线程，废除掉jank;
3. 支持运动路径;
4. 提供后动画回调；
5. 重新引进自从Flash以后就没有见过的嵌套和顺序动画;
6. 能夠通过定时字典和动画播放器让我们暂停，播放，查找，倒退，慢放，或者快进回放。

这是Web动画API能够实现而CSS不能单独实现的一个事例。

通过Rachel Nabors(@racheInabors)在CodePen见识Pen(codepen)利用Web动画API运行

支持

Web动画API在创建的过程中已经超过了2年，API的特性已经在chrome和firefox发行版测试通过前前后后花了6个月。Mozilla是制订这标准的主要力量。以此同时，chrome团队已经为特性的支持设立优先级。

为IE浏览器“微软正在考虑支持API”。令人吃惊的是，苹果为Safari浏览器也采纳wait-and-see的方法。然后我们只能幻想当Web API碰上被开源浏览器所过时的叉形指令所支持web应用引擎。

想浏览API的早期尝试者可以试验Web动画API中的polyfill，正在随时被Web Animation Next逐字取代(更多关于polyfill及其API详见Polymer project)。然而，对浏览器来说，不支持Web API，意味着polyfill库性能仍然会比GSAP(基于JavaScript动画类库的冠军)差。因此，polyfill库并不是开发人员为了构建高性能产品而把它加入到上述产品中的可交互类库。

Web API被全部支持还需些时日。一半的浏览器厂商推迟支持API以便来观察开发人员如何使用API，并且大多数开发人员是拒绝使用未广泛支持的工具，Web API正面临鸡和蛋的窘境。然而，舞台上一次与Google的Paul Kinlan对话中，我表明，Web API在一个不公开的获利系统中完美的支持像Google Player等web应用，在Web API未达到成熟稳定以及完全支持情况下，开发人员可以在"有墙的花园"中安全使用API。

性能

API的作者和参与者希望动画类库的开发人员可以开始尝试寻找Web API支持提升自身的性能优势的特性。因为Web动画API使用的是CSS渲染引擎，所以我们可以预期CSS性能的好坏程度。只要动画不依赖发生在类似JavaScript或者布局的主线程的任何事情，这样的话动画就会依据自己的线程来运行。

说到布局，对浏览器而言回流存在一个最大的处理障碍。除非你通过WebGL动画类库(开发人员正在使用灵活性高的内部动画类库)直接将所有的东西输出到GPU，否则没有哪个CSS动画或者JavaScript动画可以规避这个障碍。除了不透明度和变形以外，令我们倍受启发的是，CSS属性的改变会导致回流的产生，例如布局上的一些改变或者屏幕上像素点的重绘。改变CSS属性有助于这些并促使我们指出一些问题，然后告诉浏览器，“CSS属性将要改变，浏览器要做的事情就是如何高效的改变CSS属性”。希望浏览器在图像处理能够变得更灵活，这样的话，浏览器可以将图像元素移动到浏览器的图层中或者在另外方面优化浏览器处理图像的方式。这是消除像translateZ(0) hack的第一步。

每当动画正在(进行)闪避(动作)时，一些“性能hacks”就会被用来对动画(的运动轨迹)进行神奇的修正，但是当无意识的使用性能hacks，就经常会造成性能事故。从长远来看，性能决策真的最适用于浏览器。幸运的是，浏览器制造厂商正在争相让浏览器只需要更少的属性(的功能)就能实现触发回流，这样的话，可以使动画规避主线程。对动画类库开发人员而言，这就意味着在不久的将来，Web动画API在性能上成为最大的赢家。

工具

与web动画打交道的任何人迫切希望有合适的动画开发工具必须具有以下功能：时间轴，审查元素，编辑器，能够暂停和倒带，在另外方面处于调试状态下可以检测动画。Web动画API会对开发人员开放CSS渲染引擎内核，然后浏览器制造厂商基于CSS渲染引擎开发针对自己浏览器的工具。但是Chrome和Firefox正在为它们的开发工具实现支持动画特性的功能。Web API让这些事情的实现变成了可能。

今天的Web动画社区

除了与Web动画API打交道的人之外，还有不少的人知道Web动画API。官方社区殷切希望获得来自现实世界中交互的反馈以及动画类库开发人员的青睐。然而，一些开发人员感觉标准化(让他们感觉)像活在象牙塔里面，远离战场的残酷，不用顾虑用户的需求，不用再为Flash烦恼纠结。

公平地说，标准化的出现并不是在动画这个领域迎合它们的忠实支持者。参与到官方的Web动画API交流，必须通过层层审核，避免人们通过邮件链接导致(忙碌的)开发人员的收件箱遭受爆满的情况。或者，你也可以使用IRC然后加入交流中来(只有设计师使用IRC)。需要开展的对话，如果处于这种情况下(占据重要地位的人没有参与交流)，一般是很难开展下去的。浏览器供应商和标准制定者需要找到如何与重要的支持者交流的多条途径，否则就要冒着没有一个支持者的支持风险来创建Web API。

标准化并不是唯一一个有交流上的问题。作为一个社区，我们是具有批判精神的，并且能够很快放弃我们认为不值得做的事情(Flash或者我们不喜欢的API)。我们大多数人喜欢对自己(开发的)工具和项目进行自我投资。但是这些情况不能对我们进行定义。我们在一起创造的东西才能定义。

动画类库开发人员，阅读这些标准，很长，但是如果GreenSock’s Jack Doyle可以做的话，你也可以。

交互设计师，这是一群没有足够的时间来阅读这些标准，仅仅是阅读详见polyfill，完美的TLDR。既然你知道这些标准，就应该知道这些标准对你优化类库的性能或者构建浏览器内置时间轴UI可能有很大的作用

设计师，工作上优先考虑JavaScript。鼓捣polyfill技术，把玩GSAP和Velocity。在你工作中找出CSS不能单独完成的项目。

正因为有web动画，我们才能有这少有的机会来撇开自我，然后一起为社区构建将来一代开发人员和设计师能够用它做出伟大的东西的工具。为了(这个伟大的愿望)，我希望我们可以(创建这样的工具)。

   “艺术挑战科技，科技激发艺术。”

   – John Lasseter, CCO Pixar

资源

Rachel Nabors有Web动画API更新的资源列表。加入非官方的交流，无论你在什么地方，只要你喜欢交流，就可以寻找#waapi标签。

1.Web动画(API标准)，W3C
2.Web动画polyfill和Web动画的下一步(下一个polyfill的实体)
3.GreenSock动画类库
4.Velocity Velocity.animate()代替jQuery的animate()

加入交流当中来

1.官方邮件列表：public-fx@w3.org，开启[web-animations]...相关的主题列
2.IRC:irc.w3.org#webanimations
3.其他任何地方：使用标签#waapi然后加入到这个社区

区别对待

熟悉C++代码风格的工程师可以在FireFox中实现API。Brian Birtles可以指导你!然后Mozilla经常招人，帮忙在MDN上写文档。

对标准(语法，拼写，矛盾等)的小幅度修改后，然后可以在GitHub上提交。

在Twitter可以关注的工程师

Brian Birtles，Web Animation标准制订主要作者，Mozilla日本

Alex Danilo，Google平台成员和发起人

Tab Atkins—Googler，CSS标准发起人和制订者

Jack Doyle，GreenSock成员和GSAP成员

Rachel Nabors，动画中最前卫的思想击败了Tin Magpie

解决手机方面的问题令人很头疼。这也是我们为什么和Peter-Paul Koch合作编写移动web手册(有效处理手机常见的前端问题的实战新指南)，现在可以了解这本书

---

Rachel Nabors，交互设计开发人员和漫画大赛获奖的漫画家。她环游世界，在web动画的艺术领域培养团队和谈论web动画。考虑到她从不在Portland骑车闲逛，她在公司Tin Magpie里创作互动性强的漫画。你可以在Twitter@rachelnabors关注她或者她的主页rachelnabors.com。