導讀：動效平臺作為快手舉辦大型線上活動的堅實后盾，發揮著承上啟下的關鍵作用。本篇文章將全方位地為您呈現Vision動效平臺的整體架構及其演進思路，為您揭開這一強大平臺的神秘面紗。

一、前言

本系列文章從我們在Vision 動效平臺中做的一些工作為切入點，計劃通過多篇文章全面展現我們的工作成果。首篇將闡述Vision動效平臺的整體演進思路，聚焦于平臺的核心能力，為讀者勾勒出我們在動效領域的初步布局。隨后，我們將詳細介紹渲染引擎Crab，并分享在復雜動效渲染場景下積累的實踐經驗。接著，文章將深入剖析動效Code Gen能力的技術原理，揭示其背后的奧秘。此外，我們還將探討多種序列幀格式（包括APNG、AVIF、WEBP、普通視頻、透明視頻等）的最佳實踐，幫助讀者更好地理解這些格式在實際應用中的優勢和局限。在此基礎上，我們將進一步講解背后的序列幀多格式轉換服務的技術原理，揭示其高效運作的機制。

接下來，文章將轉向動效準入、準出檢測過程中的技術原理，為讀者呈現我們在確保動效質量方面所做的努力。最后，我們將分享Spine動效在React Native技術棧下的實踐，展示其在移動開發中的廣泛應用和潛力。通過這些內容，我們希望能夠為讀者提供一個全面而深入的視角，以更好地理解我們在動效領域的探索與實踐。

二、動效的核心價值及現存挑戰

1.動效的重要性

快手作為一個短視頻平臺，其豐富的內容需要通過多樣化的表現形式來呈現。設計師精心設計的動效，在各種業務和活動場景中展現出了極高的表現力，不僅增強了內容的吸引力，還提升了用戶的互動體驗。

此外，我們更是充分利用了動效的潛力，通過在相同場景下對比運用不同的動效設計方案進行A/B測試。測試結果清晰地表明，那些融入了動效的頁面在數據表現上往往更加出色，無論是用戶停留時長、互動率還是轉化率，都較未使用動效的頁面有了顯著提升。這充分證明了動效在快手日常業務以及大型活動場景中的不可或缺性。

2.動效流程中的重重難題

鑒于動效在提升業務數據中的優秀表現，無論是日常運營需求還是大型活動項目，都涌現出了大量的動效需求。然而，動效的生產、交付、開發等多個關鍵環節都面臨著諸多挑戰。對于曾參與開發復雜動效需求的開發者而言，這種體驗尤為深刻。要將動效需求高質量地開發并上線，往往需要付出較高的成本，開發效率也存在較大的提升空間。因此，我們亟需尋找解決方案，以優化動效開發流程，降低成本，提高效率。

從動效流程簡要可概述：

動效生產環節：設計師們主要遭遇以下難題：

• 生產與運行不一致：當前市面上的粒子生產工具大多源自游戲領域，如Unity、Unreal Engine等，它們所產出的動效往往無法直接在Web平臺上順暢播放，導致設計與實際展示間存在顯著的差異。
• 資產管理成本高，復用難，例如：設計師生產完成的資產缺乏高效的管理手段，使得復用變得極為困難。這些資產不僅檢索不易，還可能因設計師的流動而面臨流失的風險，極大地增加了管理成本。

動效交付環節：設計師與研發人員之間的協調流程亦存在諸多問題：

• 交付流程繁瑣：傳統的基于文檔的交付方式不僅要求設計師頻繁導出資產并手動上傳，而且在后續的維護上也需耗費較高成本。
• 缺乏交付標準：設計師在交付動效產物時，缺乏明確的流程標準和產物標準，導致研發人員在接收時難以判斷其是否符合開發要求。
• 前置驗收缺乏：設計師在工具中完成粒子、3D模型等設計后，無法直接預覽其在Web平臺上的實際播放效果。

動效開發環節：研發人員則面臨著更為嚴峻的挑戰：

