1.情感动画

情感动画往往更偏向于情感化，其主要目的是提升产品的气质，传达情感，增加产品的魅力。我们也可以通过一些彩蛋的形式，在一些小细节中加入一些情感元素，给用户带来惊喜。常见的例子有APP内的动画，点赞动画等。

2.交互式动画

产品流程与交互行为的衔接，无论是可以实际操作的交互原型，还是纯粹用于演示展示的动态转场，都可以视为交互动效设计。交互动效最基本的形式就是原型流程图的衔接。

交互特效又可以分为转场特效和微交互，分别应用于页面衔接和基础组件的交互反馈，前者可以向用户传达产品的层级结构和空间关系，后者可以降低用户的操作成本。

3. 合成动画

复杂的动效并不局限于感知层面的情感传达，也不局限于交互行为的串联，这类动效往往在现实场景中更为常见，与开发者交互时也存在更多不稳定因素，对设计师的挑战更大。

影响产出的因素

影响产出的因素

情感动画一般受大小、时间和动画复杂度三个属性影响：

1.动画大小

动画尺寸越大=占用系统空间越大=占用系统性能越大，但是这个等式只适用于一些常见的所见即所得格式，例如gif/video/webp/apng等。

这类格式是我们的设备能够接受的最简单、最直接的格式。制作动画的逻辑通常是将不同的静态图像堆叠在一起，按照给定的顺序和时间逐张播放。

每张静态合成图的尺寸越大，整个动画占用的内存就越大，但我们的产品包容量永远是有限的，不能允许占用过多内存的动画存在。

另一方面，大尺寸静态图片在预览过程中也需要更多的设备计算。举一个很简单的例子，当我们在电脑上预览一张800*600的图片和一张2400*1800的图片时，电脑打开它们所需的时间是不一样的。相应的，在预览多张动画格式的大尺寸静态图片时消耗的系统性能也会成倍增加。

2.动画时长

影响的原因和大小类似，当图片入栈时间变长时，栈内图片的数量也会变多sketch怎么合并图层，动画占用的内存也会相应变大。

所以当我们的动画时间太长的时候就不适合使用这些格式类型。

需要注意的一点是动画的持续时间对性能的影响相对较小。

3.动画复杂性

动画的复杂度在以上几种输出格式中都不是问题，但在近些年比较流行的一些输出工具中，动画的复杂度就成了问题。对于复杂的动画，我们尽量选择所见即所得的格式输出。在选择其他格式时，也要尽量降低动画的复杂度，保留关键点，去除多余的细节。

情感动画输出选择

一般来说，我们根据动画的类型把输出方式分为两类：

所见即所得格式

所见并非所得格式

所谓所见即所得，就是我们在输出之后可以预览一些最常见的格式，例如GI比例的图像/视频，这也是我们很多动画输出的最基本格式：

GIF 图像格式

GIF 是设计师接触到的最常见的动态格式，自 1987 年被公司推出以来，GIF 就因为体积小，图像比较清晰，特别适合早期较慢的互联网而大受欢迎。因为时代背景，它的兼容性非常强，基本上可以在目前大多数智能设备上直接预览。

它的动画效果和平台兼容性都非常好，特别是在一些设计平台上，它是概念演示最流行的格式之一。它还具有很好的可传播性，因为它兼容不同的平台和设备。

当然，GIF格式除了自身有种种优点外，由于其应用时代的技术限制，还存在着很多其他的缺陷，上面所说的很多优点往往是其诞生初期给它带来的好处，而它本身就存在着很多不可逆转的问题。

第一点就是占用大量电脑内存和性能（根据GIF的时间大小等，会有不同程度的影响），作为设计师常见的经历就是在网页上打开几个GIF之后，电脑风扇就开始鼓鼓的。

第二点是它是一种有损文件格式，无论是颜色还是图像纹理都会受到一定程度的压缩；第三点是对透明通道的支持非常有限，输出效果会很差，经常会出现锯齿状边缘或者白边的情况。

以上是我们在导出为GIF格式之前需要提前考虑的一些问题：上述问题是否可以接受。

另外，导出GIF图片的过程也常常困扰着很多设计师，我也录制了一篇关于GIF导出的经验分享文章。

常规GIF输出（After）有三个选项：

