码迷,mamicode.com
首页 > 移动开发 > 详细

Android Multimedia框架总结(四)MediaPlayer中从Java层到C++层类关系及prepare及之后其他过程

时间:2016-09-03 09:49:44      阅读:210      评论:0      收藏:0      [点我收藏+]

标签:

转载请把头部出处链接和尾部二维码一起转载,本文出自:http://blog.csdn.net/hejjunlin/article/details/52420803

前言:在上篇中,分析了MediaPlayer的从创建到setDataSource过程,尽管看了代码,但是没有从MediaPlayer生态上认识各类库之间依赖调用关系,在本篇中将作一个补充整体上的认识。看下今天的Agenda:

  • MediaPlayer各个so库之间关系结构图
  • MediaPlayer各个具体类之间依赖关系图
  • prepare的执行过程
  • prepareAsync执行过程
  • prepare和prepareAsync区别
  • start执行过程
  • pause执行过程

MediaPlayer各个so库之间关系结构图

技术分享

在各个so中,libmedia.so位于核心的位置,它对上层的提供的jni主要是Java中MediaPlayer类,类libmedia_jni.so通过调用MediaPlayer类提供对Java的接口,并且实现了Android.media.MediaPlayer类。
libmediaplayerservice.so是Media的服务器,它通过继承libmedia.so的类实现服务器的功能,而libmedia.so中的另外一部分内容则通过IPC和libmediaplayerservice.so进行通信。libmediaplayerservice.so的真正功能通过调用OpenCore Player来完成解码。OpenCore是一个多媒体的框架,从宏观上来看,它主要包含了两大方面的内容:

  • PVPlayer:提供媒体播放器的功能,完成各种音频(Audio)、视频(Video)流的回放(Playback)功能
  • PVAuthor:提供媒体流记录的功能,完成各种音频(Audio)、视频(Video)流的以及静态图像捕获功能
  • PVPlayer和PVAuthor以SDK的形式提供给开发者,可以在这个SDK之上构建多种应用程序和服务。在移动终端中常常使用的多媒体应用程序,例如媒体播放器、照相机、录像机、录音机等等。
  • OpenCore组织了codec等一些组建,统一接口,MediaPlayer调用OpenCore的东西,不用太关心下层的codec是什么,这个库在6.0上已经不用,代替它的是Stagefright,比OpenCore简洁很多。
    MediaPlayer部分的头文件在frameworks/base/include/media/目录中,这个目录是和libmedia.so库源文件的目录frameworks/base/media/libmedia/相对应的。主要的头文件有以下几个:
    • IMediaPlayerClient.h
    • mediaplayer.h
    • IMediaPlayer.h
    • IMediaPlayerService.h
    • MediaPlayerInterface.h

在这些头文件mediaplayer.h提供了对上层的接口,而其他的几个头文件都是提供一些接口类(即包含了纯虚函数的类),这些接口类必须被实现类继承才能够使用。

MediaPlayer各个具体类之间依赖关系图

技术分享

整个MediaPlayer在运行的时候,可以分成Client和Server两个部分,它们分别在两个进程中运行,它们之间使用Binder机制实现IPC通信。从框架结构上来看,IMediaPlayerService.h、IMediaPlayerClient.h和MediaPlayer.h三个类定义了MeidaPlayer的接口和架构,MediaPlayerService.cpp和mediaplayer.cpp两个文件用于MeidaPlayer架构的实现,MeidaPlayer的具体功能在PVPlayer(库libopencoreplayer.so)中的实现。

prepare的执行过程

技术分享

prepare播放器为playback,这是个同步方法,当setDataSource且展现了surface,你应当开始调用prepare或prepareAsync方法,对于文件类型,调用prepare方法将暂时block,直到MediaPlayer已经为playback准备好。接着调用native层android_media_MediaPlayer_prepare方法:

技术分享

上述1,2,3 我们在上一篇中,曾结介绍过,1中getVideoSurfaceTexture是获取一个IGraphicBufferProducer类型指针,2中是setVideoSurfaceTexture,这个xxx中最后的部分介绍过,这里不再细说。3中是个判定并且notify的方法,这里是送进mp->prepare的方法调用的状态送入,如果不ok,就notify相关error或者抛出异常。我们知道还有一个prepareAsync方法,我们前面的思路都是顺着MediaPlayer中create方法来的。

prepareAsync的执行过程

如果是下面这种场景,一个网络url送过来,视频非常大:这时就要用到异步prepare

技术分享

看下MediaPlayer中prepareAsync方法: 准备好播放器为接下来playback,这是个异步方法,当setDataSource且展现了surface,你应当开始调用prepare或prepareAsync方法了,对于流类型,你应该调用prepareAsync方法能立马返回,而不是在没有足够的流数据被缓冲时一直block

