做Android開發(fā)這些年類似“為什么不用WebP”的問題真的被問過無數(shù)次。每次我都想先反問一句你說的是哪個(gè)WebP是無損、有損、帶動(dòng)畫、還是帶透明通道平臺(tái)不一樣業(yè)務(wù)場(chǎng)景不一樣結(jié)論完全不一樣。WebP是Google推出的圖片格式Android系統(tǒng)從4.0開始就原生支持理論上應(yīng)該大殺四方可實(shí)際項(xiàng)目里我們經(jīng)?？吹揭欢裀NG和JPG甚至有人明令禁止用WebP。這篇文章不做理論吹捧只從一個(gè)Android開發(fā)者的角度把WebP在App里的真實(shí)處境、適用邊界和踩坑記錄講清楚。適合正在糾結(jié)要不要把圖片資源切換成WebP的人。1. WebP 在 Android 開發(fā)里到底算老幾先聊完這層再談?dòng)貌挥?.1 一個(gè)經(jīng)常被誤解的“不支持”史WebP剛出來那幾年最大的問題不是格式本身而是生態(tài)。iOS和Android對(duì)WebP的支持進(jìn)度不一樣瀏覽器也拖了很久很多開發(fā)者早年在兼容性上吃過虧于是形成了“不能碰”的印象。Android官方支持WebP是4.0開始的也就是API 14但當(dāng)時(shí)只保證有損WebP的基本解碼帶透明通道的無損WebP要到Android 4.2.1之后才算完整支持。注意這個(gè)版本節(jié)點(diǎn)很關(guān)鍵早幾年的低成本安卓機(jī)大量停留在4.1、4.2如果你在資源里放了一張帶透明區(qū)域的WebP輕則透明區(qū)域變黑底重則直接解碼失敗。一次線上事故足以讓團(tuán)隊(duì)把它拉進(jìn)黑名單?，F(xiàn)在很多App的minSdk都到21以上了但那段歷史在不少老工程師心里留下了陰影寧可繼續(xù)用PNG也不愿動(dòng)。另一個(gè)被忽略的事實(shí)是WebP和PNG/JPG在Android系統(tǒng)里的“待遇”并不對(duì)等。PNG從Android誕生第一天起就是親兒子解析路徑經(jīng)過無數(shù)次優(yōu)化連硬件加速都能很好地配合WebP雖然是親生的但早期系統(tǒng)版本的解碼實(shí)現(xiàn)并不算快。尤其是有損WebP它編碼時(shí)用了VP8幀內(nèi)編碼的思路解碼器要做很多反向預(yù)測(cè)和變換這在當(dāng)年的低端芯片上就是一場(chǎng)災(zāi)難。很多團(tuán)隊(duì)嘴上說“不用WebP”其實(shí)是“早年間用過一次卡得要命”記憶被妖魔化了后來版本再怎么升級(jí)也懶得回頭。1.2 “不用WebP”的聲音從哪里來除了歷史兼容問題日常團(tuán)隊(duì)里最常見的聲音其實(shí)有三類一是怕出問題。圖片資源不像代碼出了問題不好回滾PNG在Android上服役了十幾年行為非常穩(wěn)定。把一個(gè)穩(wěn)定資源換成格式上有些“歷史包袱”的WebP光風(fēng)險(xiǎn)評(píng)估就能讓技術(shù)負(fù)責(zé)人猶豫半天。二是沒有收益認(rèn)知。很多人以為WebP能“省內(nèi)存”結(jié)果轉(zhuǎn)了以后用Android Studio Profiler一看內(nèi)存一點(diǎn)沒降就覺得這東西沒用順手把WebP方案斃掉。三是流程成本。設(shè)計(jì)交付的是PSD或Sketch要變成WebP得專門走一遍工具很多時(shí)候設(shè)計(jì)師輸出PNG順手得多。開發(fā)這邊也一樣老項(xiàng)目的drawable目錄里幾千張PNG你很難說服團(tuán)隊(duì)一次性全換掉。這三類聲音單獨(dú)看都合理但它們混在一起就很容易變成一句籠統(tǒng)的“Android開發(fā)不用WebP”。實(shí)際上正確的說法應(yīng)該是在合適的場(chǎng)景下用合適的格式而不是一刀切。WebP從來不是“不能用”而是“不能無腦用”。2. 為什么很多團(tuán)隊(duì)不碰 WebP三個(gè)真實(shí)原因2.1 兼容性不是紙面參數(shù)而是低端機(jī)上的噩夢(mèng)系統(tǒng)API說支持不代表所有機(jī)型解碼WebP都順暢。WebP的有損編碼基于VP8/VP9視頻編碼框架解碼邏輯比PNG、JPEG復(fù)雜得多在高通低端芯片上純軟件解碼耗時(shí)經(jīng)常是JPEG的一到兩倍。打個(gè)比方JPEG解碼像是做快餐流程固定翻臺(tái)率高WebP解碼像是做定制料理味道好但費(fèi)工時(shí)。圖片少無所謂但如果一個(gè)列表頁(yè)要同時(shí)加載十幾張甚至幾十張圖解碼耗時(shí)的差距就會(huì)被無限放大。我測(cè)過一個(gè)真實(shí)項(xiàng)目一個(gè)1000像素寬的商品Banner從JPG換成同視覺質(zhì)量的WebP后磁盤體積少了30%但在兩臺(tái)低端真機(jī)上列表滑動(dòng)時(shí)的幀率掉了將近20%。原因就是每次滑出屏幕再滑回來都要重新解碼WebP每次解碼多花的那幾毫秒被連續(xù)觸發(fā)最終反映到了掉幀上。所以不能說WebP“兼容性有問題”而應(yīng)該說在性能預(yù)算卡得很死的場(chǎng)景里它會(huì)占掉你一筆不小的CPU開銷。另外Android 8.0之后系統(tǒng)解碼器對(duì)WebP做了更多優(yōu)化包括靜態(tài)圖和動(dòng)圖的支持都在變好但這只解決新機(jī)型的問題。老機(jī)型你攔不住只能靠代碼做降級(jí)。如果你的最低支持版本還卡在4.x那WebP透明圖就是一顆定時(shí)炸彈尤其在國(guó)產(chǎn)ROM上廠商自己魔改了解碼器有時(shí)候連BitmapFactory.decodeStream的結(jié)果都不可靠。這種“兼容性”不是紙面上的API文檔而是大量線上真機(jī)踩出來的。2.2 解碼性能和收益邊界省的不是內(nèi)存是流量和存儲(chǔ)這里必須先把一個(gè)常見誤解糾正過來WebP不能省內(nèi)存。Bitmap在內(nèi)存里的占用量只和圖片的像素尺寸、色彩模式有關(guān)和磁盤上壓縮成什么格式?jīng)]有關(guān)系。一張1000x1000的ARGB_8888圖片不管是PNG、JPG還是WebP解碼到內(nèi)存里都是約4MB。你從PNG換成WebP安裝包小了網(wǎng)絡(luò)流量小了但App運(yùn)行時(shí)的內(nèi)存占用一點(diǎn)都不會(huì)少。如果團(tuán)隊(duì)當(dāng)初是為了“省內(nèi)存”去轉(zhuǎn)WebP那結(jié)果注定失望然后很容易得出“WebP沒用”的錯(cuò)誤結(jié)論。WebP真正的收益在存儲(chǔ)和帶寬兩個(gè)維度。靜態(tài)資源換成WebPAPK能小一點(diǎn)網(wǎng)絡(luò)圖片讓后端輸出WebP用戶可以少走流量弱網(wǎng)下加載更快。這種收益在大尺寸、內(nèi)容豐富的圖片上特別明顯比如Banner、運(yùn)營(yíng)插畫、商品圖。反過來一張8x8的小圖標(biāo)PNG可能只有兩百字節(jié)轉(zhuǎn)成WebP以后反而可能更大因?yàn)楦袷筋^、參數(shù)塊這些固定開銷攤不薄。另外PNG針對(duì)大面積純色、色塊簡(jiǎn)單的圖片有調(diào)色板機(jī)制壓縮效率非常高WebP的無損壓縮整體優(yōu)于PNG但遇到極簡(jiǎn)單圖像優(yōu)勢(shì)不一定存在。還有解碼耗時(shí)的邊界問題。WebP有損解碼雖然費(fèi)CPU但如果圖片只顯示一次比如啟動(dòng)圖、詳情頁(yè)大圖那多出的幾毫秒用戶根本感知不到收益卻實(shí)實(shí)在在。可一旦進(jìn)入高頻復(fù)用場(chǎng)景比如列表頭像、縮略圖、九宮格解碼器會(huì)被頻繁調(diào)用這時(shí)候多出來的開銷就會(huì)疊加成肉眼可見的掉幀。所以準(zhǔn)確的說法是WebP適合“低頻加載、一次展示、大尺寸”的圖片不適合“高頻加載、滾動(dòng)復(fù)用、小尺寸”的圖片。用對(duì)了它是省體積的利器用錯(cuò)了它就是浪費(fèi)CPU的負(fù)擔(dān)。2.3 工具鏈、設(shè)計(jì)協(xié)作和歷史包袱技術(shù)問題往往可以通過升級(jí)API解決但工具鏈和協(xié)作習(xí)慣很難?，F(xiàn)在的Photoshop、Sketch雖然可以通過插件導(dǎo)出WebP但流程沒有PNG那么“零成本”。設(shè)計(jì)師改完圖順手導(dǎo)出PNG丟到共享文件夾可能幾分鐘就完事如果要出WebP他得選插件、調(diào)參數(shù)、再導(dǎo)一次有些人干脆放棄了。開發(fā)端也一樣老項(xiàng)目的drawable目錄里幾千張PNG你很難說服團(tuán)隊(duì)一次性全換掉因?yàn)槊恳粡埍澈蠖伎赡荜P(guān)聯(lián)一個(gè)線上頁(yè)面轉(zhuǎn)完還得做視覺回歸排期不允許。還有第三方SDK的資源問題。很多廣告SDK、地圖SDK內(nèi)部封裝了圖片加載邏輯它自帶的資源還是PNG/JPG你沒法要求對(duì)方的交付格式?；旌腺Y源環(huán)境下格式之間來回切換反而增加排查成本。比如你項(xiàng)目里大部分圖片都是WebP突然某個(gè)SDK里蹦出一張PNG如果接口返回的格式判斷代碼寫得不嚴(yán)謹(jǐn)很容易出現(xiàn)解碼失敗或者圖片錯(cuò)位。我看到過比較現(xiàn)實(shí)的狀態(tài)是新資源統(tǒng)一WebP老資源按頁(yè)面逐個(gè)遷移不搞一刀切。同時(shí)還要維護(hù)一套設(shè)計(jì)規(guī)范告訴團(tuán)隊(duì)什么時(shí)候用矢量圖、什么時(shí)候用WebP、什么時(shí)候保留PNG。這些規(guī)范聽起來很虛但實(shí)際上能把大半的“WebP翻車”問題提前擋在門外。3. 什么時(shí)候該用什么時(shí)候別硬用場(chǎng)景對(duì)照表3.1 這些場(chǎng)景用WebP收益明顯先說適合用WebP的場(chǎng)景基本都是“大”和“遠(yuǎn)”這兩個(gè)字可以概括的圖片尺寸大、內(nèi)容離用戶視線遠(yuǎn)比如運(yùn)營(yíng)位、啟動(dòng)屏或者圖片要從網(wǎng)絡(luò)拉取。啟動(dòng)圖和引導(dǎo)頁(yè)。這類圖通常尺寸大、色彩豐富、不需要透明通道用有損WebP可以做到比JPEG小30%左右App冷啟動(dòng)時(shí)資源IO壓力更小。Banner和運(yùn)營(yíng)位。運(yùn)營(yíng)設(shè)計(jì)經(jīng)常是整張圖漸變、投影、噪點(diǎn)全都有JPEG容易出壓縮痕跡WebP在同等體積下畫質(zhì)更好尤其是漸變邊緣色帶控制比JPEG好。網(wǎng)絡(luò)圖片。服務(wù)端可以把原圖統(tǒng)一成WebP客戶端用Glide/Fresco/Coil加載CDN流量直接減少。注意這里說的是圖片文件體積變小不是節(jié)省內(nèi)存但弱網(wǎng)環(huán)境下加載速度提升是很明顯的。顏色豐富的插畫資源。比如引導(dǎo)頁(yè)插畫、空狀態(tài)插畫直接用無損WebP替代PNG體積一般能減少20%到30%而且保留透明。這類圖通常只加載一次解碼耗時(shí)多一點(diǎn)點(diǎn)也無所謂。實(shí)際項(xiàng)目里我習(xí)慣先用cwebp轉(zhuǎn)幾張典型大圖放到測(cè)試包上跑一輪性能對(duì)比如果解碼耗時(shí)的增量在低端機(jī)上小于10%那基本可以放心推廣。啟動(dòng)頁(yè)和詳情頁(yè)大圖是最容易說服合作方的地方因?yàn)槭找嬷庇^好驗(yàn)證出了問題影響面也小。3.2 這些場(chǎng)景硬上WebP反而吃虧反過來下面這些場(chǎng)景是WebP的減分項(xiàng)第一小圖標(biāo)。特別是16dp、24dp這種尺寸要么轉(zhuǎn)成VectorDrawable顏色數(shù)極多且需要復(fù)雜細(xì)節(jié)的才考慮位圖。如果強(qiáng)行從PNG轉(zhuǎn)WebP壓縮收益很小解碼成本卻可能變高。這時(shí)候理性的選擇是保留PNG甚至直接用矢量圖。第二需要頻繁改版的運(yùn)營(yíng)素材。一次活動(dòng)素材用PNG從上線到下架可能就改三次換成WebP后每次改版都得走轉(zhuǎn)碼流程很容易出現(xiàn)線上包更新不及時(shí)的尷尬。我就遇到過設(shè)計(jì)師臨時(shí)改了一個(gè)數(shù)字結(jié)果我們連夜批量轉(zhuǎn)圖還差點(diǎn)把活動(dòng)給耽誤了。第三透明動(dòng)畫需求。WebP動(dòng)圖格式本身不差但很多加載庫(kù)對(duì)動(dòng)圖WebP的支持要額外配置舊機(jī)型解碼一幀一幀地畫耗電和發(fā)熱都比較明顯。如果團(tuán)隊(duì)沒有這方面經(jīng)驗(yàn)動(dòng)畫需求老老實(shí)實(shí)上GIF或者Lottie。GIF雖然體積大但是解碼路徑成熟坑少。第四內(nèi)存敏感的滑動(dòng)列表。前面說過WebP解碼耗時(shí)相比PNG高在低端機(jī)上大量高頻解碼會(huì)放大卡頓。圖片小收益又不大不如保留PNG/JPEG配合LruCache和DiffUtil用。真的想優(yōu)化優(yōu)先做尺寸采樣和復(fù)用而不是換格式。場(chǎng)景推薦格式原因啟動(dòng)圖/Banner有損WebP大圖收益高、透明需求少帶透明的插畫無損WebP比PNG小20%以上小圖標(biāo)VectorDrawable/PNGWebP無收益解碼耗CPU動(dòng)圖GIF/Lottie/動(dòng)圖WebPWebP動(dòng)圖兼容性成本高網(wǎng)絡(luò)圖片服務(wù)端WebP流量和首屏速度收益明顯低端列表小圖PNG/JPG解碼吞吐量?jī)?yōu)先3.3 一個(gè)簡(jiǎn)單的圖片替換決策清單如果你還是拿不準(zhǔn)可以按這個(gè)清單走一遍圖片有透明通道嗎有優(yōu)先考慮無損WebP或PNG。圖片面積大嗎超過512x512值得用WebP。色彩模式復(fù)雜嗎漸變、噪點(diǎn)多有損WebP收益高純色塊多保留PNG。最低支持的Android版本是多少低于4.2.1別用帶透明的WebP。圖片會(huì)被高頻加載嗎會(huì)優(yōu)先考慮解碼速度和緩存策略。圖片會(huì)經(jīng)常改版嗎會(huì)保留源文件不要直接把唯一素材轉(zhuǎn)成WebP。清單走完大部分項(xiàng)目都能得到明確答案。我見過太多團(tuán)隊(duì)一上來就喊“全項(xiàng)目WebP化”結(jié)果三天后就被各種邊角問題勸退。與其這樣不如先用清單過濾一輪把高風(fēng)險(xiǎn)圖片提前篩掉剩下的成功率會(huì)高很多。4. 真要切 WebP這套實(shí)操方案可以少踩一半坑4.1 批量轉(zhuǎn)換工具和命令行先說工具。libwebp官方套件里的cwebp是命令行轉(zhuǎn)換主力跨平臺(tái)。macOS可以brew install webpUbuntu可以apt install webpWindows去官方倉(cāng)庫(kù)下載預(yù)編譯二進(jìn)制?；居梅? 有損轉(zhuǎn)換質(zhì)量80適合Banner和運(yùn)營(yíng)圖 cwebp -q 80 input.png -o output.webp # 無損轉(zhuǎn)換適合需要透明的插畫圖 cwebp -lossless input.png -o output.webp # 查看轉(zhuǎn)換結(jié)果信息 webpinfo output.webp質(zhì)量參數(shù)不建議無腦壓到60以下尤其是有漸變背景的運(yùn)營(yíng)圖壓太低容易出現(xiàn)色帶。常用的是75到85透明圖無損轉(zhuǎn)。如果你想在一個(gè)項(xiàng)目里批量處理可以寫一個(gè)Gradle Task把drawable目錄里的PNG掃一遍自動(dòng)調(diào)cwebp轉(zhuǎn)換。代碼大致是這個(gè)意思task convertPngToWebp { doLast { def drawableDir file(src/main/res/drawable-xhdpi) drawableDir.eachFile { f - if (f.name.endsWith(.png)) { def outName f.name.replace(.png, .webp) def outFile new File(f.parentFile, outName) exec { commandLine cwebp, -q, 80, f.absolutePath, -o, outFile.absolutePath } } } } }這個(gè)Task我一般只在專門的分支上跑跑完先檢查diff再讓設(shè)計(jì)師和開發(fā)一起驗(yàn)收不會(huì)直接跑在主分支上刪原圖。因?yàn)閏webp存在極個(gè)別情況轉(zhuǎn)換出來的圖會(huì)有顏色偏差批量操作前要有回滾方案。另外轉(zhuǎn)換前一定要備份原始PNG最好是扔進(jìn)一個(gè)獨(dú)立的original_src目錄否則后面想改顏色或者重新導(dǎo)出時(shí)會(huì)很痛苦。4.2 在 Android 工程中集成 WebP 資源靜態(tài)WebP資源不需要額外配置直接把.webp文件放到res/drawable目錄下代碼里照常使用R.drawable.xxx或用drawable/xxx引用。Android Gradle Plugin的AAPT2是支持WebP資源的不會(huì)像早期版本那樣報(bào)錯(cuò)。網(wǎng)絡(luò)WebP的加載Glide默認(rèn)就能解靜態(tài)WebPFresco和Coil同樣支持。如果你發(fā)現(xiàn)動(dòng)態(tài)WebP沒反應(yīng)先檢查庫(kù)版本。Glide在4.x版本中雖然能解靜態(tài)WebP但動(dòng)圖WebP的支持并不算完整需要引入額外的解碼器或者做降級(jí)。Fresco在這方面支持得比較全動(dòng)圖WebP也能處理代價(jià)是庫(kù)體積變大。選擇方案時(shí)確認(rèn)團(tuán)隊(duì)是否真的需要?jiǎng)訄DWebP如果只是想要“會(huì)動(dòng)的運(yùn)營(yíng)圖”Lottie有時(shí)候比WebP更省事。如果你用原生代碼加載assets目錄里的WebPAPI 18以上的系統(tǒng)可以直接用BitmapFactory.decodeStream。代碼示例簡(jiǎn)單一行val bitmap BitmapFactory.decodeStream(assets.open(bg.webp))但decodeStream返回的Bitmap可能不是理想的ARGB_8888要緊的話用BitmapFactory.Options明確指定inPreferredConfig。比如val options BitmapFactory.Options().apply { inPreferredConfig Bitmap.Config.ARGB_8888 } val bitmap BitmapFactory.decodeStream(assets.open(bg.webp), null, options)這個(gè)細(xì)節(jié)在部分模擬器上特別容易踩坑默認(rèn)配置可能給RGB_565導(dǎo)致漸變圖出現(xiàn)明顯色塊。4.3 質(zhì)量參數(shù)和最低版本控制轉(zhuǎn)換的時(shí)候我會(huì)給自己定幾條鐵律帶透明通道的圖只用無損WebP。有損WebP雖然也可以保留透明但復(fù)雜場(chǎng)景下兼容性不如無損來得穩(wěn)。有損質(zhì)量值不要超過85。再往上體積增加很快畫質(zhì)提升肉眼很難看出來。低于Android 4.2.1的設(shè)備不要在應(yīng)用資源里放透明WebP。如果你的minSdk已經(jīng)到21基本不用顧慮。每次轉(zhuǎn)完用webpinfo檢查圖片尺寸、透明通道和文件頭避免生成損壞文件。這些規(guī)則是從多次線上問題里總結(jié)出來的。比如有次運(yùn)營(yíng)同學(xué)給了一張帶半透明遮罩的PNG我們直接用默認(rèn)參數(shù)轉(zhuǎn)了有損WebP結(jié)果在幾臺(tái)老平板上半透明區(qū)域變成了純黑最后緊急發(fā)版才解決。從那以后帶透明圖一律無損轉(zhuǎn)換寧可體積略大一點(diǎn)也不要拿兼容性冒險(xiǎn)。5. 常見問題與排查實(shí)錄從黑底到卡頓5.1 問題速查表遇到WebP相關(guān)問題先對(duì)照下面這張表現(xiàn)象可能原因處理方式透明區(qū)域變黑色舊系統(tǒng)不支持透明WebP或加載庫(kù)沒開透明解碼提升minSdk、用無損WebP、加兼容庫(kù)圖片解碼失敗/白屏文件損壞或ROM解碼異常用webpinfo檢查文件前端做加載失敗回退動(dòng)圖不播放加載庫(kù)不支持動(dòng)態(tài)WebP換Fresco動(dòng)圖配置或用GIF/Lottie轉(zhuǎn)換后體積變大圖片太小或顏色單調(diào)保留PNG或用VectorDrawable列表滑動(dòng)掉幀WebP解碼占用CPU時(shí)間高換小圖格式、做圖片緩存、降低分辨率打包后圖片不可見AAPT2版本過舊或資源混淆配置問題升級(jí)AGP、檢查ProGuard/R8資源處理規(guī)則5.2 排查思路和工具排查WebP問題我先看文件本身是否健康。一個(gè)比較偷懶的辦法是命令行執(zhí)行file image.webp如果返回RIFF開頭的WebP標(biāo)識(shí)基本能確定文件不是空文件。再用webpinfo image.webp看寬高、格式、是否帶alpha確認(rèn)是不是版本不支持的格式。代碼層面用BitmapFactory.Options.inJustDecodeBounds可以先拿尺寸和mimeType不觸發(fā)完整解碼。如果解碼返回null把異常日志打到本地文件再讓用戶反饋。Android Studio Profiler里可以抓memory和CPU如果懷疑是解碼耗時(shí)問題重點(diǎn)看decode方法的調(diào)用次數(shù)而不是簡(jiǎn)單看圖片格式。很多時(shí)候卡頓的根源是大量全尺寸解碼哪怕?lián)Q成PNG也一樣卡只是WebP把問題放大了。還有一個(gè)容易被忽略的地方資源混淆工具。如果你的項(xiàng)目用了R8或者資源混淆壓縮有些混淆規(guī)則會(huì)把資源文件名改寫WebP文件如果沒被正確匹配運(yùn)行時(shí)就會(huì)出現(xiàn)Resources$NotFoundException。遇到這種問題先檢查ProGuard規(guī)則里有沒有保留res/drawable下的webp文件再檢查打包產(chǎn)物里的resources.arsc。這個(gè)坑很隱蔽排查了半天解碼問題結(jié)果只是打包階段把文件搞沒了。5.3 我現(xiàn)在的習(xí)慣做法新項(xiàng)目里我的默認(rèn)選擇是矢量圖標(biāo)用VectorDrawable復(fù)雜位圖用WebP透明圖用無損WebP動(dòng)圖優(yōu)先Lottie。老項(xiàng)目則按收益排序遷移先轉(zhuǎn)體積最大的運(yùn)營(yíng)圖、啟動(dòng)圖和Banner小圖標(biāo)一律不動(dòng)。每次轉(zhuǎn)換都會(huì)在同一條真機(jī)上和原圖做對(duì)比重點(diǎn)看透明區(qū)域、漸變、文字邊緣這三個(gè)地方因?yàn)檫@些最容易出現(xiàn)可見差異。如果團(tuán)隊(duì)里有人對(duì)WebP沒有把握我通常建議先做一個(gè)“試點(diǎn)頁(yè)面”。挑一個(gè)流量大、圖片多、但邏輯簡(jiǎn)單的頁(yè)面把主要大圖轉(zhuǎn)成WebP跑一個(gè)版本觀察線上崩潰率、卡頓率和包體積變化。有了真實(shí)數(shù)據(jù)團(tuán)隊(duì)自然知道該不該全面推開。比任何技術(shù)討論都有效。最后說點(diǎn)個(gè)人體會(huì)。Android開發(fā)不用WebP很多時(shí)候不是格式不行而是團(tuán)隊(duì)沒用對(duì)它。WebP像是一個(gè)偏科生存儲(chǔ)和帶寬上特別能打但在解碼耗時(shí)、工具鏈和兼容性上需要你額外操心。你把它的長(zhǎng)板用在刀刃上它就是個(gè)好工具你要是拿它去補(bǔ)短板那就是給自己挖坑。我踩過的最大一個(gè)坑就是當(dāng)年想用WebP“省內(nèi)存”結(jié)果內(nèi)存沒省下來還因?yàn)橥该魍ǖ绬栴}發(fā)了個(gè)緊急版本。所以轉(zhuǎn)格式之前先想清楚你到底要省什么比選任何工具都重要。