Android音频系统学习二：Android音频框架

第二章：Android 音频框架

音频系统算是在Android中一个比较复杂的模块，他的整体框架和Android是一样的，先看一下他的框架图：
对于上面的框架图我们主要看一下audio相关的，因为AudioTrack只能播放pcm、wav格式的文件，即原始的音频数据，至于MP3、MP4等格式的文件就需要通过解码得到pcm文件，然后在通过AudioTrack去播放，既然不用去解码那么音频系统就做播放数据这么简单事情吗？实测不然，我们使用手机播放声音的时候，声音需要通过什么设备输出（speaker、耳机…）声量大小的调节、音效、混音等等这些都是需要音频系统去做处理的，涉及到的场景很多，因为我目前工作其实多数就是负责音频Framework的问题处理，由于场景的复杂性让初学音频的我有点头疼；

二、Audio System 中重要的类和服务：

AudioTrack：提供给应用开发的外部类，主要负责播放声音数据，处于音频框架的应用层，应用开发者通过调用AudioTrack去实现播放功能

AudioRecord：提供给应用开发的外部类，主要负责声音数据的采集，同AudioTrack一样给应用开发者调用实现录音功能

AudioFlinger:它是Audio系统的工作引擎，管理着系统中的输入输出音频流，并承担音频数据的混音，以及读写Audio硬件以实现数据的输入输出等工作。

AudioPolicyService：它是Audio系统的策略控制中心，具有掌管系统中声音设备的选择和切换、音量控制等功能。

AudioSystemServer：协调AudioPolicy和AudioFlinger 的交互，因为上面提到AudioFlinger是音频系统的引擎，它是去负责和audiohal----> Audio Driver交互的,而AudioPolicy只决定策略的选择，如设备的切换、音量的大小等，都是通过command 传给AudioSystemServer再去Call AudioFlinger的接口去实现策略，也就是说AudioFlinger就是一个真正的“打工人“，而AudioPolicy只负责“想”，活得AudioFlinger来干；实现音频相关的功能了；

注：AudioFlinger和AudioPolicy处于Framework层，是音频系统的两大服务，AudioTrack/AudioRecoder 通过这两个服务就可以实现Audio的相关功能；

Audio HAL：Audio 硬件抽象层，负责和TinyALSA交互，这块后面再看下代码单独补一篇分析
框架大概就是这样，目前还没加入代码分析，后续就开始从上往下结合代码学习一下流程，一点一点的完善；加油！