作者：陳忱
目前移動端營運素材大部分依賴圖檔，基于對圖檔流量更少，渲染速度更快的訴求，我們推動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的接入。
sharpP是騰訊公司SNG即通産品部音視訊技術中心推出的一種圖檔壓縮元件，現已支援iOS、Android、Windows、Linux四個平台。編碼壓縮率、編碼耗時、解碼耗時相比webP有明顯的優勢。
在原有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。
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緩存重新整理工具，支援一次清理所有緩存副本。
以上皆為項目推進中遇到的問題，未考慮周全可能就會影響功能，線上實施前得在測試結點充分驗證，結點部署要控制節奏，并且要有完善的線上監控機制，以及功能回退的能力。
1）為了提高接入效率，減少人工驗證步驟，我們開發了圖檔檢測監控工具，定時監控業務頁面圖檔在各OC結點傳回是否正常。原理：工具根據業務URL，抓取頁面内所有CDN域名的圖檔，随機抽取一部分OC結點，構造sharpP，webP，原圖3種請求，根據傳回的圖檔格式，大小對比驗證圖檔是否正常。
2）現網圖檔加載資料上報：為了監控更多使用者的圖檔加載真實資料，我們在業務中接入了圖檔加載上報元件，原理是利用X5核心收集的資源加載資訊，過濾出圖檔資訊，上報圖檔類型，傳回碼，加載耗時，網絡類型等。
上傳一張新圖檔，使用手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轉換工具也将疊代支援。
文章來源公衆号：小時光茶社（Tech Teahouse）
相關推薦
谷歌開源圖檔壓縮算法Guetzli實測體驗報告
借助騰訊雲CDN開啟全站https及問題解決分享