作者：京東零售 何驍
介紹
京喜APP早期開發主要是快速原生化迭代替代原有H5，提高用戶體驗，在這期間也積累了不少性能問題。之後我們開始進行一些性能優化相關的工作，本文主要是介紹京喜圖片庫相關優化策略以及關於圖片相關的一些關聯知識。
圖片性能問題
作爲電商APP，圖片在各個業務場景被大量使用。我們需要做到儘可能降低網絡消耗/內存消耗/硬盤消耗，同時不降低圖片質量，提高圖片加載速度，給用戶帶來更好的使用體驗。基於這些性能目標，我們也通過初步性能評估梳理出了一些性能問題：
圖片加載慢/流量消耗高
圖片鏈接主要由後臺接口下發，下發圖片格式和尺寸由每個業務後臺指定。部分業務沒有使用更小的圖片格式比如WebP，或圖片尺寸過大，都會使圖片過大導致網絡消耗高。特別是網絡狀況不佳的場景，圖片加載過慢給用戶帶來不好的體驗。同時也會導致更多的I/O讀寫和解碼耗時，造成更多的電量消耗。
圖片內存佔用高
經過初步的APP內存使用評估，圖片內存消耗佔APP總內存消耗的比例最高，特別是大尺寸圖片會佔用很多內存。一方面APP佔用太高內存退到後臺容易被系統殺死，導致下次打開重新啓動影響體驗。另一方面APP大量使用內存，容易被系統殺死產生OOM。特別是我們目前有大量的低端設備用戶，設備內存相對比較低。
優化方向
基於上面分析出的一些性能問題，我們對圖片框架進行了整體重構優化。一方面是降低圖片網絡傳輸，提高圖片加載速度。另一方面是減少圖片內存消耗。
最小化網絡傳輸
京東圖片服務器提供了多種處理功能，例如圖片格式轉換，圖片降質，圖片縮放，圖片圓角等功能。這些功能通過在圖片URL中添加特定參數實現，圖片服務器會根據參數設置提前將圖片處理完成並保存到CDN服務器。我們可以通過添加圖片處理參數，減少圖片傳輸大小。
雖然後臺可以提前進行URL預處理，下發已添加過圖片參數的圖片URL。但是由於對接後臺業務很多，每個業務圖片參數設置差異很大無法統一，而且可能會造成性能影響，例如沒有使用webP圖片格式，下發太大的圖片尺寸。同時考慮到推動各業務後臺修改成本也很高，並且前端機型多，不同機型需要使用不同的圖片尺寸。另外也不方便灰度降級功能，後續功能修改也不方便。所以在客戶端進行圖片URL預處理是更好的方式，可以統一控制，也方便之後功能更新。
圖片URL預處理
圖片庫在網絡圖片加載前，檢測是否是京東域名的圖片URL。如果域名匹配，圖片框架先對圖片URL進行預處理，預處理包括域名統一，添加縮放參數，添加webP參數，添加降質參數的方式減少圖片網絡傳輸大小。
提示：因爲後臺返回的圖片
URL可能會帶有一部分圖片處理參數，例如https://img11.360buyimg.com/img/pingou-head/25.jpg!webp，直接追加圖片參數可能會導致圖片處理參數不生效，或格式錯誤導致加載失敗。所以轉換時會先將所有圖片參數提前計算出來，之後一起處理，避免添加重複參數。
域名統一
目前圖片服務器提供了多個圖片域名可使用，例如m.360buyimg.com，img10.360buyimg.com等多個域名。m.360buyimg.com主要提供給移動端使用。但是由於對接了各種業務後臺，導致接口會下發不同的域名圖片。圖片使用不同域名可能會導致以下問題：
不利於緩存複用- 圖片框架通常默認以URL字符串生成圖片緩存key，不同域名導致生成不同的緩存key。硬盤緩存無法複用會導致圖片重複下載，內存緩存無法複用導致同樣的圖片佔用多份內存。不利於HTTP/2連接複用- 大部分界面圖片比較多，很多場景都會同時加載多張圖片，特別是首屏通常會加載幾十張圖片。當加載多個圖片時，每個域名都需要重新建立HTTPS連接，經歷DNS解析/TCP連接/TLS握手過程（目前一次HTTPS請求創建過程大概耗時50-150ms）。如果利用HTTP/2鏈接複用就只需要創建一次HTTPS請求，之後的圖片請求可以減少這部分的耗時。
所以在預處理時，如果是京東域名的圖片，將圖片URL域名統一替換爲m.360buyimg.com。
追加圖片參數
圖片縮放
很多業務後臺返回的原始圖片URL的size都比客戶端實際顯示的size要大。一方面導致使用更多的網絡流量造成浪費。另一方面會導致佔用更多內存。同時因爲圖片size和實際顯示size不一致導致像素不對齊，GPU需要做額外的插值處理，也會一定的影響渲染性能。所以我們通過添加縮放參數的方式，指定圖片服務器下發更小和更匹配實際顯示size的圖片尺寸。
動態scale計算尺寸
因爲iOS設備主要使用2x/3x的分辨率，所以業務方使用API時需要傳入對應的ptsize大小，圖片庫內部根據設備的scale進行動態計算出真實的像素寬高。
提示：
android設備因爲屏幕差異比較大，更適合使用固定的scale。太多的圖片尺寸不利於CDN緩存，無緩存的時候需要對圖片進行相關參數處理，圖片處理本身是耗時操作。
Scale降級
低端機降級- 對於部分3xscale的低端設備，因爲機器本身內存比較低，使用3x分辨率計算出來的圖片像素寬高比較大，會造成更多的內存消耗以及解碼/渲染更多的性能消耗。所以對於寬高超過一定要求的圖片，降級到使用2x分辨率來計算像素寬高，減少設備性能消耗。iPad降級- 因爲目前APP並沒有針對iPad做特定優化，所以iPad設備下默認是放大顯示。這會導致在iPad下圖片尺寸計算出來特別大。所以也是針對iPad圖片尺寸做了特定限制，防止下發圖片尺寸過大。大圖片降級- 正常情況下圖片寬/高不應該超過屏幕寬/高。爲了防止部分業務使用過大的圖片size，所以添加了一個限制，最終生成的圖片像素尺寸不能超過屏幕寬/高。
降質
圖片服務器支持0-100的圖片質量參數設置，通過降低圖片質量可以減少圖片大小，但是質量降低太多也會影響圖片的觀看體驗。我們將圖片質量參數設置爲q70，指定圖片服務器下發70%質量的圖片。對於大部分業務，一方面可以大幅減少圖片下載大小，同時也可以保證觀看體驗。通過添加圖片降質參數至少可以減少30-40%的圖片大小。
使用WebP
按照Google官方的數據，與PNG相比，WebP無損圖像的字節數要少26％。WebP有損圖像比同類JPG圖像字節數少25-34％。圖片服務器支持轉換webP格式，可以減少圖片大小。針對png/jpg圖片格式，添加webP參數，指定圖片服務器下發webp格式。雖然webP相比png/jpg圖片解碼需要更長時間，但相對網絡傳輸速度提升還是很大。
提示：由於目前圖片服務器並不支持
GIF轉webP，GIF並沒有做處理。
URL預處理緩存
添加輕量緩存，提高URL轉換性能。因爲URL轉換本身有一定的耗時，而且單個圖片URL可能會多次加載/多次轉換。轉換後的URL會直接保存到緩存中，下次使用可以直接返回。緩存key由URL+相關圖片轉換參數拼接組成。
圖片API設計
圖片處理參數通過options設置，默認使用q70圖片質量以及webP格式。業務方在調用加載圖片方法時傳入，下面是iOS端的API：
imageView6.jx.setImage(url: URL(string: "https://img11.360buyimg.com/img/pingou-head/25.jpg"),
placeholder: nil, options: [.imageSize(CGSize(width: 40, height: 40))])
磁盤緩存優化
圖片緩存查找優化
設置圖片不同的size參數會導致更多的圖片下載和磁盤緩存，例如同樣一張圖片100px、200px、300px尺寸因爲URL不同會下載3次，同時緩存也無法不同。由於圖片庫通常默認使用URL作爲圖片緩存key，所以我們需要針對圖片緩存key查找圖片進行優化改造。簡單來講，相同的圖片小size的圖片可以直接複用更大size的緩存，這樣當存在更大尺寸圖片時，可以避免圖片直接下載並且複用磁盤緩存。
降低圖片內存消耗
png/jpg等圖片格式在顯示之前都需要經過解碼生成一張位圖，之後根據位圖創建紋理傳給GPU做渲染。一張位圖的內存消耗大概是像素寬x像素高x位深。通常圖片使用的是RGBA，位深爲32位。一張500px_500px的大概1MB內存。對於GIF圖片因爲本身有多幀，所以最終的內存消耗爲單幀內存x幀數。
我們的優化方向一方面是通過圖片縮放的方式，減少圖片位圖的內存消耗。另一方面限制圖片緩存上限避免緩存使用過高。
圖片縮放
通過上面URL預處理過程讓圖片服務器下發更小的圖片格式，已經降低了一部分內存。但是URL預處理只處理了jd域名的jpg/png圖片，對於GIF或京東域名外的圖片沒有處理，包括一部分URL轉換後加載失敗的圖片。所以對於這部分圖片，我們會在端側做圖片縮放的處理，降低內存消耗。例如一張300px_300px包含100幀的GIF圖片，實際顯示區域只有50px_50px，優化後總內存消耗可從30MB+內存降低到3MB。
GIF動態幀率播放
之前根據線上監控數據發現，部分頁面場景偶爾會配置尺寸大/幀數多的GIF圖片，導致內存佔用極高。例如一張500x400px播放200幀的GIF圖片會佔用100MB+內存消耗。所以針對這種場景，我們針對GIF做了減幀播放改造。當GIF圖片總內存消耗大於一定量級時（例如圖片內存緩存上線的20%），將GIF播放的幀數適當減少，每一幀的播放時間增加，這樣可以將內存控制在一定範圍之內。
提示：這裏也可以通過 GIF 圖片緩存 Buffer 控制內存總量，但是會導致更頻繁的解碼造成更多的 CPU 消耗。
圖片內存緩存上限
圖片緩存的設計目的是減少圖片解碼消耗。圖片第一次使用的時候，將圖片進行解碼後的位圖保存在內存中，這樣可以避免下次使用時避免重複解碼。雖然圖片內存高可以儘量避免圖片重複解碼，但是佔用太高內存也會導致APP後臺被系統殺掉或產生OOM等問題。所以我們應該將內存緩存控制在一定範圍內。
例如iOS的第三方圖片庫SDWebImage/Kingfisher默認都使用系統庫NSCache來實現內存緩存。雖然NSCache會在設備內存緊張時回收內存，但是默認並不限制可保存內存最大字節數，所以在設備內存可用的情況下內存可以一直增加。所以通過設置圖片緩存上限，防止圖片緩存佔用太高內存。圖片緩存定義了一個默認的初始值上限，之後對於3x大屏幕設備和高端設備(內存比較高)，適當增加更多內存上限。
優化成果
其他收益
域名統一- 減少了10%+的重複圖片下載和內存消耗。同時減少之前多域名圖片加載時重複創建HTTPS請求的過程，減少圖片加載時間。
其他策略
加載異常處理
因爲少量圖片通過URL預處理轉換後，可能會存在圖片不存在的異常場景導致加載失敗。所以當發生圖片加載失敗時，我們還是需要加載原始圖片URL。但是這裏需要屏蔽一些特殊的加載錯誤，避免非必要的加載，例如無網絡/網絡超時/主動取消加載等錯誤。之後會將錯誤圖片URL上報到後臺，方便之後調整URL轉換策略，也可以發現一部分錯誤的圖片URL推動業務修改。同時將這部分連接加入到錯誤連接緩存中，避免下次重複執行預處理和重複上報。
線上配置
目前存在的一些功能，例如URL預處理/統一域名/WebP使用等功能，都添加了線上配置，方便灰度/降級。一在出現問題時可以降級某些功能，新功能上線時也可以進行灰度測試。
大圖檢測
需要有一個機制及時發現圖片不符合規範的問題。一方面我們通過線上灰度檢測的方式，當發現大圖片時會進行上報，後續推動業務方進行優化。另一方面我們在日常測試階段，會開啓Debug檢測工具，當檢測到大圖片時，通過圖片翻轉/高亮背景顏色的方式提醒業務開發同學進行優化。
Flutter圖片庫優化
目前京喜APP有10+個二級界面是基於Flutter開發，所以我們也針對Flutter圖片加載做了一些優化。
對接原生圖片庫
因爲Flutter框架自帶圖片庫只提供內存圖片緩存，並不支持硬盤緩存，所以會導致圖片重複下載。所以我們通過重寫ImageProvider，當加載網絡圖片時，通過Channel調用原生圖片庫，原生圖片庫下載圖片到本地磁盤後，返回圖片文件目錄。之後Flutter通過文件目錄加載解碼圖片顯示。這樣一方面可以利用原生圖片庫相關優化能力，同時也可以複用圖片硬盤緩存避免重複下載。
減少內存消耗
使用Image組件時，通過設置cacheHeight/cacheWidth，將圖片解碼爲置頂像素寬高的位圖尺寸，減少內存消耗。同時因爲Flutter內存消耗相對原生更高，所以在Flutter界面關閉時，通過調用imageCache方法清除圖片內存消耗降低內存消耗。
GIF優化
動畫優化- 因爲通常使用Flutter都是混合棧的機制，原生和Flutter界面在頁面導航中相互跳轉。所以當Flutter界面存在GIF圖片時，跳轉到原生以後GIF動畫還會一直執行。所以我們通過在Image組件內監聽Flutter engine發送的生命週期通知，當Flutter界面不在棧頂時，停止GIF動畫執行，減少內存和CPU消耗。減少解碼次數- Flutter框架內部對GIF渲染的處理方式，在屏幕每一幀判斷當前需要顯示的GIF幀，之後對該GIF幀進行解碼之後渲染。因爲並不會把解碼過的幀保存，所以會導致頻繁解碼導致內存波動大。經過優化，對已經解碼過的幀進行保存，避免重複解碼的消耗，同時避免內存的波動。
優化前內存波動很明顯
優化後內存傾於平穩
提示：保存每一幀也會導致更多的內存消耗。目前APP中通常是小尺寸的GIF所以整體可控。可以考慮設置緩衝區上限來控制緩存的圖片幀數避免內存過高。
後續優化方向
更優的緩存算法
優先移除最大內存- iOS系統NSCache實現。通過設置最大內存數，當內存不足時優先移除最大的值。LRU緩存- 優先淘汰最久未使用的圖片內存。對於很多二級界面的場景，用戶打開界面後並不會再次打開。但是因爲這些圖片緩存是最後使用，所以清除內存時也會最後移除，但是在這種場景下就不太合適。界面棧管理- 當界面關閉時將該界面的所有的圖片內存移除，但是對於經常會打開的界面會導致頻繁圖片編解碼也不太合適。
所以針對不同的業務場景使用不同的回收方式可能更加合適：
- 對於
購物車/我的訂單這類界面，用戶每次加載的圖片基本固定，所以更適合在內存中常駐，當內存消耗過高時再回收。 - 對於
商詳/搜索商品列表這類界面，通常商品列表展示的圖片不一樣並且用戶也不會頻繁進某一個特定的商詳，所以更適合優先移除這部分的內存。 - 對於部分彈窗功能，圖片顯示後並不會再次使用，可以考慮不添加到內存中。
使用更好的圖片格式
使用更好的圖片格式通常可以帶來更小的圖片字節大小。同時因爲壓縮率的提高，可以在減少大小的同時提高圖片質量。
提示：使用系統支持硬解碼的圖片格式更有優勢。硬解碼就是使用
GPU進行解碼，相比使用CPU軟解碼性能更好更省電。
APNG/動畫WebP代替GIF- 按照Google官方的說法，GIF轉換爲有損WebP的字節數縮小了64％，而無損WebP字節數縮小了19％。所以使用動畫WebP可以減少更多的網絡流量傳輸。APNG是Mozilla推出的基於PNG的動圖格式並且完全支持RGBA，相比GIF可以減少20%+的圖片大小。而且GIF本身只支持256色索引顏色以及1位alpha(加上透明度後，邊緣會出現明顯的鋸齒)，使用APNG/WebP也可以帶來相比GIF更好的顯示效果。
提示：相比
GIF，WebP的解碼比GIF佔用更多的CPU資源。有損WebP的解碼時間是GIF的2.2倍，而無損WebP的解碼時間是GIF的1.5倍。
HEIC-HEIC是基於H.265視頻編碼格式推出的圖片格式。HEIC相比WebP可以減少20%+的圖片大小，並且編解碼性能更好。在系統兼容性上，Android 9.0以上的系統支持HEIC。蘋果在iOS14以上系統才提供了WebP硬解碼，之前的系統只能使用軟解碼，而HEIC在iOS11之後的機器上都已經支持硬解碼，不過並不支持瀏覽器。AVIF-AVIF是基於AV1編碼格式推出的圖片格式。AVIF相比WebP可以減少30%+的圖片大小。不過目前只有Android 12以上的版本支持。
提示：這裏主要是以
VP8編碼格式的WebP，VP9編碼格式的WebP整體性能和HEIC差異不大。
不過這些圖片格式需要圖片服務器支持之後才能使用。
Flutter
雖然我們對Flutter圖片庫做了一些優化，但總體上還有很多優化空間。包括業界有在使用的基於紋理的圖片方案。在原生側將圖片解碼後，通過Flutter引擎創建紋理。之後講圖片紋理id傳遞給Flutter進行渲染。這樣可以統一在原生側管理圖片內存緩存，優化之前Flutter和原生都分別有一份內存緩存的方式。而且針對於混合棧的導航棧方式，也可以更好的進行圖片內存回收。另外針對Flutter，需要提供更靈活的圖片內存回收策略，避免內存消耗過高。
提示：紋理可以複用內存中的
位圖緩存，所以並不會導致更多的內存佔用。紋理方式大概能減少30%的內存消耗相比Flutter引擎圖片庫，主要是一些其他對象使用導致。
優化H5圖片加載
我們可以通過攔截WebView圖片加載的方式，讓原生圖片庫來下載圖片之後傳遞圖片二進制數據給WebView顯示。
減少流量消耗
通過這種方式，我們可以將原生圖片庫URL預處理相關功能支持到H5圖片，減少H5加載過程中圖片流量消耗，提高圖片加載速度。同時因爲APP原生和WebView圖片緩存機制是相互獨立的，所以通過統一在原生側管理圖片緩存，可以減少相同圖片的重複下載。
支持更多圖片格式
例如在iOS系統上，WKWebView目前只支持PNG/JPG/GIF圖片格式。所以我們可以通過在原生端實現下載WebP/HEIC圖片，之後對圖片進行解碼再傳給WebView，這樣就可以支持其他圖片格式的顯示。
提示：因爲
WebView不支持直接傳遞位圖二進制數據顯示，所以需要提前轉換爲PNG/JPG二進制數據傳遞。所以對於其他圖片格式增加一次PNG/JPG編碼過程會造成更多的性能消耗。不過對於Android系統應該可以在web內核層優化減少這塊消耗。
總結
本文並沒有講底層圖片加載庫的具體實現，目前圖片庫不管是直接用第三方庫還是自研圖片庫實現方式通常差異不大。我們更多是關注自身業務以及如何利用圖片服務器能力最大化改善網絡圖片加載性能。所以部分策略可能不一定針對所有APP都合適，應該針對自身業務場景仔細評估優化方案。