第一种方法：先AE输出视频格式，再通过PS输出GIF格式，这种方式是市面上最常见的输出方式，内存占用一般，输出质量也一般。

第二种方法：在原有基础上做局部优化，先AE输出序列帧格式，然后PS选择图片的优化方式输出。

这是目前所有输出方法中内存占用最少，失真度最低的方法。内存占用低，输出质量高。不过有个问题，就是无法输出上述动画（受限于其自身局限性）。

第三种方法：直接通过GIF输出。内存占用一般，输出质量较低。一般在前两种方法无法输出时才选择这种方法。优点是比较稳定，基本不会出什么问题。

下图对比了不同输出方式的输出结果：

还有第四种选择，就是直接通过AE插件导出，该插件是一个非常方便好用的插件，但是这里不推荐，因为它有个限制就是只能输出低30FPS的动画，而且往往输出结果会有掉帧的情况。

EZGIF 压缩 GIF

当我们将图像输出为GIF时，如果图像内存无法达到理想大小，我们可以使用压缩。

视频格式

视频格式也直接兼容大部分产品，相比GIF格式，在一些衍生格式上它的内存可以更小，我们的智能设备也可以读取系统性能较小的视频格式。它的问题在于对透明通道的支持较差，同时也是一种有损输出格式，所以我们在导出动画时会尽量减少使用该视频格式。

压缩视频格式

我们可以通过软件直接对视频格式进行压缩，这样可以保证我们在输出视频格式时以最低的内存占用来呈现

APNG/WEBP

上面提到的两种格式是我们接触到的最古老、最不容易出错的格式，但随着技术的进步，这些格式显然已经不能满足我们现在的动画需求了。我们还衍生出了很多新的情感动画格式，比如 APNG、WEBP，这些格式都是从我们现有的 JPEG、PNG、GIF 等格式衍生而来的。

APNG格式是来自代码社区的一种格式，是png位图格式的动画扩展，但尚未得到png格式的官方认可。通过一些代码框架，可以在目前所有主流浏览器和移动设备上完美支持。与GIF相比，它支持的颜色范围更广，更清晰，占用内存更少，支持透明通道，具有很多优点。

WEBP是由 推出的，目前基本兼容所有主流浏览器。同样的效果，webp格式比png格式大小大约小一半。同时，它也兼容所有安卓设备。部分ios设备需要一定方式支持，但相比较而言，其各方面的表现都十分优秀。

这里我推荐一个可以帮助我们导出 APNG 和 WEBP 格式的工具（它也可以帮我们导出带透明通道的 GIF，不过以我的经验来看，导出 GIF 的效果并不是很理想）。我们可以根据自己不同的设备分别导出这两种格式，这样既可以保证我们的内容质量不被压缩，又可以保证更小的体积和性能使用率。我们也可以直接将这些格式拖到我们的浏览器中来查看实际的预览。

这种新格式虽然可以弥补GIF或者视频的负面效果，但它们也面临一个问题，就是硬件需要各种辅助支持才能使用，而它们在开发阶段往往无法得到很好的支持。这时候就需要我们引入另外一种格式—— Frame/Elf 。

序列帧/精灵

帧序列

在客户端，我们可以将我们的动画导出为单独的图层序列，并且使用一些工具对单独的图层序列进行压缩，以达到最低的内存使用量。

序列帧是一种无损低内存格式，但是只能在客户端环境中使用，不建议在Web环境中使用。原因是序列帧一般是随App包一起下载的，但是在Web上每次进入新的网页都需要重新下载。比如一个60帧的动画要反复向服务器请求60次，在如此高频率的请求下，很容易出现一个小问题就导致整个动画无法正常播放。为了避免这种错误，我们通常会将这60张图片合并成一张，通过代码在规定时间内显示某一块，所以这里我们介绍另外一种格式——精灵图/

精灵兔/雪碧圖片 ()

当我们把所有序列组合成一张图片时，往往是不够的，我们还需要为开发者提供具体参数，让开发者在什么时候显示哪部分，我们可以通过AE插件CSS(By)直接快速地输出开发所需的代码和精灵。

可以说是近两年动画输出必提的一个格式，由国内外各大厂推出并迅速推广，现在已经是十分常见和常用的一种格式，AE中其插件调用，其原理就是将我们的各种矢量元素和位图图层以及其关键效果节点打包成一个json格式的文件。

