动效平台作为快手举办大型线上活动的坚实后盾，发挥着承上启下的关键作用。本篇文章将全方位地为您呈现 Vision 动效平台的整体架构及其演进思路，为您揭开这一强大平台的神秘面纱。 本系列文章从我们在 Vision 动效平台中做的一些工作为切入点，计划通过多篇文章全面展现我们的工作成果。首篇将阐述 Vision 动效平台的整体演进思路，聚焦于平台的核心能力，为读者勾勒出我们在动效领域的初步布局。随后，我们将详细介绍渲染引擎 Crab，并分享在复杂动效渲染场景下积累的实践经验。接着，文章将深入剖析动效 Code Gen 能力的技术原理，揭示其背后的奥秘。此外，我们还将探讨多种序列帧格式（包括 APNG、AVIF、WEBP、普通视频、透明视频等）的最佳实践，帮助读者更好地理解这些格式在实际应用中的优势和局限。在此基础上，我们将进一步讲解背后的序列帧多格式转换服务的技术原理，揭示其高效运作的机制。
接下来，文章将转向动效准入、准出检测过程中的技术原理，为读者呈现我们在确保动效质量方面所做的努力。最后，我们将分享 Spine 动效在 React Native 技术栈下的实践，展示其在移动开发中的广泛应用和潜力。通过这些内容，我们希望能够为读者提供一个全面而深入的视角，以更好地理解我们在动效领域的探索与实践。
快手作为一个短视频平台，其丰富的内容需要通过多样化的表现形式来呈现。设计师精心设计的动效，在各种业务和活动场景中展现出了极高的表现力，不仅增强了内容的吸引力，还提升了用户的互动体验。
此外，我们更是充分利用了动效的潜力，通过在相同场景下对比运用不同的动效设计方案进行 A/B 测试。测试结果清晰地表明，那些融入了动效的页面在数据表现上往往更加出色，无论是用户停留时长、互动率还是转化率，都较未使用动效的页面有了显著提升。这充分证明了动效在快手日常业务以及大型活动场景中的不可或缺性。以下是快手过去带有复杂动效的项目案例：
鉴于动效在提升业务数据中的优秀表现，无论是日常运营需求还是大型活动项目，都涌现出了大量的动效需求。然而，动效的生产、交付、开发等多个关键环节都面临着诸多挑战。对于曾参与开发复杂动效需求的开发者而言，这种体验尤为深刻。要将动效需求高质量地开发并上线，往往需要付出较高的成本，开发效率也存在较大的提升空间。因此，我们亟需寻找解决方案，以优化动效开发流程，降低成本，提高效率。
从动效流程简要可概述：
动效生产环节：设计师们主要遭遇以下难题：
动效交付环节：设计师与研发人员之间的协调流程亦存在诸多问题：
交付流程繁琐：传统的基于文档的交付方式不仅要求设计师频繁导出资产并手动上传，而且在后续的维护上也需耗费较高成本。
缺乏交付标准：设计师在交付动效产物时，缺乏明确的流程标准和产物标准，导致研发人员在接收时难以判断其是否符合开发要求。
前置验收缺乏：设计师在工具中完成粒子、3D 模型等设计后，无法直接预览其在 Web 平台上的实际播放效果。
动效开发环节：研发人员则面临着更为严峻的挑战：
这套方案对于整个动效流程，希望通过制定 SOP + 平台化落地规范和流程，解决规范和流程导致的低效问题，同时在各个阶段通过提供不同的能力，解决上述提到的各个环节各自的问题。
在着手开发我们自己的解决方案之前，我们深入调研了行业内的现有方案。排除纯游戏开发的特定场景，当前在常规动效需求的开发中，业界主要呈现出以下三种策略：
游戏化开发方案：通过一个包含编辑器 + Runtime 在内的引擎，实现中大型团队协同完成复杂场景开发的问题。然而，该引擎本身并不支持动效的直接生产，需要配置专业人员来负责把生产工具的产物导入为符合引擎要求的格式。这一方案适合大型团队协同开发复杂需求的场景。
单一动效类型的方案：通过只支持一种动效类型（例如序列帧），大大简化了交付与开发流程，大量减少自研工具复杂度和成本，但动效性能和表现力存在一定的局限性。更适合比较简单的纯播放类动效场景。
多动效类型统一生产工具的方案：通过自研的生产工具 + 支持多类型动效的 Runtime，使设计资产可以无损传递到开发阶段。但该生产工具因为既要实现生产工具（例如 AE、Unity 等）的功能，又要实现方案一的编辑器功能，开发成本极高。适合中小型团队开发多种动效类型的场景。
考虑到快手在日常业务和大型活动动效开发中的具体特点：
我们发现，方案 1 对设计师的能力要求过高，与快手当前的组织架构和设计师团队现状不相符；方案 2 在动效性能和表现力上无法满足快手对大型活动的高标准；而方案 3 在人员能力匹配、性能要求满足以及业务场景适应性方面，整体更符合快手的实际需求。因此，方案 3 为我们提供了一个值得深入探索和优化的方向。
或许有读者会感到好奇，为何我们不直接采纳现有的开源项目呢？
诚然，方案 3 中确实存在外部的优秀产品，但其中编辑器部分作为开发工作量较大的关键环节，却是以在线工具的形式存在，无法实现本地化部署。这一特性使得我们在使用时不得不面临资产流失的潜在风险。鉴于此，我们审慎地决定，整套方案需采取自研的方式，以确保资产的安全与可控。
当然，在自研的过程中，我们也并未完全排斥开源工具。相反，在部分场景下，我们巧妙地融入了合适的开源工具，以期在保障功能实现的同时，进一步降低开发成本。
为了更高效地推进自研工作，我们对整个动效开发流程进行了详尽的功能拆解：
针对动效流程的三个部分：
进一步的拆解，因为我们专注于活动 / 日常业务场景的动效，不考虑纯游戏的场景，需求又分为两种类型：
| 通用性需求 |
| 效果 | 弹窗、气泡、Banner 等常规动效 |
示例 | 
|
占比 | 约91% |
重点关注 | 效率和稳定性 |
承接方式 | 通过标准化、平台化交付，提升交付链路的效率；通过准入准出检测，提升线上稳定性；通过动效编排 + 统一的 Runtime，提升开发效率，同时要保证功能覆盖度。 |
| 复杂渲染类需求 |
| 效果 | 2D、3D 骨骼动画等复杂动效的简单应用 |
示例 | 
|
占比 | 约9% |
重点关注 | 能力覆盖度和性能 |
承接方式 | 自研渲染引擎 Crab；实现满足业务需求的渲染和编辑功能，提升功能覆盖度和开发效率；对比其他开源渲染引擎，要做到性能更优、开发效率更高。 |
因此，我们整个平台的演进路线如下：
截至目前，我们已经圆满完成了阶段一与阶段二的核心功能构建，而阶段三关于动效生产的部分仍在紧锣密鼓地推进中。在此过程中，我们已经积累了超过 3000 个高质量的动效资产，成功规避了 30 多项可能引发线上崩溃的潜在风险，累计导出代码次数达 3900 余次。更令人高兴的是，借助我们的平台，一个动效的开发周期最短可缩短至 15 秒，这一成就显著降低了动效开发的成本。
这篇文章会大致讲解一下各个核心功能，对于其中的技术细节不会有很深入的讲解，会在之后通过其他的文章再详细分析。
在动效的交付阶段，为了确保动效能够高质量地上线，我们同样实施了准入准出的管理机制，这一机制涵盖了动效资产的准入检测、单动效的性能准出检测以及多动效的性能集成测试三大关键环节。
动效资产的静态准入检测：
以上是 Vision 进行动效检测的一个大致流程，设计师使用 AE 等工具生产完动效后，需要把相应的产物导出后上传到 Vision 平台。首先，系统会对上传的入口文件进行初步校验，这包括检查文件的后缀名以及文件内容，以确保文件格式的正确性。这一步是确保后续检测能够顺利进行的基础。紧接着，系统会调用 Vision 的检测服务，对动效资产进行更为详尽的静态检测。
静态检测的目的有三个：
识别并规避线上 Bug 的直接诱因：例如当插件导出的 Lottie 缺乏 ind 属性时，iOS 播放器可能会因此闪退。针对此类问题，我们提供的解决方案之一是将资产以 base64 的方式导出，以避免兼容性问题。同样，使用 Webp 等图片格式时，我们也会进行严格的兼容性检查，确保它们能在不同环境下正常显示。
发现可能引发性能问题的异常：比如，如果图片的尺寸远大于实际图层所需，这将导致资源体积过大，进而影响加载速度和播放流畅度。另外，使用“Matte”等复杂特性时，可能会在运行时导致 CPU 使用率过高，造成卡顿现象。通过细致的检测，我们能够及时指出这些问题，并建议优化方案。
确保生产工具预览与实际播放效果的一致性：有时，设计师在生产工具中看到的预览效果与实际播放效果可能存在差异。例如，Lottie 文件中如果包含了摄像机图层，我们将提示设计师只能使用 Lottie 的 HTML 模式进行播放，否则摄像机效果将无法呈现。这样的检测有助于确保设计师的创意能够准确无误地传达给最终用户。同时对于这些准入检测中发现的问题，部分问题我们会提供自动修复的能力，帮助设计师快速解决问题，例如删除空图层等。
当设计师上传的动效通过静态检测，并在平台预览验收通过后，研发同学希望能尽快对动效的一些性能指标做验收，以防动效开发完成后，发现动效性能有问题再返工到生产环节。
此外，我们还根据公司稳定团队所设定的性能红线，为动效的准出环节增加了严格的校验机制。一旦某个动效的性能指标超出了预设的红线范围，系统将会立即向用户发出预警，提示其关注并优化该动效的性能表现。
对于多动效的集成测试，用户需要自主构建测试用例（Test Case），并在页面级别上执行检测。检测的项目与单动效性能测试时保持一致，以确保整体动效集成后的稳定性和性能表现。此外，鉴于不同设备性能差异对动效体验的影响，特别是在低端机上，为保证基本可用性，往往需要对动效进行降级处理。因此，在进行性能测试时，用户可以选择高端机和低端机进行有针对性的测试，并依据各自设备的性能特点设定不同的通过标准。通过这样的测试策略，我们能够更全面地评估动效在不同设备上的表现，确保其在各种环境下都能提供稳定且流畅的用户体验。
在日常动效需求的开发中，我们深刻体会到，该领域涉及的概念繁多且复杂，这对我们的开发工作构成了不小的挑战。其中，最为突出的有以下三个方面：
动效类型与工具繁多导致的研发选型难的问题
工具 API 差异带来的学习成本增加
动效格式转换工具的混乱使用风险
为了解决这些问题，我们需要建立更加清晰、系统的动效开发流程和选型标准，同时加强对各种工具和 API 的学习和培训，以及审慎选择和使用动效格式转换工具，确保动效开发的顺利进行和高质量交付。
针对动效开发中所遇到的诸多问题，我们采取了一系列创新措施，其中最为核心的是开发了一个统一的 Runtime 环境。这一环境在多个层面上发挥了关键作用，有效解决了选型困难、学习成本高以及格式转换混乱等问题。在适配层，我们通过适配器针对不同的开发工具提供了统一的 API，减少了选型和学习成本。在功能层，我们实现了动效类型的工具透明化。我们可以随时根据技术的发展替换最佳实践方案。在最上层的应用层，我们提供针对不同平台的组件、Cli，以便用户快速在项目中使用。
此外，针对格式转换的需求，我们提供了标准化的格式转换能力。我们确保导出的格式与我们的 Runtime 环境完全兼容。这种配套的编码和解码工具不仅提高了动效的兼容性和稳定性，还为用户提供了更多的灵活性和便利性。
动效内容的动态替换：
先看一段动效：
在动效内容的实际应用中，我们经常会遇到需要将设计师导出的 Lottie 动效与业务数据相结合的场景。例如，动效中的文字、头像图片等可能需要根据服务端下发的动态数据进行实时更新。虽然理论上可以通过手动修改 Bodymovin 导出的 JSON 文件来实现这一需求，但在实际操作中却面临着两大难题：
为了解决这些问题，我们对 lottie-web 进行了深度定制和优化，实现了图层内容的动态替换功能。这一功能允许开发者在播放过程中实时替换文字图层的文字内容、图片图层的图片地址，甚至可以直接将某个图层替换为自定义的 DOM 元素。此外，为了支持更丰富的交互行为，还在图层上添加点击事件。
仅需两步即可完成具体操作：
就可以做到使用动态的内容进行动效播放，极大减少了过去需要开发组件 + 动效内容的开发成本。
动效代码生成：
用 CSS 开发过贝塞尔曲线运动的读者可能会有体会，这类曲线运动效果实现起来还是比较困难的，因为无法直接用关键帧动画去实现。
类似的这类动效开发难题很多，而且不同水平的开发者还原程度也会有差异。那么我们想到，是不是可以通过系统直接生成代码的方式来解决这个问题？
答案是肯定的，我们系统提供了 Code Gen 的能力，设计师使用 Lottie 进行交付，Vision 会解析 Bodymovin 里的各种 transform 信息，并转换成动画代码片段。在平台上选中一个图层，用户可以复制使用。
例如这是一个复制了代码后实现的曲线运动效果。
这里我们还针对三种不同的场景，提供三种不同的代码生成方式：
普通 CSS：适合关键帧可以实现的简单动画
序列帧 CSS：适合路径动画的场景
Animated：适合 KRN 动效开发
通过平台提供的代码生成能力，就避免了人工对参数“翻译”不准确的问题，规避了开发者能力导致的差异。
以上便是 Vision 动效平台的设计思路和一些核心功能的分享，其中有很多功能还有很多值得分享的技术细节，后续会有更多的文章来讲解，欢迎大家关注。
