现在的营销活动，用一张简单的图片去吸引消费者已经远远不够，必须要有能给消费者带来视觉冲击的东西，或者在动画过程中提供更好的引导部分。手淘的前端团队经历了从Gif、视频到CSS Animation的从0-1的过程，并致力于研究的数据化驱动的动效。大漠将为我们带来在手淘互动动效上的探索分享。
如果你对这个话题感兴趣，点击这里可以看视频。
互动，是连接用户的桥梁
我们以前访问Web页面是没有动画和动效的，甚至点击跳转的功能都很少。那时是纯粹的文字展示，图片在网站上也很少能看见。
最初点击一个链接跳到一个新的页面，这是一种交互。随着技术的变革，点击一个按钮会弹出一个窗口，这也是我以前认识的一种交互。现在我们的交互行为变得更加复杂。
用户无需进行任何操作，页面只是告诉用户去点击某个按钮可以进入一个页面或一个会场。这种交互行为在内部我们称之为引流。
- 一种是纯氛围的动画交互效果。
- 橱窗是加上一些动效或陀螺仪的功能，让用户觉得耳目一新。
- 抽奖是加入了一些用户的交互行为，点击红包就会告诉用户中了多少钱或者运气不好没有中奖。
- 视频现在也是一种传替交互的表现形式，如果加上一些其它的技术手段上去，能表现出来的就不止是我们看到的视频那样。
- 我们目前尝试在手淘互动里加一些简单的游戏，这些游戏就是利用前端的代码加一些创意，把用户吸引到互动的活动里来，让用户在这里驻留的时间更久。或者通过这些小游戏给用户带来一定的收益。
- 提醒是一个时间倒计时，告诉用户还有多少时间去参加“双十一”抢红包的活动。
交互在我们团队就是以上这些表现形式等。
最早我们只能看到PC端的Web页面，随着移动端的快速发展，移动端的互动方式也会越来越丰富。
动画，用于点缀
最早实现动画的技术方案是Gif、视频，还有早期PC端看到的Flash页面，这些方案都是前端不用参与的。但是Gif图放到移动端，会产生一些不好的后果。以及iOS不支持Flash，视频也有一些存在的风险。在CSS3出现以后，大家做简单动画的时候会经常用到。还有一些SVG和Canvas动画。但其实这些都还不能满足我们各种业务场景。我们今天的重点会放在JS-Driven Animation动画。
0-1的过程
2015年，我们团队经历了一个0-1的过程。在15年之前，各种大触看到的氛围和动效基本上是Gif图或是视频。15年年货节，我们尝试了第一次的改变，通过前端CSS或JS的技术手段，把一个Gif图转换成动画效果。完成这个效果的时候，无论是需求方还是产品都很满意，因为这种方案可以随时更改动画中的元素。
CSS动画的痛点
- 沟通成本高。
- 开发成本高：因为要通过CSS去繁衍一个视频或Gif图演示的动效，除了要懂这方面的技术之外，还要让Gif图通过代码层面来实现。
- 还原度低：CSS实现动画的手段是有限的，要做一些复杂的动画还是有难度。
- 可控制性低：如果需求方改变了其中某一个动画需求，我们至少要花2-3天来繁衍那部分的效果。
- 可交互性弱：CSS动画无法实现在播到某个时间段突然弹出窗口告知用户可以参加的活动。
- 日渐无法满足业务场景：在0-1的过程中，需求方可能还是比较满意的，但是如果每次的动画效果都是用这种方案来实现，需求方会觉得很无聊，做出来也无法达到100%的还原度。
JS-Driven Animation
经过市场调研综合结果之后，我们最终还是选择自己“造轮子”。因为我们希望可以是自己控制的，不用担心被别人起诉，也不担心新功能无法在它的基础上进行扩展。
后来我们经过一年的时间做了一个用JS驱动动画的工具Animation Flow Tool。
动画管理
我个人喜欢把动画的管理当作是导演一场舞台剧，要指挥每个演员何时出场，出来做什么，何时退场。在我们的动画管理中有一个timeline，它很像导演的角色。
通过时间轴可以很好地控制动画的场景，包括它何时播放、何时停止、何时退出。
CSS处理动画衔接的短板
CSS是通过持续时间来实现控制，如果所有时间点都已经确定了，这样做是没有问题的。
比如动画“火山升起”的时候发来1秒的时间，第二个动画“火焰柱喷发”是在“火山升起”结束后开始播放。这时就可知它的延迟时间是1秒，“岩浆流动”同时播放也是1秒。到了“红包喷发”的时候就需要进行计算，前面的动画播放4秒后再播放“红包喷发”，它的延迟是1.4秒。如果这时“火山升起”的持续时间有所变动，那么后续的所有时间都要重新进行计算。这是CSS管理动画最大的缺点之一。
动画（片段）之间有重叠
后来我们改变了一种模式，通过JS来监控第一段动画，并告诉后面的动画什么时候结束再可以开始播放。这时无论第一段动画如何改变，都不用担心后面的动画。
扩展动画
CSS在手淘上实现的动效性质都是相同的，我们把它定义为精灵动画和路径动画。经过一年我们发现这两种动画是我们业务中最常见的动画效果，于是就对它们进行了封装。
精灵动画
以前要把所有图案拼成一张图，然后通过Animation控制每一帧的播放。后来我们通过API来控制。
比如一个图案从底部出现到顶部隐藏一共经历了80帧。按照以前CSS的动画实现方案，需要拼80张图片。在这80张小图里有40张可能是相同的，CSS却不能把相同的图片利用起来。
而AFT的方案是可以的，也就是说在这个基础上最起码节省了40张图片。
CSS路径动画
在没有AFT的情况下，我们做的是路径动画，通过translate来改变x和y轴的轨径位置。
我们当时做这个动画效果描点描了很久，但是产品经理突然提出不要Z形的路径，要改成S形，我们又只好重新描S形的路径出来。有一位同事描了七套路径，需求方还不是很满意，因为用translate来描点，不管怎么描到无法达到流畅的效果。
AFT路径动画
后来我们改用SVG的路径，无论需求方想要什么路径，只要找个SVG的制图软件导出路径节点就可以。这是我们后来对路径动画做的改变。
如果以后CSS的路径动画属性得到浏览器的支持，可以直接用原生的CSS路径动画，也支持SVG导出的路径，实现路径动画，AFT就要退出历史舞台了。
AFT骨骼动画
骨骼动画是借助第三方平台的工具把骨骼动画做出来，导出它的json数据，拿到json数据再出动画效果。
AFT架构的演变
最早的时候我们是利用IDE导出一份json数据，通过第三方JS库来实现DOM的动画效果。我们的第二种方案是通过An/AE导出一份json数据，再通过前端的DSL层面来实现动画效果。经过实验，这两种都不是我们想要的实现方案，后来我们对它进行了一些简单的改造。
aft.js架构细节
第一部分是元素，第二部分是动效器，第三部分是引擎，最关键的一点是动画管理，也就是时间轴。元素和动效是分离的，只要做动效，然后把动效赋予到元素上，再找引擎来渲染。
我们专注于做管理动画，怎样把动画描述出来，怎样把动画串起来构成我们所需业务的动画。这是AFT后面实现的底层架构，看上去没有以前那么复杂。
业务开发模式
曾经开发模式
视觉设计提供一个Gif或视频文件和一个PSD文件，交付到前端。前端根据Gif或视频的动画效果，把整个动画繁衍出来。也就是AFT动画繁衍的过程。这个模式的沟通成本非常高。
现在的业务开发模式
前端只负责业务层的逻辑代码，视觉通过AE这种制作动画的工具去导出动画。要有业务逻辑，再通过前端加入业务逻辑。如果不要业务逻辑的话，就无需前端界入了。
可量化和数据驱动
粗犷的做法
AE导出的不是json数据，它做出一个视频，然后前端再通过代码繁衍。
正确的做法
通过动画编程语言进行实现，要什么效果就能繁衍出什么效果。
思考探索
我们提出了一个“动画工程师”的概念。我们团队目前还在思考动画工程师应该做什么，动画工程师是不是能直接实现动画的过程就可以称之为动画工程师。但我个人认为远远不止这些，我们还在思考探索中。
我今天的分享就到这里，感谢聆听！
大漠
如需转载，烦请注明出处：https://www.w3cplus.com/animation/animation-exploration-for-taobao-mobile.html