本文详细阐述了Android多媒体框架的构建基础，包括核心组件、依赖关系及其实现方式。深入理解多媒体库如OpenCORE、vorbis和sonivox的作用，以及它们如何通过一致的接口为各种服务提供支持，使得多媒体处理变得更加透明和高效。通过展示多媒体框架类层次结构简化版，揭示了关键类及其在不同模块中的实现细节，如libmedia、libmediaplayerservice和libmedia_jni等。同时，文章强调了Android应用与媒体服务器进程之间的分离，以及通过Binder IPC机制进行通信的机制。最后，解释了为什么MediaPlayer类不提供使用内存流作为源的API，这是由于内存流的数据空间与媒体服务器进程不直接共享。
The figure below shows the dependency relationships between libraries of the media framework.
The core of the media framework is composed of libmedia, libmediaplayerservice and libmedia_jni. Their codes reside in frameworks/base/media folder.
libmedia defines the inheritance hierarchy and base interfaces. It’s the base library.
libmedia_jni is the shim between java application and native library. First, it implements the JNIspecification so that it can be used by java application. Second, it implements the facade patternfor the convenience of caller.
libmediaplayerservice implements some of concrete players and the media service which will manage player instances.
The figure below shows the class hierarchy.
Note the BpInterface and BnInterface are template classes. Any instantiation of them also inherit the template argument INTERFACE as well.
In the class hierarchy diagram, though listed as a separate module, binder is actually implemented inside libutils component whose source code locate at /frameworks/base/libs/utils folder.
An interesting thing to note is in android, the application that intends to show the media content and the player that actually renders the media content run in different process. The red line in the sequence diagram below shows the boundary of two processes.
The figure shows three most common operations, creating a new player, setting datasource and playing. The last MediaPlayerBase object is the interface that MediaPlayerService::Client object uses to refer to the concrete player instance. The concrete player can be VorbisPlayer, PVPlayer, or any other player, depending on the type of the media to be played.
When an application creates a android.media.MediaPlayer object, it’s actually holding a proxywhich can be used to manipulate the concrete player resides in the mediaserver process. During the whole procedure, two process communicates with Binder IPC mechanism.
Having knowledge above, it’s not difficult to understand why MediaPlayer doesn’t provide an API to use memory stream as source. Because the memory manipulated by the stream is in the address space of the application, and it’s not directly accessible by the mediaserver process.
References:
扫一扫
103
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
