圖片流量節省大殺器：基於CDN的sharpP自適應圖片技術實踐

版權聲明：本文由陳忱原創文章，轉載請註明出處: 
文章原文連接：https://www.qcloud.com/community/article/156

來源：騰雲閣 https://www.qcloud.com/community

 

目前移動端運營素材大部分依賴圖片，基於對圖片流量更少，渲染速度更快的訴求，咱們推進CDN，X5內核，即通產品部共同推出了一套業務透明，無痛接入的CDN圖片優化方案：基於CDN的sharpP自適應圖片無痛接入方案。據統計效果可在原圖基礎上節省60%-75%的流量，比以前webP無痛接入方案效果提高40%-50%，減小流量的同時提升頁面渲染速度，提高用戶體驗。

效果數據

目前手Q增值業務：VIP中心、遊戲中心、動漫、遊戲公會、特別關心 以及增值渠道的QQ錢包，空間的個性化商城已經接入sharpP自適應，優化效果數據：

sharpP自適應方案在原有webP自適應方案效果提高40%-50%，提高效果主要來自sharpP高於webP的編碼壓縮率，同時能優化到webP沒法覆蓋的png圖片（備註：以前webP無痛方案只實現了jpg的支持），sharpP方案和原圖對比能夠節省60%-75%的流量。

以咱們的VIP中心爲例，以前webP方案：

上sharpP方案後

在圖片增長的狀況下 圖片流量減小了近100K，頁面速度也有提高，而且sharpP圖片的效果也通過設計同窗的驗證，肉眼幾乎沒法區分，圖片質量參數細節後面會介紹。

方案概述

利用自建CDN結點的緩存，以及帶請求頭的回源能力作到同一個URL根據終端分辨率，以及是否支持sharpP解碼，按需返回不一樣的原圖副本，作到圖片資源的最合理利用：
手Q X5內核支持sharpP圖片的解碼，請求圖片時會帶上accept: image/sharpp標識，User-Agent中會加上手機的分辨率Pixel參數，CDN節點收到請求後，先檢查若是有對應的sharpP自適應副本直接返回，若是沒有則將請求回源到CDN源站，源站會根據請求的User-Agent、Accept參數返回對應分辨率的sharpP圖片副本(原圖上傳後，或第一個用戶請求觸發CDN源站服務器圖片轉換，生成不一樣尺寸的sharpP圖片), 若是請求頭沒有sharpP標識，則按原有邏輯返回原圖，不影響業務。

整套優化方案接入對基於X5內核的H5業務徹底透明，無需改動代碼，便可讓頁面的圖片得到可觀的圖片專項優化效果；app業務接入，音視頻有提供sharpP解碼的sdk的接入。

方案詳解

1.何爲sharpP

sharpP是騰訊公司SNG即通產品部音視頻技術中心推出的一種圖片壓縮組件，現已支持iOS、Android、Windows、Linux四個平臺。編碼壓縮率、編碼耗時、解碼耗時相比webP有明顯的優點。

2.CDN sharpP方案

在原有webP自適應無痛方案基礎上，咱們聯合終端、CDN進一步升級優化，作了以下優化改造：
終端支持：增值業務大部分是基於手Q webview的hybird應用，安卓平臺基於X5內核，X5內核於2.1.1版本開始引入了sharpP組件，支持sharpP解碼，並約定支持sharpP的版本發起的請求會在http請求的頭部帶上Accept: image/sharpp字段，同時X5內核UA中會帶上終端分辨率Pixel字段,iOS平臺因爲系統對webview內核的限制，暫時沒法很好的嵌入sharpP組件，未能支持sharpP解碼。將來能夠在原生app引入sharpP組件，原生請求帶上Accept:image/sharpp，就可使用到CDN的sharpP能力。

CDN側改造：CDN源站轉換工具集成了sharpP組件，CDN的OC結點新增支持 sharpP副本的緩存，總體流程大體以下：

客戶端發起請求後，OC結點根據請求UA檢查Accept字段是否帶有image/sharpp，並獲取Pixel分辨率信息，OC結點判斷是否有知足要求的原圖副本緩存，沒有緩存則將URL+請求頭回源，源站識別請求頭中的信息，返回圖片對應的sharpP副本，OC結點緩存下來。源站圖片若是未轉換完成(圖片上傳後或第一次請求觸發CDN源站異步轉換)，源站會先返回原圖,max-age=10,讓OC結點暫時不緩存，再次請求時，判斷轉換完成才返回sharpP圖片並設置默認的緩存時間max-age=25920000。目前CDN sharpP已支持了咱們BGtop5流量的域名：