技术分享

本文出自逆流的鱼yuiop:http://blog.csdn.net/hejjunlin/article/details/52420803

这是个native方法,我们看android_media_MediaPlayer_prepareAsync方法:

技术分享

从代码上看,除了最后process_media_player_call中mp->prepareAsync()判断状态时,不一样,其他和prepare都是一样。它的操作结果经过回调通知给Java层。
看下media/mediaplayer.h中prepareAsync函数,c++代码:

技术分享
技术分享
技术分享

上面代码总结为:首先判断mFlags,此时不是preparing。接着启动mQueue(类TimedEventQueue)。之后修改mFlags的状态为PREPARING,表示现在正在准备处理文件的音视频流。然后通过实例一个AwesomeEvent,然后放到之前启动的mQueue中进行通知出去。
queue中处理的结果就是调用AwesomePlayer::onPrepareAsyncEvent函数。后面的过程就是初始化解码器,将流解码出来,也能知道视频流的宽高等属性,然后通知prepared.不再向下跟踪。prepare的流程就完成了。

接下来,我们再回到java层中之前prepare方法中的scanInternalSubtitleTracks()方法

技术分享

这个方法是扫描内嵌字幕并进行跟踪.

start的执行过程

接下来分析看下MediaPlayer中start过程:

技术分享

以上代码总结为:start方法用于start或者重新恢复播放,如果playback先前已暂停,playback将开始从paused状态变成在start状态,如果playback已经是stopped,或之前从来没有started过,playback将会开始start。
3中执行stayAwake()中是对屏幕进行操作:

  • 首先PowerManager pm = (PowerManager)getSystemService(Context.POWER_SERVICE);
  • 通过 Context.getSystemService().方法获取PowerManager实例。
  • 然后通过PowerManager的newWakeLock((int flags, String tag)来生成WakeLock实例。int flags指示要获取哪种WakeLock,不同的Lock对CPU、屏幕、键盘灯有不同影响。获取WakeLock实例后通过acquire()获取相应的锁,然后进行其他业务逻辑的操作,最后使用release()释放(释放是必须的)。
    关于int flags,各种锁的类型对CPU 、屏幕、键盘的影响:
    • PARTIAL_WAKE_LOCK:保持CPU 运转,屏幕和键盘灯有可能是关闭的。
    • SCREEN_DIM_WAKE_LOCK:保持CPU运转,允许保持屏幕显示但有可能是灰的,允许关闭键盘灯
    • SCREEN_BRIGHT_WAKE_LOCK:保持CPU运转,允许保持屏幕高亮显示,允许关闭键盘灯
    • FULL_WAKE_LOCK:保持CPU运转,保持屏幕高亮显示,键盘灯也保持亮度
    • ACQUIRE_CAUSES_WAKEUP:正常唤醒锁实际上并不打开照明。相反,一旦打开他们会一直仍然保持。当获得wakelock,这个标志会使屏幕或/和键盘立即打开。一个典型的使用就是可以立即看到那些对用户重要的通知。

最后通过updateSurfaceScreenOn()进行,更新屏幕上的Surface.我们还是回到最上面start方法中。最后会调用_start方法到native jni中。

技术分享

从中间的mp-start开始,就调到底层c++,在native中引入media/mediaplayer.h,我们进入这个头文件看看:

技术分享

从接口中可以看出MediaPlayer类实现了一个MediaPlayer的基本playback操作,播放(start)、停止(stop)、暂停(pause), 重置(reset)等。
另外的一个类DeathNotifier在MediaPlayer类中定义,它继承了IBinder类中的DeathRecipient类,这些作用都是为了进程间通信准备:

技术分享

以下过程就是和mediaplayerservice通过IPC进行通信,不再向下分析。
可以发现start后,底层来返回一个状态,是ok还是不ok的。这就回到process_media_player_call中判定这个返回的状态,然后notify java层中的回调函数。

pause的执行过程

接下来,再看下pause方法,

技术分享

在对应的jni中找到android_media_MediaPlayer_pause方法

技术分享

pause方法,可以看到和start的流程类似,也是通过 mp->pause()返回对应的状态,然后notify上层去pause

还有一个stop方法也是类似,这里不再分析。

第一时间获得博客更新提醒,以及更多android干货,源码分析,欢迎关注我的微信公众号,扫一扫下方二维码或者长按识别二维码,即可关注。

技术分享

如果你觉得好,随手点赞,也是对笔者的肯定,也可以分享此公众号给你更多的人,原创不易

Android Multimedia框架总结(四)MediaPlayer中从Java层到C++层类关系及prepare及之后其他过程

标签:

原文地址:http://blog.csdn.net/hejjunlin/article/details/52420803

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!