给 1 分钟的王者“击杀”合集做一系列炫酷动画，并集成到客户端的一键战报生成功能中，需要多长时间？就像这样，带“开黑局”专属的转场动画，英雄昵称 KDA 一应俱全：
能在每段“高光”操作出现时，加上一段文字动效渲染气氛：
还可以在出现“三杀”等极限操作的时候，配合英雄来一把炸场效果：
对于特效设计师和客户端的开发人员们而言，从设计完成到研发还原效果上线的时间原本应该在一周以上：毕竟设计师不光要在 AE 里搞定特效设计，还得跟研发人员反复确认代码的效果还原度。碰上特效太复杂、动画文件太大等情况，免不了又是一场办公室 battle……
这种掉头发伤感情的事，早已让程序员们坐不住了。这不，他们干脆搞出了一套自动化工具，用上它最快 4 小时就可以交付上线一个动画。
而最近，这个由腾讯 PCG 发布器中台开发，名为 PAG （Portable Animated Graphics）的工具传出“即将对外开源”的消息，更是直接在动画设计师和研发圈子里点燃了一把火。毕竟，官方邮箱里早已塞满来自外部的 SDK 申请和开源许愿贴。
所以，PAG 到底是怎么一回事，能让研发和设计师们如此跃跃欲试？
简单来说，PAG 是一套完整的动画工作流。在 PAG 出现之前，理想的移动端动画制作流程是这样的：设计师们先用 AE（Adobe Effect）设计出一段动画效果，导出动画效果文件（gif 或视频 Demo）并交给研发；然后，研发们尝试用代码还原动画，渲染出我们在移动端看到的效果。
但实际上，设计和研发的（一整周）工作流程是这样的：
双方 battle 的问题包括且不限于：从研发角度来看，并非设计给出的所有特效都能在手机上实现。
如果系统不支持特效实现方式，即使它非常酷炫狂拽，用户也无法体验。例如，某个交互特效在安卓和 iOS 上都无法实现，研发就可能把它打回给设计“重做”。除了无法实现的特效以外，难以实现的特效也在“重做”范围内。如果设计给出的特效不在库里、或是排期不允许，最后都得让设计重做。
即使前两个需求都满足，研发还得考虑实现性能等问题，如果实现完发现对性能要求过高，也会被打回去“重头再来”。
从设计角度来看，并非研发给出的每个解决方案都可以接受。如果一个精心设计的动画，被研发用另一种方式“拼凑”出来，导致效果看起来很“低级”，就脱离了设计的初衷。
因此设计往往需要和研发反复 battle 协商，最终确定一个折中的方案，甚至在预览阶段，动画特效也不一定就能拍板，如果临时变更需求，研发就又得再来一遍……
这种情况下，PAG（Portable Animated Graphics）作为一套动画工作流“横空出世”。它包含三部分：PAG 导出插件（PAG Exporter）、桌面预览工具（PAGViewer）、渲染 SDK，分别用来解决前面提到的三大研发问题。
首先，设计师在 AE 中做出一段动画后，无需再导出成视频或 gif 这样的动画效果文件，而是能通过 PAG 导出插件，直接将 AE 动画编码导出成一份.pag 格式的动画文件。
这个插件，相当于从源头上解决了设计与研发之间“来回返工”的问题。当设计文件中出现系统不支持的 AE 矢量特性、或使用了特别影响性能的属性时，PAG 导出插件就会给出修改提示，帮助设计师导出符合系统要求的动画文件。
细节上也有一些好用的地方，例如一键设置就能导出 BMP 预合成、设置占位图填充模式等功能，进一步节省设计的时间；
由于导出的.pag 文件采用二进制格式存储动画信息，不仅有效降低了文件大小，还能让设计师们往里面直接放各种素材资源（图片、音频等），交付时只用发送一个文件。
▲ 文件格式长这样
然后，设计师在预览时，就能直接采用 PAGViewer 在 PC 端预览.pag 动画文件的效果。这样设计师无需等待动画文件上线、就能一键预览移动端的动画效果。还可以直接在 PAGViewer 里面修改可编辑文本或占位图：
除了修改可编辑文件和预览效果，PAGViewer 还增加了性能展示面板，里面包含了 pag 动画的基本信息，如时长、帧率、尺寸、bmp 预合成的数量、图层总数等。
如下图所示，设计师直接就能通过面板，看到量化的性能指标，来定量评估.pag 文件的性能，并进行针对性优化，避免上线前才发现“性能卡设计”等问题：
最后，开发只需要一次性的渲染 SDK 接入就能加载 PAG 文件，直接在 Android、iOS、mac OS、windows、web、Linux 等常用的平台端准确还原动画效果，无需进行额外开发。当然，由于 pag 文件的可编辑性，开发自己也能直接修改或替换文件中的文本和占位图，不用再在需求上麻烦设计。
一段动画特效可以被分成‘动画效果 + 内容’两部分，‘可编辑性’指的是替换‘内容’部分。
以“滚动的一串文本”动画效果为例，其中文本信息是内容，滚动就是动画效果。pag 可以在保留预设动画的情况下，做到修改文本的内容，字体，字号，颜色等十几项属性。除了文本可以被修改替换，PAG 还提供了占位图的替换能力，同样在保留预设动画的情况下，不仅可以替换照片，甚至可以直接把视频也放进占位图。
这样一来，不仅避免了设计反复根据需求修改动画特效的痛苦，还能将动画特效运用于视频剪辑中。像我们在开头看到的王者特效，包括昵称和 KDA 其实都可以被一键替换，不需要再将对应的动效重新设计一遍。
▲ 这次是情侣组合（狗头）
总结一下，PAG 最大的优势有以下几点：
输出动画文件极小，比同类型方案平均降低 50%
支持所有 AE 效果导出，包括第三方 AE 特效插件
运行时保留动画效果，实时编辑文本替换占位图
提供从导出、预览、到性能优化的完善工具链支持
SDK 覆盖所有平台，包含 Web 以及服务端渲染能力
解决的正是当前短视频特效设计师们最头疼的几大痛点。
其实在 PAG 出现之前，业内已经有一些类似的设计插件，但或多或少存在一点问题。PAG 究竟是怎么解决它们的？我们与 PAG 的研发团队、腾讯 PCG 发布器中台下编辑子工作组的负责人 Dom 取得了联系，了解了背后的实现原理。
Dom 表示，PAG 早期最有挑战的地方，其实就在于“动画文件设计”和“全 AE 特性支持”这两部分。
在输出文件格式方面，已有的 JSON 等格式存在两大问题：解码速度慢、压缩率低。为此，团队重新设计了一种名为.pag 的文件格式，采用二进制数据结构来存储动画信息。
一方面，二进制数据结构不需要做字符串匹配、序列化等操作，解码速度会比 JSON 等格式的文件快上许多。测试数据显示，在解码速度上，PAG 格式的动画文件要比 JSON 文件快 12 倍。
另一方面，相比于 JSON，二进制数据结构具有更高的压缩率。JSON 文件导出的冗余信息较多，而二进制的数据结构则能跳过大量默认值存储，并使用动态比特位来紧凑存储。因此相同的动画内容，PAG 文件比同类型方案压缩文件小 50% 左右。
此外，采用二进制数据结构还有一个额外的好处，在导出动画文件时不用再搭配“图片包”（外挂图片），一个文件就能搞定，包括音频也能够内置。
说完文件格式，再来看看 PAG 文件是如何做到支持所有 AE 效果的。这个特性使得 PAG 文件既能实时预览复杂特效，又能确保动画的可编辑性，但在之前，它们并不能同时被实现。这是因为传统的动画的导出模式有两种，即矢量导出和序列帧导出。
矢量导出的动画文件具有可编辑性，但缺点是一些复杂特效无法在移动端实时预览，因此无法做到全 AE 特性支持。序列帧导出基于截图的原理解决了这个问题，也就是将复杂的视觉动效全部截成图片，再实现导出。但这就导致文件大小可能高达几十上百兆，对移动端而言“又大，又没法编辑”。
为了让文件既可以编辑，又能保证精彩动态效果的实现，PAG 的研发人员们想到了混合导出的方法。简单来说，就是给不需要可编辑性的图层打标记。这样在导出时，需要保留编辑性的图层就会以纯矢量形式被导出，而打了标记的图层，则以序列帧的方式导出。
值得一提的是，为了尽可能压缩导出文件的大小，PAG 团队还自己设计了 bmp 预合成的格式，充分利用了视频的极限帧间压缩能力，并在此基础上扩展了对透明通道的支持。
再加上渲染方面的优化，最终，相比于传统图片序列帧，视频序列帧格式的文件大小可以降低到原来的 1.24% 左右。
但从基础功能的实现，到如今成为一整套完整的工具流，PAG 并非“一蹴而就”。与之相反，虽然 SDK 去年才开始对外开放，但早在 2016 年，PAG 的第一行代码就已经写下。从最初的 1.0 版本迭代到如今的形态，PAG 已经走过了 4 个版本。
“从写下第 1 行代码，到第 1 次跑通，团队就用了 6 个月时间。”至于为何要选择坚持打磨这样一款工具产品，Dom 提到了一个“回忆杀”的词语 Flash：
在 Flash 时代，动效开发有一套非常完善的工作流：设计师把动画制作出来，导出一个 SWF 文件，开发人员无需手敲代码还原效果，直接导入就能使用。并且动效里面的细节是可以调整的。
但到了现在的 H5、移动应用开发里，很少有工具能够完整还原这套完善的动画工作流。
他希望 PAG 能在视频编辑这样一个场景里，把这套工作流带到移动端动画制作上，降低或者消除动画相关的研发成本。
这个想法在市场上也很快有了案例验证 ——
PAG 项目开始的同一年，支持将矢量动画导出到各个平台的 AE 插件 Lottie 问世。这款插件的成功问世，证明了还原 Flash 这套设计到研发之间的流畅工作流“跑得通”。
和 PAG 团队一样，Lottie 背后的开发者同样有着深厚的 Flash 相关经验，只是 Lottie 主要面向 UI 动画设计，不太适用于短视频场景。
为了能够满足短视频贴纸动画以及模板的开发需求，PAG 团队选择了继续自研。6 个月之后，PAG 1.0 版本出炉。
腾讯的设计师们试用后，PAG 团队得到的反馈是“存在不少问题”，核心概括起来就是：
1.0 版本虽然支持了带动画的文本编辑，但仅覆盖了 AE 的纯矢量导出能力，很多复杂动画效果无法被完整还原。
为此，PAG 继续迭代出了 2.0 版本：通过混合导出实现 AE 全特性支持，同时解决了特效和可编辑性的问题。开发团队还在 2.0 版本引入了占位图的能力，为照片模板和视频模板的生产带来了工业化量产的能力。
到 3.0 版本时，PAG 在编辑性上进一步探索突破，强化了图层级别的原子编辑组合能力，支持了从原子特效组件动态构建模板，很好地支撑了游戏战报和一键出片等动态模板的需求……
这时候，PAG 功能已经相对全面，腾讯内部设计师开始“口口相传”，将 PAG 主动推荐给外部的其他设计师使用，也因此反馈出了更多的需求。
就在本月，PAG 完成了 4.0 版本的开发，并传出开源信号。这个版本耗时近一年时间完成了渲染架构的重大升级，彻底脱离了谷歌的 Skia 2D 绘图库，SDK 包体也直接下降了 60%。
具体而言，PAG 团队自研实现了一套轻量纯 GPU 绘图引擎，通过最大化利用平台端提供的所有能力，以 500K 左右的包体覆盖了 Skia 的绝大部分功能，并且在接口设计上充分暴露了针对现代 GPU 渲染的优化能力。因此，包体减小的同时，渲染性能的上限实际得到了进一步的提升。
另外，PAG 4.0 版本基于这个全新的 2D 绘图引擎，也将正式拓展对 Web 端的支持。量子位还获悉，目前 PAG 4.0 版本已经走完腾讯开源审核流程。
回过头看，PAG 的不断进化，其实也得益于腾讯内部复杂的业务需求。开发团队与业务方的持续“battle”，使得这套动画工作流始终贴合着设计师、工程师们最真实的“痛点”。这或许也就是为什么，明明是一个腾讯内部工具，却在外部因使用者们的口口相传打出名气，被推动着走向开放、开源。
说了这么多，是时候附上传送门了。如果你对 PAG 感兴趣，现在就可以去官网获取 SDK。开源代码也正在路上，可以一起蹲一个~
官网链接：
https://pag.io/
广告声明：文内含有的对外跳转链接（包括不限于超链接、二维码、口令等形式），用于传递更多信息，节省甄选时间，结果仅供参考，IT之家所有文章均包含本声明。