bilibili-AVIF圖片格式落地
本期作者
背景
圖片庫(kù)加載服務(wù)是為bilibili打造的移動(dòng)端一站式解決方案，集圖像加載、顯示、處理、監(jiān)控于一體，以高可用、高性能、可高度定制、數(shù)據(jù)服務(wù)、省流量五大核心優(yōu)勢(shì)被公司各個(gè)業(yè)務(wù)接入使用，經(jīng)過(guò)長(zhǎng)期的迭代與維護(hù)，已成熟穩(wěn)定。
在如今越來(lái)越看重體驗(yàn)的大環(huán)境下，對(duì)圖片庫(kù)的要求也日益攀升。從成本的角度來(lái)看，使用AVIF格式可以節(jié)省大量的網(wǎng)絡(luò)帶寬和存儲(chǔ)空間，減少網(wǎng)站加載時(shí)間，并且可以改善用戶體驗(yàn)，進(jìn)而提高網(wǎng)站的效率和收益，從而節(jié)約大量的費(fèi)用。
AVIF格式能夠帶來(lái)許多優(yōu)勢(shì)，首先，AVIF格式具有明顯的壓縮率優(yōu)勢(shì)，可以比其他常用圖片格式（如JPEG、PNG）節(jié)省更多的存儲(chǔ)空間，減少圖片加載所需時(shí)間和帶寬，提高網(wǎng)站加載速度，提高訪問(wèn)者的體驗(yàn)；其次，AVIF格式豐富的特性支持，可以支持更多的設(shè)備和瀏覽器，提高圖片的可用性，并可以免專(zhuān)利費(fèi)的優(yōu)勢(shì)；最后，AVIF格式支持圖片的質(zhì)量?jī)?yōu)化，可以保證圖片的質(zhì)量，同時(shí)節(jié)省更多的容量。
一、AVIF圖片格式研究
1、圖片格式編解碼研究
圖片格式AVIF編解碼詳解（期待后續(xù)公布的分享）進(jìn)行AVIF圖片格式的研究，AVIF格式相比其他圖片格式，有著更高的壓縮比，可以支持更多的色彩深度，支持alpha通道，支持更多的圖片尺寸，支持動(dòng)態(tài)圖片，支持更多的壓縮選項(xiàng)，可以更有效地利用計(jì)算資源，支持多層編碼，支持非碼率壓縮，支持虛擬化和硬件加速，支持縮略圖和視頻幀等。
2、AVIF在B站落地的調(diào)研
2022 年以前，B 站主流圖片格式為 WebP，在對(duì)基礎(chǔ)設(shè)施成本做回顧的過(guò)程中，定位到靜態(tài)資源 CDN 成本是重要的組成部分。隨著業(yè)界技術(shù)的逐漸成熟，經(jīng)過(guò)相關(guān)調(diào)研，我們認(rèn)為 AVIF 在 B 站大規(guī)模落地存在可行性。
在相同格式相同編碼器下，可以簡(jiǎn)單的認(rèn)為編碼速度、圖像質(zhì)量與圖片體積構(gòu)成一個(gè)不可能三角，需要通過(guò)調(diào)整編碼速度參數(shù)（下稱 speed）與圖像質(zhì)量參數(shù)（下稱 quality），在三者之間做取舍。
我們選取了三百萬(wàn)線上真實(shí)的縮略圖請(qǐng)求，于實(shí)驗(yàn)環(huán)境進(jìn)行回放，盡可能貼近 B 站實(shí)際使用場(chǎng)景。對(duì)同一個(gè)縮略請(qǐng)求，我們會(huì)使用線上現(xiàn)有編碼參數(shù)，生成 PNG 和 WebP 兩個(gè)版本，并用幾個(gè)不同檔位的 speed 和 quality，生成若干個(gè) AVIF 版本，其中 PNG 被認(rèn)為是無(wú)損格式，用作比較基準(zhǔn)。
PSNR 可以被用于衡量原圖與編碼后圖片的差異大小，一般大于 30 dB 即可認(rèn)為人眼較難察覺(jué)出圖像差異，大于 20 dB 被認(rèn)為人眼觀感差異不明顯。PSNR 不能代替人類(lèi)主觀評(píng)價(jià)，但定量實(shí)驗(yàn)中，我們需要一個(gè)客觀指標(biāo)。無(wú)特別描述的前提下，下文提及 WebP/AVIF 的圖像質(zhì)量時(shí)，指的是 PSNR ( PNG → WebP ) 和 PSNR ( PNG → AVIF ) 的數(shù)值大小。
經(jīng)過(guò)持續(xù)數(shù)天的流量回放實(shí)驗(yàn)，我們有以下定性結(jié)論：
1. ?speed 對(duì)編碼耗時(shí)影響顯著，對(duì)圖像質(zhì)量與圖片體積影響不大。
2. ?相同 speed/quality 的前提下，圖片越大，AVIF 相對(duì) WebP 的體積優(yōu)勢(shì)越明顯。
3. ?相同 speed/圖片大小 的前提下，質(zhì)量(quality)越高，AVIF 相對(duì) WebP 的體積優(yōu)勢(shì)越明顯。
對(duì)齊圖像質(zhì)量（PSNR 差值不超過(guò) 1）的前提下，我們有以下定量結(jié)論：
1. ?B 站主流縮略圖場(chǎng)景下，AVIF 相比 WebP 平均體積優(yōu)化在 35% 左右。
2. ?B 站主流縮略圖場(chǎng)景下，AVIF 相比 WebP 耗時(shí)增長(zhǎng) 4 ~ 5 倍，圖片越大，耗時(shí)增長(zhǎng)越明顯，視頻預(yù)覽圖等超大圖場(chǎng)景，耗時(shí)增長(zhǎng) 20 倍以上。
B 站主流縮略圖場(chǎng)景下，AVIF 4 線程編碼耗時(shí)約為單線程的 73%，CPU 開(kāi)銷(xiāo)是單線程的 115%，且進(jìn)一步增大并發(fā)度的收益不高。
瀏覽器兼容性角度，caniuse.com（http://caniuse.com/）提供的數(shù)據(jù)表明，截止2023年已經(jīng)有79.81%的瀏覽器版本支持WebP，具體支持情況如下圖所示
實(shí)際根據(jù)對(duì) B 站網(wǎng)頁(yè)端訪問(wèn)日志的分析，目前超過(guò) 50% 的用戶瀏覽器支持 AVIF。
二、分端實(shí)現(xiàn)
圖片庫(kù)的管理以及服務(wù)的部署，進(jìn)行圖片的加載、顯示、處理等操作。
1、服務(wù)端架構(gòu)
B 站圖片服務(wù)底層使用 ImageMagick 作為核心的圖片處理庫(kù)，ImageMagick 設(shè)計(jì)上是針對(duì)桌面場(chǎng)景手動(dòng)處理圖片，著眼于功能的豐富性。我們?cè)诼涞胤?wù)端的過(guò)程中，修改了部分代碼，以適配在線服務(wù)的性能與穩(wěn)定性需求，因定制化較強(qiáng)，遺憾未能回饋上游。在 AVIF 處理方面，我們使用 libheif 集成 libaom 編碼 AVIF。
從前文可以看出，相比 WebP，AVIF 編碼耗時(shí)顯著增長(zhǎng)。我們?cè)?B 站概念版客戶端進(jìn)行了較長(zhǎng)時(shí)間的 AVIF 灰度實(shí)驗(yàn)，用戶側(cè)八十分位圖片加載耗時(shí)等埋點(diǎn)指標(biāo)顯著劣化，預(yù)期會(huì)對(duì)用戶留存有較大影響，無(wú)法滿足業(yè)務(wù)需求。多次嘗試優(yōu)化 AVIF 編碼器后，沒(méi)有獲得編碼速度上的顯著提升，AVIF 推進(jìn)進(jìn)度暫時(shí)擱置。
某次重構(gòu)線上代碼時(shí)，發(fā)現(xiàn)歷史上曾有用戶將動(dòng)圖偽裝成普通 PNG 上傳，繞過(guò)業(yè)務(wù)限制，獲得了酷炫的動(dòng)圖頭像（該漏洞已被修復(fù)）。受此啟發(fā)，圖片服務(wù)架構(gòu)從純?cè)诰€架構(gòu)演進(jìn)到了在離線混合架構(gòu)，以下是相關(guān)解釋?zhuān)?/p>
1. ?背景：簡(jiǎn)化后的縮略圖鏈路為 用戶 ? 第三方 CDN ? B 站內(nèi)網(wǎng) CDN ? 圖片服務(wù) ? 原圖存儲(chǔ)，其中 CDN 主要通過(guò) HTTP Response 中的 Cache-Control 頭決定資源緩存多久，默認(rèn)是一個(gè)極長(zhǎng)的數(shù)值。
2. ?前提：第三方瀏覽器和 B 站 APP，均可以根據(jù)響應(yīng)內(nèi)容而非 URL 后綴名決定所需圖片解碼格式，且 B 站場(chǎng)景下，圖片資源的訪問(wèn)有較大聚集性。
3. ?思路：某個(gè) AVIF 縮略圖請(qǐng)求首次請(qǐng)求時(shí)，圖片服務(wù)返回一個(gè)緩存有效期較短的 WebP 資源。
a. ?同時(shí)觸發(fā)離線任務(wù)，產(chǎn)出對(duì)應(yīng)的 AVIF 縮略圖，推送到 Boss 中，配合一個(gè)較長(zhǎng)的緩存有效期。
b.? 同一請(qǐng)求重新穿透到內(nèi)網(wǎng)時(shí)，直接命中?Boss?中的 AVIF 資源并返回。
Boss 是 B 站自研對(duì)象存儲(chǔ)，相關(guān)實(shí)現(xiàn)介紹：https://www.bilibili.com/read/cv16653640
4. ?驗(yàn)證：
a. ?體驗(yàn)視角，回收概念版實(shí)驗(yàn)數(shù)據(jù)后，確認(rèn) AVIF 加載耗時(shí)于 WebP 無(wú)顯著劣化。b. ?成本視角，AVIF 請(qǐng)求中降級(jí)所用的 WebP 流量占 2%，帶寬成本收益不受影響。
5. ?成本：
a. ?額外的存儲(chǔ)成本，但相比 CDN 帶寬收益，可以忽略不計(jì)（存儲(chǔ)成本占帶寬收益 1% 以下）。b.? 額外的計(jì)算成本，多出了用于降級(jí)的 WebP 資源需求，相比 AVIF 的 CPU 需求，不算特別顯著（ 計(jì)算成本增長(zhǎng)不超過(guò) 20%）
附，源站架構(gòu)簡(jiǎn)圖：
2、Web端實(shí)現(xiàn)
通過(guò)分析線上頁(yè)面的埋點(diǎn)信息，我們發(fā)現(xiàn)在 B 站 Web 端請(qǐng)求中，約有一半的瀏覽器不支持 AVIF 格式，主要是 Edge 瀏覽器。為了兼容這部分用戶，我們需要一個(gè)合適的自動(dòng)降級(jí)方案。
最初，我們計(jì)劃所有用戶使用相同的 URL，并根據(jù) HTTP 請(qǐng)求頭中 Accept 字段智能協(xié)商圖片格式（WebP 或 AVIF）。但由于 B 站圖片資源同時(shí)使用多個(gè)第三方 CDN 廠商，在標(biāo)準(zhǔn)實(shí)現(xiàn)細(xì)節(jié)上存在差異，難以保證該方案可靠性。
后來(lái)，我們采用 HTML picture 標(biāo)簽提供若干 source 元素，并讓瀏覽器根據(jù)其支持的圖片格式自動(dòng)選擇對(duì)應(yīng)的 URL：優(yōu)先請(qǐng)求 AVIF 格式；如果瀏覽器不支持，則降級(jí)到 WebP；對(duì)于極少數(shù)不支持 WebP 的瀏覽器，則進(jìn)一步降級(jí)到 JPG/PNG 格式。
由于 B 站 Web 端歷史積累較多，在短時(shí)間內(nèi)無(wú)法完成全量改造。目前已經(jīng)開(kāi)發(fā)出統(tǒng)一圖片組件，并按接入業(yè)務(wù)優(yōu)先級(jí)逐步推廣。首頁(yè)、播放頁(yè)等核心場(chǎng)景已經(jīng)完成了接入工作。
3、移動(dòng)端處理
1. 解碼器選擇
客戶端本地處理 AVIF 圖片解碼采用的是開(kāi)源庫(kù) libavif，因?yàn)?AVIF 實(shí)際上是基于 AV1 格式的視頻幀進(jìn)行處理，所以 libavif 庫(kù)也有多個(gè)可選視頻解析庫(kù)來(lái)作為底層能力的提供者。而我們選擇dAV1d的原因如下：
dAV1d 是一個(gè) AV1 軟件解碼器，AV1 是開(kāi)放媒體聯(lián)盟在2018年發(fā)布的一個(gè)視頻編碼標(biāo)準(zhǔn)，用于互聯(lián)網(wǎng)視頻流，包括視頻聊天、視頻云直播（https://cloud.tencent.com/product/css?from=10680）、云點(diǎn)播VOD（https://cloud.tencent.com/product/vod?from=10680）等。
dAV1d 是一個(gè) VideoLAN 的項(xiàng)目，在 2-clause BSD 許可下開(kāi)源。dAV1d 的目標(biāo)是快速、高效，包含幀級(jí)、tile 級(jí)、后處理濾波的多線程，以及平臺(tái)優(yōu)化包括 ARM(Neon）, X86(AVX2/SSSE3)。
VideoLAN的主席Jean-Baptiste Kempf在其博客上透露了AV1解碼器dAV1d的最新進(jìn)展，和libaom相比，dAV1d性能普遍提升100%，最高提升400%。
dAV1d 由 VideoLAN，VLC 和 FFmpeg 聯(lián)合開(kāi)發(fā)，項(xiàng)目由 AOMedia 贊助
此外，Jean-Baptiste Kempf 還介紹了 dAV1d 的其他關(guān)鍵改進(jìn)：
1.? dAV1d 支持所有 spec 和功能以及 8bits 和 10bits 色深
2.? 已經(jīng)完成包括 Film Grain, Super-Res, Scaled References 等功能，并全部支持 8bits 和 10bits 色深，正在開(kāi)發(fā)公有 API
3. ?開(kāi)發(fā)工作已經(jīng)覆蓋99%的功能，通常一個(gè) issue 會(huì)被在幾天內(nèi)搞定。
4.? 編譯器方面已經(jīng)支持大部分流行的桌面 CPU，已經(jīng)開(kāi)始開(kāi)發(fā)移動(dòng)端和古老的桌面 CPU 的編譯器、
5. ?減少了 C語(yǔ)言代碼的體積。
6. ?已經(jīng)準(zhǔn)備好了針對(duì) SSE 和 ARM 指令優(yōu)化，ARMv8 也準(zhǔn)備好了。
2.請(qǐng)求策略
得益于統(tǒng)一的圖片框架，我們能夠以最小的代碼改動(dòng)覆蓋幾乎所有應(yīng)用場(chǎng)景。業(yè)務(wù)指定圖片資源與縮略指令時(shí)，統(tǒng)一圖片框架會(huì)根據(jù)服務(wù)端動(dòng)態(tài)下發(fā)的策略，分業(yè)務(wù)、分場(chǎng)景決定是否獲取對(duì)應(yīng) AVIF 資源。
3.監(jiān)控及降級(jí)策略
BiliImage 框架會(huì)對(duì)圖片的解碼流程進(jìn)行詳細(xì)的監(jiān)控，包括但不限于內(nèi)存、磁盤(pán)、網(wǎng)絡(luò)的讀取耗時(shí)以及解碼耗時(shí)、圖片解析異常等重要數(shù)據(jù)。
BiliImage 支持自定義解碼器，對(duì)于一種新的格式的圖片處理，我們只需定義好 decoder 并插入到 image pipline 中即可。解碼器支持熱插拔，我們通過(guò)一系列的校驗(yàn)措施來(lái)保證 AVIF 圖片處理的穩(wěn)定性。
a.? 應(yīng)用啟動(dòng)時(shí)，我們會(huì)對(duì)本地存儲(chǔ)的一張 1x1 的 AVIF 圖像進(jìn)行預(yù)解碼，若解碼失敗則禁止該設(shè)備在這次生命周期內(nèi)進(jìn)行 AVIF 圖片請(qǐng)求
b.? 配置設(shè)備維度的黑名單，由于 AVIF 圖片解碼對(duì) CPU 性能要求較高，針對(duì)線上監(jiān)控中性能表現(xiàn)不佳的老舊機(jī)型，會(huì)做特殊處理
4.踩過(guò)的坑及怎么爬出來(lái)的
a.? Android
● fresco性能問(wèn)題
主站的圖片處理框架基于 Fresco 構(gòu)建，在添加 AVIF 解碼能力的時(shí)候，我們發(fā)現(xiàn)圖片的內(nèi)存、磁盤(pán)讀取耗時(shí)以及解碼耗時(shí)相比于同樣大小的 WebP 文件均有較大幅度的增長(zhǎng)，甚至某些指標(biāo)達(dá)到了近十倍的差距，這與預(yù)期不符。通過(guò)閱讀 Fresco 源碼發(fā)現(xiàn)，一張圖片從請(qǐng)求到展示到用戶界面，其數(shù)據(jù)流會(huì)被預(yù)定義的各種 producer 和 consumer 進(jìn)行處理，那么我們就可以通過(guò)代碼插樁以上兩個(gè)處理器的所有派生類(lèi)，來(lái)分析具體的耗時(shí)瓶頸。最終我們定位到一個(gè)高頻的調(diào)用方法, parseMetadata。在該方法中 Fresco 會(huì)預(yù)解析圖片的信息，而對(duì)于不支持的圖片格式，則會(huì)強(qiáng)制使用系統(tǒng)的 BitmapFactory 進(jìn)行處理（Android12 以下的版本不支持 AVIF 格式）。通過(guò)修改 Fresco 代碼，我們修復(fù)了這個(gè)問(wèn)題：在執(zhí)行 parseMetadata 方法前做一個(gè)判斷，當(dāng)識(shí)別到 AVIF 格式的圖片時(shí)略過(guò)這步處理，圖片相關(guān)信息從自定義 decoder 中獲取。（最新版本的 Fresco 已經(jīng)支持 setUseCachedMetadata 方法來(lái)復(fù)用 parseMetadata 的處理結(jié)果）
● 系統(tǒng)區(qū)域解碼兼容性處理
Android 系統(tǒng)提供了 BitmapRegionDecoder 工具類(lèi)來(lái)處理超大圖，支持傳入尺寸參數(shù)來(lái)進(jìn)行區(qū)域解碼，但遺憾的是 BitmapRegionDecoder 暫不支持 AVIF 格式的區(qū)域解碼操作，當(dāng)嘗試進(jìn)行解碼的時(shí)候會(huì)拋出異常。針對(duì)這個(gè)問(wèn)題，我們提供了接口，允許業(yè)務(wù)方針對(duì)大圖場(chǎng)景禁用 AVIF 加載，但是這無(wú)法杜絕后續(xù)業(yè)務(wù)方的誤用。所以我們通過(guò) Ghost 工具 hook 了 BitmapRegionDecoder#newInstance 方法，在執(zhí)行該方法之前，校驗(yàn)圖片文件的前32位數(shù)據(jù)，若為 AVIF 格式，測(cè)試版本會(huì)直接拋出異常，而發(fā)布版本則會(huì)進(jìn)行埋點(diǎn)上報(bào)來(lái)通知業(yè)務(wù)方進(jìn)行修改。
b.? iOS
●?AVIF支持預(yù)乘格式
AVIF 圖像格式進(jìn)行圖像處理時(shí)，例如縮放、旋轉(zhuǎn)、裁剪等操作，需要將圖像標(biāo)記為“預(yù)乘”的格式，以確保圖像顏色的正確性。在Conversion（轉(zhuǎn)換）中 AVIF 圖像處理，需要將圖像標(biāo)記為預(yù)乘格式，以避免顏色失真。對(duì)于非預(yù)乘的圖像格式，需要進(jìn)行轉(zhuǎn)換，以將其轉(zhuǎn)換為預(yù)乘格式，然后再進(jìn)行處理。這個(gè)過(guò)程可以通過(guò)將顏色值除以 alpha 值來(lái)實(shí)現(xiàn)，以得到預(yù)乘的顏色值。
●?支持 libavif 0.9.1
支持最新版本的 libavif 編解碼庫(kù)，該庫(kù)包括了一些新的特性和改進(jìn)，以提高 AVIF 圖像的編解碼性能和質(zhì)量。
● avifdec：添加--dimension-limit，指定應(yīng)該容忍的圖像尺寸限制（寬度或高度）
avifdec 是用于解碼 AVIF 圖像的工具，可以通過(guò)添加--dimension-limit參數(shù)來(lái)指定應(yīng)該容忍的圖像尺寸限制，以避免解碼超大尺寸的圖像導(dǎo)致內(nèi)存溢出和程序崩潰。
●?fix vImageConvert 失敗時(shí)的雙重空閑內(nèi)存問(wèn)題
vImageConvert 是蘋(píng)果開(kāi)發(fā)的一個(gè)圖像處理函數(shù)庫(kù)，可以用于對(duì)圖像進(jìn)行轉(zhuǎn)換和處理。在使用 vImageConvert 進(jìn)行圖像處理時(shí)，可能會(huì)出現(xiàn)雙重空閑內(nèi)存的問(wèn)題，導(dǎo)致內(nèi)存泄漏和程序崩潰。修復(fù)這個(gè)問(wèn)題需要進(jìn)行內(nèi)存管理的優(yōu)化和錯(cuò)誤處理的改進(jìn)等方面。
●?fix ICC 配置文件、緩沖區(qū)和 AVIF 編碼內(nèi)存泄漏
ICC（International Color Consortium）是一種用于顏色管理的標(biāo)準(zhǔn)，包括顏色空間和顏色配置文件等。在處理 AVIF 圖像時(shí)，可能會(huì)涉及到 ICC 配置文件和緩沖區(qū)的使用，如果處理不當(dāng)可能會(huì)導(dǎo)致內(nèi)存泄漏。修復(fù)這個(gè)問(wèn)題需要對(duì)內(nèi)存管理和 ICC 配置文件處理進(jìn)行優(yōu)化。為此移動(dòng)端7.8版本以前客戶端會(huì)有偶像的解碼變成黑白圖。
●?fix 動(dòng)畫(huà) AVIF 解碼失敗和解碼動(dòng)畫(huà)圖像泄漏
在解碼動(dòng)畫(huà) AVIF 圖像時(shí)，可能會(huì)出現(xiàn)解碼失敗和內(nèi)存泄漏的問(wèn)題。修復(fù)這些問(wèn)題需要涉及到 AVIF 解碼器的開(kāi)發(fā)，包括內(nèi)存管理等方面。
經(jīng)過(guò)一段時(shí)間的各方面驗(yàn)證，解決 AVIF 圖像解碼相關(guān)的技術(shù)問(wèn)題涉及到圖像處理、解碼算法、內(nèi)存管理、錯(cuò)誤處理等多個(gè)方面。需要對(duì)各個(gè)方面進(jìn)行細(xì)致的分析和優(yōu)化，解決這些問(wèn)題，并提高 AVIF 圖像的解碼性能和穩(wěn)定性。
經(jīng)過(guò)一系列的性能優(yōu)化措施后，我們配合測(cè)試部門(mén)進(jìn)行了天馬封面圖專(zhuān)項(xiàng)自動(dòng)化測(cè)試，雙端測(cè)試覆蓋圖片共15000張左右，基本涵蓋了市面上所有的主流機(jī)型。測(cè)試結(jié)果表明 AVIF 圖片在用戶視覺(jué)體驗(yàn)上相比于其他格式的圖片沒(méi)有明顯降低，內(nèi)存使用、CPU 占用率、平均 FPS 也沒(méi)有明顯的波動(dòng)。
三、業(yè)務(wù)落地
對(duì)接公司業(yè)務(wù)，進(jìn)行圖片庫(kù)的定制，保證服務(wù)的可用性及性能。
1.Web端
完成播放頁(yè)、首頁(yè)等核心場(chǎng)景覆蓋，伴隨日常業(yè)務(wù)迭代，漸進(jìn)式推廣中。
?2.移動(dòng)端
移動(dòng)端落地計(jì)劃的前置：
1. ?在引入 AVIF 之前，評(píng)估現(xiàn)有業(yè)務(wù)中所使用的圖片格式，并確定哪些圖片可以被 AVIF 替換。在評(píng)估中考慮的因素包括：圖片類(lèi)型、圖片大小、使用場(chǎng)景、壓縮質(zhì)量和壓縮率等。
2. ?AVIF 目前在移動(dòng)端的支持程度夠不夠完善，確定需要支持的移動(dòng)端版本型號(hào)，硬件等，以便在決定是否使用 AVIF 時(shí)考慮到兼容性的問(wèn)題。
3. ?引入 AVIF 后，需要進(jìn)行性能和效果的評(píng)估，以確保引入 AVIF 后能夠滿足業(yè)務(wù)需求。這些評(píng)估可以包括：頁(yè)面加載速度、圖片渲染速度、內(nèi)存占用率、CPU占用率、圖像質(zhì)量和文件大小等。
4. ?在確定那些業(yè)務(wù)和格式使用 AVIF 的圖片和支持的系統(tǒng)版本，品牌，可以逐步引入 AVIF。先在嗶哩嗶哩藍(lán)板（概念版）或新功能中嘗試使用 AVIF，以評(píng)估 AVIF 的效果和兼容性，然后再逐步應(yīng)用到其他業(yè)務(wù)中。
5. ?在引入 AVIF 后，需要對(duì)其進(jìn)行監(jiān)控和優(yōu)化，以確保其能夠持續(xù)地滿足業(yè)務(wù)需求。這些監(jiān)控和優(yōu)化可以包括：監(jiān)控頁(yè)面加載速度、圖片渲染速度、內(nèi)存占用率、CPU占用率、圖像質(zhì)量和文件大小等，并根據(jù)監(jiān)控結(jié)果進(jìn)行優(yōu)化。
四、數(shù)據(jù)監(jiān)控
1、服務(wù)端監(jiān)控
為觀察 AVIF 上線后的各項(xiàng)指標(biāo)，在既有 QPS、耗時(shí)、SLO 外，還針對(duì) AVIF 離線處理的特性，添加了 AVIF 專(zhuān)屬監(jiān)控。
其中 fallback 表示 AVIF 請(qǐng)求降級(jí)到 WebP 并觸發(fā)離線任務(wù)，cache_hit 表示當(dāng)前 AVIF 請(qǐng)求已在之前的請(qǐng)求中完成處理，直接從緩存中獲取 AVIF 并響應(yīng)。
2、移動(dòng)端監(jiān)控
圖片監(jiān)控體系
實(shí)時(shí)數(shù)據(jù)
展示AVIF圖片的請(qǐng)求耗時(shí)、錯(cuò)誤率、訪問(wèn)量、響應(yīng)包大小等指標(biāo)。
通過(guò)監(jiān)控?cái)?shù)據(jù)，定期分析AVIF在線運(yùn)行情況，找出可能的性能瓶頸和問(wèn)題點(diǎn)。
請(qǐng)求耗時(shí)：分析請(qǐng)求耗時(shí)的分布，找出請(qǐng)求較慢的原因，如網(wǎng)絡(luò)延遲、服務(wù)器處理能力不足等，進(jìn)行相應(yīng)優(yōu)化。
錯(cuò)誤率：觀察錯(cuò)誤類(lèi)型和分布，排查可能的故障原因，如圖片解碼失敗、服務(wù)器錯(cuò)誤等，并采取措施修復(fù)。
訪問(wèn)量：分析訪問(wèn)量的變化趨勢(shì)，預(yù)測(cè)系統(tǒng)的負(fù)載情況，提前做好資源擴(kuò)展和優(yōu)化準(zhǔn)備。
響應(yīng)包大?。罕O(jiān)控圖片大小分布，對(duì)于過(guò)大的圖片，分析原因并優(yōu)化壓縮算法，降低用戶的流量消耗。
根據(jù)監(jiān)控?cái)?shù)據(jù)和分析結(jié)果，不斷優(yōu)化AVIF的使用策略和性能表現(xiàn)，提高用戶體驗(yàn)。同時(shí)，將監(jiān)控指標(biāo)與業(yè)務(wù)指標(biāo)相結(jié)合，評(píng)估AVIF在實(shí)際業(yè)務(wù)場(chǎng)景中的效果，為后續(xù)優(yōu)化提供依據(jù)。
大盤(pán)帶寬
業(yè)務(wù)告警
3、帶寬收益
前期，我們?cè)?B 站移動(dòng)端完成視頻封面場(chǎng)景的全面 AVIF 化，回看 CDN 數(shù)據(jù)時(shí)，可以觀察到：在該場(chǎng)景下，AVIF 體積 / WebP 體積 ≈ 63%，每年為公司節(jié)約數(shù)百萬(wàn)的帶寬成本。后續(xù)進(jìn)一步推進(jìn) AVIF 覆蓋情況，預(yù)計(jì)可再節(jié)約每年數(shù)百萬(wàn)的 CDN 帶寬成本。
五、優(yōu)化與維護(hù)
1.推廣過(guò)程中遇到的問(wèn)題
a.在線資源池容量
在B站的多個(gè)自建 IDC 中，絕大多數(shù)容器化業(yè)務(wù)部署在 K8s 集群中，混部在同一套資源池里，由內(nèi)部容器平臺(tái)管理。然而，由于 AVIF 的資源占用顯著高于 WebP，在灰度上量的過(guò)程中，圖片服務(wù)占用的資源急劇增加，影響了整體資源池的水位安全。這對(duì)于即將到來(lái)的重要活動(dòng)，如跨晚等，可靠性產(chǎn)生了一定的影響。
為解決這一問(wèn)題，B站將 WebP 和 AVIF 任務(wù)拆分到了兩個(gè)不同的容器集群中。由于 AVIF 任務(wù)是離線任務(wù)且對(duì)可用性和延遲要求不高，因此每個(gè) AVIF 容器都被配置了一個(gè)極低的 CPU request和一個(gè)相對(duì)較高的CPU limit。這樣，在低峰期時(shí)，圖片服務(wù)能夠盡可能多地利用資源處理AVIF，而在高峰期時(shí)，圖片服務(wù)進(jìn)程的優(yōu)先級(jí)較低，從而減少對(duì)其他業(yè)務(wù)的影響。
通過(guò)這個(gè)策略，我們成功利用“白嫖”算力來(lái)滿足其目前規(guī)模下的AVIF處理需求。
b.負(fù)載不均導(dǎo)致利用率低
基于實(shí)例的任務(wù)分發(fā)策略導(dǎo)致容器負(fù)載不均，影響集群整體利用率的提升。AVIF 落地初期， B 站內(nèi)部容器平臺(tái)尚未普及 vCPU 和算力標(biāo)準(zhǔn)化，容器調(diào)度以核數(shù)為單位。由于不同物理機(jī)單核算力不同，同樣是 8 核的容器，在新硬件上的處理能力顯著強(qiáng)于舊硬件。受限于短板效應(yīng)，集群整體利用率不高。
注：關(guān)于大規(guī)模 K8s 集群算力標(biāo)準(zhǔn)化，可以期待 B 站即將公布的分享
為緩解這個(gè)問(wèn)題，我們?cè)陔x線集群上實(shí)驗(yàn)性開(kāi)啟了基于 P2C 算法的分發(fā)策略，針對(duì)圖片處理場(chǎng)景的特性，單機(jī) QPS 較低、請(qǐng)求耗時(shí)天然不均，做了一些調(diào)優(yōu)。效果如下圖，有一定收益，仍有較大優(yōu)化空間。
c.研發(fā)資源不足問(wèn)題
AVIF 圖像格式的開(kāi)發(fā)和推廣需要大量的技術(shù)和人力資源，特別是在進(jìn)行高級(jí)優(yōu)化和性能調(diào)優(yōu)時(shí)，需要具備深厚的圖像處理和算法知識(shí)。此外，開(kāi)發(fā)和維護(hù) AVIF 格式的軟件庫(kù)和工具也需要大量的資源投入。
圖像算法：AVIF 格式的設(shè)計(jì)和開(kāi)發(fā)需要涉及圖像算法和數(shù)據(jù)結(jié)構(gòu)的知識(shí)，例如色彩空間轉(zhuǎn)換、DCT 變換、預(yù)測(cè)編碼等。由于 AVIF 是一種較新的圖像格式，可能需要對(duì)這些算法進(jìn)行改進(jìn)和優(yōu)化，以提高圖像質(zhì)量和壓縮性能。
元數(shù)據(jù)處理：AVIF 格式包含了大量的元數(shù)據(jù)，例如色彩空間信息、色彩配置信息、ICC 配置文件等。處理這些元數(shù)據(jù)需要具備深入的圖像處理和計(jì)算機(jī)視覺(jué)知識(shí)，并且需要使用一些專(zhuān)門(mén)的庫(kù)和工具來(lái)處理和管理這些元數(shù)據(jù)。
內(nèi)存分配：
在解碼 AVIF 動(dòng)圖時(shí)，需要為每個(gè)幀分配足夠的內(nèi)存空間，以存儲(chǔ)解碼后的圖像數(shù)據(jù)。這可能需要大量的內(nèi)存，特別是在解碼高分辨率或高幀率的動(dòng)圖時(shí)，需要處理更多的圖像數(shù)據(jù)。為了避免內(nèi)存占用過(guò)高的問(wèn)題，需要進(jìn)行適當(dāng)?shù)膬?nèi)存分配和釋放，以確保內(nèi)存的合理使用。AVIF 動(dòng)態(tài)圖（動(dòng)圖）在移動(dòng)端的解碼問(wèn)題比在桌面端更為復(fù)雜和嚴(yán)重。這主要是因?yàn)橐苿?dòng)設(shè)備通常具有較低的計(jì)算資源和內(nèi)存限制，而解碼器剛剛支持動(dòng)圖，動(dòng)圖解碼對(duì)于內(nèi)存管理很差，移動(dòng)端上動(dòng)圖解碼的內(nèi)存占用是webp的7-10倍，完全無(wú)法接受的狀態(tài)。
緩存管理：
在解碼 AVIF 動(dòng)圖時(shí)，可以使用緩存技術(shù)來(lái)減少內(nèi)存占用和提高解碼性能。緩存可以在解碼后的圖像幀中存儲(chǔ)一定的圖像數(shù)據(jù)，并在下一幀解碼時(shí)重用這些數(shù)據(jù)，從而減少對(duì)內(nèi)存的需求。但是，緩存的大小和管理方式需要根據(jù)具體的場(chǎng)景和設(shè)備進(jìn)行優(yōu)化和調(diào)整，以確保緩存的效果和可靠性。
內(nèi)存釋放：
在解碼 AVIF 動(dòng)圖后，需要及時(shí)釋放內(nèi)存，以避免內(nèi)存泄漏和內(nèi)存占用過(guò)高的問(wèn)題。在釋放內(nèi)存時(shí)，需
六、展望
持續(xù)優(yōu)化與升級(jí)
隨著AVIF格式的普及，我們將持續(xù)關(guān)注相關(guān)技術(shù)進(jìn)展，對(duì)解碼器、編碼器進(jìn)行升級(jí)，以提高圖片加載速度、減少解碼成本。
跟進(jìn)不同平臺(tái)（如Android、iOS、Web等）的特性和限制，進(jìn)一步優(yōu)化圖片加載策略，提升用戶體驗(yàn)。
優(yōu)化緩存管理和內(nèi)存復(fù)用策略，提高系統(tǒng)資源利用率，降低內(nèi)存占用。
?拓展更多圖片應(yīng)用場(chǎng)景
除了當(dāng)前已實(shí)現(xiàn)的圖片加載場(chǎng)景，探索AVIF在更多業(yè)務(wù)場(chǎng)景（如廣告、社交分享等）的應(yīng)用，以實(shí)現(xiàn)更廣泛的性能優(yōu)化。
研究AVIF與其他圖片格式（如WebP、HEIC等）的混合使用策略，以實(shí)現(xiàn)最佳的圖片加載體驗(yàn)。
跨平臺(tái)解決方案研發(fā)
針對(duì)不同平臺(tái)，研發(fā)統(tǒng)一的圖片加載策略，簡(jiǎn)化業(yè)務(wù)接入成本，提高開(kāi)發(fā)效率。
深入研究移動(dòng)端硬件加速特性，探索利用GPU等硬件資源優(yōu)化圖片加載性能的可能性。
社區(qū)貢獻(xiàn)與標(biāo)準(zhǔn)制定
積極參與AVIF相關(guān)技術(shù)標(biāo)準(zhǔn)的討論與制定，推動(dòng)圖片加載技術(shù)的發(fā)展。
將在項(xiàng)目中積累的經(jīng)驗(yàn)和技術(shù)成果分享給開(kāi)源社區(qū)，推動(dòng)AVIF技術(shù)在業(yè)界的普及與應(yīng)用。
?硬件加速方案探索
在已有小流量驗(yàn)證基礎(chǔ)上，繼續(xù)嘗試落地 FPGA/VPU 等硬件編碼方案，加速服務(wù)端編碼效率，簡(jiǎn)化整體架構(gòu)。
通過(guò)以上展望，我們將持續(xù)優(yōu)化AVIF圖片格式的應(yīng)用效果，拓展其在更多場(chǎng)景的應(yīng)用，提升用戶體驗(yàn)。同時(shí)，我們將積極參與社區(qū)貢獻(xiàn)，推動(dòng)AVIF技術(shù)的發(fā)展與普及。
Q&A
AVIF加載時(shí)間沒(méi)劣化，但解碼成本更高應(yīng)該更耗電？有這方面數(shù)據(jù)么？
在 WWDC 2018 中，蘋(píng)果推出了一種新的耗電監(jiān)控工具 Energy Log。Energy Log 通過(guò)定期獲取當(dāng)前應(yīng)用的線程堆棧信息，并對(duì) CPU 占用率進(jìn)行監(jiān)控來(lái)識(shí)別可能存在的耗電問(wèn)題。當(dāng)應(yīng)用在前臺(tái)平均三分鐘或者后臺(tái)平均一分鐘內(nèi) CPU 占用超過(guò) 80% 時(shí)，系統(tǒng)會(huì)將收集到的線程堆棧信息組合成一顆函數(shù)調(diào)用樹(shù)形成 Energy Log。
經(jīng) Energy Log 的啟發(fā)，AVIF 耗電分析監(jiān)控，在應(yīng)用啟動(dòng)后開(kāi)啟一個(gè)檢測(cè)子線程，檢測(cè)線程會(huì)持續(xù)識(shí)別當(dāng)前應(yīng)用哪個(gè)線程的 CPU 占用過(guò)高，并將耗 CPU 多的線程的堆棧信息收集起來(lái)。當(dāng)應(yīng)用 CPU 占用達(dá)到閾值時(shí)，耗電監(jiān)控將收集到的堆棧信息組合形成耗電堆棧。在 iPhone 7 Plus 下測(cè)試，使用 backtrace() 獲得一個(gè)線程的堆棧平均耗時(shí)是 50 微秒，在實(shí)際應(yīng)用場(chǎng)景中，應(yīng)用 CPU 占用過(guò)高時(shí)，一般最多只有 5 個(gè)線程的 GPU 占用會(huì)超過(guò) 5%。在我們現(xiàn)有的ImageLoad結(jié)構(gòu)下，引入 AVIF 解碼幾乎不會(huì)帶來(lái)性能損耗。
針對(duì) AVIF 格式進(jìn)行了移動(dòng)端雙端的雙盲測(cè)試，測(cè)試結(jié)果顯示 AVIF 組對(duì)耗電量并沒(méi)有明顯增加。同時(shí)，也進(jìn)行了專(zhuān)項(xiàng)自動(dòng)化測(cè)試，包括內(nèi)存使用、CPU 占用率和平均 FPS 等指標(biāo)，結(jié)果也沒(méi)有明顯波動(dòng)。在用戶視覺(jué)體驗(yàn)方面，與其他格式的圖片相比，沒(méi)有明顯的降低。
參考
1.? What’s New in Energy Debugging - WWDC18 - Videos - Apple Developer（https://developer.apple.com/videos/play/wwdc2018/228/）
2.? ?Pixelmator Pro 3.1 adds support for macOS 13, AVIF images, introduces smooth corner style, and more - Pixelmator Blog.（https://www.pixelmator.com/blog/2022/11/02/pixelmator-pro-3-1-adds-support-for-macos-13-avif-images-introduces-smooth-corner-styles-and-more/）
3.? ?no display of .avif files with dAV1d decoder (#21568) · Issues · VideoLAN / VLC · GitLab. （https://code.videolan.org/videolan/vlc/-/issues/21568）GitLab. Retrieved 2021-10-08.
4.? Cimpanu, Catalin (2020-07-09). Chrome and Firefox are getting support for the new AVIF image format | ZDNET. （https://www.zdnet.com/article/chrome-and-firefox-are-getting-support-for-the-new-avif-image-format/）ZDNet. （https://en.wikipedia.org/wiki/ZDNet）Archived（https://web.archive.org/web/20200813185435/https://www.zdnet.com/article/chrome-and-firefox-are-getting-support-for-the-new-avif-image-format/） from the original on 13 August 2020.
5.? BOSS 實(shí)現(xiàn)相關(guān)介紹?https://www.bilibili.com/read/cv16653640丨https://www.bilibili.com/read/cv16703900
6.? Bilibili KV 系統(tǒng)實(shí)現(xiàn)?https://www.bilibili.com/read/cv15610515