我们的开发人员不能直接使用输出的json格式，需要在代码中加入提供的第三方库来读取播放，相当于我们各种端口设备上的文件播放器的作用。会占用一定的系统空间，但一般不会很大，从长期的产品开发角度来说，绝对可以为我们的App节省不少空间。这也是它在这么短的时间内得到这么多公司认可的原因之一。

它是一款非常强大的输出工具，可以满足很多类型的矢量动画和图片动画的需求。但是它也存在一些不足：首先它对缓和曲线的解析会占用很大的内存，这个后面会讲到；其次对各平台的效果支持不是很稳定，很多时候很容易出现bug。

。

显卡

为了解决由于缓和曲线分析不佳而导致的性能和稳定性问题，我们提供了第二种替代方案 SVGA，它在导出后的内存使用率和所有终端上的性能稳定性方面要好得多。但是，它的内存使用率略高，并且支持的功能较少。

与SVGA最本质的区别在于代码记录动画过程的方式。基本上它在AE中是以关键帧和缓动的方式记录动画的；而SVGA则是记录每个时刻各个图层的动画状态，这样就省去了缓动值的计算。逻辑上和序列帧很像，但是因为它的材质可以重复使用，所以占用的内存会比序列帧要小。

基于实现方法，它将更加稳定，并且相应地，它将支持更少的功能。

可以结合使用SVGA格式，而且SVG在设备上的分辨率比在iOS上好很多，所以在很多设备上经常使用。

和之前的格式最大的区别就是输出后不能立刻看到输出结果，因为它和我们智能设备的格式比较垂直。不过好在他们也提供了一些可以在桌面端和移动端直接预览的软件，可以帮助我们在开发完全落地之前排除一些错误，可以在开发结果落地之前提前预判效果的可行性。

预览 (/iOS/Web)：#/

SVGA 在线预览：

（经过 ）

它可以帮我们从AE中导出CSS格式，理论上这个插件可以支持我们所有的AE动画，而且大多数情况下动画质量无损，比格式占用内存更小。

它的原理很简单，就是把所有的动画分成两种，基础的动画属性记录状态信息，复杂的效果变化属性直接导出为精灵，一起打包输出为一套文件，可以忽略我们之前遇到的所有问题，但是有一个限制就是只能用在web和h5页面上。

第三方动画库

要知道其实第三方的导出方式有很多，但是市面上被大家认可的并不多，这类输出方式的一大优势就是自带社区生态，尤其是网上有很多开源的动画资源可以直接下载使用，让我们可以用最小的成本获得一些动画效果。

/SVGA 优势

要知道其实第三方的导出方式有很多，但是市面上被大家认可的并不多，这类输出方式的一大优势就是自带社区生态，尤其是网上有很多开源的动画资源可以直接下载使用，让我们可以用最小的成本获得一些动画效果。

交互式动画和特效输出选择

所谓交互动画，顾名思义，动画的内容和我们的交互操作相关，并根据我们的操作反馈相应的动画效果。因此，它的实现原理比较多样，也比较复杂。

贝塞尔曲线

上一篇文章我们提到，大量的贝塞尔缓和曲线会带来系统计算压力的问题，要理解这一点，我们首先要了解贝塞尔曲线是如何构造的。

在开发环境中，我们为开发者提供了贝塞尔曲线，需要以下参数：

锚点 1 (P0)

锚点 2 (P3)

操纵杆 1（P1）

操纵杆 2 (P2)

在大多数情况下，我们可以直接按照上面提供的格式连接我们的矢量形状。少数情况下，特别是在一些交互效果中，我们需要手动提供每条曲线的参数。然而，我们不可能逐一测量并输出每个点的参数，这非常不现实。目前，市场上大多数设计软件和输出软件都会为我们提供一些简单的代码参数。

不过这些只是基于静态页面的情况，在动态效果页面的切换中我们该如何进行连接呢？以下图为例：

类似这样的例子中，我们需要为开发者提供动画的两种状态，分别是图标搜索框形式和输入光标的竖线形式。我们可以直接将各个路径的 svg 信息输出给开发者。/ 之类的工具虽然可以直接输出 Web 端使用的格式，但它们只局限于 CSS 格式，而无法提供 iOS 下对应的代码。为了解决这个问题，这里推荐另外一款软件——3。

