android多媒体框架介绍（一）整体架构

android 四层 架构概述

在理解android多媒体框架之前，先理解android的四层架构。

1、应用层 Applications（JAVA为主）：
应用是用Java语言编写的运行在虚拟机上的程序，即图中最上层的蓝色部分，也就是我们常说的APK。Google最开始时就在Android系统中捆绑了一些核心应用比如e-mail客户端、SMS短消息程序、日历、地图、浏览器、联系人管理程序，等等。这一层媒体相关的应用 如 Exoplayer，Yutube，NetFlix，截屏 录屏应用等。

2、应用框架层Application Framework（JAVA）：
应用所使用的API框架，开发人员用这些框架来开发应用，提高开发效率，典型组件如下：
丰富而又可扩展的视图（Views System）：用于UI设计，包括列表lists、网格grids、文本框text boxes、按钮buttons等。
内容提供器（Content Providers）：它可以让一个应用访问另一个应用的数据（如联系人数据库），或共享它们自己的数据
资源管理器（Resource Manager）：提供非代码资源的访问，如本地字符串、图形、和布局文件（layout files）。
通知管理器 （Notification Manager）：应用可以在状态栏中显示自定义的提示信息。
活动管理器（Activity Manager）：用来管理应用程序生命周期并提供常用的导航退回功能。
窗口管理器（Window Manager)：管理所有的窗口程序。
包管理器（Package Manager）：Android系统内的程序管理
电话管理器(Telephony Manager)：主要提供Telephony相关信息的查询/修改功能，以及Phone状态监听功能。
定位管理器(Location Manager)：获取经纬度及定位过程

3、系统库和虚拟机运行环境层（C/C++）：
Android系统会通过一些C/C++库来支持各个组件，常被成为中间件层次，并且C++执行效率比JAVA更高。核心库与虚拟机共同构成了Android的运行时框架，提供对上层Java代码的编译解析能力。（由于是c/c++语言实现的，与上层Java通过JNI实现相互调用，JNI提供了Java可以调用c/c++的一种机制，属于Java虚拟机的一部分）

典型库包括：
C库：C语言的标准库，这也是系统中一个最为底层的库，C库是通过Linux的系统调用来实现。
Media Framework多媒体框架：这部分内容是Android多媒体的核心部分，该库支持多种常用的音频、视频格式的回放和录制以及一些图片，比如：MPEG4、MP3、AAC、AMR、JPG, PNG等。
SGL：2D图像引擎。
SSL：即Secure Socket Layer位于TCP/IP协议与各种应用层协议之间,为数据通讯提供安全支持。
OpenGL ES 1.0 ：本部分提供了对3D的支持。
Surface Management界面管理工具：本部分提供了对管理显示子系统等功能。
SQLite：一个通用的嵌入式数据库，和mysql类似。
WebKit：网络浏览器的核心
FreeType：位图和矢量字体的功能。

Android Runtime运行时，主要指Dalvik虚拟机。每个Java程序都运行在自己的Dalvik虚拟机之上。
Dalvik虚拟机和一般Java虚拟机（Java VM）不同，它执行的不是JAVA标准的字节码（bytecode ）而是Dalvik可执行格式（.dex）中执行文件。在执行的过程中，每一个应用程序即一个进程（Linux的一个Process）。 二者最大的区别在于Java VM是以基于栈的虚拟机（Stack-based），而Dalvik是基于寄存器的虚拟机（Register-based）。显然，后者最大的好处在于可以根据硬件实现更大的优化，这更适合移动设备的特点。

4、Linux内核层（C）：
Android的核心系统服务基于内核，如安全性、内存管理、进程管理、网络协议栈和驱动模型等都依赖于Linux。Linux内核同时也作为硬件和软件栈之间的抽象层，主要的驱动如下所示：
显示驱动（Display Driver）：基于Linux的Frame Buffer驱动，用于内容显示。
键盘驱动(KeyBoard Driver)：作为输入设备的键盘驱动。
Flash内存驱动（Flash Memory Driver）：基于MTD的Flash驱动程序。
照相机驱动（Camera Driver）：常用的基于Linux的v4l2（Video for Linux）驱动。
音频驱动（Audio Driver）：常用的基于ALSA（Advanced Linux SoundArchitecture）的高级Linux声音体系驱动。
蓝牙驱动（Bluetooth Driver）：基于IEEE 802.15.1标准的无线传输技术。
WiFi驱动（Camera Drive）：基于IEEE 802.11标准的驱动程序。
Binder IPC驱动：Android的一个特殊的驱动程序，具有单独的设备节点，提供进程间通讯的功能。

