android 是一个很大的世界，凭借个人的能力想要把它全部弄懂，不太现实。花了很多的时间看了一些（谦虚点）android的源码，去了解它的流程，每次看完一个模块的代码（只是浏览完代码，具体细节并不一定知道），总觉得也就那样，感觉跟搭不上关系，这也就是很多人都有的心理（学那个有什么用，你又不弄那个等等之类）。当然，我不是这样的心理。
如果是分散的，单独的看某个模块的源码，发现有很多流程都串不起来，很难想象到底是不是这样实现的。我有时候也觉得自己对android了解得挺多的，意思是范围很广，但是并没有用，因为不清楚里面的细节，所以还是外行人，于是我改变了学习的方向，今后有时间的话基本上就会认真研究一下android的录制和播放这两个大头。当然不仅仅只是录制或播放这个模块本身的流程，而是把与之相关的模块也要掌握。重点是数据流，数据在各个模块的结构，各个模块对数据做了那些处理。
关于模块的学习，我想分享一下我的看法，就我目前所在的公司要求而言，可以分成三个层次。
1、了解了这个模块的流程，也就是说这个模块的代码你基本看不不止两三遍，对里面的很多细节和流程都知道了，即使忘记了或者记不太清楚了，仍然可以快速找到代码的位置，再认真看看，然后就懂了。
2、能够找到模块里面的bug，不要认为android 的代码就是完美的，没有bug，公司提供的是android系统的技术支持，所以经常会有各种各样的问题，当然android原生的问题比较少，很多都是我们修改了一些需求，或者做了客制化而引入，找bug也是一件比较困难的事，如果没有一定的经验，即使你对这个模块再熟悉，也很难快速找到问题的原因，因为有可能是这个模块的上游或者下游的问题。
3、为了新的需求而修改模块的代码，为什么说这个更难做，更具有挑战性呢？主要是这个要考虑的太多了，比如是否会影响原先的功能，会不会引入新的问题，修改之后能否满足需求。一般新手是没有机会做这件事的，都是需要更有经验的人来做。不得不吐槽一下，有些客户的需求这是奇怪，android原生就不支持，但是他们硬是要你修改，把原来的代码改得乱七八糟。
关于上面三个层次，我个人的理解是 第一个对应的是技术支持，第二个对应的是开发维护，第三个对应的是？？
录制相关模块结构图
从硬件（摄像头\麦克风）出数据到最上层将数据打包好写到文件，真心要全部弄懂，的确需要好多时间呀，这些模块基本都有看过，有一些我只是大致浏览（也就是说上面提到的三个层次连第一个都达不到）。
数据流是自下而上
1、ALSA linux的声卡架构，在android中用的是soc-alsa，可以认为是在标准alsa基础上的进一步架构。 soc-alsa分为machine，platform和codec三个部分，这部分可以简单的认为是audio的driver部分（实际上alsa只是一个audio driver的架构，真正的driver部分还需要单独去实现）。
2、tinyalsa 调用alsa接口的封装，上层和driver打交道基本上都是通过ioctl来完成的，所以tinyalsa可以认为是ioctl调用的进一步封装，方便上层调用。
3、audio hal audio抽象层，android里面搞的一个东西，hal 怎么理解呢？android 只是定义了一系列的函数指针集合，然后厂商把这些函数指针指向他们对应的实现函数，这样上层调用定义好的函数指针，就相当于调用厂商们的实现函数了。
4、audioFlinger 它还有一个和它在同一层次，但权利比它大的兄弟audioPolicy，先简单把他们理解成为service 。
5、AudioSource 负责从audioFlinger 拿audio 数据的模块，一般情况下会跨进程，数据跨进程传递，大家会认为使用到了binder来传输数据，其实并不是，其他并不是，这里用到的是Ashmem，共享内存，通过sys_call 的方式来实现进程同步。
6、imgSensor （相关的东西太多了，只提一下camera driver），没有看出这个模块认为camera 出来的数据会先到driver，或者driver里面能够操作到实际数据，其实并不是，camera driver 起的是控制作用，比如给imgSensor上电，设置寄存器参数而已。实际的数据是通过硬件送到isp模块，当然中间还有很多硬件电路。
7、ISP/MDP ISP会对送进来的camera 数据进行处理，如果送进来的是raw data（原始数据），还有转换成yuv格式的数据，MDP也是一个硬件模块，主要功能是对video （camera 图像等）进行裁剪，缩放等。
8、camera hal 这里面的东西好多呀，不同厂商实现应该都不一样。这里面的代码才是真正的实现部分，比如录制的帧率，分辨率等都在这里面实现。
9、camera framework 作为service ，对应用层（或者其他模块）提供接口
10、录制模块 录制模块拿到audio和video数据后，会分别送到encoder 模块去编码，编码完成后写到文件里面。
11、OMX android里面的编码/解码模块， 都是android 定义好的构架，厂商们在做具体的实现，公司里面的编解码这部分用的都是自己开发的，用的是硬件模块进行编解码，那时候抽了点时间看了一下，实在是看不下去了，代码写得实在是乱，各种宏定义，config 控制（就是 #ifdefine #endif 之类），甚至多层次的嵌套，大概知道是又调用了相关的硬件，最终又是ioctl和driver打交道。
12、gralloc 这部分的源代码看不到，不知道里面的具体实现，但是大致的功能是对buffer的管理，像camera 的buffer。
播放相关模块结构图
数据流是自上而下
1、source 数据的来源（可以是本地文件，或者网络视频流等）
2、extractor 负责对数据进行解析（分离出audio 和 video）
3、decoder 分离出来的audio和video数据被分别送到decoder模块进行解码
4、解码后的video数据被送到surfaceflinger，最后输出到屏幕
5、解码后的audio数据被送到audioflinger，最后通过扬声器播放出来
6、audio 硬件上的结构，在内部的资料上看到过，不过现在记不太清了，其实这部分的核心有几个，比如回音消除，混音（mix）等，其他的，比如增益的调正（设置高音，低音等），我看了一下基本上就是操作对应的寄存器，给寄存器设置对应的值来完成。
7、HWComposer 可以认为是surfaceflinger 的hal层，surfaceflinger要显示的数据都会送到HWComposer，然后HWComposer送到fb（linux的东西），最后送到lcm去显示，当然可以是其他显示设备。当然如果不是一个图层时，会先调用硬件模块进行叠图。
8、overlay 硬件叠图模块 ，公司设计的硬件叠图模块一次最多只能叠4张，如果超过了4张，多余的会交给gpu去叠图。
录制，播放和目前的工作有些关系，上面列的模块也很多，我只是其中一个模块而已，具体说来是负责camera hal 和 camera framework，camera hal也只是负责一部分而已，今后的博客基本和上面这些模块的相关。