3是一款专门为设计师准备的简易矢量图形绘制软件，有了3，设计师即使没有编程经验，也可以用合适的图形输出iOS/Web/对应代码，并且与它的关联性非常强，你可以直接在里面复制合适的形状，也可以直接在软件里编辑创作合适的图形，非常强大。

缓和贝塞尔曲线

缓和贝塞尔曲线就是我们在设计运动效果时使用的缓和曲线，它可以控制我们的运动效果的速度，直接控制我们运动效果的整体节奏。大多数情况下我们看到的缓和贝塞尔曲线是如下图这样的，和我们的贝塞尔曲线很相似，不同的是缓和贝塞尔曲线的两个端点是固定的，而贝塞尔曲线的端点是动态的。也就是说我们在给开发者对接缓和曲线的时候，只需要提供两个控制杆的位置就可以了。如下图所示，我们的缓和曲线的参数就是两个端点的坐标位置，分别是（0.17,0.67,0.83,0.67）。

那么我们在AE中怎样得到我们对应的缓动曲线的参数呢？在AE中我们可以将缓动曲线图表的显示类型选择为“编辑值图表”，调整为我们常用的缓动曲线的类型。

为了在AE中获取缓动曲线的参数，我们可以以图表的左下角为起点，按照两个摇杆的位置建立两个矩形，以左摇杆为基准的矩形的宽和高（整个区域的宽和高的比例作为值）作为缓动曲线的前两个值，以右摇杆为基准的矩形的宽和高作为缓动曲线的后两个值。

虽然上面的方法可以让我们更加方便的获取AE缓动参数的具体值，但是由于操作比较繁琐，所以只适用于我们已经完成了动画，需要落地的情况。大多数情况下，我们都需要在动画设计之前，通过一些方法来使用参数来使用缓动曲线。Flow插件就可以帮我们做到这一点。

它可以帮助我们使用通用的缓动曲线来设计动画，并且提供了开发环境中常用的25种缓动类型。我们还可以自定义一些缓动类型，并将它们备份为文件在团队内部作为规范进行传输，或者导入一些外部的缓动参数文件。

当然，在平时使用中，还是建议使用一些默认的缓动类型，这样做的原因有两点，一方面这样的默认曲线在算法上更容易计算，对系统性能的默认占用可以更低，另一方面，很多非系统默认的缓动差异需要开发和重写，无形中增加了我们的对接成本和后续的代码维护成本。

手动注释

基于我们对贝塞尔曲线和缓和曲线的理解，我们在手动输出标注的时候可以有更多的选择，也更容易实现。在手动标注的情况下，我们需要对动画中每个具体元素的参数进行参数化，一般我们把动画的基本单元分为以下六个部分：

元素（正在变化的元素）

属性（元素发生变化的性质）

参数（属性的具体数值变化）

时间（变化开始时间/持续时间）

差异（动画的缓和曲线）

备注（其他说明）

有了这些基本参数sketch怎么合并图层，我们就可以向开发人员完整的描述我们的动画流程，如下图所示。

另外，我们还可以采用更加直观的方式进行标注，并将这些样式做成组件并在团队内部推广，形成共识，这样可以大大提高动效标注交接的效率。

动态效果实现与扩展——代码

当我们通过上述手工标注的方式把工作交给开发人员时，从设计的角度看似乎已经把一切都做得很完美了，但回头再看，输出的结果往往大多数情况下并不是那么令人满意，这里面有很多综合因素，站在开发人员的角度看，我们往往做的很少，无法输出结果。造成这种输出和实现的巨大差异，最大的原因是设计师和开发人员对产品构成理解的巨大差异。

在输出动画时，设计师会花更多的时间和精力在调整动画细节（缓动、时间等）上，而对于开发者来说，影响最终输出效果的外界因素还有很多，一般有以下几点：

开发者的水平

时间安排的影响

框架结构和代码语言限制

其他影响

大多数动画都包含很多细节层次，逐一实现它们需要花费大量时间。例如，要制作如下所示的动画，您只需使用 CSS 设置最外层面板的宽度并添加过渡动画，但对于大多数产品开发人员来说，您需要同时为所有外部和内部元素制作动画。