android 多媒体整体框架 示意

android的多媒体框架如今已经演变得非常复杂的，这里面原因多种多样，后续争取逐步总结完整。
我们先用一个最基础的mediaplayer播放视频示意图看一下与架构之间的关联（实际android各种完整的媒体通路要更复杂数十倍以上），用户创建一个播放器APK或者APK需要播放一个视频，通过framework层的mediaplayer进行调用播放，mediaplayer会通过mediaserver在native服务层取找到解码器，通过软件解码 或者 硬件解码（如GPU等来实现）进行解码，然后通过surface进行显示。最后surface要送显示。这个时候需要通过linux的显示驱动 framebuffer来送到底层硬件驱动中，操作硬件把画面显示出来。

一个视频播放总体思路还是：APK触发媒体业务，通过Application Framework封装的API进行业务播放，然后Framework到本地系统库层级去指定 解码与显示 通路组合（这里选择非常多样，一部分与APK传递的参数相关，更多的还和不同媒体使用场景决策，设备类型与配置相关，后面会提到），从解码选择 的硬解码还是软解码不同 决定是否要使用底层linux硬件解码驱动，根据显示通路选择 对应 linux底层驱动进行画面显示。

讨论一下android多媒体通路如此复杂的原因

个人总结了android多媒体通路演变得如此复杂的原因，主要有以下几点：
1、android本身架构演讲变化。
举个例子，流媒体框架从2.3版本开始引入，其中最核心的流媒体播放器是Nuplayer，本地播放使用的是Awesomeplayer+stagefightplayer，后续版本中到5.0开始 本地播放也开始基于Nuplayer。media相关API也在演进中，一些旧的API会逐步淘汰。

2、硬解码引入。
使用纯CPU进行软解码随着视频分辨率帧率的提升，效率变得很低，对性能影响也更大。伴随版本的迭代，逐步引入硬件解码，后续会介绍到mediacodec。硬件解码可以使用GPU进行实现，相对CPU并行效率更高，也有硬件厂商单独做解码器硬件设备，这样能解放GPU的视频解码工作，进行8K60hz甚至更高的8K120hz设备也能流畅的完成解码。

3、电视/机顶盒 等 强视频显示 业务形态影响。
最开始的android并没有针对视频内容做特殊的优化，更多的是偏向图形绘制的设计，视频只是作为一个单纯的图形窗口和其他图形界面进行统一叠加显示。但是随着电视/机顶盒的android智能系统推出，对视频画面显示效果的要求出现了更高的需求，此时不能把视频和普通图形界面进行相同的处理，硬件设备厂商需要做单独的视频通路 和 图形显示通路，android系统也需要进行适配，后续会介绍类似overlay通路，就是应对这类场景。很多设备厂商也会做自己的私有方案（同自己设备匹配度更好的私有软硬件整体方案，往往在功耗，延时，流畅度，性能，效果等方面有更突出的表现），白名单的方式开发给部分APK，形成差异化竞争力。

4、对于不同显示场景 不同述求 的 业务细化。
视频内容显示场景多种多样，不同场景有各自的显示述求。举个例子，当我们在浏览器中打开一个小窗口预览视频，此时我们可能对效果要求不高，更在意视频和UI的匹配程度，在滑动界面过程是否更顺滑，拖动视频移动反馈如何。而我们全屏打开一个视频，就会更关注显示效果是否最优，显示流程度是否最佳，附加特性如HDR或者3D效果是不是支持，如果是TV电视形态 还会对视频画面风格调教要求更高。如果是电视通过HDMI连接游戏机或者看网络在线直播，相对流程度和效果，会更关注延时是否足够低。在一些手持设备上，有时为了低功耗也会主动牺牲部分场景的显示效果。 总而言之，在 功耗，延时，流畅度，性能，效果，附加特性支持 各种因素的权衡取舍，形成了多种多样的媒体通路。

典型android 多媒体通路整理（待补充）