AndroidAudio架构⾃学笔记（⼀）
由于⾃⼰的⼯作内容是和android 系统audio 相关，虽然只是调⽤了Android的⼏个NDK接⼝进⾏⾳频数据的采集以及转码⼯作，但是我还是趁着这个契机好好的认真的学习⼀下android audio的整体框架，来丰富⾃⼰的知识库。在此记录下⾃⼰的学习过程，如果有幸有⼈在此和我讨论以及分享⾃⼰的内容，那么我将不胜感激。话不多说，直接进⼊正题。
虽然具有争议，但是我仍然认为android系统在本质上与linux系统没有区别，只是对linux系统上的部分系统组件进⾏了添加以及优化。在⽤户空间上增加了⼀套完整的framework框架来实现⾃⼰的特定功能需求，所以liunx系统上的很多概念仍然在安卓系统之上仍然适⽤。
在传统的linux系统上，⼀个依赖于具体的物理设备的⽤户系统，⼤概分为⼏个部分：物理硬件、操作系统、设备驱动（内核空间）以及⽤户程序，对此在安卓上也仍然适⽤。
安卓系统软件开发培训不过在Android系统上，为了避免Linux系统的对于软件开源的具体要求，将传统的设备驱动程序进⾏了再次拆分为驱动程序以及⽤户空间的驱动程序（HAL）。通过这种设计，部分硬件⼚商就可以将具有⾃主产权的设计功能放在HAL层实现，只需要向外提供接⼝以及动态库就可以，不必将源码开源。随着安卓系统的逐步发展，这种⽅式在安卓系统上以及成为主流。（部分商⽤Linux系统项⽬也将这部分内容借鉴过来了）。
对于⽤户程序，安卓系统设计了⼀条⾃⼰的框架，通过使⽤这套框架，应⽤程序开发⼈员就可以不⽤关注于底层特别复杂的逻辑设计，只要关注于⾃⼰应⽤业务就可以了。
⾄此就形成了安卓系统的整个设计⽣态。对于Android 的Audio软件架构如下：
（1）由⼚商⾃定义的Audio HAL或者是安卓⾃带的tinyalsa程序与Linux kernel 驱动程序构建成了安卓系统与硬件交互的最底层软件程序
（2）AudioPolicy与AndroidFlinger为核⼼构建了Android audio framework层，直接与最底层程序进⾏交互。
  主要职责为：
  向HAL层写⼊⾳频数据进⾏⾳频播放。从HAL层采集⾳频数据进⾏⾳频数据传输或者保存。（audioFlinger）
  根据应⽤场景以及具体配置，对⾳频通路的控制，即在什么场景之下，声⾳应该从哪个设备上发声（audioPolicy通过控制audioFlinger 来进⾏实现）
（3）audioTrack以及audioRecord为Android audio framework层对上层提供的接⼝，⽤户应⽤程序可以通过audio Track与Audio fligner进⾏交互。（⽤户可以通过audioSystem与audioPolicy进⾏交互）
（4）应⽤程序负责客户业务需求的实现。
这样由下到上就构筑了andriod audio的基本框架。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。