1.  SDK簡(jiǎn)介

圖片在業(yè)務(wù)應(yīng)用場(chǎng)景是一個(gè)常見的元素，veImageX（簡(jiǎn)稱ImageX）為業(yè)務(wù)提供了靈活、高效的一站式圖片處理解決方案，包括了服務(wù)端 SDK、上傳 SDK 和客戶端圖片加載 SDK。

1.1 業(yè)內(nèi)主流開源圖片加載 SDK

在介紹 veImageX 圖片加載 SDK 之前先看看業(yè)內(nèi)目前有哪些主流的圖片加載 SDK，veImageX 圖片加載 SDK 是使用 Objective-C 語言開發(fā)的，業(yè)內(nèi)使用 Objective-C 語言實(shí)現(xiàn)的主流開源圖片加載 SDK 有 YYWebImage，SDWebImage 等

• YYWebImage：一個(gè)異步圖片加載框架（YYKit 的一個(gè)組件）。它是作為 SDWebImage、PINRemoteImage 和 FLAnimatedImage 的改進(jìn)替代品而創(chuàng)建的。它使用 YYCache 支持內(nèi)存和磁盤緩存，使用 YYImage 支持 WebP/APNG/GIF 圖片解碼，但可惜的是此優(yōu)秀的框架于 2017 年左右已停止更新；
• SDWebImage：目前使用較廣泛的一個(gè)圖片處理框架，可以異步加載網(wǎng)絡(luò)圖片，并支持圖片本地緩存等特性，也是一款優(yōu)秀的圖片加載框架。

1.2 veImaegX 的 SDK 優(yōu)勢(shì)

veImageX 圖片加載 SDK 也是借鑒各家之所長(zhǎng)，基于一些業(yè)務(wù)實(shí)際線上應(yīng)用的屬性自研了一套圖片加載 SDK，相比于這些開源圖片加載 SDK，主要有以下特性：

• 采用分層與模塊化架構(gòu)設(shè)計(jì)，根據(jù)業(yè)務(wù)需要選擇相應(yīng)功能模塊，最大程度精簡(jiǎn)包大?。?/li>
• 支持 WebP、AVIF、HEIF 這種高壓縮率圖片格式，特別是在自研的高性能HEIF軟件解碼庫支持下，能夠高效解碼 HEIF 格式，并擺脫 HEIF 原生 iOS 系統(tǒng)版本的限制；
• 支持云端加密、客戶端解密，保障圖片隱私安全；
• SDK 的網(wǎng)絡(luò)庫支持 HTTPDNS，可以高效防止內(nèi)容劫持及域名劫持，能夠有效降低圖片解碼失敗率，提升客戶端圖片加載體驗(yàn)；
• 支持采集各項(xiàng)圖片相關(guān)數(shù)據(jù)并上報(bào)，配合 veImageX 控制臺(tái)實(shí)時(shí)大盤數(shù)據(jù)查看，可以為業(yè)務(wù)的運(yùn)營及產(chǎn)品的體驗(yàn)提升提供全面的從數(shù)據(jù)發(fā)現(xiàn)、數(shù)據(jù)分析、數(shù)據(jù)監(jiān)控、數(shù)據(jù)診斷、數(shù)據(jù)追蹤等全鏈路支持。

2.  SDK 架構(gòu)

隨著時(shí)間的推移，SDK 的功能越來越多，各種業(yè)務(wù)對(duì) SDK 的功能選擇也開始多樣化起來，特別是在 App 包體積日益增長(zhǎng)需要降低的大背景下，SDK 也需要做包體積瘦身，面對(duì)以上種種問題，SDK 對(duì)功能的模塊化/插件化能力的要求也越來越高，SDK 的架構(gòu)也就隨之演變成下圖的樣子。

SDK 主要分為三層

