導(dǎo)讀：動效平臺作為快手舉辦大型線上活動的堅(jiān)實(shí)后盾，發(fā)揮著承上啟下的關(guān)鍵作用。本篇文章將全方位地為您呈現(xiàn)Vision動效平臺的整體架構(gòu)及其演進(jìn)思路，為您揭開這一強(qiáng)大平臺的神秘面紗。

一、前言

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

接下來，文章將轉(zhuǎn)向動效準(zhǔn)入、準(zhǔn)出檢測過程中的技術(shù)原理，為讀者呈現(xiàn)我們在確保動效質(zhì)量方面所做的努力。最后，我們將分享Spine動效在React Native技術(shù)棧下的實(shí)踐，展示其在移動開發(fā)中的廣泛應(yīng)用和潛力。通過這些內(nèi)容，我們希望能夠?yàn)樽x者提供一個全面而深入的視角，以更好地理解我們在動效領(lǐng)域的探索與實(shí)踐。

二、動效的核心價(jià)值及現(xiàn)存挑戰(zhàn)

1.動效的重要性

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

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

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

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

從動效流程簡要可概述：

動效生產(chǎn)環(huán)節(jié)：設(shè)計(jì)師們主要遭遇以下難題：

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

動效交付環(huán)節(jié)：設(shè)計(jì)師與研發(fā)人員之間的協(xié)調(diào)流程亦存在諸多問題：

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

動效開發(fā)環(huán)節(jié)：研發(fā)人員則面臨著更為嚴(yán)峻的挑戰(zhàn)：

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

針對上述動效生產(chǎn)、交付及開發(fā)環(huán)節(jié)中存在的種種問題，我們渴望構(gòu)建一套全面而高效的解決方案，以下圖示正是我們對這一理想方案的憧憬與規(guī)劃：

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

三、快手Vision動效平臺演進(jìn)之路

?

1.行業(yè)內(nèi)的通用解決方案

在著手開發(fā)我們自己的解決方案之前，我們深入調(diào)研了行業(yè)內(nèi)的現(xiàn)有方案。排除純游戲開發(fā)的特定場景，當(dāng)前在常規(guī)動效需求的開發(fā)中，業(yè)界主要呈現(xiàn)出以下三種策略：

游戲化開發(fā)方案：通過一個包含編輯器 + Runtime 在內(nèi)的引擎，實(shí)現(xiàn)中大型團(tuán)隊(duì)協(xié)同完成復(fù)雜場景開發(fā)的問題。然而，該引擎本身并不支持動效的直接生產(chǎn)，需要配置專業(yè)人員來負(fù)責(zé)把生產(chǎn)工具的產(chǎn)物導(dǎo)入為符合引擎要求的格式。這一方案適合大型團(tuán)隊(duì)協(xié)同開發(fā)復(fù)雜需求的場景。

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

多動效類型統(tǒng)一生產(chǎn)工具的方案：通過自研的生產(chǎn)工具 + 支持多類型動效的 Runtime，使設(shè)計(jì)資產(chǎn)可以無損傳遞到開發(fā)階段。但該生產(chǎn)工具因?yàn)榧纫獙?shí)現(xiàn)生產(chǎn)工具（例如 AE、Unity 等）的功能，又要實(shí)現(xiàn)方案一的編輯器功能，開發(fā)成本極高。適合中小型團(tuán)隊(duì)開發(fā)多種動效類型的場景。

2.快手動效開發(fā)的特點(diǎn)與需求

考慮到快手在日常業(yè)務(wù)和大型活動動效開發(fā)中的具體特點(diǎn)：

• 動效數(shù)量多但各自相對獨(dú)立，很少需要多人協(xié)同開發(fā)一個復(fù)雜場景的需求
• 業(yè)務(wù)場景對于性能和表現(xiàn)力要求高：需要盡可能用綜合最優(yōu)的動效方案，且可能同時使用多種動效類型進(jìn)行組合開發(fā)

我們發(fā)現(xiàn)，方案1對設(shè)計(jì)師的能力要求過高，與快手當(dāng)前的組織架構(gòu)和設(shè)計(jì)師團(tuán)隊(duì)現(xiàn)狀不相符；方案2在動效性能和表現(xiàn)力上無法滿足快手對大型活動的高標(biāo)準(zhǔn)；而方案3在人員能力匹配、性能要求滿足以及業(yè)務(wù)場景適應(yīng)性方面，整體更符合快手的實(shí)際需求。因此，方案3為我們提供了一個值得深入探索和優(yōu)化的方向。

3.Vision平臺的演進(jìn)路線和功能拆解

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

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

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

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

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

