Android设备音频数据获取过程中的性能问题求助

Hey，针对你这段用MediaMetadataRetriever配合Cursor获取设备音频数据遇到的性能问题，我给你梳理一些实际项目里验证过的排查方向和优化方案：

一、先定位到底慢在哪 #

首先得搞清楚性能瓶颈出在哪，别盲目优化：

• 用Android Studio Profiler实锤：打开Profiler的CPU跟踪，跑一遍代码看看耗时占比——大概率是循环里反复调用MediaMetadataRetriever.setDataSource拖了后腿，毕竟每次调用都要打开音频文件、解析元数据，属于频繁IO操作，特别吃性能。
• 加简单计时统计：在代码里加几个System.currentTimeMillis()，分别记录Cursor查询的总耗时，以及循环里每一次元数据解析的耗时，快速定位是查询慢还是解析慢。

二、针对性优化方案 #

1. 别用MediaMetadataRetriever拿MediaStore已经有的数据！ #

这是最容易踩的坑：MediaStore本身已经存储了绝大多数常用音频元数据（标题、艺术家、专辑名、时长、文件路径等），完全没必要再用MediaMetadataRetriever去重复解析。

你当前query方法传了null作为projection，这会查询所有列，反而更慢。应该只指定你需要的字段：

// 只查询你需要的元数据列，避免冗余数据
String[] projection = {
    MediaStore.Audio.Media._ID,
    MediaStore.Audio.Media.TITLE,
    MediaStore.Audio.Media.ARTIST,
    MediaStore.Audio.Media.ALBUM,
    MediaStore.Audio.Media.DURATION,
    MediaStore.Audio.Media.DATA // 文件路径（如果需要的话）
};
Cursor cursor = contentResolver.query(uri, projection, null, null, null);

之后直接从Cursor里取数据就行，省掉大量重复的IO操作。

2. 绝对不要在主线程做这些操作！ #

不管是Cursor查询还是元数据解析，都是耗时操作，放在主线程会直接导致UI卡顿，甚至触发ANR。必须放到后台线程处理：

• 如果是Java项目，可以用AsyncTask（简单场景够用）或者RxJava；
• 推荐用Kotlin Coroutine（现在Android开发主流），代码更简洁。

举个Java用AsyncTask的例子（记得要处理Cursor关闭）：

new AsyncTask<Void, Void, List<AudioItem>>() {
    @Override
    protected List<AudioItem> doInBackground(Void... voids) {
        List<AudioItem> audioList = new ArrayList<>();
        ContentResolver resolver = getActivity().getContentResolver();
        String[] projection = {/* 你需要的字段 */};
        // 加上过滤条件，只获取音乐文件，减少数据量
        String selection = MediaStore.Audio.Media.IS_MUSIC + " = ?";
        String[] selectionArgs = {"1"};
        // 指定排序规则，避免默认排序的额外开销
        String sortOrder = MediaStore.Audio.Media.TITLE + " ASC";

        try (Cursor cursor = resolver.query(uri, projection, selection, selectionArgs, sortOrder)) {
            if (cursor != null && cursor.moveToFirst()) {
                do {
                    // 直接从Cursor取数据，不用MediaMetadataRetriever
                    String title = cursor.getString(cursor.getColumnIndexOrThrow(MediaStore.Audio.Media.TITLE));
                    String artist = cursor.getString(cursor.getColumnIndexOrThrow(MediaStore.Audio.Media.ARTIST));
                    audioList.add(new AudioItem(title, artist));
                } while (cursor.moveToNext());
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
        return audioList;
    }

    @Override
    protected void onPostExecute(List<AudioItem> audioItems) {
        // 回到主线程更新UI
        updateAudioList(audioItems);
    }
}.execute();

3. 优化Cursor查询的范围 #

• 过滤非音乐文件：上面代码里加了IS_MUSIC = 1的条件，这样可以排除铃声、通知音等不需要的音频，减少Cursor返回的数据量；
• 指定排序规则：不要传null作为sortOrder，明确指定排序字段（比如按标题排序），避免MediaStore做默认排序的额外开销；
• 用try-with-resources自动关闭Cursor：Java 7+支持的语法，能确保Cursor用完后自动关闭，避免资源泄漏和内存占用。

4. 真要用到MediaMetadataRetriever时的优化 #

如果有些特殊元数据（比如专辑封面的Bitmap、歌词）MediaStore没有存储，必须用MediaMetadataRetriever的话：

• 复用实例：不要每次循环都创建新的MediaMetadataRetriever，复用同一个实例，减少对象创建和销毁的开销；
• 批量异步处理：把需要解析的文件路径收集起来，用线程池批量处理，不要在循环里同步阻塞；
• 及时释放资源：用完后记得调用release()释放底层资源，避免内存泄漏。

三、总结下核心优化点 #

1. 优先从MediaStore直接获取元数据，避免重复解析；
2. 所有耗时操作必须放到后台线程；
3. 只查询需要的字段，过滤不需要的音频文件；
4. 及时关闭Cursor和释放MediaMetadataRetriever资源。

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