• 動效開發難度高，工作量大，動效的選型、復雜動效的還原、復雜渲染效果的實現以及跨平臺的開發，每一項都考驗著研發人員的專業技能與耐心，使得整個開發過程既耗時又費力。

針對上述動效生產、交付及開發環節中存在的種種問題，我們渴望構建一套全面而高效的解決方案，以下圖示正是我們對這一理想方案的憧憬與規劃：

這套方案對于整個動效流程，希望通過制定 SOP + 平臺化落地規范和流程，解決規范和流程導致的低效問題，同時在各個階段通過提供不同的能力，解決上述提到的各個環節各自的問題。

三、快手Vision動效平臺演進之路

?

1.行業內的通用解決方案

在著手開發我們自己的解決方案之前，我們深入調研了行業內的現有方案。排除純游戲開發的特定場景，當前在常規動效需求的開發中，業界主要呈現出以下三種策略：

游戲化開發方案：通過一個包含編輯器 + Runtime 在內的引擎，實現中大型團隊協同完成復雜場景開發的問題。然而，該引擎本身并不支持動效的直接生產，需要配置專業人員來負責把生產工具的產物導入為符合引擎要求的格式。這一方案適合大型團隊協同開發復雜需求的場景。

單一動效類型的方案：通過只支持一種動效類型（例如序列幀），大大簡化了交付與開發流程，大量減少自研工具復雜度和成本，但動效性能和表現力存在一定的局限性。更適合比較簡單的純播放類動效場景。

多動效類型統一生產工具的方案：通過自研的生產工具 + 支持多類型動效的 Runtime，使設計資產可以無損傳遞到開發階段。但該生產工具因為既要實現生產工具（例如 AE、Unity 等）的功能，又要實現方案一的編輯器功能，開發成本極高。適合中小型團隊開發多種動效類型的場景。

2.快手動效開發的特點與需求

考慮到快手在日常業務和大型活動動效開發中的具體特點：

• 動效數量多但各自相對獨立，很少需要多人協同開發一個復雜場景的需求
• 業務場景對于性能和表現力要求高：需要盡可能用綜合最優的動效方案，且可能同時使用多種動效類型進行組合開發

我們發現，方案1對設計師的能力要求過高，與快手當前的組織架構和設計師團隊現狀不相符；方案2在動效性能和表現力上無法滿足快手對大型活動的高標準；而方案3在人員能力匹配、性能要求滿足以及業務場景適應性方面，整體更符合快手的實際需求。因此，方案3為我們提供了一個值得深入探索和優化的方向。

3.Vision平臺的演進路線和功能拆解

或許有讀者會感到好奇，為何我們不直接采納現有的開源項目呢？

誠然，方案3中確實存在外部的優秀產品，但其中編輯器部分作為開發工作量較大的關鍵環節，卻是以在線工具的形式存在，無法實現本地化部署。這一特性使得我們在使用時不得不面臨資產流失的潛在風險。鑒于此，我們審慎地決定，整套方案需采取自研的方式，以確保資產的安全與可控。

當然，在自研的過程中，我們也并未完全排斥開源工具。相反，在部分場景下，我們巧妙地融入了合適的開源工具，以期在保障功能實現的同時，進一步降低開發成本。

為了更高效地推進自研工作，我們對整個動效開發流程進行了詳盡的功能拆解：

針對動效流程的三個部分：

進一步的拆解，因為我們專注于活動/日常業務場景的動效，不考慮純游戲的場景，需求又分為兩種類型：

①通用性需求

② 復雜渲染類需求

因此，我們整個平臺的演進路線如下：

?

四、Vision動效平臺的核心功能

截至目前，我們已經圓滿完成了階段一與階段二的核心功能構建，而階段三關于動效生產的部分仍在緊鑼密鼓地推進中。在此過程中，我們已經積累了超過3000個高質量的動效資產，成功規避了30多項可能引發線上崩潰的潛在風險，累計導出代碼次數達3900余次。更令人高興的是，借助我們的平臺，一個動效的開發周期最短可縮短至15秒，這一成就顯著降低了動效開發的成本。