進(jìn)一步的拆解，因?yàn)槲覀儗Ｗ⒂诨顒?日常業(yè)務(wù)場景的動效，不考慮純游戲的場景，需求又分為兩種類型：

①通用性需求

② 復(fù)雜渲染類需求

因此，我們整個平臺的演進(jìn)路線如下：

?

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

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

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

1.動效的準(zhǔn)入與準(zhǔn)出

在動效的交付階段，為了確保動效能夠高質(zhì)量地上線，我們同樣實(shí)施了準(zhǔn)入準(zhǔn)出的管理機(jī)制，這一機(jī)制涵蓋了動效資產(chǎn)的準(zhǔn)入檢測、單動效的性能準(zhǔn)出檢測以及多動效的性能集成測試三大關(guān)鍵環(huán)節(jié)。

動效資產(chǎn)的靜態(tài)準(zhǔn)入檢測：

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

靜態(tài)檢測的目的有三個：

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

單動效的性能準(zhǔn)出檢測：

當(dāng)設(shè)計(jì)師上傳的動效通過靜態(tài)檢測，并在平臺預(yù)覽驗(yàn)收通過后，研發(fā)同學(xué)希望能盡快對動效的一些性能指標(biāo)做驗(yàn)收，以防動效開發(fā)完成后，發(fā)現(xiàn)動效性能有問題再返工到生產(chǎn)環(huán)節(jié)。

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

此外，我們還根據(jù)公司穩(wěn)定團(tuán)隊(duì)所設(shè)定的性能紅線，為動效的準(zhǔn)出環(huán)節(jié)增加了嚴(yán)格的校驗(yàn)機(jī)制。一旦某個動效的性能指標(biāo)超出了預(yù)設(shè)的紅線范圍，系統(tǒng)將會立即向用戶發(fā)出預(yù)警，提示其關(guān)注并優(yōu)化該動效的性能表現(xiàn)。

多動效的性能集成測試：

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

2.動效開發(fā)提效

統(tǒng)一的 Runtime 和格式轉(zhuǎn)換工具

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

1. 動效類型與工具繁多導(dǎo)致的研發(fā)選型難的問題
2. 工具API差異帶來的學(xué)習(xí)成本增加
3. 動效格式轉(zhuǎn)換工具的混亂使用風(fēng)險(xiǎn)

為了解決這些問題，我們需要建立更加清晰、系統(tǒng)的動效開發(fā)流程和選型標(biāo)準(zhǔn)，同時加強(qiáng)對各種工具和API的學(xué)習(xí)和培訓(xùn)，以及審慎選擇和使用動效格式轉(zhuǎn)換工具，確保動效開發(fā)的順利進(jìn)行和高質(zhì)量交付。

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

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

動效內(nèi)容的動態(tài)替換和動效代碼生成

動效內(nèi)容的動態(tài)替換：

先看一段動效：

在動效內(nèi)容的實(shí)際應(yīng)用中，我們經(jīng)常會遇到需要將設(shè)計(jì)師導(dǎo)出的Lottie動效與業(yè)務(wù)數(shù)據(jù)相結(jié)合的場景。例如，動效中的文字、頭像圖片等可能需要根據(jù)服務(wù)端下發(fā)的動態(tài)數(shù)據(jù)進(jìn)行實(shí)時更新。雖然理論上可以通過手動修改Bodymovin導(dǎo)出的JSON文件來實(shí)現(xiàn)這一需求，但在實(shí)際操作中卻面臨著兩大難題：

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

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

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

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

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

2、使用 Runtime 提供的替換能力快速替換內(nèi)容：

就可以做到使用動態(tài)的內(nèi)容進(jìn)行動效播放，極大減少了過去需要開發(fā)組件 + 動效內(nèi)容的開發(fā)成本。

動效代碼生成：

用 CSS 開發(fā)過貝塞爾曲線運(yùn)動的讀者可能會有體會，這類曲線運(yùn)動效果實(shí)現(xiàn)起來還是比較困難的，因?yàn)闊o法直接用關(guān)鍵幀動畫去實(shí)現(xiàn)。

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

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

例如這是一個復(fù)制了代碼后實(shí)現(xiàn)的曲線運(yùn)動效果。

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

• 普通CSS：適合關(guān)鍵幀可以實(shí)現(xiàn)的簡單動畫
• 序列幀CSS：適合路徑動畫的場景
• Animated：適合 KRN 動效開發(fā)

通過平臺提供的代碼生成能力，就避免了人工對參數(shù)“翻譯”不準(zhǔn)確的問題，規(guī)避了開發(fā)者能力導(dǎo)致的差異。

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

- END -

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