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

一、前言

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

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

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

1.動(dòng)效的重要性

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

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

2.動(dòng)效流程中的重重難題

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

從動(dòng)效流程簡(jiǎn)要可概述：

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

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

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

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

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

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

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

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

三、快手Vision動(dòng)效平臺(tái)演進(jìn)之路

?

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

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

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

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

多動(dòng)效類型統(tǒng)一生產(chǎn)工具的方案：通過自研的生產(chǎn)工具 + 支持多類型動(dòng)效的 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ā)多種動(dòng)效類型的場(chǎng)景。

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

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

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

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

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

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

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

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

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

針對(duì)動(dòng)效流程的三個(gè)部分：

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

①通用性需求

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

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

?

四、Vision動(dòng)效平臺(tái)的核心功能

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

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

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

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

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

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

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

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

單動(dòng)效的性能準(zhǔn)出檢測(cè)：

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

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

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

多動(dòng)效的性能集成測(cè)試：

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

2.動(dòng)效開發(fā)提效

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

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

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

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

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

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

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

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

先看一段動(dòng)效：

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

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

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

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

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

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

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

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

動(dòng)效代碼生成：

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

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

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

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

這里我們還針對(duì)三種不同的場(chǎng)景，提供三種不同的代碼生成方式：

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

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

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

- END -

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