为何MediaMetadataRetriever检索专辑封面耗时过长？如何优化？

你当前的实现耗时高主要来自MediaMetadataRetriever重复初始化、大图无压缩解码、无缓存、串行处理四个核心问题，可按以下优先级优化：

1. 复用MediaMetadataRetriever实例 #

每次新建、销毁MediaMetadataRetriever的开销极高，批量处理时全程复用一个实例，处理完成后再统一释放，可直接降低30%以上的总耗时。
优化后的批量处理示例：

private void batchLoadAlbumArt(List<String> audioPaths) {
    MediaMetadataRetriever mmr = new MediaMetadataRetriever();
    try {
        for (String path : audioPaths) {
            try {
                mmr.setDataSource(path);
                byte[] rawArt = mmr.getEmbeddedPicture();
                Bitmap albumArt = null;
                if (rawArt != null) {
                    // 结合后续的采样解码逻辑使用
                    albumArt = decodeSampledBitmap(rawArt, 200, 200);
                }
                // 此处将封面存入你自定义的存储结构即可
            } catch (Exception e) {
                // 单个文件解析失败直接跳过，不中断整体流程
            }
        }
    } finally {
        mmr.release();
    }
}

2. 下采样压缩解码 #

你当前直接解码原图的逻辑开销极大，多数音频内嵌的原图分辨率可达2k以上，而列表展示类场景仅需几百像素的缩略图，加入采样解码可降低80%以上的单张解码耗时：

// 按所需的展示尺寸解码缩略图
private Bitmap decodeSampledBitmap(byte[] data, int reqWidth, int reqHeight) {
    final BitmapFactory.Options options = new BitmapFactory.Options();
    // 仅解码图片边界信息，不加载全图
    options.inJustDecodeBounds = true;
    BitmapFactory.decodeByteArray(data, 0, data.length, options);
    // 计算合适的采样率
    options.inSampleSize = calculateInSampleSize(options, reqWidth, reqHeight);
    // 真正解码压缩后的图片
    options.inJustDecodeBounds = false;
    return BitmapFactory.decodeByteArray(data, 0, data.length, options);
}

private int calculateInSampleSize(BitmapFactory.Options options, int reqWidth, int reqHeight) {
    final int height = options.outHeight;
    final int width = options.outWidth;
    int inSampleSize = 1;
    if (height > reqHeight || width > reqWidth) {
        final int halfHeight = height / 2;
        final int halfWidth = width / 2;
        while ((halfHeight / inSampleSize) >= reqHeight && (halfWidth / inSampleSize) >= reqWidth) {
            inSampleSize *= 2;
        }
    }
    return inSampleSize;
}

3. 新增多级缓存 #

• 内存缓存：用LruCache缓存已经加载过的封面，重复访问同个音频封面时直接从内存读取，无需二次解析
• 磁盘缓存：如果需要多次加载同一批音频的封面，可将解码后的缩略图缓存到本地磁盘，下次启动无需重新解析原音频文件

4. 并发处理 #

把批量解析逻辑放到线程池并发执行，核心线程数设为CPU核心数的1-2倍即可，避免IO阻塞，可进一步将总耗时降低到串行处理的1/3-1/2。

5. （可选）优先用系统媒体库查询 #

如果仅需要处理本地存储的音频，不需要解析外部传入的音频文件，直接查询系统MediaStore媒体库即可，系统已经提前解析好了所有音频的专辑封面信息，无需自行逐文件解析，速度可提升10倍以上：

String[] projection = {MediaStore.Audio.Media.ALBUM_ID, MediaStore.Audio.Media.DATA};
Cursor cursor = getContentResolver().query(MediaStore.Audio.Media.EXTERNAL_CONTENT_URI, projection, null, null, null);
if (cursor != null) {
    while (cursor.moveToNext()) {
        long albumId = cursor.getLong(cursor.getColumnIndexOrThrow(MediaStore.Audio.Media.ALBUM_ID));
        String audioPath = cursor.getString(cursor.getColumnIndexOrThrow(MediaStore.Audio.Media.DATA));
        // 直接构造专辑封面URI，用Glide等图片框架直接加载即可
        Uri albumArtUri = ContentUris.withAppendedId(Uri.parse("content://media/external/audio/albums"), albumId);
    }
    cursor.close();
}

按上述方案优化后，100-200个音频的封面检索耗时可降到10秒以内，用系统媒体库方案的话可压缩到1秒内完成。

内容的提问来源于stack exchange，提问作者KODE