Android MediaPlayer getDuration 源码解析：从Java到Native再到Binder

2. 调用链路的整体设计从Java到Native再到Binder写到这里我觉得有必要先把整条链路拆开来讲。MediaPlayer.getDuration()在应用层看上去只是一个简单的同步方法调用但它背后实际上跨了三个进程边界App进程Java层 → Native层C → MediaPlayerService进程Binder服务端 → 具体播放引擎NuPlayer/Stagefright → 底层解码器。这个设计不是拍脑袋定的Android的整个多媒体框架从一开始就走的是应用与解码服务分离的架构目的是让音视频解码这种高风险、高负载的任务跑在独立的系统进程里App被杀掉或者发生解码崩溃时不至于把整个系统拖垮。先放一张我脑内的路径图这个图我画了无数遍手写比画图工具快App进程Java层MediaPlayer对象 → 状态机检查 → native_getDuration同一进程的Native层android_media_MediaPlayer.cpp → sp → mPlayer-getDurationBinder跨进程IMediaPlayerService代理 → MediaPlayerService::Client服务端进程具体PlayerBase实现 → NuPlayer/Stagefright → 解码器时长信息这一条链路里每一层都有一层防御性检查比如状态检查、空指针检查、IPC状态码检查。你如果只停留在Java层使用API永远不会知道为什么一个简简单单的getDuration在某些机型、某些音频格式、某些网络环境下会返回0、返回-1甚至直接抛异常。所以接下来我就用AOSP源码一层一层往下扒。2.1 第一站MediaPlayer.java的状态机与native方法声明Java层的MediaPlayer是一个状态机驱动的类这一点文档里写得很清楚但实际开发中很多人并不关心。getDuration()在Java层的实现非常短public int getDuration() { return getDurationInternal(); } private native int getDurationInternal();从Android 5.0开始原始的getDuration()被重构成getDurationInternal()这样的重构理由很简单为了统一处理RuntimeException和错误码。你去看native层的实现会发现它返回的并不是毫秒时长本身而是一个status_t状态码真正的时长是通过出参指针回传的。Java层拿到这个时长后还要根据状态码决定是正常返回还是抛IllegalStateException。那状态机在这里扮演什么角色很多人以为getDuration只要在new完MediaPlayer之后就能调用其实不是。MediaPlayer有Idle、Initialized、Preparing、Prepared、Started、Paused、PlaybackCompleted、Error、End这9个状态getDuration只有在Prepared、Started、Paused、PlaybackCompleted这几个状态才有意义。在其他状态调用native层会返回INVALID_OPERATIONJava层就会抛IllegalStateException。这个坑我遇到过好多次后面在常见问题里会详细说。我在AOSP的MediaPlayer.java源码里摘一段关键实现加了注释private int getDurationInternal() { try { return native_getDuration(); } catch (RuntimeException e) { // 这里不是吞异常而是根据具体的业务场景决定是否抛出 // native层返回错误时会生成一个IllegalStateException Log.w(TAG, Unable to retrieve duration, e); return -1; } }注意上面这段代码并不是完整源码我做了精简。但关键点在于它默认返回-1而不是0这一点很多人没注意。如果你在业务代码里遇到getDuration返回-1不要以为只是没获取到它其实代表native层明确返回了一个错误码可能是播放器还未进入可查询状态也可能是底层解码器不支持时长查询。2.2 JNI桥接android_media_MediaPlayer.cpp里发生了什么Java层的native方法声明好之后真正干活的在C层。AOSP的JNI实现在frameworks/base/media/jni/android_media_MediaPlayer.cpp里这个文件我读过很多遍每次版本更新它都有微调但核心逻辑一直很稳定。这里有个很关键的设计JNI层不是直接把Java对象转成C对象就完事了它维护了一个从Java对象到Native对象的映射表。getMediaPlayer(env, thiz)会根据Java层的MediaPlayer对象找到关联的spMediaPlayer智能指针。这个机制保证了同一个Java对象在Native层只有一个对应的C对象不会出现一个Java对象被创建出两个Native播放器实例。static jint android_media_MediaPlayer_getDuration(JNIEnv *env, jobject thiz) { spMediaPlayer mp getMediaPlayer(env, thiz); if (mp NULL) { jniThrowException(env, java/lang/IllegalStateException, NULL); return 0; } int msec 0; status_t ret mp-getDuration(msec); if (ret ! OK) { // 这里不仅仅记录日志它还会把错误码映射成Java异常 jniThrowException(env, java/lang/IllegalStateException, NULL); return 0; } return msec; }我最早看这段代码的时候有一个疑问为什么失败时要返回0而不是-1后来才想明白这个0是给Java层的兜底值真正能不能用要看Java层的逻辑判断。JNI层的主要职责是类型转换和异常映射而不是业务判断。所以你在JNI层看不到这个错误应该返回什么业务含义的判断它只负责把Native错误翻译成Java异常。还有一个细节mp-getDuration(msec)这里的status_t不是毫秒数而是状态码OK代表成功INVALID_OPERATION代表播放器状态不对NO_INIT代表Native播放器还没准备好。这也是整个框架最容易迷惑人的地方之一——一个int返回值得拆成两层去看状态值和出参。2.3 Native层MediaPlayer与IMediaPlayerService的Binder通信真正拿到时长的地方在App进程的Native层其实也拿不到因为实际播放是在MediaPlayerService进程里。C层的MediaPlayer::getDuration只是把请求通过Binder发出去然后等结果返回。这就是跨进程通信的典型场景也是整个过程中最可能出问题的环节。status_t MediaPlayer::getDuration(int *msec) { if (mPlayer NULL) { return NO_INIT; } return mPlayer-getDuration(msec); }这里的mPlayer类型是spIMediaPlayer它本身就是一个Binder代理对象。你调用mPlayer-getDuration(msec)时表面上是一个普通的C方法调用实际执行流程是IMediaPlayer代理对象把方法调用打包成一个Parcel数据通过Binder驱动发送到MediaPlayerService进程MediaPlayerService进程里的BnMediaPlayer服务端对象解析数据包调用真正的实现类方法把结果打包并回传给App进程整个过程的阻塞时间取决于Binder线程池的繁忙程度以及MediaPlayerService进程当前是否有其他耗时任务。我曾经在低端机上遇到过一个很奇怪的现象getDuration偶尔会卡住200多毫秒排查下来发现是MediaPlayerService进程同时在处理一个视频解码任务CPU抢占激烈导致Binder响应变慢。这种情况在主线程调用getDuration就会导致卡顿所以建议放到子线程去取。Binder调用的超时机制也是值得注意的。系统默认的Binder调用超时是1分钟对于getDuration这种高频小调用来说基本不可能触发超时。但如果MediaPlayerService进程发生死锁或者线程池耗尽你会在logcat里看到Binder call failed之类的日志然后调用端收到一个TransactionErrorException。这种问题在正式环境很难复现因为它是系统级的异常应用层基本无法恢复只能建议用户重启。2.4 服务端MediaPlayerService与具体播放引擎的最终实现请求到达MediaPlayerService进程后最终会走到MediaPlayerService::Client::getDuration。这个Client类是核心它持有一个具体的播放器引擎实例可能是StagefrightPlayer也可能是NuPlayer取决于音视频的类型和系统版本。status_t MediaPlayerService::Client::getDuration(int *msec) { Mutex::Autolock lock(mLock); if (mPlayer NULL) { return UNKNOWN_ERROR; } player_type playerType getPlayerType(); switch (playerType) { case STAGEFRIGHT_PLAYER: case NU_PLAYER: return mPlayer-getDuration(msec); default: return INVALID_OPERATION; } }当调用到达NuPlayer层时情况变得更复杂了。NuPlayer本身也是一个状态机它的duration信息来自内部的数据源和解析器。对于本地文件Extractor会从文件头或元数据中直接读取时长对于网络流媒体可能要等播放器收到完整的元数据块之后才能知道时长这就是为什么有些音频流的getDuration在播放前几秒会返回-1。这里有一个很实际的经验不管框架层做得多完善最终结果还是取决于底层解码器能不能给出答案。就拿MP3来说CBR固定比特率格式的MP3可以直接通过文件大小和比特率估算时长一般都能拿到准确值VBR可变比特率格式的MP3如果文件头部没有VBR头解码器就不得不扫描整个文件或者按平均比特率估算这时拿到的时长可能就有偏差。个别编码不规范的MP3甚至会出现播放总时长为1小时但getDuration返回59分58秒的情况这不一定是框架的错而是源文件本身的问题。3. 调用时机与参数细节什么时候调、返回什么、怎么判理解了调用链再看代码就简单多了。但还是有非常多的人在业务代码里把getDuration用错要么在错误的时机调用要么拿到返回值后判断错误。所以这一节我专门讲调用时机、返回值的各种可能性以及正确的写法。3.1 正确的调用时机首先明确一点getDuration必须在MediaPlayer进入Prepared状态之后才能可靠调用。什么是Prepared状态就是你调用了prepare()或prepareAsync()并且收到了onPrepared回调之后的状态。我来整理一下推荐的调用顺序创建MediaPlayer实例设置数据源setDataSource调用prepareAsync避免阻塞主线程在onPrepared回调里获取时长获取之后再做UI更新比如进度条最大值MediaPlayer mediaPlayer new MediaPlayer(); try { mediaPlayer.setDataSource(urlOrPath); mediaPlayer.setOnPreparedListener(new MediaPlayer.OnPreparedListener() { Override public void onPrepared(MediaPlayer mp) { int duration mp.getDuration(); // 这里的值才是可信的 if (duration 0) { seekBar.setMax(duration); } } }); mediaPlayer.prepareAsync(); } catch (IOException e) { e.printStackTrace(); }有人会问onPrepared回调难道不是已经在子线程了吗为什么还要考虑getDuration的耗时其实onPrepared回调所在的线程是Looper线程具体看你用的是什么Looper。如果你给MediaPlayer设置了主线程的Handler那onPrepared就跑在主线程上getDuration的Binder调用阻塞就仍然会卡UI。所以一个更稳妥的做法是在onPrepared回调里把getDuration的调用再丢到单独的子线程去执行。3.2 getDuration返回值的几种可能性我总结了一张表把getDuration可能返回的值和对应的业务含义列出来了。这张表我放在项目文档里团队新人看一遍就能少踩很多坑返回值状态/原因业务处理建议正数毫秒时长获取成功直接用于UI展示或逻辑判断0播放器尚未准备好或系统认为不需要时长不要直接展示等onPrepared后再取-1Native层返回错误通常是状态不正确或底层不支持尝试用备用方案获取非法状态异常在Idle/Initialized/Error状态调用修复调用时机这里要特别强调-1的情况。Android官方文档没有把-1写得很明确但实际开发中它是很常见的。如果你是在prepare之前调用getDurationJava层可能抛IllegalStateException也可能返回-1。不同系统版本行为不一致所以代码里必须做双重判断。我自己的项目里封装了一个时长获取工具类核心逻辑就是先判断状态机再调用getDuration拿到-1后自动降级到MediaMetadataRetriever方案。这个工具类后面会给出完整代码。3.3 网络流媒体场景下的特殊问题网络音频播放是getDuration问题的高发区。流媒体文件的时长信息不像本地文件那样生来就有而是要等播放器通过网络下载并解析元数据之后才知道。如果你的业务是播放一个在线MP3用户在播放器刚开始加载时就去拿时长很可能拿到-1。HLS流媒体m3u8就更特殊了。HLS本身是分片的m3u8播放列表里如果没有声明#EXT-X-ENDLIST说明这是一个直播流时长理论上应该是无穷大播放器会返回-1。而点播流如果包含#EXT-X-PLAYLIST-TYPE:VOD播放器可能会根据分片列表计算出总时长但也有些播放器版本不会立刻解析完所有分片。针对网络流媒体我建议的规避方案是不要依赖getDuration做核心逻辑先用MediaMetadataRetriever获取一次元数据对于HLS直播流直接放弃时长显示改成直播标签对于点播流如果30秒内拿不到时长就隐藏进度条避免用户看到异常这些细节如果你不做用户在实际体验中就会发现有的音频明明在播放但进度条一直是0或者进度条一闪而过这都是时长获取异常导致的用户体验问题。3.4 用MediaMetadataRetriever作为补充方案MediaMetadataRetriever是另一个可以获取媒体时长的类它的好处是不依赖MediaPlayer的状态机只要你给它一个有效的媒体源它就能尝试读取元数据。对于本地文件、HTTP链接、content://协议它都能处理。MediaMetadataRetriever retriever new MediaMetadataRetriever(); try { retriever.setDataSource(context, uri); String durationStr retriever.extractMetadata( MediaMetadataRetriever.METADATA_KEY_DURATION); if (durationStr ! null) { return Long.parseLong(durationStr); } } catch (Exception e) { Log.w(TAG, MediaMetadataRetriever failed, e); } finally { try { retriever.release(); } catch (IOException ignored) { } }这个方案的优点是简单直接适合在播放器初始化早期就拿到时长不用等MediaPlayer准备完成。它的缺点是内存开销和耗时尤其是对大型本地视频文件MediaMetadataRetriever内部可能会做一次完整的demux操作耗时可能几百毫秒到几秒不等。所以它更适合放在后台线程执行或者配合缓存方案只为同一个媒体源获取一次。我把这个方案作为兜底逻辑是先尝试MediaPlayer.getDuration如果返回-1或0再异步切换为MediaMetadataRetriever。这样既保证准确率又不牺牲主链路的响应速度。4. 实战封装一个可复用的媒体时长获取工具类说了这么多原理是时候给出一个可以直接抄作业的封装了。这个工具类我在多个项目里用下来整体稳定也兼容了几个常见的异常情况。它的设计原则有三个非主线程执行、双路获取、结果缓存。4.1 工具类设计思路整个工具类的入口是一个异步方法传入Context、Uri和回调接口。内部先走MediaPlayer路线如果失败就走MediaMetadataRetriever备选方案。拿到时长后缓存到LruCache中避免同一个媒体文件反复获取时长造成性能浪费。主线程调用会直接抛异常避免开发者误用MediaPlayer状态判断通过反射实现兼容不同Android版本时长结果的单位统一为毫秒异常时回调错误码由调用方决定UI策略public class MediaDurationFetcher { private static final LruCacheString, Long durationCache new LruCache(128); private static final long INVALID_DURATION -1L; public interface DurationCallback { void onSuccess(long durationMs); void onError(int errorCode); } public static void fetchDuration(Context context, Uri uri, DurationCallback callback) { if (Looper.myLooper() Looper.getMainLooper()) { throw new IllegalStateException(cannot call fetchDuration on main thread); } if (context null || uri null || callback null) { return; } String key uri.toString(); Long cached durationCache.get(key); if (cached ! null) { callback.onSuccess(cached); return; } long duration fetchFromMediaPlayer(context, uri); if (duration 0) { durationCache.put(key, duration); callback.onSuccess(duration); return; } duration fetchFromRetriever(context, uri); if (duration 0) { durationCache.put(key, duration); callback.onSuccess(duration); return; } callback.onError(ERROR_UNKNOWN); } private static long fetchFromMediaPlayer(Context context, Uri uri) { MediaPlayer mediaPlayer null; try { mediaPlayer new MediaPlayer(); mediaPlayer.setAudioStreamType(AudioManager.STREAM_MUSIC); mediaPlayer.setDataSource(context, uri); mediaPlayer.prepare(); // 这里会阻塞所以必须在子线程调用 return mediaPlayer.getDuration(); } catch (Exception e) { Log.w(TAG, MediaPlayer getDuration failed, e); return INVALID_DURATION; } finally { if (mediaPlayer ! null) { mediaPlayer.release(); } } } private static long fetchFromRetriever(Context context, Uri uri) { MediaMetadataRetriever retriever new MediaMetadataRetriever(); try { retriever.setDataSource(context, uri); String duration retriever.extractMetadata( MediaMetadataRetriever.METADATA_KEY_DURATION); if (duration ! null) { return Long.parseLong(duration); } } catch (Exception e) { Log.w(TAG, Retriever getDuration failed, e); } finally { try { retriever.release(); } catch (IOException ignored) { // release失败一般可以忽略 } } return INVALID_DURATION; } }这些代码是我从项目里精简出来的直接复制就能用。有几个细节说明一下fetchFromMediaPlayer里调用了prepare()而不是prepareAsync()因为这里本来就是子线程同步准备更省事。但要注意prepare()对某些网络源可能耗时较长需要配合超时机制否则一个挂起的网络请求会让你的线程池线程耗尽。我实际项目中给这个调用加了超时控制超出5秒就放弃。release()一定要放在finally里而且要防止重复调用。MediaPlayer不release会造成Native资源泄漏MediaMetadataRetriever也是一样。我在fetchFromMediaPlayer中加了setAudioStreamType这行代码在某些版本的Android上会对时长获取有影响。虽然是设置音频流类型但它会影响播放器的初始化参数从而间接影响某些编码器的时长解析。4.2 使用方式与接入注意事项使用这个工具类很简单但有几个注意事项要提醒必须在子线程调用主线程会直接抛IllegalStateException这是故意的回调结果默认切回主线程需要自己处理建议用Handler或者协程封装一层对于content://协议的UriMediaPlayer和Retriever都能直接处理但如果你的媒体数据来自加密的FileDescriptor那就要自己额外适配了new Thread(new Runnable() { Override public void run() { MediaDurationFetcher.fetchDuration(context, uri, new MediaDurationFetcher.DurationCallback() { Override public void onSuccess(long durationMs) { runOnUiThread(new Runnable() { Override public void run() { progressBar.setMax((int) durationMs); } }); } Override public void onError(int errorCode) { runOnUiThread(new Runnable() { Override public void run() { progressText.setText(未知时长); } }); } }); } }).start();在Kotlin项目里我更喜欢用协程包装这个工具类一行代码就能从挂起函数转换成回调。不过在文章里我还是用Java示例因为这是这个系列一贯的风格方便老读者对照。4.3 性能对比与选型建议我拿一个约8MB的MP3本地文件和一段约20秒的流媒体音频做过对比测试。结果如下方案本地MP3平均耗时流媒体音频平均耗时备注MediaPlayer.getDuration已prepare5~20ms10~50ms最快但需要先prepareMediaMetadataRetriever100~800ms200~1500ms较慢但不需要整个播放器先prepareAsync再取时长30~200ms50~500ms折中方案工具类双路方案5~1500ms10~2000ms按需选择结论很清楚如果你已经要播放这个媒体那直接走MediaPlayer的方案在onPrepared回调里取时长性能最好。如果你只是想在播放前展示时长信息比如列表页需要显示所有音频的时长那就用MediaMetadataRetriever虽然慢一些但不会触发整个播放器的初始化内存占用也更少。我见过有人为了在列表页显示所有歌曲时长在RecyclerView的onBindViewHolder里直接调用MediaMetadataRetriever结果列表一滑就卡成PPT。这是典型的在错误的地方用了对的工具。正确做法是只在数据准备阶段异步批量获取一次拿到结果后用Room或LruCache缓存下来。5. 常见问题与排查技巧实录这一节我把自己这些年踩过的坑和群里朋友问得最多的问题整理成一套速查表然后挑几个典型场景展开讲。排查思路可能比具体命令更重要因为MediaPlayer的很多问题在不同ROM上的表现都不一样。5.1 常见问题速查表现象可能原因排查思路getDuration返回0播放器尚未Prepared检查调用时机确保在onPrepared后调用getDuration返回-1状态错误或底层不支持尝试MediaMetadataRetriever兜底抛IllegalStateException在Idle/Initialized/Error状态调用用状态机判断后调用主线程卡顿Binder调用阻塞MediaPlayerService繁忙移到子线程调用本地视频返回时长偏大或偏小视频文件元数据损坏用第三方工具修复或重新封装文件HLS直播流返回-1直播流本身时长无限UI上隐藏进度条显示直播VBR MP3时长不准编码器未生成VBR头尽量使用规范的编码工具某些机型总是返回-1ROM定制了多媒体服务收集厂商信息针对性适配5.2 实战排查getDuration返回0的完整定位过程我举个例子曾经有个用户反馈在某个通话录音播放页面点击播放后进度条一直是0。我看日志发现getDuration确实返回了0但MediaPlayer的状态是对的onPrepared也回调了。这就有意思了。一步步排查先看MediaPlayer状态确认onPrepared已经回调状态没有问题看文件本身用MediaMetadataRetriever去读同一个小文件返回时长正常看MediaPlayerService日志发现音频文件是通过setDataSource(context, uri)传入的content://Uri进一步看MediaPlayerService的解析日志发现它无法open这个content://Uri对应的文件句柄因为权限不足确认是Android分区存储权限问题调用方没有申请读取该目录的权限最后解决办法是改用文件路径或者FileDescriptor方式传入数据源并检查运行时权限。这个问题很典型getDuration返回0有时候并不是时长获取的问题而是数据源本身没有被正确打开。我把这个案例总结成一句话getDuration返回0时先别急着怪播放器先确认MediaPlayer是不是真的能读到你要播放的数据。5.3 我的几个独家避坑心得第一个心得永远不要在主线程直接调用prepare() getDuration。就算是一次性获取时长也请放到子线程。哪怕你的本地音频只有几百KBprepare()内部要做的事情也远比你想的多解析文件头、读取元数据、初始化解码器、分配音频输出通道。这些操作加起来可能超过16ms甚至更久主线程一旦被阻塞用户马上就会感觉到掉帧或者ANR。第二个心得遇到getDuration多次调用结果不一致的情况优先怀疑缓存。项目里如果用了LruCache缓存时长就要考虑缓存Key的设计。同一个Uri可能对应不同的播放场景比如有加密参数的时间戳如果Key只用了base Uri拿到的是上一次的缓存结果自然就不准确。建议Key用uri.toString() # lastModified把文件最后修改时间也拼进去。第三个心得如果想要通过可视化方式调试MediaPlayer状态机市面上有一些开源的监控插件可以在悬浮窗里实时展示MediaPlayer当前处于哪个状态、时长获取结果是什么。我自己也做过一个类似的调试工具原理就是通过AOP拦截MediaPlayer的关键方法调用把状态机变化的轨迹实时刷新到悬浮窗。这个工具对排查状态混乱导致的时长异常特别有效。在正式环境我一般不会开这个功能只会在debug包开启。第四个心得自动化回归测试里如果想批量验证不同音频文件的时长获取是否正常可以借助自动化工具写脚本。比如用Python通过subprocess调用adb shell命令循环播放测试音频、抓取logcat里的时长数据再和预期值比对。这个思路和很多RPA工具的主流程调子流程类似本质上就是做任务编排和状态校验效率很高。我建议做多媒体功能的团队都建立这样一个自动化时长校验用例集每次发版前跑一遍能提前发现不少兼容性问题。5.4 还没有解决的深层问题最后说一个我研究过但至今没有完全解决的问题个别视频文件的getDuration返回结果与真实播放时间不符。这种情况多出现在某些短视频App缓存下来的视频它们使用了一种非标准的flv封装格式实际上是H.264 AAC裸流但文件扩展名是.mp4。MediaPlayer在解析这类文件时会尝试读取moov box如果没有找到完整的moov box就会走边下载边播放的模式时长自然就不准。我目前的应对方案是在获取时长之前先用轻量的方式检查文件头确认moov box的位置。如果moov box在文件末尾且文件较大就直接走MediaMetadataRetriever的慢速解析流程或者干脆让用户先播放再动态更新时长。这个问题没有根本解法因为非标准封装文件本身就缺少可靠的时长字段。6. 写在最后的动手建议整个getDuration的调用链路讲到这里其实已经把Java层、JNI层、C层和Binder服务端的过程都过了一遍。我个人的体感是MediaPlayer这套框架虽然老但设计得非常规整理解它的调用链对排查其他多媒体问题也有很强的迁移价值比如seekTo的调用流程、isPlaying的底层实现走的路径几乎一模一样。如果你正在做音视频相关的开发我的建议是找一个周末把AOSP源码里MediaPlayer.java、android_media_MediaPlayer.cpp这两份文件完整读一遍读的过程中对照着这篇文章提到的几个关键节点动手打断点跑一遍本地示例。只有自己亲手看一遍日志、看一遍源码执行顺序才能真正理解什么时候该用getDuration、什么时候该放弃这个API。还有一个建议在你的项目里把时长获取逻辑单独抽成一个模块不要散落在各种Activity里。这样即使以后换播放器方案比如换ExoPlayer或者自研播放器迁移成本也会低很多。时长获取是所有播放器都绕不开的基础能力值得做好沉淀。