第二个更麻烦的事情是，你在 HTML 中的图层与 HTML 中的图层不匹配。所以即使你在动画注释中标记一个矩形从 0 点向右移动 10 个像素，这对于设计来说非常容易，但代码中会有很多非常复杂的框架层，而且你设计的矩形可能并不存在。所以，它增加了一个烦人的过程。开发人员需要将设计块调整到他们的代码中，并且每个元素都需要以相同或不同的方式实现。这是一个非常容易出错的过程，这完全取决于你在文档中描述你的动画的清晰度，以及开发人员审查和实现你的内容的仔细程度。

第三点是修改动画效果非常麻烦。设计和产品开发是一个不断迭代的过程。然而在调整一个动画效果的时候，无论是设计还是开发，都需要花费大量的时间去重新理解之前的文件和代码。无论是AE文件还是开发实现代码，每个人根据自己的理解都会有不同的实现方式。从重新熟悉前期版本的实现逻辑到调整再到开发实现，需要经过一套非常复杂的流程。以上一系列的操作，都是我们为了单个动画转场所需要付出的大量努力。

为了让这个过程不那么痛苦，我们意识到我们需要跳出舒适区，使用不同的逻辑来构建动画，这也意味着我们不建议使用所见即所得的设计工具。相反，我建议你使用 html/css/js 来构建我们的动画系统。这需要一些时间来适应，但在做了几个动画之后，很多过程就会变得特别容易。事实上，对于开发人员来说，你不需要了解太多的代码就可以创建一些基本的动画。

一方面，我们可以真正控制动画的微小细节。对于开发人员来说，这种方法可以更轻松地将我的代码适配到他们现有的代码库中，而不是大多数注释软件自带的单薄 CSS 属性。虽然每个平台都会有不同的代码语言差异，但与从设计到代码的跨度相比，它们之间的跨度可以忽略不计。

我只是把输出的代码放在上面，这样开发人员就可以轻松地看到我做了什么，也可以复制和粘贴部分代码来产生一些效果。

当然，这样做也有自己的问题。首先，我需要在开始设置动画之前用 HTML 重构我的设计。但是，因为我们只设计动画发生的部分，所以它不会受到框架和代码逻辑的影响，所以会容易得多。此外，我们还可以直接复制 CSS 代码进去，这只需要几个步骤就可以重构我们的设计。甚至一些根本没有动画的部分也可以截图粘贴进去。

还有一种方式就是直接从实际项目的代码入手，但是这会比我们自己写一个demo要复杂很多，因为实际产品的代码框架更加复杂，需要重新梳理。

虽然这种工作方式主要是用代码来做一些动画，但大多数情况下还是需要先在一些动画软件上摸索一些想法，而不同的想法可能需要很长时间来编写代码。所以，如果我不知道自己想要什么类型的动画，我还是会花一些时间做一个 demo。

哪怕你在学习之前从来没写过一行代码，我也极力鼓励你去尝试。这些东西会给你非常意外的收获，而且也有很多优质资料可以供你学习。你不需要从 0-1 开始构建自己的代码知识体系。很多时候，连我都是自己动手，边写边查代码，查不到就问公司的开发。你需要学习的可能是对 HTML 和 CSS 代码的基本框架有一点了解，然后开始写。有了基础知识，你会发现你已经可以写出很多动画了。并尝试将其运用到工作中，一一攻克。

还有一种可能就是我们平时可以用一些简单的代码来画一些基础的组件动画，这种东西我们叫脚手架，可以为我们所有的基础元素制作一些小的动画，比如开关，按钮点击效果等，因为这些都是我们大部分时间都会重复用到的一些组件，制作一个动画就相当于把整个系统的动画都跑通了，这个方向不管是自己写代码还是通过开发人员来做都是一个很轻松的过程，而且它带来的效果其实是非常可观的。

市面上也有一些针对设计师的代码动画输出工具，比如 / 等，都是目前开发动画的热门产品，也非常推荐大家尝试一下。

总结

虽然输出动效的方式有很多，而且随着技术的进步，选择也会越来越多。但是，没有任何一种方案可以完全解决我们在动效方面的所有问题。而目前市面上没有任何一种工具能够真正解决设计思维的局限性。作为设计师，我们需要时刻保持敏锐的观察力，不断更新自己的知识树，以应对各种需求下的动效输出。另一方面，我们也需要站在更长远的视角去理解一个动效需求从产品逻辑到开发逻辑之间的差距，并尝试通过更多样化的手段去跨越这个差距。

如有侵权请联系删除！