给 1 分钟的王者击杀合集做一系列炫酷动画，并集成到客户端的一键战报生成功能中，需要多长时间。就像这样，带开黑局专属的转场动画，英雄昵称 KDA 一应俱全:

能在每段高光操作出现时，加上一段文字动效渲染气氛:

还可以在出现三杀等极限操作的时候，配合英雄来一把炸场效果:

对于特效设计师和客户端的开发人员们而言，从设计完成到研发还原效果上线的时间原本应该在一周以上:毕竟设计师不光要在 AE 里搞定特效设计，还得跟研发人员反复确认代码的效果还原度碰上特效太复杂，动画文件太大等情况，免不了又是一场办公室 battle

这种掉头发伤感情的事，早已让程序员们坐不住了这不，他们干脆搞出了一套自动化工具，用上它最快 4 小时就可以交付上线一个动画

而最近，这个由腾讯 PCG 发布器中台开发，名为 PAG的工具传出即将对外开源的消息，更是直接在动画设计师和研发圈子里点燃了一把火毕竟，官方邮箱里早已塞满来自外部的 SDK 申请和开源许愿贴

所以，PAG 到底是怎么一回事，能让研发和设计师们如此跃跃欲试。第四，游戏从开始到结束是一个相对较长的决策过程，需要权衡长期收益和短期收益，需要形成一些组合套路；。

PAG 是什么。

简单来说，PAG 是一套完整的动画工作流在 PAG 出现之前，理想的移动端动画制作流程是这样的:设计师们先用 AE设计出一段动画效果，导出动画效果文件并交给研发，然后，研发们尝试用代码还原动画，渲染出我们在移动端看到的效果

但实际上，设计和研发的工作流程是这样的:

双方 battle 的问题包括且不限于:从研发角度来看，并非设计给出的所有特效都能在手机上实现。

如果系统不支持特效实现方式，即使它非常酷炫狂拽，用户也无法体验例如，某个交互特效在安卓和 iOS 上都无法实现，研发就可能把它打回给设计重做除了无法实现的特效以外，难以实现的特效也在重做范围内如果设计给出的特效不在库里，或是排期不允许，最后都得让设计重做

即使前两个需求都满足，研发还得考虑实现性能等问题，如果实现完发现对性能要求过高，也会被打回去重头再来。

从设计角度来看，并非研发给出的每个解决方案都可以接受如果一个精心设计的动画，被研发用另一种方式拼凑出来，导致效果看起来很低级，就脱离了设计的初衷

因此设计往往需要和研发反复 battle 协商，最终确定一个折中的方案，甚至在预览阶段，动画特效也不一定就能拍板，如果临时变更需求，研发就又得再来一遍。

这种情况下，PAG作为一套动画工作流横空出世它包含三部分:PAG 导出插件，桌面预览工具，渲染 SDK，分别用来解决前面提到的三大研发问题

PAG 导出插件

首先，设计师在 AE 中做出一段动画后，无需再导出成视频或 gif 这样的动画效果文件，而是能通过 PAG 导出插件，直接将 AE 动画编码导出成一份.pag 格式的动画文件。

这个插件，相当于从源头上解决了设计与研发之间来回返工的问题当设计文件中出现系统不支持的 AE 矢量特性，或使用了特别影响性能的属性时，PAG 导出插件就会给出修改提示，帮助设计师导出符合系统要求的动画文件

细节上也有一些好用的地方，例如一键设置就能导出 BMP 预合成，设置占位图填充模式等功能，进一步节省设计的时间，

由于导出的.pag 文件采用二进制格式存储动画信息，不仅有效降低了文件大小，还能让设计师们往里面直接放各种素材资源，交付时只用发送一个文件。

文件格式长这样

桌面预览工具 PAGViewer

如下图所示，设计师直接就能通过面板，看到量化的性能指标，来定量评估.pag 文件的性能，并进行针对性优化，避免上线前才发现性能卡设计等问题:

