導(dǎo)讀：快手動(dòng)效 Vision 平臺(tái)為解決動(dòng)效資源交付問(wèn)題，引入了動(dòng)效資源準(zhǔn)入準(zhǔn)出檢測(cè)機(jī)制。通過(guò)分析現(xiàn)有交付流程的痛點(diǎn)，平臺(tái)增加了了靜態(tài)和動(dòng)態(tài)檢測(cè)服務(wù)，確保動(dòng)效質(zhì)量與性能。該套系統(tǒng)已成功召回并預(yù)防了多次線(xiàn)上問(wèn)題，提升了使用動(dòng)效資源的穩(wěn)定性和效率。

一、引言

在系列文章的首篇??《快手前端動(dòng)效大揭秘：告別低效，vision平臺(tái)來(lái)襲！》（點(diǎn)擊回顧）???中，我們探討了 Vision 平臺(tái)的整體架構(gòu)和演進(jìn)思路，特別是針對(duì)動(dòng)效生產(chǎn)成本高、交付流程繁瑣、資產(chǎn)管理成本高以及資產(chǎn)復(fù)用困難等問(wèn)題進(jìn)行了概括性的介紹。在實(shí)踐中，我們還發(fā)現(xiàn)不同的線(xiàn)上場(chǎng)景（如活動(dòng) H5、直播間、客戶(hù)端等）對(duì)動(dòng)效資源的需求各不相同，這進(jìn)一步增加了動(dòng)效交付與使用的復(fù)雜性。同時(shí)，部分一線(xiàn)使用動(dòng)效的同學(xué)對(duì)相關(guān)標(biāo)準(zhǔn)理解不一，導(dǎo)致在不同業(yè)務(wù)線(xiàn)中因動(dòng)效資源使用不當(dāng)或配置錯(cuò)誤而引發(fā)的線(xiàn)上事故時(shí)有發(fā)生。

為了解決這些動(dòng)效交付中的問(wèn)題，Vision 平臺(tái)決定通過(guò)動(dòng)效資源系統(tǒng)性的準(zhǔn)入和準(zhǔn)出檢測(cè)方案來(lái)加以解決。接下來(lái)，我將從方案的分析思路、架構(gòu)設(shè)計(jì)、實(shí)現(xiàn)細(xì)節(jié)與項(xiàng)目收益幾個(gè)方面進(jìn)行詳細(xì)介紹。

二、分析與思考

2.1 動(dòng)效交付流程分析

分析以往的動(dòng)效資源交付流程，動(dòng)效資源的交付嚴(yán)重依賴(lài)于設(shè)計(jì)師通過(guò) Docs 文檔記錄和附件上傳，更新則完全依靠人工同步，缺乏系統(tǒng)化的流程和質(zhì)量管控。由于動(dòng)效資源問(wèn)題的解決往往需要對(duì)比較多資源，許多問(wèn)題場(chǎng)景需要反復(fù)與設(shè)計(jì)師溝通，導(dǎo)致資源交付流程循環(huán)往復(fù)，極易影響項(xiàng)目的整體交付進(jìn)度。

2.2 平臺(tái)針對(duì)交付鏈路的改善

Vision 平臺(tái)引入了資源準(zhǔn)入和準(zhǔn)出檢測(cè)流程，在動(dòng)效預(yù)覽時(shí)對(duì)未通過(guò)檢測(cè)的資源進(jìn)行強(qiáng)制報(bào)告。后續(xù)的動(dòng)效交付將從依賴(lài) Docs 的方式轉(zhuǎn)向平臺(tái)化方案，通過(guò)統(tǒng)一的準(zhǔn)入準(zhǔn)出檢測(cè)實(shí)現(xiàn)更好的管控和同步。

三、具體方案

為了實(shí)現(xiàn)交付流程中的準(zhǔn)入和準(zhǔn)出檢測(cè)，Vision 構(gòu)建了一套基礎(chǔ)檢測(cè)服務(wù)。該服務(wù)涵蓋基礎(chǔ)檢測(cè)功能、獨(dú)立檢測(cè)服務(wù)、平臺(tái)轉(zhuǎn)發(fā)/開(kāi)放服務(wù)，以及最終面向業(yè)務(wù)方的檢測(cè)服務(wù)。此外，還涉及數(shù)據(jù)庫(kù)、自動(dòng)化測(cè)試任務(wù)調(diào)度平臺(tái)和運(yùn)行時(shí)檢測(cè)平臺(tái)等內(nèi)部第三方服務(wù)。

