1. 項目緣起為什么我們需要在Android上支持HEIF如果你最近幾年換過手機尤其是iPhone或者一些中高端的Android機型你可能會發(fā)現(xiàn)手機拍出來的照片文件格式不再是熟悉的.jpg或.png而是一種叫做.heic或者.heif的文件。我第一次在Android項目里遇到這種格式的圖片時直接懵了——用Glide或者Picasso加載要么直接報錯要么顯示一片空白。當時項目里急著要上線一個圖片瀏覽功能用戶上傳的iPhone照片全是HEIF格式服務端也沒做轉換壓力一下子就給到了客戶端。HEIF全稱High Efficiency Image File Format高效圖像文件格式它不是某個公司拍腦袋想出來的而是MPEG組織基于HEVCH.265視頻編碼標準制定的一種圖像容器格式。它的核心優(yōu)勢就兩個字高效。在同等甚至更好的畫質(zhì)下HEIF文件的大小通常只有JPEG的50%左右。這意味著用戶手機里能存下更多高質(zhì)量照片App上傳下載圖片也更省流量對云存儲成本也是實實在在的降低。所以無論是從用戶體驗還是技術趨勢來看支持HEIF都從一個“加分項”變成了“必選項”。然而Android官方對HEIF的支持卻有點“擠牙膏”。雖然從Android 8.1API 27開始系統(tǒng)BitmapFactory和MediaMetadataRetriever等類就通過NDK提供了基礎的編解碼能力但直到Android 11API 30ImageDecoder才原生支持了HEIF靜態(tài)圖片。這帶來了幾個現(xiàn)實問題第一你的App如果minSdkVersion低于30就無法直接使用官方的ImageDecoder第二即便是API 30系統(tǒng)解碼庫的兼容性和性能表現(xiàn)也可能因廠商定制而異第三我們常用的第三方圖片加載庫如Glide其默認配置也并不直接“開箱即用”地支持HEIF。所以這個項目的目標非常明確在不依賴付費商業(yè)庫、不強制提升App最低API級別的前提下為我們的Android應用實現(xiàn)一套穩(wěn)定、免費且向后兼容的HEIF圖片解碼與加載方案。這不僅僅是調(diào)用一個API那么簡單它涉及到編解碼器的選擇、與現(xiàn)有圖片加載框架的集成、不同Android版本的兼容性處理以及如何優(yōu)雅地處理解碼失敗等邊界情況。接下來我將結合我實際踩過的坑把整個方案的設計思路和實現(xiàn)細節(jié)拆解清楚。2. 核心方案選型免費解碼器的對比與抉擇要實現(xiàn)HEIF解碼我們首先需要一個“解碼器”。市面上主要有三條技術路線使用Android系統(tǒng)內(nèi)置能力、集成第三方C/C編解碼庫、或者尋找純Java/Kotlin的實現(xiàn)。我們的原則是免費、穩(wěn)定、輕量并且最好能無縫接入現(xiàn)有技術棧比如Glide。讓我們逐一分析。2.1 路線一Android系統(tǒng)原生APIImageDecoder這是最“正統(tǒng)”的路線。從Android 11開始android.graphics.ImageDecoder類提供了強大的圖片解碼能力其中就包括HEIF/HEIC。// 示例使用 ImageDecoder 解碼 HEIF 文件 val source ImageDecoder.createSource(File(filePath)) val bitmap ImageDecoder.decodeBitmap(source) { // 可以在這里配置解碼參數(shù)如大小、裁剪等 it.setTargetSize(1024, 1024) }優(yōu)點官方支持無需引入額外庫APK體積零增長。功能強大支持動態(tài)HEIF即動圖、解碼過程精細控制大小、裁剪、后處理。性能有保障底層調(diào)用系統(tǒng)優(yōu)化過的Native庫。致命缺點API級別限制僅限Android 11API 30及以上。對于需要兼容到Android 5.0或8.0的廣大應用來說這直接判了“死刑”。我們不能為了一個圖片格式而拋棄大量舊版本用戶。結論此方案適合那些minSdkVersion已經(jīng)30的新應用或內(nèi)部工具。對于需要廣泛兼容性的項目它只能作為高版本系統(tǒng)上的一個備選或優(yōu)化路徑不能作為主力方案。2.2 路線二集成libheif或其他C/C庫libheif是處理HEIF格式事實上的標準開源C庫由HEIF格式的主要貢獻者之一開發(fā)功能完整支持編解碼。集成方式通常通過Android NDK將libheif編譯為.so動態(tài)庫并通過JNI提供Java接口。優(yōu)點功能全面且權威支持HEIF所有特性靜態(tài)圖、動圖、深度圖、透明通道等?？缙脚_一套C代碼可在多平臺使用。性能極致Native代碼執(zhí)行效率高。缺點與挑戰(zhàn)NDK開發(fā)復雜度需要搭建NDK編譯環(huán)境處理交叉編譯為armeabi-v7a,arm64-v8a,x86等不同ABI分別編譯這對不熟悉Native開發(fā)的Android工程師來說門檻較高。APK體積膨脹每個ABI的.so庫都可能達到1MB以上如果支持多個ABIAPK體積的增加是顯著的。維護成本需要關注libheif上游的更新處理可能存在的安全漏洞并重新編譯集成。與圖片加載庫集成需要自己編寫大量的JNI膠水代碼并實現(xiàn)Glide的ResourceDecoder等接口工作量不小。結論libheif是功能最強大的方案但也是成本和復雜度最高的方案。它適合對HEIF特性有深度需求如需要編輯、寫入HEIF文件且團隊有NDK開發(fā)能力的項目。對于大多數(shù)僅需要“解碼顯示”的場景有點“殺雞用牛刀”。2.3 路線三使用Android平臺已內(nèi)置的HEVC解碼器MediaCodec這是本文要重點推薦的、最具性價比的“免費”方案。其核心思路非常巧妙既然HEIF圖像的數(shù)據(jù)是使用HEVCH.265編碼的而Android系統(tǒng)早在Android 5.0就通過MediaCodec提供了HEVC視頻的解碼能力那我們何不“借用”視頻解碼器來解碼圖片呢Android系統(tǒng)在API 27時在BitmapFactory中悄悄加入了對HEIF的試探性支持其底層很可能就是利用了MediaCodec。我們可以繞過BitmapFactory直接使用MediaExtractor和MediaCodec來模擬一個“只有一幀的視頻”從而解碼出圖片。優(yōu)點極佳的兼容性只要設備支持HEVC視頻解碼絕大部分Android 5.0的設備都支持就能解碼HEIF圖片。這幾乎覆蓋了我們所有的目標用戶。零依賴完全使用Android SDK現(xiàn)有API無需引入任何第三方庫APK體積無影響。系統(tǒng)級性能MediaCodec是硬件加速解碼的效率非常高。缺點實現(xiàn)相對復雜需要理解MediaExtractor、MediaCodec、Image等多媒體API的使用代碼量比直接調(diào)用BitmapFactory要多。功能單一此方案專注于“解碼靜態(tài)HEIF圖片為Bitmap”不支持HEIF動圖、編輯或寫入。但對于顯示需求這已經(jīng)足夠了。需要處理解碼器可用性并非100%的設備都支持HEVC需要有一個fallback機制。對比結論對于絕大多數(shù)以“加載和顯示用戶照片”為核心需求的App路線三MediaCodec方案無疑是平衡了兼容性、成本、性能和實現(xiàn)復雜度的最佳選擇。它完美契合了“免費”和“廣泛支持”的核心訴求。接下來我們就深入探討如何實現(xiàn)這一方案。3. 實戰(zhàn)基于MediaCodec的HEIF解碼器實現(xiàn)這個方案的本質(zhì)是把一個HEIF文件當作一個編碼格式為HEVCH.265、且只包含一個關鍵幀I幀的“視頻文件”來處理。MediaExtractor負責解析文件容器提取出編碼的視頻數(shù)據(jù)ES流MediaCodec則扮演解碼器的角色將數(shù)據(jù)解碼為原始的YUV或RGB圖像數(shù)據(jù)最后我們再將其轉換為Android需要的Bitmap。3.1 解碼流程拆解與核心代碼整個過程可以分為六個步驟我將其封裝成了一個獨立的HeifDecoder類。步驟1檢查設備支持與創(chuàng)建MediaExtractor首先我們需要確認當前設備的MediaCodec是否支持HEVC解碼。然后用MediaExtractor綁定到HEIF文件。import android.media.MediaCodec import android.media.MediaExtractor import android.media.MediaFormat import android.graphics.Bitmap import android.graphics.ImageFormat import android.media.Image import android.media.ImageReader import java.nio.ByteBuffer class HeifDecoder { companion object { // 檢查是否支持HEVC解碼 fun isHevcSupported(): Boolean { val codecList MediaCodecList(MediaCodecList.REGULAR_CODECS) for (codecInfo in codecList.codecInfos) { if (!codecInfo.isEncoder) { // 找解碼器 for (type in codecInfo.supportedTypes) { if (type.equals(MediaFormat.MIMETYPE_VIDEO_HEVC, ignoreCase true)) { return true } } } } return false } } fun decode(filePath: String): Bitmap? { val extractor MediaExtractor() try { extractor.setDataSource(filePath) // 步驟2尋找視頻軌道 val trackIndex selectVideoTrack(extractor) if (trackIndex 0) { return null // 不是有效的視頻/HEIF文件 } extractor.selectTrack(trackIndex) val format extractor.getTrackFormat(trackIndex) // ... 后續(xù)步驟 } catch (e: Exception) { e.printStackTrace() return null } finally { extractor.release() } } private fun selectVideoTrack(extractor: MediaExtractor): Int { for (i in 0 until extractor.trackCount) { val format extractor.getTrackFormat(i) val mime format.getString(MediaFormat.KEY_MIME) if (mime?.startsWith(video/) true) { return i } } return -1 } }步驟2 3配置MediaCodec與ImageReader獲取到視頻軌道的MediaFormat后我們創(chuàng)建對應的MediaCodec解碼器。同時創(chuàng)建一個ImageReader來接收解碼后的圖像數(shù)據(jù)。這里的關鍵是ImageReader的格式我們選擇ImageFormat.YUV_420_888因為這是MediaCodec輸出最通用的YUV格式。private fun decode(filePath: String): Bitmap? { // ... 步驟1代碼 val format extractor.getTrackFormat(trackIndex) val mime format.getString(MediaFormat.KEY_MIME) if (mime ! MediaFormat.MIMETYPE_VIDEO_HEVC) { // 有些HEIF文件的MIME類型可能直接是image/heif但MediaCodec需要video/hevc。 // 這里為了簡化我們假設能走到這里的軌道就是HEVC。實際生產(chǎn)環(huán)境需要更健壯的判斷。 } val width format.getInteger(MediaFormat.KEY_WIDTH) val height format.getInteger(MediaFormat.KEY_HEIGHT) // 創(chuàng)建解碼器 val decoder MediaCodec.createDecoderByType(MediaFormat.MIMETYPE_VIDEO_HEVC) // 配置解碼器Surface傳null因為我們用ByteBuffer模式接收數(shù)據(jù) decoder.configure(format, null, null, 0) // 創(chuàng)建ImageReader用于獲取解碼后的Image val imageReader ImageReader.newInstance(width, height, ImageFormat.YUV_420_888, 1) decoder.setOutputSurface(imageReader.surface) // 關鍵將解碼器輸出連接到ImageReader decoder.start() // ... 后續(xù)步驟編解碼循環(huán) }注意這里我們使用了decoder.setOutputSurface(imageReader.surface)這告訴解碼器將解碼后的圖像幀直接渲染到ImageReader提供的Surface上然后我們可以從ImageReader中獲取Image對象。這是一種比使用ByteBuffer模式更高效、更現(xiàn)代的方式。步驟4 5編解碼循環(huán)與獲取Image這是最核心的部分。我們啟動一個循環(huán)向解碼器輸入數(shù)據(jù)從MediaExtractor讀取的編碼幀然后嘗試從輸出端即ImageReader獲取解碼后的圖像。private fun decode(filePath: String): Bitmap? { // ... 前述步驟代碼 decoder.start() val timeoutUs 5000L // 5毫秒超時 var inputDone false var outputDone false var decodedBitmap: Bitmap? null while (!outputDone) { // 1. 輸入數(shù)據(jù)送編碼幀進解碼器 if (!inputDone) { val inputBufferId decoder.dequeueInputBuffer(timeoutUs) if (inputBufferId 0) { val inputBuffer decoder.getInputBuffer(inputBufferId) val sampleSize extractor.readSampleData(inputBuffer!!, 0) if (sampleSize 0) { // 沒有更多數(shù)據(jù)了發(fā)送結束標志 decoder.queueInputBuffer(inputBufferId, 0, 0, 0, MediaCodec.BUFFER_FLAG_END_OF_STREAM) inputDone true } else { val presentationTimeUs extractor.sampleTime decoder.queueInputBuffer(inputBufferId, 0, sampleSize, presentationTimeUs, 0) extractor.advance() // 移動到下一幀對于HEIF圖片通常就一幀 } } } // 2. 嘗試獲取解碼后的圖像 val image imageReader.acquireLatestImage() // 獲取最新的Image if (image ! null) { // 步驟6將Image轉換為Bitmap decodedBitmap imageToBitmap(image) image.close() outputDone true // 我們只需要第一幀對于靜態(tài)HEIF } // 3. 處理解碼器輸出狀態(tài)可選用于更精細的控制和錯誤處理 val info MediaCodec.BufferInfo() val outputBufferId decoder.dequeueOutputBuffer(info, timeoutUs) when (outputBufferId) { MediaCodec.INFO_OUTPUT_FORMAT_CHANGED - { // 輸出格式發(fā)生變化通?？梢院雎?} MediaCodec.INFO_TRY_AGAIN_LATER - { // 暫時沒有輸出繼續(xù)循環(huán) } else - if (outputBufferId 0) { // 成功解碼出一幀數(shù)據(jù)數(shù)據(jù)已通過Surface輸出到ImageReader // 我們已經(jīng)在上面通過ImageReader拿到了Image這里只需要釋放輸出緩沖區(qū) decoder.releaseOutputBuffer(outputBufferId, true) // true表示渲染到Surface if ((info.flags and MediaCodec.BUFFER_FLAG_END_OF_STREAM) ! 0) { outputDone true } } } } // 清理資源 decoder.stop() decoder.release() imageReader.close() return decodedBitmap }步驟6將YUV_420_888格式的Image轉換為Bitmap從ImageReader獲取的Image對象是YUV_420_888格式的我們需要將其轉換為RGB格式的Bitmap。這是一個涉及顏色空間轉換的運算過程。我們可以使用RenderScript、OpenGL ES或者純CPU計算。這里提供一個相對高效且兼容性好的CPU轉換方法簡化版實際生產(chǎn)需優(yōu)化import android.graphics.YuvImage import java.io.ByteArrayOutputStream private fun imageToBitmap(image: Image): Bitmap? { if (image.format ! ImageFormat.YUV_420_888) { throw IllegalArgumentException(Expected YUV_420_888 image format) } val planes image.planes val width image.width val height image.height // 獲取Y、U、V三個分量的數(shù)據(jù) val yBuffer planes[0].buffer val uBuffer planes[1].buffer val vBuffer planes[2].buffer // 計算各分量的步長和像素步進 val yRowStride planes[0].rowStride val uvRowStride planes[1].rowStride val uvPixelStride planes[1].pixelStride // 創(chuàng)建ARGB_8888格式的Bitmap val bitmap Bitmap.createBitmap(width, height, Bitmap.Config.ARGB_8888) val pixels IntArray(width * height) // YUV420sp (NV21) 轉換到 RGB 的算法實現(xiàn) (這里是一個簡化示例) // 注意YUV_420_888可能是Planar或Semi-Planar這里假設為NV21類似格式進行簡化。 // 實際生產(chǎn)代碼需要根據(jù)image.planes的詳細屬性進行更精確的轉換。 // 以下代碼僅為示意性能并非最優(yōu)。 val yArr ByteArray(yBuffer.remaining()) val uArr ByteArray(uBuffer.remaining()) val vArr ByteArray(vBuffer.remaining()) yBuffer.get(yArr) uBuffer.get(uArr) vBuffer.get(vArr) var yIdx 0 var uvIdx 0 for (j in 0 until height) { for (i in 0 until width) { val y (yArr[yIdx i].toInt() and 0xff).toFloat() val u (uArr[uvIdx (i / 2) * uvPixelStride].toInt() and 0xff).toFloat() - 128.0f val v (vArr[uvIdx (i / 2) * uvPixelStride].toInt() and 0xff).toFloat() - 128.0f // YUV to RGB 轉換公式 (ITU-R BT.601) var r y 1.402f * v var g y - 0.344136f * u - 0.714136f * v var b y 1.772f * u r r.coerceIn(0.0f, 255.0f) g g.coerceIn(0.0f, 255.0f) b b.coerceIn(0.0f, 255.0f) pixels[yIdx i] (0xff shl 24) or ((r.toInt() shl 16)) or ((g.toInt() shl 8)) or b.toInt() } yIdx yRowStride if (j % 2 0) { uvIdx uvRowStride } } bitmap.setPixels(pixels, 0, width, 0, 0, width, height) return bitmap }重要提示上面的YUV轉RGB代碼是一個高度簡化的示例用于說明原理。在實際項目中直接使用CPU進行逐像素轉換在大圖如1200萬像素上性能極差。強烈建議使用以下方案之一使用RenderScriptAndroid官方提供的異構計算框架可以編寫高性能的轉換腳本。雖然API 31后不推薦但在低版本上仍是高效選擇。使用OpenGL ES著色器在GL線程中進行轉換性能最佳但實現(xiàn)復雜度最高。使用第三方優(yōu)化庫例如libyuvGoogle開源它提供了高度優(yōu)化的YUV轉RGB匯編代碼。如果API 29可以考慮使用ImageDecoder直接解碼或者使用YuvImage類配合Canvas繪制但需要注意格式兼容性。3.2 關鍵細節(jié)與避坑指南解碼器生命周期管理務必在try-catch-finally塊中確保MediaExtractor、MediaCodec和ImageReader被正確釋放release()或close()否則會導致嚴重的資源泄漏如相機無法打開。線程安全MediaCodec的解碼操作是阻塞且耗時的絕對不能在主線程中調(diào)用。必須放在后臺線程如AsyncTask、Kotlin協(xié)程、RxJava或線程池中執(zhí)行。內(nèi)存與性能解碼大尺寸HEIF圖片如4800萬像素會消耗大量內(nèi)存存儲YUV數(shù)據(jù)和RGB Bitmap。務必根據(jù)顯示區(qū)域的大小進行采樣Sample Size或縮放Target Size避免解碼出全尺寸的Bitmap導致OOM?？梢栽诮獯a前通過MediaFormat獲取原圖尺寸然后計算合適的縮放比例。格式兼容性雖然理論上HEIF都使用HEVC編碼但有些設備尤其是舊設備的HEVC解碼器可能對某些編碼配置Profile, Level支持不全。因此解碼失敗是必須處理的常態(tài)。我們的decode方法返回Bitmap?上層調(diào)用者必須做好為空和降級處理例如嘗試用其他方法解碼或顯示一個錯誤占位圖。顏色空間上述示例忽略了顏色空間如BT.601 vs BT.709和色度采樣位置如JPEG vs MPEG的差異。對于追求精確色彩還原的應用如專業(yè)圖像處理需要從MediaFormat中解析出相關參數(shù)KEY_COLOR_STANDARD,KEY_COLOR_RANGE,KEY_COLOR_TRANSFER并在轉換公式中應用。4. 無縫集成讓Glide加載HEIF圖片我們有了一個能工作的HeifDecoder但直接在每個需要加載圖片的地方調(diào)用它太麻煩而且無法享受Glide帶來的緩存、生命周期管理、圖片變換等強大功能。理想的方式是將其封裝成一個Glide的ResourceDecoder。4.1 實現(xiàn)Glide的ResourceDecoderGlide通過ResourceDecoder接口來擴展其支持的圖片格式。我們需要實現(xiàn)一個用于InputStream或File的Decoder。import com.bumptech.glide.load.Options import com.bumptech.glide.load.ResourceDecoder import com.bumptech.glide.load.engine.Resource import com.bumptech.glide.load.resource.SimpleResource import java.io.File import java.io.IOException class HeifDecoder : ResourceDecoderFile, Bitmap { // 1. 判斷是否支持解碼此數(shù)據(jù)源 override fun handles(source: File, options: Options): Boolean { // 簡單通過文件后綴名判斷生產(chǎn)環(huán)境可結合文件魔數(shù)(magic number)更準確 val name source.name.lowercase(Locale.getDefault()) return name.endsWith(.heic) || name.endsWith(.heif) || name.endsWith(.avif) // AVIF也基于類似原理 } // 2. 核心解碼方法 Throws(IOException::class) override fun decode(source: File, width: Int, height: Int, options: Options): ResourceBitmap? { // 在實際項目中這里應該傳入一個更健壯的HeifDecoder實例 val bitmap HeifDecoder().decode(source.absolutePath) // 調(diào)用我們之前實現(xiàn)的解碼器 return if (bitmap ! null) { SimpleResource(bitmap) } else { null // 返回nullGlide會嘗試其他Decoder } } }4.2 將Decoder注冊到Glide模塊為了讓Glide在全局使用我們的解碼器需要創(chuàng)建一個AppGlideModule確保已添加Glide注解處理器依賴。import com.bumptech.glide.Glide import com.bumptech.glide.Registry import com.bumptech.glide.annotation.GlideModule import com.bumptech.glide.module.AppGlideModule import java.io.InputStream GlideModule class MyAppGlideModule : AppGlideModule() { override fun registerComponents(context: Context, glide: Glide, registry: Registry) { super.registerComponents(context, glide, registry) // 將我們的Decoder插入到Glide的解碼器鏈中。 // 優(yōu)先級File - Bitmap 的解碼路徑。 registry.prepend(File::class.java, Bitmap::class.java, HeifDecoder()) // 如果你還想支持從InputStream直接解碼例如網(wǎng)絡加載可以再注冊一個。 // registry.prepend(InputStream::class.java, Bitmap::class.java, HeifStreamDecoder()) } }HeifStreamDecoder的實現(xiàn)考慮從網(wǎng)絡加載HEIF時數(shù)據(jù)是InputStream。一種做法是將流先寫入臨時文件再調(diào)用HeifDecoder。但這有IO開銷。更優(yōu)的方案是修改我們的底層解碼器使其支持從ByteBuffer或InputStream解碼這需要更深入地控制MediaExtractor的數(shù)據(jù)源例如使用MediaExtractor.setDataSource(MediaDataSource)。初期為了簡化使用臨時文件方案是可行的。4.3 使用與降級策略集成完成后使用方式就和Glide加載其他圖片完全一樣了Glide.with(context) .load(heifFileOrUrl) .placeholder(R.drawable.placeholder) .error(R.drawable.error) // 當所有Decoder都無法處理時顯示 .into(imageView)關鍵的降級策略設備不支持HEVC解碼在HeifDecoder.handles()方法中可以加入設備能力檢查。如果!HeifDecoder.isHevcSupported()直接返回falseGlide會跳過此Decoder嘗試用其他默認的Decoder當然會失敗最終觸發(fā).error()占位符。解碼過程失敗我們的decode方法返回nullGlide會將其視為當前Decoder解碼失敗自動嘗試鏈上的下一個Decoder。如果沒有其他Decoder能處理則加載失敗。服務端降級最根本的解決方案是移動端上傳HEIF圖片后服務端應即時轉碼生成一份JPEG或WebP格式的副本并在圖片URL中通過參數(shù)或內(nèi)容協(xié)商Accept頭來返回最適合客戶端的格式。這樣舊版客戶端或解碼失敗的設備可以自動回退到兼容格式。這是一個更健壯、更推薦的后端配合方案。5. 兼容性覆蓋與進階優(yōu)化我們的核心方案基于MediaCodec其兼容性下限是“支持HEVC解碼的Android 5.0設備”。為了覆蓋更多場景我們可以構建一個分層級的解碼策略。5.1 分層解碼策略我們可以創(chuàng)建一個統(tǒng)一的HeifDecoder門面類內(nèi)部按優(yōu)先級嘗試多種解碼方式object RobustHeifDecoder { fun decode(file: File, targetWidth: Int, targetHeight: Int): Bitmap? { // 策略1: Android 11 優(yōu)先使用官方ImageDecoder (最穩(wěn)定) if (Build.VERSION.SDK_INT Build.VERSION_CODES.R) { try { return decodeWithImageDecoder(file, targetWidth, targetHeight) } catch (e: Exception) { // 降級到策略2 } } // 策略2: 使用MediaCodec方案 (主力) if (HeifDecoder.isHevcSupported()) { try { return decodeWithMediaCodec(file, targetWidth, targetHeight) } catch (e: Exception) { // 降級到策略3 } } // 策略3: 嘗試使用第三方純軟件解碼庫 (如ddxxheifdecoder一個輕量級Java解碼器) // 此方案兼容性最好但性能最差可作為最后保底手段。 try { return decodeWithSoftwareDecoder(file, targetWidth, targetHeight) } catch (e: Exception) { // 所有方案都失敗 } return null } RequiresApi(Build.VERSION_CODES.R) private fun decodeWithImageDecoder(file: File, targetWidth: Int, targetHeight: Int): Bitmap? { val source ImageDecoder.createSource(file) return ImageDecoder.decodeBitmap(source) { decoder, info, source - decoder.setTargetSize(targetWidth, targetHeight) } } private fun decodeWithMediaCodec(file: File, targetWidth: Int, targetHeight: Int): Bitmap? { // 這里集成第3節(jié)實現(xiàn)的解碼邏輯并加入尺寸縮放。 // 關鍵在配置MediaCodec時通過MediaFormat設置KEY_MAX_WIDTH和KEY_MAX_HEIGHT // 或者解碼出Bitmap后再進行縮放以節(jié)省內(nèi)存。 // ... return bitmap } private fun decodeWithSoftwareDecoder(file: File, targetWidth: Int, targetHeight: Int): Bitmap? { // 集成一個輕量級的純Java解碼庫例如通過JNI調(diào)用libheif的簡化版或尋找其他開源實現(xiàn)。 // 注意性能問題建議只在低分辨率預覽時使用。 return null } }5.2 性能優(yōu)化要點內(nèi)存優(yōu)化采樣解碼在調(diào)用MediaCodec.configure()之前可以通過修改從MediaExtractor獲取的MediaFormat設置KEY_MAX_WIDTH和KEY_MAX_HEIGHT來請求解碼器直接輸出縮小后的圖像。這比解碼全尺寸圖再縮放高效得多。Bitmap復用在列表等頻繁加載的場景考慮使用BitmapPoolGlide已內(nèi)置來復用Bitmap內(nèi)存避免頻繁GC。及時回收解碼得到的Bitmap在使用完畢后應確保被Glide正確回收或手動調(diào)用recycle()如果Bitmap是你自己管理的。解碼速度優(yōu)化后臺線程重申所有解碼操作必須在后臺進行。避免重復解碼充分利用Glide的內(nèi)存緩存和磁盤緩存。我們的HeifDecoder返回的Bitmap會被Glide自動緩存。確保為HEIF文件設置合適的緩存鍵Cache Key避免因URL參數(shù)不同導致重復解碼。預加載對于已知即將顯示的HEIF圖片可以使用Glide.preload()進行預解碼和緩存。功耗考慮MediaCodec的硬件解碼雖然快但相比軟件解碼可能在某些芯片上帶來更高的功耗。在連續(xù)解碼大量圖片如瀏覽相冊時需關注手機發(fā)熱情況?？梢钥紤]在解碼一定數(shù)量后插入短暫延遲或降低解碼優(yōu)先級。5.3 測試與異常處理單元測試為HeifDecoder編寫單元測試覆蓋不同Android版本模擬器/真機、不同分辨率/色彩深度的HEIF樣本文件、以及損壞的HEIF文件。兼容性測試矩陣品牌重點測試華為、小米、OPPO、vivo、三星等主流品牌因為其系統(tǒng)對MediaCodec的支持可能有差異。API級別從minSdkVersion如API 21到最新版本。圖片來源測試來自iPhone、Android旗艦機、以及各種圖像處理軟件生成的HEIF文件。監(jiān)控與降級在App中集成異常上報如Firebase Crashlytics當HeifDecoder在特定設備或特定圖片上頻繁失敗時可以動態(tài)禁用該設備上的HEIF解碼功能或對該圖片URL強制請求JPEG格式。通過以上方案我們構建了一個從解碼器核心到上層集成再到兼容性覆蓋和性能優(yōu)化的完整HEIF圖片加載支持體系。它不增加額外的庫依賴充分利用了系統(tǒng)能力并能夠優(yōu)雅地集成到現(xiàn)有的Glide圖片加載框架中是一個真正可落地、可維護的免費解決方案。