• 接口層，也是最上層，這一層提供圖片加載與處理的各種接口，接口設(shè)計(jì)與主流開源圖片加載 SDK 保持一致，在這一層提供適配器，提供了開源圖片加載 SDK（如 YYWebImage，SDWebImage 等）的適配層，方便業(yè)務(wù)快速上手與無縫切換；
• 管理層，作為中間層負(fù)責(zé)各種模塊的交互管理，也包括云控配置管理和授權(quán)管理等；
• 模塊層，這一層包含了圖片加載流程的各個(gè)模塊：下載模塊，緩存模塊，解碼模塊，日志上報(bào)模塊等，業(yè)務(wù)可以根據(jù)自身需求來選擇性依賴這些模塊的各種功能，達(dá)到最小化依賴的原則。

3.  UIImageView 如何通過 SDK 渲染出一張網(wǎng)絡(luò)圖片

業(yè)務(wù)上圖片的主流應(yīng)用場(chǎng)景就是加載網(wǎng)絡(luò)圖片，以 iOS 原生系統(tǒng)控件 UIImageView 為例，通過 SDK 加載一張網(wǎng)絡(luò)圖片的完整流程如下：

發(fā)起圖片請(qǐng)求 -> 查詢內(nèi)存緩存 -> 查詢磁盤緩存 -> 加入下載隊(duì)列 -> 開始下載 -> 獲取到服務(wù)端圖片未解碼數(shù)據(jù) -> 從圖片未解碼數(shù)據(jù)中解碼后得到可以渲染的圖片 -> 將解碼后的圖片和圖片未解碼數(shù)據(jù)分別緩存進(jìn)內(nèi)存和磁盤 -> UIImageView 渲染解碼后的圖片，至此，一張網(wǎng)絡(luò)圖片被成功加載并展示給用戶。

4.  SDK 模塊介紹

在了解完 SDK 的主流場(chǎng)景中網(wǎng)絡(luò)圖片的完整加載流程后，下面分別介紹一下 SDK 加載流程中的下載、緩存、解碼、日志上報(bào)與圖片后處理這五大主要模塊。

4.1 下載模塊

下載模塊的主要任務(wù)是通過網(wǎng)絡(luò)庫把網(wǎng)絡(luò)圖片從服務(wù)端下載到客戶端，這個(gè)過程對(duì)圖片加載來講是非常重要的一環(huán)，下載的成功與否直接決定了圖片能否正確展示，而網(wǎng)絡(luò)庫的性能也決定了圖片下載的快慢，最終反映到用戶的感受體驗(yàn)上。所以，下載模塊中的下載任務(wù)除了支持蘋果原生系統(tǒng)的網(wǎng)絡(luò)庫實(shí)現(xiàn)外，也支持字節(jié)內(nèi)部強(qiáng)大的自研網(wǎng)絡(luò)庫 TTNetwork 實(shí)現(xiàn)，該庫不僅做了一些網(wǎng)絡(luò)相關(guān)優(yōu)化，例如 HTTPDNS，HTTP2+HTTPS 連接復(fù)用優(yōu)化、鏈路選擇、動(dòng)態(tài)策略等，支持最新的網(wǎng)絡(luò)協(xié)議 QUIC，也提供了更為細(xì)粒度的網(wǎng)絡(luò)監(jiān)控，為 SDK 的圖片下載提供了高效的支持。SDK 默認(rèn)支持原生網(wǎng)絡(luò)庫與自研網(wǎng)絡(luò)庫，如果業(yè)務(wù)有自己的網(wǎng)絡(luò)庫，也可以通過插件化的形式集成進(jìn)來。

