从崩溃日志看混淆的必要性

最近在项目中使用ExoPlayer播放DASH流媒体时，遇到一个诡异问题：在release包中播放器无法加载视频，日志中出现NoSuchMethodError: androidx.media3.exoplayer.source.MediaSource$Factory.createMediaSource错误。经过排查发现，这是典型的混淆配置缺失导致的问题——ProGuard将MediaSource工厂类的方法名优化后，播放器内部通过反射调用的API无法正确匹配。

默认混淆规则为何不适用

Android默认的ProGuard配置主要针对普通应用场景，但ExoPlayer作为多媒体框架有其特殊性：

1. 反射调用密集：如DynamicConcatenatingMediaSource通过类名动态加载插件
2. JNI接口依赖：Native层需要精确匹配Java层方法签名
3. 注解驱动逻辑：DRM相关的@Nullable等注解影响运行时行为

完整配置方案

以下是经过生产验证的proguard-rules.pro配置（以ExoPlayer 2.18.x为例）：

# 核心媒体组件保留
-keep class com.google.android.exoplayer2.** { *; }
-keep interface com.google.android.exoplayer2.** { *; }

# MediaSource工厂类必须保留
-keepclassmembers class * implements com.google.android.exoplayer2.source.MediaSource$Factory {
    public *;
}

# HTTP数据源动态加载
-keep class * extends com.google.android.exoplayer2.upstream.HttpDataSource$BaseFactory {
    public <init>(...);
}

# DRM相关注解
-keepattributes *Annotation*
-keepclassmembers class * {
    @com.google.android.exoplayer2.drm.RequiresApi *;
}

性能优化要点

1. 方法内联影响：
2. 避免过度优化解码器相关方法（如SampleQueue类）

3. 测试显示混淆后H.264解码帧率下降约5%

4. ABI优化策略：

5. 对armeabi-v7a/arm64-v8a分别配置不同优化级别
6. 使用-libraryjars指定特定CPU架构的so库

版本差异与避坑指南

1. 2.x vs 3.x：
2. ExoPlayer 3.x开始使用androidx.media3包名

3. 3.x需要额外保留Player.Listener接口

4. R8特别处理：

5. 在gradle.properties添加：

   android.enableR8.fullMode=false

6. 避免R8的激进优化破坏LoadControl时序

思考与延伸

当项目需要自定义RenderersFactory时，如何在保留扩展性的同时确保混淆安全？建议：

1. 对自定义渲染器使用@Keep注解
2. 在混淆配置中添加包名前缀白名单
3. 通过-whyareyoukeeping参数验证保留结果

最后提醒：每次升级ExoPlayer版本后，都应该检查release包的播放测试，毕竟Google的API变动可能影响混淆规则的有效性。