渲染 SDK

以滚动的一串文本动画效果为例，其中文本信息是内容，滚动就是动画效果pag 可以在保留预设动画的情况下，做到修改文本的内容，字体，字号，颜色等十几项属性除了文本可以被修改替换，PAG 还提供了占位图的替换能力，同样在保留预设动画的情况下，不仅可以替换照片，甚至可以直接把视频也放进占位图

这样一来，不仅避免了设计反复根据需求修改动画特效的痛苦，还能将动画特效运用于视频剪辑中像我们在开头看到的王者特效，包括昵称和 KDA 其实都可以被一键替换，不需要再将对应的动效重新设计一遍

这次是情侣组合

• 总结一下，PAG 最大的优势有以下几点:

• 输出动画文件极小，比同类型方案平均降低 50%

• 支持所有 AE 效果导出，包括第三方 AE 特效插件

• 提供从导出，预览，到性能优化的完善工具链支持

• SDK 覆盖所有平台，包含 Web 以及服务端渲染能力

解决的正是当前短视频特效设计师们最头疼的几大痛点。

PAG 背后的技术门道

Dom 表示，PAG 早期最有挑战的地方，其实就在于动画文件设计和全 AE 特性支持这两部分。

高效动画文件

在输出文件格式方面，已有的 JSON 等格式存在两大问题:解码速度慢，压缩率低为此，团队重新设计了一种名为.pag 的文件格式，采用二进制数据结构来存储动画信息

一方面，二进制数据结构不需要做字符串匹配，序列化等操作，解码速度会比 JSON 等格式的文件快上许多测试数据显示，在解码速度上，PAG 格式的动画文件要比 JSON 文件快 12 倍

另一方面，相比于 JSON，二进制数据结构具有更高的压缩率JSON 文件导出的冗余信息较多，而二进制的数据结构则能跳过大量默认值存储，并使用动态比特位来紧凑存储因此相同的动画内容，PAG 文件比同类型方案压缩文件小 50% 左右

全 AE 特性支持

值得一提的是，为了尽可能压缩导出文件的大小，PAG 团队还自己设计了 bmp 预合成的格式，充分利用了视频的极限帧间压缩能力，并在此基础上扩展了对透明通道的支持。

但从基础功能的实现，到如今成为一整套完整的工具流，PAG 并非一蹴而就与之相反，虽然 SDK 去年才开始对外开放，但早在 2016 年，PAG 的第一行代码就已经写下从最初的 1.0 版本迭代到如今的形态，PAG 已经走过了 4 个版本

被 battle 出来的产品

从写下第 1 行代码，到第 1 次跑通，团队就用了 6 个月时间。至于为何要选择坚持打磨这样一款工具产品，Dom 提到了一个回忆杀的词语 Flash:

在 Flash 时代，动效开发有一套非常完善的工作流:设计师把动画制作出来，导出一个 SWF 文件，开发人员无需手敲代码还原效果，直接导入就能使用并且动效里面的细节是可以调整的

但到了现在的 H5，移动应用开发里，很少有工具能够完整还原这套完善的动画工作流。

这个想法在市场上也很快有了案例验证 ——

PAG 项目开始的同一年，支持将矢量动画导出到各个平台的 AE 插件 Lottie 问世这款插件的成功问世，证明了还原 Flash 这套设计到研发之间的流畅工作流跑得通

和 PAG 团队一样，Lottie 背后的开发者同样有着深厚的 Flash 相关经验，只是 Lottie 主要面向 UI 动画设计，不太适用于短视频场景。

为了能够满足短视频贴纸动画以及模板的开发需求，PAG 团队选择了继续自研6 个月之后，PAG 1.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，使得这套动画工作流始终贴合着设计师，工程师们最真实的痛点这或许也就是为什么，明明是一个腾讯内部工具，却在外部因使用者们的口口相传打出名气，被推动着走向开放，开源

。