這篇文章會大致講解一下各個核心功能，對于其中的技術細節不會有很深入的講解，會在之后通過其他的文章再詳細分析。

1.動效的準入與準出

在動效的交付階段，為了確保動效能夠高質量地上線，我們同樣實施了準入準出的管理機制，這一機制涵蓋了動效資產的準入檢測、單動效的性能準出檢測以及多動效的性能集成測試三大關鍵環節。

動效資產的靜態準入檢測：

以上是 Vision 進行動效檢測的一個大致流程，設計師使用 AE 等工具生產完動效后，需要把相應的產物導出后上傳到 Vision 平臺。首先，系統會對上傳的入口文件進行初步校驗，這包括檢查文件的后綴名以及文件內容，以確保文件格式的正確性。這一步是確保后續檢測能夠順利進行的基礎。緊接著，系統會調用Vision的檢測服務，對動效資產進行更為詳盡的靜態檢測。

靜態檢測的目的有三個：

• 識別并規避線上Bug的直接誘因：例如當插件導出的 Lottie 缺乏 ind 屬性時，iOS播放器可能會因此閃退。針對此類問題，我們提供的解決方案之一是將資產以base64的方式導出，以避免兼容性問題。同樣，使用Webp等圖片格式時，我們也會進行嚴格的兼容性檢查，確保它們能在不同環境下正常顯示。
• 發現可能引發性能問題的異常：比如，如果圖片的尺寸遠大于實際圖層所需，這將導致資源體積過大，進而影響加載速度和播放流暢度。另外，使用“Matte”等復雜特性時，可能會在運行時導致CPU使用率過高，造成卡頓現象。通過細致的檢測，我們能夠及時指出這些問題，并建議優化方案。
• 確保生產工具預覽與實際播放效果的一致性：有時，設計師在生產工具中看到的預覽效果與實際播放效果可能存在差異。例如，Lottie文件中如果包含了攝像機圖層，我們將提示設計師只能使用Lottie的HTML模式進行播放，否則攝像機效果將無法呈現。這樣的檢測有助于確保設計師的創意能夠準確無誤地傳達給最終用戶。同時對于這些準入檢測中發現的問題，部分問題我們會提供自動修復的能力，幫助設計師快速解決問題，例如刪除空圖層等。

單動效的性能準出檢測：

當設計師上傳的動效通過靜態檢測，并在平臺預覽驗收通過后，研發同學希望能盡快對動效的一些性能指標做驗收，以防動效開發完成后，發現動效性能有問題再返工到生產環節。

為了滿足這一需求，我們巧妙地結合了公司的云真機平臺與性能測試工具。把該動效添加到檢測頁面中，使用云真機對以下的一些指標進行測試：

此外，我們還根據公司穩定團隊所設定的性能紅線，為動效的準出環節增加了嚴格的校驗機制。一旦某個動效的性能指標超出了預設的紅線范圍，系統將會立即向用戶發出預警，提示其關注并優化該動效的性能表現。

多動效的性能集成測試：

對于多動效的集成測試，用戶需要自主構建測試用例（Test Case），并在頁面級別上執行檢測。檢測的項目與單動效性能測試時保持一致，以確保整體動效集成后的穩定性和性能表現。此外，鑒于不同設備性能差異對動效體驗的影響，特別是在低端機上，為保證基本可用性，往往需要對動效進行降級處理。因此，在進行性能測試時，用戶可以選擇高端機和低端機進行有針對性的測試，并依據各自設備的性能特點設定不同的通過標準。通過這樣的測試策略，我們能夠更全面地評估動效在不同設備上的表現，確保其在各種環境下都能提供穩定且流暢的用戶體驗。

2.動效開發提效

統一的 Runtime 和格式轉換工具

在日常動效需求的開發中，我們深刻體會到，該領域涉及的概念繁多且復雜，這對我們的開發工作構成了不小的挑戰。其中，最為突出的有以下三個方面：