業(yè)務(wù)上一般會(huì)并發(fā)下載多張圖片，在 Feed 流場(chǎng)景中如果用戶來回滑動(dòng)圖片，同樣的圖片會(huì)發(fā)生多次請(qǐng)求，如果相同圖片的多個(gè)請(qǐng)求都去反復(fù)下載圖片，這樣顯然會(huì)浪費(fèi)用戶流量，也會(huì)增加帶寬成本。SDK 會(huì)管理這些并發(fā)的下載任務(wù)，并標(biāo)記相同的圖片請(qǐng)求，避免這種問題的發(fā)生。下載任務(wù)的管理與調(diào)度通過 iOS 系統(tǒng)原生的 NSOperation 與 NSOperationQueue 實(shí)現(xiàn)，同時(shí)會(huì)根據(jù)請(qǐng)求參數(shù)生成一個(gè) Identifier，用來唯一標(biāo)識(shí)一個(gè)下載任務(wù)，交由下載管理器去管理，這樣就能避免在同一個(gè)時(shí)間段內(nèi)重復(fù)多次下載相同的圖片。

4.2 緩存模塊

緩存模塊由內(nèi)存和磁盤共同組成一個(gè)二級(jí)緩存結(jié)構(gòu)，當(dāng)一張圖片被下載到客戶端上時(shí)，會(huì)被緩存進(jìn)內(nèi)存和磁盤緩存，如果 App 生命周期內(nèi)再請(qǐng)求這張圖片，則可以從內(nèi)存緩存中查到，如果冷啟動(dòng) App 后再請(qǐng)求這張圖片，則可以從磁盤緩存中查到。這樣不僅可以加快圖片的加載速度，提升用戶體驗(yàn)，也可以降低用戶流量，節(jié)省帶寬成本。再對(duì)緩存加上過期時(shí)間限制，就可以解決圖片的時(shí)效性問題。

內(nèi)存緩存方面除了支持 iOS 原生的 NSCache 外，還支持 Strong-Weak 的弱引用緩存，當(dāng)緩存對(duì)象無人持有時(shí)會(huì)被及時(shí)釋放掉，降低內(nèi)存占用，同時(shí)也支持 LRU 緩存。在收到內(nèi)存不足的通知時(shí)會(huì)主動(dòng)釋放內(nèi)存，緩解內(nèi)存壓力，同時(shí)保證線程安全。磁盤緩存方面除了支持最基本的 iOS 系統(tǒng)文件管理 NSFileManager，還支持 LRU 緩存，同時(shí)保證線程安全。

整體看，如果 App 內(nèi)只使用同一種固定的緩存算法的話，由于圖片使用場(chǎng)景各不相同，同一種緩存算法無法滿足所有場(chǎng)景，緩存命中率就會(huì)偏低。除了 SDK 默認(rèn)支持的緩存算法外，由于內(nèi)存和磁盤緩存都是由協(xié)議定義的，業(yè)務(wù)也可以根據(jù)需求去自定義緩存，在不同場(chǎng)景下使用不同的緩存算法，這樣可以極大的提高緩存命中率。在一些業(yè)務(wù)特定場(chǎng)景上 SDK 的緩存命中率能夠達(dá)到 80% 左右，隨著緩存命中率的提升，帶來的帶寬成本節(jié)省收益也越大。

4.3 解碼模塊

圖片下載到客戶端上后都是未經(jīng)過解碼前的數(shù)據(jù)，想要把圖片正確展示給用戶，就必須對(duì)它進(jìn)行解碼。圖片解碼上支持通過 iOS 原生系統(tǒng)的解碼框架 ImageIO 進(jìn)行解碼，即蘋果原生能支持的格式，SDK 也能支持。除此之外，像 WebP、AVIF、VVIC（字節(jié)基于 BVC 算法自研的圖片格式）等原生不支持的圖片格式，SDK 通過自研解碼器或者開源解碼器的支持，也都能解碼這些格式的圖片。當(dāng)有新格式的圖片要支持時(shí)，只需實(shí)現(xiàn)對(duì)應(yīng)格式的動(dòng)靜圖協(xié)議就能以插件化的形式集成進(jìn) SDK，達(dá)到支持新格式圖片的目的。

4.3.1 SDK 特色能力：iOS 全系統(tǒng)支持 HEIF