imgcache.gtimg.cn、i.gtimg.cn、imgcache.qq.com、qzonestyle.gtimg.cn、qzs.qq.com

總體方案：結合以前咱們作的自適應、webP方案，與sharpP能夠徹底兼容，在CDN源站是3項單獨的配置，能夠按需配合或單獨使用，總體方案以下圖

優先判斷是否有自適應，而後檢查sharpP，若是sharpP和webP都支持優先返回sharpP。

3.項目中踩過的坑

1）運營商內容劫持，因爲同一個URL可能返回不一樣的內容(不一樣分辨率的sharpP/原圖) 線上觀察發現聯通運營商會在請求到咱們自建CDN結點以前加一層緩存，默認會按URL來緩存內容，其實就是內容劫持，致使不一樣請求頭，返回錯亂與咱們指望的不一致，後面找到一種解決方法，基於http協議的vary字段，CDN源站以及CDN結點返回內容的時候帶上 Vary：User-Agent，Accept 字段，告訴運營商的緩存服務器根據請求的Accept+User-Agent+Url來緩存內容，經驗證能夠解決問題。
2）質量參數設置，儘量保證圖片壓縮的更小，效果與原圖差距不大
sharpP採用有損壓縮，轉換工具會讀取原圖質量參數，適當下降：若是原圖質量參數低於75則保持原質量參數直接轉sharpP，若是質量參數高於75，則在原圖基礎上下降一些質量參數，根據業務要求自行設置，目前根據觀察質量參數不低於75的sharpP圖片基本肉眼沒法區分。
3）新的業務開啓sharpP自適應，源站圖片轉換致使磁盤IO壓力過大
用腳本凌晨閒時對存量圖片預轉換生成各尺寸的副本；轉換工具監聽圖片目錄的新增文件，用戶上傳後就作轉換；轉換腳本作了優化，只有第一次請求觸發轉換。
4）sharpP轉換工具對某些圖片轉換失敗，生成空文件
捕獲轉換失敗錯誤碼，空文件用原圖替換，避免返回給結點空文件
5）有時候業務圖片須要強制使用原圖
支持nosharpp參數，url帶上參數後，CDN強制返回原圖。
6）圖片緩存清理
因爲一 個圖片URL，對應了多份CDN結點緩存副本，若是圖片更新的時候，可能有個別副本緩存刷新不及時，致使不一樣分辨率、sharpP、原圖的用戶看到的圖片不一致，須要優化CDN緩存刷新工具，支持一次清理全部緩存副本。
以上皆爲項目推動中遇到的問題，未考慮周全可能就會影響功能，線上實施前得在測試結點充分驗證，結點部署要控制節奏，而且要有完善的線上監控機制，以及功能回退的能力。

4.圖片檢測監控

1）爲了提升接入效率，減小人工驗證步驟，咱們開發了圖片檢測監控工具，定時監控業務頁面圖片在各OC結點返回是否正常。原理：工具根據業務URL，抓取頁面內全部CDN域名的圖片，隨機抽取一部分OC結點，構造sharpP，webP，原圖3種請求，根據返回的圖片格式，大小對比驗證圖片是否正常。

2）現網圖片加載數據上報：爲了監控更多用戶的圖片加載真實數據，咱們在業務中接入了圖片加載上報組件，原理是利用X5內核收集的資源加載信息，過濾出圖片信息，上報圖片類型，返回碼，加載耗時，網絡類型等。

5.sharpP開啓驗證

上傳一張新圖片，使用手Q安卓版本訪問已支持sharpP域名的CDN圖片，若是請求帶了Accept:image/sharpp，檢查返回圖片格式是否爲sharpP

若是舊的圖片未按預期返回，返回了webP或原圖多是OC結點緩存，正常3天后過時回源則會返回sharpP圖片。

將來規劃

1）app業務接入sharpP優化方案目前只有安卓平臺基於X5內核的應用能獲得這套CDN sharpP方案的優化效果，根據CDN日誌的流量統計BG內最大的流量仍是來自終端發起的請求，後續咱們計劃聯合CDN大流量的終端業務接入sharpP解碼組件，讓這套方案能給更多業務帶來收益，同時也爲公司和用戶節省流量成本。 2）sharpP工具優化 sharpP組件在不斷優化，包括轉碼效率、成功率，gif格式支持等，CDN轉換工具也將迭代支持。