18、兼容性适配：不同Android版本、不同厂商ROM的差异处理

做音视频开发这么多年，我踩过最多的坑，不是API不会用，而是——同一套代码，在小米上跑得好好的，换到华为直接黑屏；Android 12没问题，Android 8.1直接崩溃。

说白了，MediaExtractor这套API虽然Google已经封装得挺好了，但底层实现还是依赖硬件解码器和厂商驱动。不同厂商、不同版本，行为差异比你想象的大得多。

18.1 版本差异：API行为变化

先说说Android版本本身带来的差异。我整理了几个最容易踩坑的点：

我记得有一次，项目需要在Android 7.1上跑。结果MediaExtractor.setDataSource()传Uri直接抛异常。查了半天文档才发现，API 26以下只支持文件路径。后来我加了个版本判断，低版本先转成FileDescriptor再传。

18.2 厂商ROM差异：华为、小米、OPPO、vivo

厂商差异才是真正的噩梦。Google的CTS测试只能保证基础API能用，但具体行为嘛……嗯，你懂的。

18.2.1 华为（HarmonyOS / EMUI）

华为的设备有个特点：对MediaExtractor的轨道数量限制比较严格。我曾经遇到过，一个MP4文件有5条音轨，在小米上全都能读到，在华为上只暴露了前3条。

另外，华为的硬件解码器对某些编码格式支持不全。比如HEVC（H.265）在麒麟芯片上虽然支持，但MediaExtractor.getTrackFormat()返回的mime类型可能是"video/hevc"而不是标准的"video/hevc"。嗯，这里要注意，最好做一次mime标准化处理。

18.2.2 小米（MIUI / HyperOS）

小米的问题主要在seekTo上。我做过测试，同一段视频，在小米11上调用seekTo(1000000, SEEK_TO_PREVIOUS_SYNC)，实际跳转到的位置偏差能达到500ms。这在做精确剪辑时完全没法用。

解决方案？我建议放弃SEEK_TO_PREVIOUS_SYNC，统一用SEEK_TO_CLOSEST（API 26+）。如果必须兼容低版本，那就自己实现一个近似seek：先seek到附近关键帧，然后逐帧往前读。

18.2.3 OPPO / vivo

这两家的问题比较类似：对某些封装格式的解析不完整。比如FLAC音频文件，在OPPO上MediaExtractor可能读不到duration。我遇到过，getTrackFormat().getLong(MediaFormat.KEY_DURATION)返回-1。

我的做法是：如果duration拿不到，就手动计算。读取第一个sample的timestamp和最后一个sample的timestamp，差值就是实际时长。虽然麻烦点，但至少不会崩。

18.3 兼容性适配的通用策略

说了这么多问题，总得给点解决方案。我个人总结了一套「三层防御」策略：

1. 第一层：版本判断 + 厂商判断
   • 用Build.VERSION.SDK_INT判断API等级
   • 用Build.MANUFACTURER判断厂商（"HUAWEI"、"XIAOMI"等）
   • 针对已知问题做特殊处理
2. 第二层：运行时异常捕获
   • 所有MediaExtractor操作都包在try-catch里
   • 捕获IllegalStateException、IllegalArgumentException、RuntimeException
   • 捕获后降级处理（比如换解码器、换读取方式）
3. 第三层：数据校验 + 重试机制
   • 读取到的数据做合法性校验（size > 0、timestamp递增等）
   • 如果数据异常，最多重试3次
   • 重试仍失败，主动抛出自定义异常，上层统一处理

// 兼容性适配工具类
public class MediaExtractorCompat {
    
    public static MediaExtractor createExtractor(Context context, Uri uri) {
        MediaExtractor extractor = new MediaExtractor();
        try {
            if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
                // Android 8.0+ 直接传Uri
                extractor.setDataSource(context, uri, null);
            } else {
                // 低版本转成FileDescriptor
                ContentResolver resolver = context.getContentResolver();
                ParcelFileDescriptor pfd = resolver.openFileDescriptor(uri, "r");
                extractor.setDataSource(pfd.getFileDescriptor());
            }
        } catch (IOException e) {
            // 降级处理：尝试用文件路径
            String path = getRealPathFromUri(context, uri);
            if (path != null) {
                extractor.setDataSource(path);
            } else {
                throw new MediaExtractorException("无法初始化Extractor", e);
            }
        }
        return extractor;
    }
    
    public static long getSafeDuration(MediaExtractor extractor, int trackIndex) {
        MediaFormat format = extractor.getTrackFormat(trackIndex);
        long duration = -1;
        if (format.containsKey(MediaFormat.KEY_DURATION)) {
            duration = format.getLong(MediaFormat.KEY_DURATION);
        }
        // 某些厂商ROM可能返回-1，手动计算
        if (duration <= 0) {
            duration = calculateDurationBySamples(extractor, trackIndex);
        }
        return duration;
    }
}

18.4 知识体系总览

下面这张图，是我对兼容性适配的整体理解。你可以把它当作一个检查清单：

18.5 实战中的一些细节

最后分享几个我在实战中积累的小细节，希望能帮你少走弯路：

• 关于mime类型：不要直接用getTrackFormat().getString(MediaFormat.KEY_MIME)做equals比较。有些厂商会在后面加版本号，比如"video/avc"变成"video/avc; codecs=\"avc1.42E01E\""。我习惯用startsWith()判断。
• 关于sample读取：readSampleData()返回的byteBuffer大小，在不同设备上可能不一样。不要假设一次能读完所有数据。我一般会循环读取，直到buffer剩余空间不足。
• 关于资源释放：MediaExtractor的release()一定要放在finally块里。有些厂商的ROM在release时可能卡住，建议加个超时机制，比如用异步线程释放，主线程最多等2秒。
• 关于日志：强烈建议在关键操作前后加日志。比如setDataSource成功/失败、getTrackCount返回值、每个sample的timestamp。线上出问题时，这些日志就是救命稻草。

兼容性适配这件事，说白了就是「见招拆招」。没有一劳永逸的方案，只有不断积累的经验。你遇到的坑越多，你的代码就越健壮。嗯，保持耐心，慢慢来。

公众号:蓝海资料掘金营，微信deep3321