1. 動效類型與工具繁多導致的研發選型難的問題
2. 工具API差異帶來的學習成本增加
3. 動效格式轉換工具的混亂使用風險

為了解決這些問題，我們需要建立更加清晰、系統的動效開發流程和選型標準，同時加強對各種工具和API的學習和培訓，以及審慎選擇和使用動效格式轉換工具，確保動效開發的順利進行和高質量交付。

針對動效開發中所遇到的諸多問題，我們采取了一系列創新措施，其中最為核心的是開發了一個統一的Runtime環境。這一環境在多個層面上發揮了關鍵作用，有效解決了選型困難、學習成本高以及格式轉換混亂等問題。在適配層，我們通過適配器針對不同的開發工具提供了統一的 API，減少了選型和學習成本。在功能層，我們實現了動效類型的工具透明化。我們可以隨時根據技術的發展替換最佳實踐方案。在最上層的應用層，我們提供針對不同平臺的組件、Cli，以便用戶快速在項目中使用。

此外，針對格式轉換的需求，我們提供了標準化的格式轉換能力。我們確保導出的格式與我們的Runtime環境完全兼容。這種配套的編碼和解碼工具不僅提高了動效的兼容性和穩定性，還為用戶提供了更多的靈活性和便利性。

動效內容的動態替換和動效代碼生成

動效內容的動態替換：

先看一段動效：

在動效內容的實際應用中，我們經常會遇到需要將設計師導出的Lottie動效與業務數據相結合的場景。例如，動效中的文字、頭像圖片等可能需要根據服務端下發的動態數據進行實時更新。雖然理論上可以通過手動修改Bodymovin導出的JSON文件來實現這一需求，但在實際操作中卻面臨著兩大難題：

1.修改成本高且易出錯：并非所有開發者都熟悉Bodymovin的schema結構，因此手動修改JSON文件不僅成本高，而且容易引入錯誤。

2.Lottie數據不支持實時更改：原生的Lottie庫并不支持在播放過程中實時更改動效數據。

為了解決這些問題，我們對lottie-web進行了深度定制和優化，實現了圖層內容的動態替換功能。這一功能允許開發者在播放過程中實時替換文字圖層的文字內容、圖片圖層的圖片地址，甚至可以直接將某個圖層替換為自定義的DOM元素。此外，為了支持更豐富的交互行為，還在圖層上添加點擊事件。

僅需兩步即可完成具體操作：

1、用戶在平臺上選中圖層后，就可以添加占位符：

2、使用 Runtime 提供的替換能力快速替換內容：

就可以做到使用動態的內容進行動效播放，極大減少了過去需要開發組件 + 動效內容的開發成本。

動效代碼生成：

用 CSS 開發過貝塞爾曲線運動的讀者可能會有體會，這類曲線運動效果實現起來還是比較困難的，因為無法直接用關鍵幀動畫去實現。

類似的這類動效開發難題很多，而且不同水平的開發者還原程度也會有差異。那么我們想到，是不是可以通過系統直接生成代碼的方式來解決這個問題？

答案是肯定的，我們系統提供了 Code Gen 的能力，設計師使用 Lottie 進行交付，Vision 會解析 Bodymovin 里的各種 transform 信息，并轉換成動畫代碼片段。在平臺上選中一個圖層，用戶可以復制使用。

例如這是一個復制了代碼后實現的曲線運動效果。

這里我們還針對三種不同的場景，提供三種不同的代碼生成方式：

• 普通CSS：適合關鍵幀可以實現的簡單動畫
• 序列幀CSS：適合路徑動畫的場景
• Animated：適合 KRN 動效開發

通過平臺提供的代碼生成能力，就避免了人工對參數“翻譯”不準確的問題，規避了開發者能力導致的差異。

以上便是 Vision 動效平臺的設計思路和一些核心功能的分享，其中有很多功能還有很多值得分享的技術細節，后續會有更多的文章來講解，歡迎大家關注。

- END -

如果業內同仁有其他更好的想法或者建議，請不吝指教。