動效資源交付的突破:Vision 平臺準(zhǔn)入準(zhǔn)出方案 原創(chuàng)
導(dǎo)讀:快手動效 Vision 平臺為解決動效資源交付問題,引入了動效資源準(zhǔn)入準(zhǔn)出檢測機(jī)制。通過分析現(xiàn)有交付流程的痛點,平臺增加了了靜態(tài)和動態(tài)檢測服務(wù),確保動效質(zhì)量與性能。該套系統(tǒng)已成功召回并預(yù)防了多次線上問題,提升了使用動效資源的穩(wěn)定性和效率。
一、引言
在系列文章的首篇??《快手前端動效大揭秘:告別低效,vision平臺來襲!》(點擊回顧)???中,我們探討了 Vision 平臺的整體架構(gòu)和演進(jìn)思路,特別是針對動效生產(chǎn)成本高、交付流程繁瑣、資產(chǎn)管理成本高以及資產(chǎn)復(fù)用困難等問題進(jìn)行了概括性的介紹。在實踐中,我們還發(fā)現(xiàn)不同的線上場景(如活動 H5、直播間、客戶端等)對動效資源的需求各不相同,這進(jìn)一步增加了動效交付與使用的復(fù)雜性。同時,部分一線使用動效的同學(xué)對相關(guān)標(biāo)準(zhǔn)理解不一,導(dǎo)致在不同業(yè)務(wù)線中因動效資源使用不當(dāng)或配置錯誤而引發(fā)的線上事故時有發(fā)生。
為了解決這些動效交付中的問題,Vision 平臺決定通過動效資源系統(tǒng)性的準(zhǔn)入和準(zhǔn)出檢測方案來加以解決。接下來,我將從方案的分析思路、架構(gòu)設(shè)計、實現(xiàn)細(xì)節(jié)與項目收益幾個方面進(jìn)行詳細(xì)介紹。
二、分析與思考
2.1 動效交付流程分析
分析以往的動效資源交付流程,動效資源的交付嚴(yán)重依賴于設(shè)計師通過 Docs 文檔記錄和附件上傳,更新則完全依靠人工同步,缺乏系統(tǒng)化的流程和質(zhì)量管控。由于動效資源問題的解決往往需要對比較多資源,許多問題場景需要反復(fù)與設(shè)計師溝通,導(dǎo)致資源交付流程循環(huán)往復(fù),極易影響項目的整體交付進(jìn)度。
2.2 平臺針對交付鏈路的改善
Vision 平臺引入了資源準(zhǔn)入和準(zhǔn)出檢測流程,在動效預(yù)覽時對未通過檢測的資源進(jìn)行強(qiáng)制報告。后續(xù)的動效交付將從依賴 Docs 的方式轉(zhuǎn)向平臺化方案,通過統(tǒng)一的準(zhǔn)入準(zhǔn)出檢測實現(xiàn)更好的管控和同步。
三、具體方案
為了實現(xiàn)交付流程中的準(zhǔn)入和準(zhǔn)出檢測,Vision 構(gòu)建了一套基礎(chǔ)檢測服務(wù)。該服務(wù)涵蓋基礎(chǔ)檢測功能、獨立檢測服務(wù)、平臺轉(zhuǎn)發(fā)/開放服務(wù),以及最終面向業(yè)務(wù)方的檢測服務(wù)。此外,還涉及數(shù)據(jù)庫、自動化測試任務(wù)調(diào)度平臺和運行時檢測平臺等內(nèi)部第三方服務(wù)。
在概述基礎(chǔ)檢測服務(wù)后,我們將從底層實現(xiàn)向上探討其具體實現(xiàn),包括靜態(tài)檢測 SDK、動態(tài)檢測服務(wù),以及相應(yīng)的平臺檢測等流程。
3.1 靜態(tài)檢測 SDK
我們常用的動效資源格式包括 Lottie、序列幀動圖(如 APNG、Webp 等)、序列幀視頻、靜態(tài)圖片和 CSS 等多種形式。抽象來看,動效資源的靜態(tài)檢測可以分為資源獲取與解碼、規(guī)則設(shè)定、特性檢測和報告生成等幾個階段。
其中資源的解碼會根據(jù)資源的不同采用不同的 Decoder:
由于多條規(guī)則需要對同一套動效數(shù)據(jù)進(jìn)行頻繁計算,容易導(dǎo)致代碼冗余。以 Lottie 檢測為例,常規(guī)檢測需要遍歷超過 40 條規(guī)則,包括對 JSON 節(jié)點的歸納、層級深度分析、圖片構(gòu)造等操作。一個非標(biāo)準(zhǔn)的 Lottie 動效可能包含數(shù)百個節(jié)點和幾十張圖片,當(dāng)項目集中檢測時,底層服務(wù)的壓力會呈幾何式增長。為提高效率,SDK 對解碼后的數(shù)據(jù)進(jìn)行緩存,并通過校驗插件進(jìn)行遍歷檢測,從而更高效地生成靜態(tài)檢測結(jié)果。SDK 的具體流程設(shè)計如下圖所示:
當(dāng)然,不同的動效實現(xiàn)方式也具備相似的檢測能力。下面,我將以 SDK 中廣泛應(yīng)用的 圖片有效率分析 為例進(jìn)行詳細(xì)介紹。
圖片有效率分析
在設(shè)計初期,動效設(shè)計師為了實現(xiàn)高還原度的炫酷效果,通常會使用與畫布大小成比例且便于對齊的圖片資源。然而,由于 AE 導(dǎo)出切片(用戶視口)的限制,一些包含大量透明通道的圖片可能會被意外導(dǎo)出到動效資源中。以下圖所示為例,一張有效展示內(nèi)容區(qū)域為 140px 的 PNG 圖片,實際使用了 350px 的圖片,導(dǎo)致內(nèi)存占用增加了 525%(盡管不同格式圖片內(nèi)存占用絕對值會有所不同,但比例趨勢相同),這對頁面整體性能有較大影響。因此,識別這些隱藏在合規(guī)資源中的異常圖片,成為亟需解決的首要問題。
在識別異常圖片后,我們需要具體的方法來檢測這些圖片的透明區(qū)域。在瀏覽器環(huán)境中,我們通常使用 Canvas 來解析圖片,通過遍歷其像素點的 RGBA 值,檢查 alpha 通道是否等于 255,以判斷圖片是否包含透明區(qū)域。
// 瀏覽器判斷方式const hasAlphaChannel = (imageSrc, callback) => { const img = new Image();src
onload = () => const canvas = document.createElement('canvas'); const context = canvas.getContext('2d');
width = img.width;height = img.height;
context.drawImage(img, 0, 0);
const imageData = context.getImageData(0, 0, img.width, img.height).data;
// 檢查透明度 for (let i = 3; i < imageData.length; i += 4) { if (imageData[i] < 255) { callback(true); // 有透明數(shù)據(jù) return; } } callback(false); };
onerror = () => console.error('圖片加載失敗'); callback(false); // 加載失敗,返回false };};
然而,在服務(wù)端檢測流程中,使用 Canvas 進(jìn)行模擬渲染效率較低。因此,我們采用 Sharp 進(jìn)行圖片解碼,以獲取圖片的像素點信息,并利用 Sharp 內(nèi)置的 trim() 函數(shù)進(jìn)行裁剪。
const sharp = require('sharp');
const calculateTrimEfficiency = async (input, output, thresholdPercentage) => { // 獲取原始圖像信息 const image = await sharp(input).metadata();
// 使用 sharp 進(jìn)行裁剪 const { info } = await sharp(input) .trim() // 這里可以根據(jù)需要傳遞參數(shù) .toFile(output);
// 計算裁剪后的有效率 const originalArea = image.width * image.height; const trimmedArea = info.width * info.height; const efficiency = (trimmedArea / originalArea) * 100;
console.log(`裁剪后的面積: ${trimmedArea}`); console.log(`原始面積: ${originalArea}`); console.log(`有效率: ${efficiency.toFixed(2)}%`);
// 判斷裁剪是否達(dá)到閾值 const isAccept = efficiency >= thresholdPercentage; if (isAccept) { console.log('裁剪后的圖像符合要求。'); } else { console.log('裁剪后的圖像不符合要求。'); }
return isAccept;};
序列幀動圖是實現(xiàn)動效的重要手段之一。與靜態(tài) PNG 的圖片有效率場景類似,盡管動圖存在幀間合并方案,但低效的序列幀動圖會因每幀的共同透明區(qū)域而導(dǎo)致內(nèi)存浪費。因此,我們需要制定有效率計算方法,以剔除不合規(guī)的動圖。參考靜態(tài)圖的有效率檢測規(guī)則,我們以每幀的最大透視范圍為依據(jù),評估序列幀動圖的效率。與靜態(tài)圖片相比,動態(tài)圖片(如 APNG、WEBP 等)的每幀解碼尤為關(guān)鍵。以 APNG 為例,可以通過 Sharp 庫設(shè)置 animated: false 獲取所有幀進(jìn)行遍歷判斷,或使用 UPNG.js 等解碼庫逐幀獲取內(nèi)容。獲取逐幀內(nèi)容后,進(jìn)行類似靜態(tài)圖片的對比,從而簡單判斷動圖的有效率。
在檢測 SDK 中,還有許多類似圖片有效率的檢測方法,這里就不逐一詳述了。
3.2 動態(tài)檢測服務(wù)
動效設(shè)計師上傳的動效經(jīng)過平臺的靜態(tài)檢測后,具備了一定的質(zhì)量保障。然而,為了避免因真機(jī)性能問題導(dǎo)致的開發(fā)返工,部分研發(fā)人員希望盡早進(jìn)行真機(jī)性能驗收。因此,在動效準(zhǔn)出階段,我們利用公司的云真機(jī)平臺和性能檢測工具,對單個動效頁面或多動效集成頁面進(jìn)行真機(jī)性能測試。通過真機(jī)性能測試采集的數(shù)據(jù),我們進(jìn)一步分析了 CPU、內(nèi)存、FPS 和溫度等指標(biāo)。同時,針對性能穩(wěn)定性團(tuán)隊設(shè)定的指標(biāo)紅線,我們添加了相應(yīng)的準(zhǔn)出校驗,以確保動效的穩(wěn)定性和性能。
在整個檢測過程中,我們成功實現(xiàn)了自動化執(zhí)行腳本的開發(fā)集成,并攻克了 Kperf 檢測報告數(shù)據(jù)的存儲、處理和分析等復(fù)雜問題。
3.3 檢測標(biāo)準(zhǔn)
在完善檢測服務(wù)后,我們意識到需要一套標(biāo)準(zhǔn)來規(guī)范動效資源的質(zhì)量。因此,我們基于快手春節(jié)活動(CNY)及日?;顒又械呢S富實踐經(jīng)驗,制定了一套動效臨時檢測標(biāo)準(zhǔn)。這些標(biāo)準(zhǔn)專注于平臺上常用的動態(tài)效果格式,確保在不同應(yīng)用場景下的動效資源都能達(dá)到預(yù)期的質(zhì)量和性能。
目前這套標(biāo)準(zhǔn)主要適用于單一動態(tài)效果的小范圍應(yīng)用場景,涵蓋了多種檢測維度,以便更全面地評估動效資源的合規(guī)性和有效性。具體檢測維度將在下文中詳細(xì)介紹。目前,這套標(biāo)準(zhǔn)正在根據(jù)用戶反饋不斷迭代和優(yōu)化,以確保其在實際應(yīng)用中的有效性和實用性。通過這種方式,我們不僅提升了動效資源的整體質(zhì)量,還為開發(fā)團(tuán)隊提供了更明確的選擇指導(dǎo)。
靜態(tài)檢測標(biāo)準(zhǔn)
動態(tài)檢測標(biāo)準(zhǔn)
流暢度與卡頓的關(guān)聯(lián)可以用以下的流程圖來大致展示:
3.4 平臺檢測流程
常規(guī)檢測流程:動效設(shè)計師無論通過平臺還是 AE 插件上傳資源,如果資源觸發(fā)靜態(tài)檢測異常,平臺會強(qiáng)制提醒結(jié)果,但不會阻止動效的上傳和使用。研發(fā)人員仍可正常下載和使用這些資源。
強(qiáng)規(guī)則卡控流程:對于強(qiáng)規(guī)則卡控的項目,動效設(shè)計師上傳未通過檢測的資源將進(jìn)入待確認(rèn)列表,而非檢測通過列表。待確認(rèn)列表中的動效需經(jīng)研發(fā)負(fù)責(zé)人或動效 BP 人工確認(rèn)后,才能被研發(fā)人員正常使用。只有經(jīng)過人工確認(rèn)的資源,才會出現(xiàn)在檢測通過列表中,供研發(fā)人員下載和使用。
四、落地實踐與收益
4.1 落地情況
平臺落地
準(zhǔn)入檢測 &報告
準(zhǔn)出檢測報告
強(qiáng)卡流程
目前平臺已經(jīng)集成了動效的準(zhǔn)入 & 準(zhǔn)出動作,并且實現(xiàn)了整套上述分享 靜態(tài)/動態(tài)資源 流程。
Open SDK/API
除了在 Vision 平臺的檢測功能的亮相,檢測基礎(chǔ)服務(wù) 還將功能打包,作為 Open SDK 和 API 對外輸出檢測能力。借助內(nèi)部檢測質(zhì)效專項的推動,目前已經(jīng)完成了在快手主站內(nèi)多個 C 端核心運營 &資源平臺的接入。
4.2 實踐收益
在 2024 年第三季度,動效檢測和開放接口的召回問題數(shù)量累計 萬余次,其中有效規(guī)避了 幾十次 有造成客戶端 Crash 風(fēng)險的問題。
五、總結(jié)
本文詳細(xì)介紹了 Vision 平臺在解決動效資源交付質(zhì)量問題中的思考與實踐,希望能為您提供啟示和支持。如果您有任何疑問或建議,歡迎隨時留言討論,我們期待您的寶貴意見。
回顧本系列文章,詳細(xì)分享了快手在 Vision 動效平臺的工作成果,首篇闡述平臺整體演進(jìn)思路及核心能力布局,隨后詳細(xì)介紹渲染引擎 Crab 及復(fù)雜動效渲染實踐、動效 Code Gen 技術(shù)原理、多種序列幀格式的最佳實踐及其轉(zhuǎn)換服務(wù)技術(shù)原理。此外,系列文章還將探討動效準(zhǔn)入、準(zhǔn)出檢測過程中的技術(shù)原理,并分享 Spine 動效在 React Native 技術(shù)棧下的實踐,為讀者提供一個全面而深入的視角,以更好地理解快手在動效領(lǐng)域的探索與實踐。
