導讀：快手動效 Vision 平臺為解決動效資源交付問題，引入了動效資源準入準出檢測機制。通過分析現有交付流程的痛點，平臺增加了了靜態和動態檢測服務，確保動效質量與性能。該套系統已成功召回并預防了多次線上問題，提升了使用動效資源的穩定性和效率。

一、引言

在系列文章的首篇??《快手前端動效大揭秘：告別低效，vision平臺來襲！》（點擊回顧）???中，我們探討了 Vision 平臺的整體架構和演進思路，特別是針對動效生產成本高、交付流程繁瑣、資產管理成本高以及資產復用困難等問題進行了概括性的介紹。在實踐中，我們還發現不同的線上場景（如活動 H5、直播間、客戶端等）對動效資源的需求各不相同，這進一步增加了動效交付與使用的復雜性。同時，部分一線使用動效的同學對相關標準理解不一，導致在不同業務線中因動效資源使用不當或配置錯誤而引發的線上事故時有發生。

為了解決這些動效交付中的問題，Vision 平臺決定通過動效資源系統性的準入和準出檢測方案來加以解決。接下來，我將從方案的分析思路、架構設計、實現細節與項目收益幾個方面進行詳細介紹。

二、分析與思考

2.1 動效交付流程分析

分析以往的動效資源交付流程，動效資源的交付嚴重依賴于設計師通過 Docs 文檔記錄和附件上傳，更新則完全依靠人工同步，缺乏系統化的流程和質量管控。由于動效資源問題的解決往往需要對比較多資源，許多問題場景需要反復與設計師溝通，導致資源交付流程循環往復，極易影響項目的整體交付進度。

2.2 平臺針對交付鏈路的改善

Vision 平臺引入了資源準入和準出檢測流程，在動效預覽時對未通過檢測的資源進行強制報告。后續的動效交付將從依賴 Docs 的方式轉向平臺化方案，通過統一的準入準出檢測實現更好的管控和同步。

三、具體方案

為了實現交付流程中的準入和準出檢測，Vision 構建了一套基礎檢測服務。該服務涵蓋基礎檢測功能、獨立檢測服務、平臺轉發/開放服務，以及最終面向業務方的檢測服務。此外，還涉及數據庫、自動化測試任務調度平臺和運行時檢測平臺等內部第三方服務。

在概述基礎檢測服務后，我們將從底層實現向上探討其具體實現，包括靜態檢測 SDK、動態檢測服務，以及相應的平臺檢測等流程。

3.1 靜態檢測 SDK

我們常用的動效資源格式包括 Lottie、序列幀動圖（如 APNG、Webp 等）、序列幀視頻、靜態圖片和 CSS 等多種形式。抽象來看，動效資源的靜態檢測可以分為資源獲取與解碼、規則設定、特性檢測和報告生成等幾個階段。

其中資源的解碼會根據資源的不同采用不同的 Decoder：

由于多條規則需要對同一套動效數據進行頻繁計算，容易導致代碼冗余。以 Lottie 檢測為例，常規檢測需要遍歷超過 40 條規則，包括對 JSON 節點的歸納、層級深度分析、圖片構造等操作。一個非標準的 Lottie 動效可能包含數百個節點和幾十張圖片，當項目集中檢測時，底層服務的壓力會呈幾何式增長。為提高效率，SDK 對解碼后的數據進行緩存，并通過校驗插件進行遍歷檢測，從而更高效地生成靜態檢測結果。SDK 的具體流程設計如下圖所示：

當然，不同的動效實現方式也具備相似的檢測能力。下面，我將以 SDK 中廣泛應用的 圖片有效率分析 為例進行詳細介紹。

圖片有效率分析

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

在識別異常圖片后，我們需要具體的方法來檢測這些圖片的透明區域。在瀏覽器環境中，我們通常使用 Canvas 來解析圖片，通過遍歷其像素點的 RGBA 值，檢查 alpha 通道是否等于 255，以判斷圖片是否包含透明區域。

// 瀏覽器判斷方式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); // 有透明數據                return;            }        }        callback(false);    };
onerror = () =>        console.error('圖片加載失敗');        callback(false); // 加載失敗，返回false    };};