HEIF 這種高壓縮率格式的圖片在字節(jié)跳動(dòng)公司內(nèi)部的應(yīng)用已經(jīng)比較成熟了。帶寬節(jié)省方面，相比 WebP，在同質(zhì)量下還能再節(jié)約 30% 的帶寬成本，為公司節(jié)省了大量的帶寬成本。加載優(yōu)化方面，HEIF 支持漸進(jìn)式加載，可以先加載 HEIF 縮略圖，再加載 HEIF 原圖，在網(wǎng)絡(luò)質(zhì)量不好的場(chǎng)景下也能有不錯(cuò)的圖片加載體驗(yàn)。SDK 有了公司內(nèi)部自研的高性能 HEIF 軟件解碼庫的支持，讓 HEIF 格式圖片的解碼支持?jǐn)[脫了 iOS 系統(tǒng)的限制，不再局限在 iOS 11 及以上才能使用 HEIF 靜圖，iOS 13 及以上才能使用 HEIF 動(dòng)圖，在低版本 iOS 上也能支持 HEIF 動(dòng)靜圖，極大的提升了 HEIF 的應(yīng)用范圍，收獲了大量的帶寬成本節(jié)省收益。

4.4 圖片后處理模塊

在圖片加載完后，業(yè)務(wù)也可以根據(jù)需要再次對(duì)圖片進(jìn)行各種實(shí)時(shí)轉(zhuǎn)換，比如說加圓角、超分等，這些都是通過圖片后處理來完成。下面介紹下 SDK 的一個(gè)特色能力：超分。

4.4.1 SDK 特色能力：超分

超分，即超分辨率，指的是基于機(jī)器學(xué)習(xí)/深度學(xué)習(xí)方法，從給定的低分辨率圖片中恢復(fù)高分辨率的圖片，借助圖片后處理，可以在移動(dòng)端上做到圖片實(shí)時(shí)超分。

一般可以用于兩種場(chǎng)景，一是用于提升用戶體驗(yàn)，當(dāng)原圖片分辨率低、清晰度低時(shí)，對(duì)其進(jìn)行超分后，可以用來提升清晰度，以達(dá)到提升用戶觀看體驗(yàn)的目的；二是用于降檔超分，用戶在請(qǐng)求高分辨率的圖片時(shí)，可以在傳輸過程中降低圖片的分辨率，然后在客戶端上進(jìn)行超分，提升到原請(qǐng)求的分辨率，以達(dá)到節(jié)省帶寬成本的目的。

4.5 日志上報(bào)模塊

SDK 包含了三大日志模塊，圖片性能日志、用戶感知日志，大圖監(jiān)控日志，為業(yè)務(wù)的運(yùn)營及產(chǎn)品的體驗(yàn)提升提供了全面的數(shù)據(jù)支持。配合火山引擎 veImageX 的控制臺(tái)，可以實(shí)時(shí)查看各項(xiàng)可視化大盤數(shù)據(jù)，全方位的監(jiān)控圖片的各項(xiàng)指標(biāo)。

其中，圖片性能日志包括了圖片 URL、下載耗時(shí)、解碼耗時(shí)、錯(cuò)誤碼、圖片來源等數(shù)據(jù)，用來監(jiān)控圖片各項(xiàng)性能指標(biāo)；用戶感知日志包括了圖片 URL、ImageView 的 Size、ImageView 展示圖片耗時(shí)等數(shù)據(jù)，用來監(jiān)控用戶體驗(yàn)各項(xiàng)指標(biāo)；大圖監(jiān)控日志則包含了大圖 URL、內(nèi)存占用大小、圖片文件體積、圖片分辨率大小等數(shù)據(jù)，可以全面的監(jiān)控異常大圖情況。

5.  演進(jìn):性能優(yōu)化

SDK 致力于極致的圖片加載用戶體驗(yàn)，為此，SDK 做了很多相關(guān)性能優(yōu)化，下面主要介紹下 SDK 如何提升圖片加載體驗(yàn)、降低內(nèi)存占用、優(yōu)化動(dòng)圖播放。

5.1 提升圖片加載體驗(yàn)

圖片加載的快慢直接影響到用戶的使用體驗(yàn)，高效的圖片加載是 SDK 不可或缺的能力。

• 漸進(jìn)式加載

加載靜圖大圖，或者加載多幀數(shù)動(dòng)圖，亦或者在弱網(wǎng)場(chǎng)景下，都可以開啟圖片漸進(jìn)式加載來提升圖片的加載體驗(yàn)。

SDK 支持傳統(tǒng)的 PNG、JPEG 靜圖漸進(jìn)式加載，也支持HEIF靜圖漸進(jìn)式加載，先加載 HEIF 縮略圖，再加載HEIF原圖。SDK 同時(shí)也支持動(dòng)圖的漸進(jìn)式加載，動(dòng)圖可以邊下載邊播放，在正常網(wǎng)絡(luò)下，可以提高首幀的加載速度，在弱網(wǎng)下，類似于視頻播放的緩沖機(jī)制，也可以提升動(dòng)圖的播放體驗(yàn)。

• Force Decode

在圖片解碼方面，SDK 支持 Force Decode，能夠提前把 Bitmap Buffer 轉(zhuǎn)移到渲染進(jìn)程，減少了未來渲染時(shí)再去拷貝的耗時(shí)，如果原始解碼出來的 Bitmap Buffer，iOS 硬件屏幕不直接支持，會(huì)提前轉(zhuǎn)換好，避免渲染時(shí)在主線程的轉(zhuǎn)換開銷，提高圖片的加載幀率。

5.2 優(yōu)雅的內(nèi)存控制

通常情況下，App 內(nèi)圖片的場(chǎng)景還是很多的，當(dāng)加載大量圖片時(shí)，圖片所占的內(nèi)存可能會(huì)很大，如果內(nèi)存占用過高，會(huì)帶來 OOM 問題，給用戶的感受跟 Crash 一樣，都是應(yīng)用突然閃退。

SDK 有如下的幾種方案來降低圖片內(nèi)存占用：

• 釋放內(nèi)存緩存

當(dāng)系統(tǒng)內(nèi)存緊張，收到內(nèi)存不足通知時(shí)，緩存模塊會(huì)及時(shí)釋放內(nèi)存緩存，同時(shí)也提供接口，由業(yè)務(wù)在適當(dāng)時(shí)機(jī)主動(dòng)釋放內(nèi)存緩存。

• 全局圖片降采樣

圖片在內(nèi)存中的占用大小可以簡(jiǎn)單用如下公式來估算：

memoryCost（單位：字節(jié)）= imageWidth（單位：像素）* imageHeight（單位：像素）* 4

由公式可以看出，如果想要降低內(nèi)存，那么就要想辦法在不影響功能和體驗(yàn)的前提下盡量降低圖片的寬高，由此，當(dāng)不能明確下載后的圖片大小是否會(huì)遠(yuǎn)大于需要展示的 ImageView 的大小時(shí)，可以使用全局圖片降采樣功能。全局圖片降采樣分為以尺寸大小限制進(jìn)行降采樣和以內(nèi)存大小限制進(jìn)行降采樣。

以尺寸大小限制進(jìn)行降采樣：

如果當(dāng)前圖片的長(zhǎng)寬都大于降采樣的長(zhǎng)寬，那么把原圖片長(zhǎng)寬等比例縮放到恰好能貼到降采樣尺寸的輪廓

以內(nèi)存大小限制進(jìn)行降采樣：

如果當(dāng)前圖片的內(nèi)存占用超過內(nèi)存限制，那么把原圖片長(zhǎng)寬等比例縮放到恰好低于內(nèi)存限額

• 禁止圖片渲染

每次需要渲染前，都會(huì)給業(yè)務(wù)回調(diào)當(dāng)前圖片的元信息，例如圖片的長(zhǎng)寬尺寸、動(dòng)圖的幀數(shù)、以及預(yù)估的內(nèi)存消耗量，業(yè)務(wù)可以根據(jù)此信息來禁止不符合預(yù)期的超大圖渲染。

• 大圖監(jiān)控

實(shí)際業(yè)務(wù)場(chǎng)景中，待展示圖片的分辨率和幀數(shù)都是未知的。在一些極端情況下（線上真實(shí)案例），某個(gè)動(dòng)圖分辨率是 1080p、幀數(shù)上百幀，是用戶錄屏生成的，是個(gè)超大的動(dòng)圖，解碼后有超過 1 個(gè) GB的內(nèi)存占用，在一些低端機(jī)上就直接 OOM了。對(duì)于這類 OOM 情況，很難根據(jù)常規(guī)方法排查。那怎么有效監(jiān)控這種不符合預(yù)期的線上大圖呢，SDK 通過圖片展示尺寸，圖片解碼后內(nèi)存占用大小和圖片文件體積這三個(gè)維度來定義一個(gè)大圖，當(dāng)一張圖片觸發(fā)這三個(gè)維度中任意一個(gè)維度的閾值限制時(shí)，就會(huì)被記錄到大圖監(jiān)控日志內(nèi)，這些數(shù)據(jù)后續(xù)會(huì)被上報(bào)。業(yè)務(wù)通過 veImageX 控制臺(tái)就可以看到大圖監(jiān)控這個(gè)指標(biāo)下的詳細(xì)數(shù)據(jù)，當(dāng)發(fā)現(xiàn)內(nèi)存占用大小這個(gè)值異常大后，就可以及時(shí)查到相應(yīng)的圖片 URL，然后結(jié)合實(shí)際業(yè)務(wù)場(chǎng)景，及時(shí)下線這種不符合預(yù)期的超大圖，降低線上 OOM 率。

5.3 動(dòng)圖播放的優(yōu)化

動(dòng)圖在業(yè)務(wù)上也是一個(gè)常見應(yīng)用場(chǎng)景，如果能做好動(dòng)圖的優(yōu)化，也可以帶來用戶體驗(yàn)的提升。動(dòng)圖在播放時(shí)，會(huì)不斷解碼每一幀圖片，這時(shí)會(huì)大量消耗 CPU 資源，SDK 內(nèi)部會(huì)計(jì)算當(dāng)前可用的內(nèi)存以及渲染動(dòng)圖的所有幀需要的內(nèi)存，如果當(dāng)前可用內(nèi)存滿足渲染動(dòng)圖所有幀需要的內(nèi)存時(shí)，SDK 會(huì)緩存動(dòng)圖的所有幀，以此來節(jié)省 CPU 資源，如果當(dāng)前可用內(nèi)存不滿足渲染動(dòng)圖所有幀需要的內(nèi)存時(shí)，SDK 會(huì)在每一幀圖片播放結(jié)束之后舍棄前一幀，也就是不斷重復(fù)渲染下一幀圖片，通過消耗 CPU 資源節(jié)約內(nèi)存，達(dá)到 CPU 消耗與內(nèi)存節(jié)省的一個(gè)平衡。

6.  寫在最后

業(yè)內(nèi)雖然已經(jīng)有很多很成熟的圖片加載 SDK 了，但要契合公司自己業(yè)務(wù)發(fā)展的 SDK 也很重要，圖片加載 SDK 作為 veImageX 整體產(chǎn)品端到端不可或缺的一環(huán)，也是在這種背景下應(yīng)運(yùn)而生了。除了一些性能優(yōu)化外，在成本節(jié)省上，HEIF 格式的應(yīng)用為公司節(jié)省了大量帶寬成本，收益非?？捎^，并且也在持續(xù)嘗試新的壓縮率更高的圖片格式，例如 VVIC。在前沿能力應(yīng)用上，隨著圖片超分算法的不斷迭代優(yōu)化，相信在未來也能帶來不錯(cuò)的體驗(yàn)上的提升和成本上的節(jié)省。