在概述基礎(chǔ)檢測(cè)服務(wù)后，我們將從底層實(shí)現(xiàn)向上探討其具體實(shí)現(xiàn)，包括靜態(tài)檢測(cè) SDK、動(dòng)態(tài)檢測(cè)服務(wù)，以及相應(yīng)的平臺(tái)檢測(cè)等流程。

3.1 靜態(tài)檢測(cè) SDK

我們常用的動(dòng)效資源格式包括 Lottie、序列幀動(dòng)圖（如 APNG、Webp 等）、序列幀視頻、靜態(tài)圖片和 CSS 等多種形式。抽象來(lái)看，動(dòng)效資源的靜態(tài)檢測(cè)可以分為資源獲取與解碼、規(guī)則設(shè)定、特性檢測(cè)和報(bào)告生成等幾個(gè)階段。

其中資源的解碼會(huì)根據(jù)資源的不同采用不同的 Decoder：

由于多條規(guī)則需要對(duì)同一套動(dòng)效數(shù)據(jù)進(jìn)行頻繁計(jì)算，容易導(dǎo)致代碼冗余。以 Lottie 檢測(cè)為例，常規(guī)檢測(cè)需要遍歷超過(guò) 40 條規(guī)則，包括對(duì) JSON 節(jié)點(diǎn)的歸納、層級(jí)深度分析、圖片構(gòu)造等操作。一個(gè)非標(biāo)準(zhǔn)的 Lottie 動(dòng)效可能包含數(shù)百個(gè)節(jié)點(diǎn)和幾十張圖片，當(dāng)項(xiàng)目集中檢測(cè)時(shí)，底層服務(wù)的壓力會(huì)呈幾何式增長(zhǎng)。為提高效率，SDK 對(duì)解碼后的數(shù)據(jù)進(jìn)行緩存，并通過(guò)校驗(yàn)插件進(jìn)行遍歷檢測(cè)，從而更高效地生成靜態(tài)檢測(cè)結(jié)果。SDK 的具體流程設(shè)計(jì)如下圖所示：

當(dāng)然，不同的動(dòng)效實(shí)現(xiàn)方式也具備相似的檢測(cè)能力。下面，我將以 SDK 中廣泛應(yīng)用的 圖片有效率分析 為例進(jìn)行詳細(xì)介紹。

圖片有效率分析

在設(shè)計(jì)初期，動(dòng)效設(shè)計(jì)師為了實(shí)現(xiàn)高還原度的炫酷效果，通常會(huì)使用與畫(huà)布大小成比例且便于對(duì)齊的圖片資源。然而，由于 AE 導(dǎo)出切片（用戶(hù)視口）的限制，一些包含大量透明通道的圖片可能會(huì)被意外導(dǎo)出到動(dòng)效資源中。以下圖所示為例，一張有效展示內(nèi)容區(qū)域?yàn)?140px 的 PNG 圖片，實(shí)際使用了 350px 的圖片，導(dǎo)致內(nèi)存占用增加了 525%（盡管不同格式圖片內(nèi)存占用絕對(duì)值會(huì)有所不同，但比例趨勢(shì)相同），這對(duì)頁(yè)面整體性能有較大影響。因此，識(shí)別這些隱藏在合規(guī)資源中的異常圖片，成為亟需解決的首要問(wèn)題。

在識(shí)別異常圖片后，我們需要具體的方法來(lái)檢測(cè)這些圖片的透明區(qū)域。在瀏覽器環(huán)境中，我們通常使用 Canvas 來(lái)解析圖片，通過(guò)遍歷其像素點(diǎn)的 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ù)端檢測(cè)流程中，使用 Canvas 進(jìn)行模擬渲染效率較低。因此，我們采用 Sharp 進(jìn)行圖片解碼，以獲取圖片的像素點(diǎ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);
    // 計(jì)算裁剪后的有效率    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;};