然而，在服務端檢測流程中，使用 Canvas 進行模擬渲染效率較低。因此，我們采用 Sharp 進行圖片解碼，以獲取圖片的像素點信息，并利用 Sharp 內置的 trim() 函數進行裁剪。

const sharp = require('sharp');
const calculateTrimEfficiency = async (input, output, thresholdPercentage) => {    // 獲取原始圖像信息    const image = await sharp(input).metadata();
    // 使用 sharp 進行裁剪    const { info } = await sharp(input)        .trim() // 這里可以根據需要傳遞參數        .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)}%`);
    // 判斷裁剪是否達到閾值    const isAccept = efficiency >= thresholdPercentage;    if (isAccept) {        console.log('裁剪后的圖像符合要求。');    } else {        console.log('裁剪后的圖像不符合要求。');    }
    return isAccept;};

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

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

3.2 動態檢測服務

動效設計師上傳的動效經過平臺的靜態檢測后，具備了一定的質量保障。然而，為了避免因真機性能問題導致的開發返工，部分研發人員希望盡早進行真機性能驗收。因此，在動效準出階段，我們利用公司的云真機平臺和性能檢測工具，對單個動效頁面或多動效集成頁面進行真機性能測試。通過真機性能測試采集的數據，我們進一步分析了 CPU、內存、FPS 和溫度等指標。同時，針對性能穩定性團隊設定的指標紅線，我們添加了相應的準出校驗，以確保動效的穩定性和性能。

在整個檢測過程中，我們成功實現了自動化執行腳本的開發集成，并攻克了 Kperf 檢測報告數據的存儲、處理和分析等復雜問題。

3.3 檢測標準

在完善檢測服務后，我們意識到需要一套標準來規范動效資源的質量。因此，我們基于快手春節活動（CNY）及日常活動中的豐富實踐經驗，制定了一套動效臨時檢測標準。這些標準專注于平臺上常用的動態效果格式，確保在不同應用場景下的動效資源都能達到預期的質量和性能。

目前這套標準主要適用于單一動態效果的小范圍應用場景，涵蓋了多種檢測維度，以便更全面地評估動效資源的合規性和有效性。具體檢測維度將在下文中詳細介紹。目前，這套標準正在根據用戶反饋不斷迭代和優化，以確保其在實際應用中的有效性和實用性。通過這種方式，我們不僅提升了動效資源的整體質量，還為開發團隊提供了更明確的選擇指導。

靜態檢測標準

動態檢測標準

流暢度與卡頓的關聯可以用以下的流程圖來大致展示：

3.4 平臺檢測流程

常規檢測流程：動效設計師無論通過平臺還是 AE 插件上傳資源，如果資源觸發靜態檢測異常，平臺會強制提醒結果，但不會阻止動效的上傳和使用。研發人員仍可正常下載和使用這些資源。

強規則卡控流程：對于強規則卡控的項目，動效設計師上傳未通過檢測的資源將進入待確認列表，而非檢測通過列表。待確認列表中的動效需經研發負責人或動效 BP 人工確認后，才能被研發人員正常使用。只有經過人工確認的資源，才會出現在檢測通過列表中，供研發人員下載和使用。

四、落地實踐與收益

4.1 落地情況

平臺落地

準入檢測 &報告

準出檢測報告

強卡流程

目前平臺已經集成了動效的準入 & 準出動作，并且實現了整套上述分享 靜態/動態資源 流程。

Open SDK/API

除了在 Vision 平臺的檢測功能的亮相，檢測基礎服務 還將功能打包，作為 Open SDK 和 API 對外輸出檢測能力。借助內部檢測質效專項的推動，目前已經完成了在快手主站內多個 C 端核心運營 &資源平臺的接入。

4.2 實踐收益

在 2024 年第三季度，動效檢測和開放接口的召回問題數量累計 萬余次，其中有效規避了 幾十次 有造成客戶端 Crash 風險的問題。

五、總結

本文詳細介紹了 Vision 平臺在解決動效資源交付質量問題中的思考與實踐，希望能為您提供啟示和支持。如果您有任何疑問或建議，歡迎隨時留言討論，我們期待您的寶貴意見。

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