做Flutter跨端開(kāi)發(fā)的人應(yīng)該都有同感功能可以搬界面可以仿但圖片加載這一環(huán)幾乎每個(gè)新平臺(tái)都要栽一遍跟頭。我最近在做一套Flutter框架適配鴻蒙的改造把原本跑在其他平臺(tái)的頁(yè)面遷移過(guò)去時(shí)iOS、Android上看著正常的圖片到鴻蒙平臺(tái)就出現(xiàn)加載失敗、白塊閃爍、偶爾整頁(yè)卡頓。問(wèn)題集中爆發(fā)之后我花了差不多兩個(gè)迭代的周期把圖片錯(cuò)誤處理體系重新梳理了一遍從框架層到底層平臺(tái)通道都過(guò)了一遍。這篇就把這套方案、代碼和排查經(jīng)驗(yàn)整理出來(lái)給正在做Flutter鴻蒙適配或者準(zhǔn)備做基礎(chǔ)組件沉淀的同學(xué)做個(gè)參考。這篇內(nèi)容比較適合兩類讀者一類是剛開(kāi)始接觸Flutter鴻蒙適配、被圖片問(wèn)題折磨到懷疑人生的開(kāi)發(fā)者另一類是已經(jīng)在做但想看看別人怎么設(shè)計(jì)錯(cuò)誤降級(jí)和統(tǒng)一兜底的。全文不打算長(zhǎng)篇大論講原理重點(diǎn)放在可落地的代碼和可復(fù)用的排查思路。圖片加載失敗這件事說(shuō)起來(lái)簡(jiǎn)單真正落地要處理的東西比想象中多不少。1. 圖片加載在鴻蒙適配中的“硬骨頭”1.1 為什么圖片錯(cuò)誤處理會(huì)集中爆發(fā)先說(shuō)結(jié)論圖片在鴻蒙上容易出問(wèn)題不是因?yàn)橄到y(tǒng)本身差而是因?yàn)镕lutter在鴻蒙上的渲染鏈路和Android、iOS不一樣。Flutter引擎在Android直接使用Skia的軟件或硬件渲染圖片解碼走的是Android系統(tǒng)的ImageDecoder在iOS同樣走系統(tǒng)解碼器。到了鴻蒙平臺(tái)適配層需要把Flutter的圖片請(qǐng)求映射到鴻蒙的圖片加載與解碼能力上。這個(gè)映射過(guò)程里Dart層的Image.network、AssetImage、MemoryImage這些API會(huì)經(jīng)過(guò)引擎轉(zhuǎn)成平臺(tái)側(cè)調(diào)用中間任何一環(huán)處理得不完全一致都會(huì)在真正加載圖片時(shí)體現(xiàn)出來(lái)。我在實(shí)際遷移中發(fā)現(xiàn)問(wèn)題不是“偶爾一張圖掛了”而是“網(wǎng)絡(luò)圖片在弱網(wǎng)下掛了之后沒(méi)有兜底方案直接白塊”。因?yàn)樵竟こ讨辉跇I(yè)務(wù)層做了簡(jiǎn)單的errorBuilder對(duì)Android和iOS夠用但對(duì)鴻蒙就不夠了。鴻蒙適配下解碼失敗會(huì)表現(xiàn)成異常拋到errorBuilder但如果使用默認(rèn)的Image.networkerrorBuilder只能拿到一個(gè)籠統(tǒng)的異常底層是網(wǎng)絡(luò)超時(shí)、解碼失敗還是路徑錯(cuò)誤根本區(qū)分不出來(lái)。沒(méi)有足夠信息業(yè)務(wù)側(cè)沒(méi)法決定是降級(jí)成占位圖、重試還是直接提示。所以這套工作的核心不只是“給圖片加個(gè)errorBuilder”而是把圖片加載鏈路上的所有錯(cuò)誤出口統(tǒng)一起來(lái)區(qū)分錯(cuò)誤類型、分級(jí)處理、可觀測(cè)、可兜底。1.2 圖片錯(cuò)誤類型與高頻觸發(fā)場(chǎng)景先把我遇到的錯(cuò)誤類型和觸發(fā)場(chǎng)景梳理成一張表后面所有方案都圍繞這張表來(lái)設(shè)計(jì)。錯(cuò)誤類型常見(jiàn)表現(xiàn)高頻觸發(fā)場(chǎng)景網(wǎng)絡(luò)加載失敗整塊空白、無(wú)圖弱網(wǎng)、請(qǐng)求超時(shí)、服務(wù)端404或5xx解碼失敗顯示黑塊或灰塊圖片格式不兼容、WebP/HEIC等解碼器缺失資源路徑錯(cuò)誤控制臺(tái)報(bào)錯(cuò)、圖片顯示空白assets配置遺漏、路徑大小寫不對(duì)內(nèi)存超限應(yīng)用崩潰、頁(yè)面卡死大尺寸圖片直接原圖加載、內(nèi)存峰值過(guò)高緩存損壞偶發(fā)白圖、重新加載后恢復(fù)緩存目錄被清理、寫入中斷、新舊緩存校驗(yàn)不一致平臺(tái)通道異常圖片永遠(yuǎn)處于加載中適配層圖片服務(wù)未注冊(cè)、通道消息無(wú)法送達(dá)第一類“網(wǎng)絡(luò)加載失敗”最明顯也最好發(fā)現(xiàn)。第二類“解碼失敗”容易被誤判成網(wǎng)絡(luò)問(wèn)題因?yàn)楸憩F(xiàn)都是“圖片沒(méi)出來(lái)”但排查方向完全不同。第三類“資源路徑錯(cuò)誤”在Android上可能表現(xiàn)不明顯到了鴻蒙上卻會(huì)嚴(yán)格匹配路徑隨手寫錯(cuò)一個(gè)大小寫就找不到資源。第四類“內(nèi)存超限”在鴻蒙上更突出因?yàn)椴糠謾C(jī)型對(duì)單張圖片解碼內(nèi)存的限制和Android不同大圖上很容易直接觸發(fā)內(nèi)存問(wèn)題。第五類緩存問(wèn)題常規(guī)平臺(tái)也會(huì)遇到但鴻蒙適配下因?yàn)榫彺婺夸浀臋?quán)限管理差異發(fā)生率更高。第六類屬于適配層框架還沒(méi)配置好時(shí)最常見(jiàn)屬于環(huán)境問(wèn)題。說(shuō)實(shí)話我最早排查時(shí)只盯著“網(wǎng)絡(luò)圖片加載失敗”結(jié)果繞了不少?gòu)澛酚行﹫D明明網(wǎng)絡(luò)正常、URL能在瀏覽器打開(kāi)就是顯示不出來(lái)最后發(fā)現(xiàn)是解碼失敗有些則是資源圖片自己沒(méi)放對(duì)位置跟網(wǎng)絡(luò)一點(diǎn)關(guān)系都沒(méi)有。所以做錯(cuò)誤處理之前先把錯(cuò)誤分類搞清楚比自己瞎猜重要得多。2. 核心方案從降級(jí)到兜底2.1 最基礎(chǔ)的errorBuilder為什么必須寫兜底Flutter官方提供的Image組件自帶errorBuilder參數(shù)這是最直觀的兜底手段。Image.network( url, errorBuilder: (context, error, stackTrace) { return Text(圖片加載失敗); }, )這段代碼看起來(lái)簡(jiǎn)單但里面有個(gè)容易忽略的點(diǎn)errorBuilder里返回什么決定了用戶看到什么。只返回一行文字視覺(jué)上很突兀也不專業(yè)。我建議至少返回一個(gè)和原圖尺寸接近的占位組件比如一個(gè)灰色容器加一個(gè)簡(jiǎn)單圖形這樣圖片加載失敗后頁(yè)面布局不會(huì)跳動(dòng)整體觀感也不會(huì)太差。另外errorBuilder回調(diào)的三個(gè)參數(shù)里error對(duì)象攜帶的信息在不同平臺(tái)差異很大。在Android和iOS上網(wǎng)絡(luò)圖片失敗時(shí)經(jīng)常拋出的是NetworkImageLoadException帶statusCode但在鴻蒙適配層可能拋出來(lái)的是通用的PlatformExceptioncode字段是類似“image_load_failed”的字符串后面才跟原因。所以如果你的錯(cuò)誤處理邏輯依賴statusCode在鴻蒙上基本拿不到必須先做兼容。還有一個(gè)坑是errorBuilder里如果直接再次發(fā)起加載會(huì)造成請(qǐng)求風(fēng)暴。我當(dāng)時(shí)就看過(guò)線上日志某張圖的URL服務(wù)端持續(xù)返回500但客戶端因?yàn)閑rrorBuilder里寫了自動(dòng)重試導(dǎo)致這張圖在短時(shí)間內(nèi)被請(qǐng)求了幾十次。所以自動(dòng)重試一定要限制次數(shù)和間隔不能無(wú)腦補(bǔ)發(fā)請(qǐng)求。2.2 自定義ImageProvider把錯(cuò)誤出口統(tǒng)一起來(lái)只靠errorBuilder兜底能解決“能不能看到圖”的問(wèn)題但解決不了“怎么知道失敗了、因?yàn)槭裁词　钡膯?wèn)題。這時(shí)候就需要自定義ImageProvider。Flutter圖片加載的核心是ImageProvider它負(fù)責(zé)根據(jù)給定的配置去加載圖片數(shù)據(jù)并緩存。Image.network底層用的是NetworkImageAssetImage對(duì)應(yīng)的是資源圖。自定義一個(gè)ImageProvider可以在加載過(guò)程的loadBuffer階段進(jìn)行錯(cuò)誤捕獲把網(wǎng)絡(luò)狀態(tài)、狀態(tài)碼、耗時(shí)統(tǒng)一封裝然后拋出統(tǒng)一結(jié)構(gòu)的異常。自定義Provider的大體結(jié)構(gòu)是這樣class AppNetworkImage extends ImageProviderAppNetworkImage { final String url; final Duration timeout; const AppNetworkImage(this.url, {this.timeout const Duration(seconds: 10)}); override FutureAppNetworkImage obtainKey(ImageConfiguration configuration) { return SynchronousFutureAppNetworkImage(this); } override ImageStreamCompleter loadBuffer(AppNetworkImage key, ImageDecoderCallback decode) { return OneFrameImageStreamCompleter(_load(decode)); } FutureImageInfo _load(ImageDecoderCallback decode) async { try { final response await _httpClient.get(url).timeout(timeout); if (response.statusCode ! 200) { throw ImageLoadException(HTTP_${response.statusCode}, url); } final buffer await response.buffer(); final codec await decode(buffer); final frame await codec.getNextFrame(); return ImageInfo(image: frame.image); } on TimeoutException { throw ImageLoadException(TIMEOUT, url); } catch (e) { throw ImageLoadException(UNKNOWN, url); } } }這里需要注意loadBuffer里的decode參數(shù)是圖片解碼回調(diào)不能自己另起爐灶直接decode否則會(huì)繞過(guò)引擎層緩存。首次加載成功后Flutter會(huì)在內(nèi)存里緩存ImageInfo同一個(gè)Provider實(shí)例只要key一致在這里就是url后面重新構(gòu)建時(shí)直接用緩存不會(huì)再發(fā)起網(wǎng)絡(luò)請(qǐng)求?？蚣軐訏伋鼋y(tǒng)一錯(cuò)誤結(jié)構(gòu)之后UI層就可以根據(jù)錯(cuò)誤碼決定降級(jí)策略。比如HTTP_404降級(jí)成占位圖TIMEOUT可以觸發(fā)靜默重試一次HTTP_500則直接走客戶端緩存或備用地址。這種分級(jí)策略比籠統(tǒng)的“失敗就顯示占位圖”要精細(xì)得多。2.3 資源圖片的封裝與路徑映射網(wǎng)絡(luò)圖片之外資源圖片在鴻蒙適配中同樣容易出問(wèn)題。最典型的情況是項(xiàng)目里的assets目錄做了多平臺(tái)差異化配置某些圖片只存在于其他平臺(tái)的assets目錄打包給鴻蒙平臺(tái)時(shí)目錄結(jié)構(gòu)變了導(dǎo)致AssetImage找不到資源。我建議對(duì)資源圖片也做一層封裝統(tǒng)一入口class AppAssetImage { static String resolve(String assetName) { // 在這里做平臺(tái)路徑的映射修正 if (PlatformUtils.isHarmonyOS) { return assets/harmony/$assetName; } return assets/$assetName; } }使用的時(shí)候統(tǒng)一走AppAssetImage.resolve這樣如果資源目錄調(diào)整只需要改這一處不需要全局搜索替換。資源圖片錯(cuò)誤處理還有個(gè)細(xì)節(jié)AssetImage加載失敗時(shí)errorBuilder同樣會(huì)收到異常但不會(huì)告訴你“是路徑不存在還是文件名拼錯(cuò)”。我建議在resolve階段先做一次存在性校驗(yàn)用一個(gè)配置清單在啟動(dòng)時(shí)注入把項(xiàng)目里用到的所有資源路徑匯總起來(lái)運(yùn)行時(shí)如果走到不存在的路徑直接斷言或上報(bào)。這個(gè)成本很低但能提前攔住不少低級(jí)錯(cuò)誤。3. 實(shí)操一套可復(fù)用的圖片錯(cuò)誤處理組件3.1 組件設(shè)計(jì)與能力邊界前面講了很多方案細(xì)節(jié)接下來(lái)直接上一套可以抄的組件。目標(biāo)很明確業(yè)務(wù)方不再直接使用Image.network或Image.asset而是統(tǒng)一使用項(xiàng)目里的安全圖片組件SafeImage。它要具備這幾個(gè)能力支持網(wǎng)絡(luò)圖和資源圖兩種模式加載中顯示占位組件加載失敗顯示統(tǒng)一風(fēng)格兜底組件支持錯(cuò)誤類型分級(jí)處理可選自動(dòng)重試自動(dòng)上報(bào)錯(cuò)誤現(xiàn)場(chǎng)給監(jiān)控平臺(tái)對(duì)鴻蒙平臺(tái)做差異化兼容處理。能力邊界也要說(shuō)清楚SafeImage不做圖片下載緩存落盤那是緩存管理器的事SafeImage也不處理任何業(yè)務(wù)邏輯只做加載展示和錯(cuò)誤兜底。這樣邊界清晰不會(huì)變成一個(gè)大雜燴。3.2 完整代碼實(shí)現(xiàn)與核心邏輯解讀組件核心代碼省略了部分無(wú)關(guān)樣式enum LoadErrorType { network, decode, notFound, unknown } class SafeImage extends StatelessWidget { final String url; final String placeholderAsset; final String fallbackAsset; final BoxFit fit; final bool autoRetry; final int retryCount; final Duration timeout; const SafeImage({ required this.url, this.placeholderAsset assets/loading.png, this.fallbackAsset assets/error.png, this.fit BoxFit.cover, this.autoRetry false, this.retryCount 0, this.timeout const Duration(seconds: 10), }); override Widget build(BuildContext context) { if (url.startsWith(asset://)) { return _buildAssetImage(url.substring(7)); } return _buildNetworkImage(url); } Widget _buildNetworkImage(String imageUrl) { return Image( image: AppNetworkImage( imageUrl, timeout: timeout, ), fit: fit, errorBuilder: (context, error, stackTrace) { final errorType error is ImageLoadException ? error.type : LoadErrorType.unknown; if (autoRetry errorType LoadErrorType.network retryCount 0) { return _RetryImage( url: imageUrl, remainCount: retryCount - 1, placeholderAsset: placeholderAsset, fallbackAsset: fallbackAsset, fit: fit, timeout: timeout, ); } ImageErrorReporter.report(errorType.name, imageUrl); return _ErrorFallback(asset: fallbackAsset, fit: fit); }, loadingBuilder: (context, child, loadingProgress) { if (loadingProgress null) return child; return _Placeholder(asset: placeholderAsset, fit: fit); }, ); } }_RetryImage內(nèi)部實(shí)現(xiàn)比較簡(jiǎn)單核心就是重新build一個(gè)SafeImage只是retryCount減一。但這里有個(gè)優(yōu)化點(diǎn)第二次重試時(shí)可以給AppNetworkImage換一個(gè)短一點(diǎn)的timeout避免在弱網(wǎng)環(huán)境下又等10秒用戶體驗(yàn)很差。實(shí)際項(xiàng)目中重試間隔建議做成可配置比如第一次重試間隔500毫秒第二次間隔1秒而不是連續(xù)發(fā)請(qǐng)求。ImageErrorReporter是一個(gè)簡(jiǎn)單的靜態(tài)上報(bào)類正常業(yè)務(wù)可以接日志平臺(tái)或者埋點(diǎn)。上報(bào)時(shí)至少要帶url、錯(cuò)誤類型、頁(yè)面標(biāo)識(shí)這三個(gè)字段。我建議再加一個(gè)“從加載開(kāi)始到失敗的時(shí)間”這個(gè)指標(biāo)很能說(shuō)明網(wǎng)絡(luò)質(zhì)量class ImageErrorReporter { static void report(String type, String url, {int costMs 0}) { // 上報(bào)到監(jiān)控系統(tǒng) print([SafeImage][$type] $url cost$costMs); } }3.3 業(yè)務(wù)接入方式與改造成本業(yè)務(wù)接入其實(shí)很簡(jiǎn)單把原來(lái)寫的Image.network(item.coverUrl, fit: BoxFit.cover)替換成SafeImage( url: item.coverUrl, fit: BoxFit.cover, autoRetry: true, )改動(dòng)成本非常低。但有一點(diǎn)要注意如果原工程里大量代碼直接使用Image.asset并且資源目錄結(jié)構(gòu)比較特殊建議先做資源遷移把目錄統(tǒng)一到一個(gè)標(biāo)準(zhǔn)路徑下再全局替換。不要邊改邊遷移否則排查錯(cuò)誤的時(shí)候分不清是代碼問(wèn)題還是路徑問(wèn)題。另外不建議在SafeImage里直接導(dǎo)入業(yè)務(wù)頁(yè)面保持它只依賴基礎(chǔ)組件庫(kù)。這樣后續(xù)其他模塊接入時(shí)也不用額外引一堆業(yè)務(wù)依賴。我在模擬項(xiàng)目里把SafeImage放在基礎(chǔ)公共包里頁(yè)面層只引用公共包獨(dú)立成層改起來(lái)很省心。4. 常見(jiàn)問(wèn)題與排查實(shí)錄4.1 圖片在鴻蒙適配中的高頻問(wèn)題速查表直接給一張排查速查表按“現(xiàn)象 - 方向”來(lái)定位比看代碼更快現(xiàn)象優(yōu)先排查方向順手驗(yàn)證方法網(wǎng)絡(luò)圖在鴻蒙上全部加載不出適配層圖片服務(wù)是否注冊(cè)、網(wǎng)絡(luò)權(quán)限是否聲明控制臺(tái)搜索image load相關(guān)日志只有部分網(wǎng)絡(luò)圖加載失敗服務(wù)端返回狀態(tài)碼、圖片格式兼容情況用同一URL在瀏覽器打開(kāi)對(duì)比加載中一直在轉(zhuǎn)圈超時(shí)設(shè)置過(guò)長(zhǎng)、底層請(qǐng)求配置問(wèn)題縮短timeout復(fù)現(xiàn)解碼失敗黑塊灰塊圖片格式WebP/HEIC、大圖尺寸轉(zhuǎn)換格式對(duì)比頁(yè)面切換后圖片偶發(fā)空白緩存池競(jìng)爭(zhēng)、ImageCache容量查看緩存命中率日志資源圖片報(bào)錯(cuò)assets目錄是否打包、路徑大小寫檢查打包產(chǎn)物文件列表第一行的情況要重點(diǎn)說(shuō)Flutter工程在鴻蒙上跑起來(lái)后所有Image.network都會(huì)走平臺(tái)通道。如果適配層的圖片服務(wù)沒(méi)有正確注冊(cè)也就是說(shuō)Dart側(cè)發(fā)起的圖片加載請(qǐng)求根本沒(méi)人接那不管URL對(duì)不對(duì)圖片都顯示不出來(lái)。這種情況不是業(yè)務(wù)問(wèn)題是框架初始化問(wèn)題。4.2 緩存與網(wǎng)絡(luò)引發(fā)的“假加載失敗”我踩過(guò)最深的一個(gè)坑是“圖片明明能加載但偶爾會(huì)白一下”一開(kāi)始以為是加載失敗后來(lái)加了日志才發(fā)現(xiàn)是緩存問(wèn)題。Flutter默認(rèn)的ImageCache內(nèi)存上限是100MB左右不同版本配置不同管理的是內(nèi)存緩存不是磁盤緩存。鴻蒙適配后部分平臺(tái)通道會(huì)額外做一層磁盤緩存兩層緩存疊加容易出現(xiàn)緩存數(shù)據(jù)版本不一致的情況。特別是服務(wù)端更新了圖片內(nèi)容但文件名沒(méi)變舊的緩存沒(méi)失效就會(huì)一直加載舊圖反過(guò)來(lái)如果磁盤緩存寫入了一半就中斷下次讀取會(huì)拿到損壞的數(shù)據(jù)表現(xiàn)為圖片偶爾空白重新進(jìn)入頁(yè)面又好了。對(duì)付這個(gè)問(wèn)題我的經(jīng)驗(yàn)是在圖片URL上帶版本參數(shù)。服務(wù)端圖片更新時(shí)URL跟著變。這樣能極大減少緩存命中錯(cuò)亂。另外給SafeImage增加一個(gè)強(qiáng)制刷新模式當(dāng)頁(yè)面需要展示最新圖片且緩存不確定時(shí)給AppNetworkImage加一個(gè)cacheBust參數(shù)比如追加時(shí)間戳從源頭繞過(guò)緩存。這個(gè)能力不能常態(tài)開(kāi)只在關(guān)鍵業(yè)務(wù)場(chǎng)景用否則會(huì)失去緩存的意義。4.3 平臺(tái)差異同樣的代碼不同結(jié)果Flutter框架適配鴻蒙本質(zhì)上是平臺(tái)差異問(wèn)題。同一個(gè)Image.network在Android上加載成功鴻蒙上失敗這種現(xiàn)象很常見(jiàn)。我做排查時(shí)用的方法比較笨但有效把圖片加載鏈路拆成幾步逐步定位。每一步留一句日志。第一步網(wǎng)絡(luò)請(qǐng)求是否發(fā)出狀態(tài)碼是什么第二步數(shù)據(jù)是否返回完整字節(jié)數(shù)是否符合預(yù)期第三步解碼是否成功第四步渲染是否正確。哪一步?jīng)]有日志問(wèn)題就在哪一步附近。為了快速定位平臺(tái)差異我還在測(cè)試包加了一個(gè)“長(zhǎng)按圖片顯示加載信息”的調(diào)試能力長(zhǎng)按后彈出一個(gè)面板顯示這張圖的url、錯(cuò)誤類型、耗時(shí)、內(nèi)存占用。這個(gè)調(diào)試工具在適配調(diào)試時(shí)期幫了大忙也能直接給測(cè)試同學(xué)用省去反復(fù)找研發(fā)復(fù)現(xiàn)。平臺(tái)差異處理上還要注意一個(gè)點(diǎn)不要在公共代碼里寫死平臺(tái)判斷把平臺(tái)差異收口到適配層。例如“是否需要走平臺(tái)側(cè)圖片加載能力”這個(gè)判斷應(yīng)該由適配層的配置項(xiàng)決定而不是業(yè)務(wù)代碼里到處判斷。這樣才能保證未來(lái)適配新平臺(tái)時(shí)不用改業(yè)務(wù)代碼。5. 測(cè)試與真實(shí)場(chǎng)景復(fù)現(xiàn)5.1 弱網(wǎng)與錯(cuò)誤模擬工具圖片錯(cuò)誤處理好不好用不能等線上出問(wèn)題才驗(yàn)證。我在模擬項(xiàng)目里搭建了一套相對(duì)完整的失敗場(chǎng)景模擬體系。最簡(jiǎn)單的做法是通過(guò)服務(wù)端工具做斷網(wǎng)、限速、超時(shí)、404返回。但Flutter的Dart層請(qǐng)求不一定走系統(tǒng)配置所以更可靠的辦法是在應(yīng)用里內(nèi)置一個(gè)調(diào)試開(kāi)關(guān)為一個(gè)測(cè)試地址配置特殊返回值。比如啟動(dòng)時(shí)帶上“圖片測(cè)試模式”參數(shù)AppNetworkImage加載時(shí)遇到指定URL就故意拋異常這樣不用搭環(huán)境就能測(cè)試SafeImage的兜底邏輯。另一個(gè)值得推薦的做法是自動(dòng)化用例覆蓋。圖片加載涉及異步、網(wǎng)絡(luò)、緩存純手工測(cè)試很難覆蓋全面。我用單元測(cè)試給SafeImage的幾個(gè)核心分支做了用例正常加載、404降級(jí)、超時(shí)重試、資源圖不存在。這些用例的價(jià)值在于后面做鴻蒙適配層的版本升級(jí)時(shí)能快速發(fā)現(xiàn)適配層改動(dòng)是否破壞了原有兜底邏輯。5.2 上線前后的經(jīng)驗(yàn)沉淀最后說(shuō)幾條經(jīng)驗(yàn)都是我實(shí)際踩過(guò)坑得來(lái)的。第一圖片容錯(cuò)要前置設(shè)計(jì)不要等出了問(wèn)題再補(bǔ)。我在這個(gè)項(xiàng)目里一開(kāi)始只想加個(gè)占位圖結(jié)果真正動(dòng)手時(shí)發(fā)現(xiàn)鏈路問(wèn)題一堆返工成本比正常做高很多。如果一開(kāi)始就把錯(cuò)誤類型、降級(jí)策略、上報(bào)字段規(guī)劃好后面會(huì)順利很多。第二兜底組件的視覺(jué)風(fēng)格也需要一個(gè)標(biāo)準(zhǔn)。不同頁(yè)面出現(xiàn)不同樣式的“圖片加載失敗”看起來(lái)會(huì)非常雜亂。統(tǒng)一用同一個(gè)fallback組件雖然不能解決加載失敗但能讓產(chǎn)品觀感穩(wěn)定。第三監(jiān)控?cái)?shù)據(jù)比想象中有用。上線前一天我加了一個(gè)“圖片加載失敗率”的監(jiān)控指標(biāo)當(dāng)天就發(fā)現(xiàn)某個(gè)頁(yè)面的圖片失敗率異常高排查后發(fā)現(xiàn)是資源路徑在鴻蒙目錄下沒(méi)有同步屬于打包遺漏。如果沒(méi)有監(jiān)控這個(gè)問(wèn)題大概率要等用戶反饋才能發(fā)現(xiàn)。第四對(duì)待平臺(tái)差異不要試圖在業(yè)務(wù)層兼容所有平臺(tái)。平臺(tái)差異應(yīng)該沉淀在Provider和適配層業(yè)務(wù)層永遠(yuǎn)只面對(duì)“加載成功、加載失敗、等待中”三種狀態(tài)。這套設(shè)計(jì)一旦成型以后適配新平臺(tái)只需要改Provider內(nèi)部實(shí)現(xiàn)業(yè)務(wù)代碼一行不用動(dòng)。我覺(jué)得這套圖片錯(cuò)誤處理方案放在Flutter適配鴻蒙的語(yǔ)境下核心思路不只是“讓失敗圖不白屏”而是把圖片加載的不可控因素全部攔截在統(tǒng)一出口讓失敗可感知、可分類、可降級(jí)、可恢復(fù)。代碼結(jié)構(gòu)不復(fù)雜但關(guān)鍵是把每一步都想清楚。如果你也在做類似的適配工作不妨先從給圖片加一個(gè)全局安全的入口開(kāi)始。