序列幀動(dòng)圖是實(shí)現(xiàn)動(dòng)效的重要手段之一。與靜態(tài) PNG 的圖片有效率場(chǎng)景類(lèi)似，盡管動(dòng)圖存在幀間合并方案，但低效的序列幀動(dòng)圖會(huì)因每幀的共同透明區(qū)域而導(dǎo)致內(nèi)存浪費(fèi)。因此，我們需要制定有效率計(jì)算方法，以剔除不合規(guī)的動(dòng)圖。參考靜態(tài)圖的有效率檢測(cè)規(guī)則，我們以每幀的最大透視范圍為依據(jù)，評(píng)估序列幀動(dòng)圖的效率。與靜態(tài)圖片相比，動(dòng)態(tài)圖片（如 APNG、WEBP 等）的每幀解碼尤為關(guān)鍵。以 APNG 為例，可以通過(guò) Sharp 庫(kù)設(shè)置 animated: false 獲取所有幀進(jìn)行遍歷判斷，或使用 UPNG.js 等解碼庫(kù)逐幀獲取內(nèi)容。獲取逐幀內(nèi)容后，進(jìn)行類(lèi)似靜態(tài)圖片的對(duì)比，從而簡(jiǎn)單判斷動(dòng)圖的有效率。

在檢測(cè) SDK 中，還有許多類(lèi)似圖片有效率的檢測(cè)方法，這里就不逐一詳述了。

3.2 動(dòng)態(tài)檢測(cè)服務(wù)

動(dòng)效設(shè)計(jì)師上傳的動(dòng)效經(jīng)過(guò)平臺(tái)的靜態(tài)檢測(cè)后，具備了一定的質(zhì)量保障。然而，為了避免因真機(jī)性能問(wèn)題導(dǎo)致的開(kāi)發(fā)返工，部分研發(fā)人員希望盡早進(jìn)行真機(jī)性能驗(yàn)收。因此，在動(dòng)效準(zhǔn)出階段，我們利用公司的云真機(jī)平臺(tái)和性能檢測(cè)工具，對(duì)單個(gè)動(dòng)效頁(yè)面或多動(dòng)效集成頁(yè)面進(jìn)行真機(jī)性能測(cè)試。通過(guò)真機(jī)性能測(cè)試采集的數(shù)據(jù)，我們進(jìn)一步分析了 CPU、內(nèi)存、FPS 和溫度等指標(biāo)。同時(shí)，針對(duì)性能穩(wěn)定性團(tuán)隊(duì)設(shè)定的指標(biāo)紅線(xiàn)，我們添加了相應(yīng)的準(zhǔn)出校驗(yàn)，以確保動(dòng)效的穩(wěn)定性和性能。

在整個(gè)檢測(cè)過(guò)程中，我們成功實(shí)現(xiàn)了自動(dòng)化執(zhí)行腳本的開(kāi)發(fā)集成，并攻克了 Kperf 檢測(cè)報(bào)告數(shù)據(jù)的存儲(chǔ)、處理和分析等復(fù)雜問(wèn)題。

3.3 檢測(cè)標(biāo)準(zhǔn)

在完善檢測(cè)服務(wù)后，我們意識(shí)到需要一套標(biāo)準(zhǔn)來(lái)規(guī)范動(dòng)效資源的質(zhì)量。因此，我們基于快手春節(jié)活動(dòng)（CNY）及日?；顒?dòng)中的豐富實(shí)踐經(jīng)驗(yàn)，制定了一套動(dòng)效臨時(shí)檢測(cè)標(biāo)準(zhǔn)。這些標(biāo)準(zhǔn)專(zhuān)注于平臺(tái)上常用的動(dòng)態(tài)效果格式，確保在不同應(yīng)用場(chǎng)景下的動(dòng)效資源都能達(dá)到預(yù)期的質(zhì)量和性能。

目前這套標(biāo)準(zhǔn)主要適用于單一動(dòng)態(tài)效果的小范圍應(yīng)用場(chǎng)景，涵蓋了多種檢測(cè)維度，以便更全面地評(píng)估動(dòng)效資源的合規(guī)性和有效性。具體檢測(cè)維度將在下文中詳細(xì)介紹。目前，這套標(biāo)準(zhǔn)正在根據(jù)用戶(hù)反饋不斷迭代和優(yōu)化，以確保其在實(shí)際應(yīng)用中的有效性和實(shí)用性。通過(guò)這種方式，我們不僅提升了動(dòng)效資源的整體質(zhì)量，還為開(kāi)發(fā)團(tuán)隊(duì)提供了更明確的選擇指導(dǎo)。

靜態(tài)檢測(cè)標(biāo)準(zhǔn)

動(dòng)態(tài)檢測(cè)標(biāo)準(zhǔn)

流暢度與卡頓的關(guān)聯(lián)可以用以下的流程圖來(lái)大致展示：

3.4 平臺(tái)檢測(cè)流程

常規(guī)檢測(cè)流程：動(dòng)效設(shè)計(jì)師無(wú)論通過(guò)平臺(tái)還是 AE 插件上傳資源，如果資源觸發(fā)靜態(tài)檢測(cè)異常，平臺(tái)會(huì)強(qiáng)制提醒結(jié)果，但不會(huì)阻止動(dòng)效的上傳和使用。研發(fā)人員仍可正常下載和使用這些資源。

強(qiáng)規(guī)則卡控流程：對(duì)于強(qiáng)規(guī)則卡控的項(xiàng)目，動(dòng)效設(shè)計(jì)師上傳未通過(guò)檢測(cè)的資源將進(jìn)入待確認(rèn)列表，而非檢測(cè)通過(guò)列表。待確認(rèn)列表中的動(dòng)效需經(jīng)研發(fā)負(fù)責(zé)人或動(dòng)效 BP 人工確認(rèn)后，才能被研發(fā)人員正常使用。只有經(jīng)過(guò)人工確認(rèn)的資源，才會(huì)出現(xiàn)在檢測(cè)通過(guò)列表中，供研發(fā)人員下載和使用。

四、落地實(shí)踐與收益

4.1 落地情況

平臺(tái)落地

準(zhǔn)入檢測(cè) &報(bào)告

準(zhǔn)出檢測(cè)報(bào)告

強(qiáng)卡流程

目前平臺(tái)已經(jīng)集成了動(dòng)效的準(zhǔn)入 & 準(zhǔn)出動(dòng)作，并且實(shí)現(xiàn)了整套上述分享 靜態(tài)/動(dòng)態(tài)資源 流程。

Open SDK/API

除了在 Vision 平臺(tái)的檢測(cè)功能的亮相，檢測(cè)基礎(chǔ)服務(wù) 還將功能打包，作為 Open SDK 和 API 對(duì)外輸出檢測(cè)能力。借助內(nèi)部檢測(cè)質(zhì)效專(zhuān)項(xiàng)的推動(dòng)，目前已經(jīng)完成了在快手主站內(nèi)多個(gè) C 端核心運(yùn)營(yíng) &資源平臺(tái)的接入。

4.2 實(shí)踐收益

在 2024 年第三季度，動(dòng)效檢測(cè)和開(kāi)放接口的召回問(wèn)題數(shù)量累計(jì) 萬(wàn)余次，其中有效規(guī)避了 幾十次 有造成客戶(hù)端 Crash 風(fēng)險(xiǎn)的問(wèn)題。

五、總結(jié)

本文詳細(xì)介紹了 Vision 平臺(tái)在解決動(dòng)效資源交付質(zhì)量問(wèn)題中的思考與實(shí)踐，希望能為您提供啟示和支持。如果您有任何疑問(wèn)或建議，歡迎隨時(shí)留言討論，我們期待您的寶貴意見(jiàn)。

回顧本系列文章，詳細(xì)分享了快手在 Vision 動(dòng)效平臺(tái)的工作成果，首篇闡述平臺(tái)整體演進(jìn)思路及核心能力布局，隨后詳細(xì)介紹渲染引擎 Crab 及復(fù)雜動(dòng)效渲染實(shí)踐、動(dòng)效 Code Gen 技術(shù)原理、多種序列幀格式的最佳實(shí)踐及其轉(zhuǎn)換服務(wù)技術(shù)原理。此外，系列文章還將探討動(dòng)效準(zhǔn)入、準(zhǔn)出檢測(cè)過(guò)程中的技術(shù)原理，并分享 Spine 動(dòng)效在 React Native 技術(shù)棧下的實(shí)踐，為讀者提供一個(gè)全面而深入的視角，以更好地理解快手在動(dòng)效領(lǐng)域的探索與實(shí)踐。