分析AudioTrack之前先分析一下AudioTrack和MediaPlayer的区别：
-
AudioTrack 只能播放 pcm 原始数据，不能播放视频。
-
MediaPlayer 可以播放视频和音频。
-
AudioTrack 只支持 pcm 原始音频数据。
-
MediaPlayer 支持 mp3,wav,aac…
-
MediaPlayer 在底层会创建指定的格式的解码器，将音频数据转化为 pcm 然后再交给 pcm
去播放。MediaPlayer底层会创建 AudioTrack，将解码后的数据交给 AudioTrack 播放。 -
每一个音频流对应着一个AudioTrack类的一个实例，每个AudioTrack会在创建时注册到
AudioFlinger中，由AudioFlinger把所有的AudioTrack进行混合（Mixer），然后输送到AudioHardware中进行播放，目前Android同时最多可以创建32个音频流，也就是说，Mixer最多会同时处理32个AudioTrack的数据流。
个人感觉AudioTrack梳理起来的过程是非常痛苦的，中间可能也有很多问题，参考了很多博客，还有实习师傅的指导，整理一篇Android P的AudioTrack流程初文出来，以后工作用的多了熟悉了，再修改。
AudioTrack的构造函数分析：
android\frameworks\base\media\java\android\media\AudioTrack.java
走private的构造函数。
获取主线程的Looper，异步消息通信的机制。
获取采样率，声道掩码，编码类型，然后验证参数是否合法
调用native层的native_setup
native_setup()
android\frameworks\base\core\jni\android_media_AudioTrack.cpp
进入JNI层
创建native层的AudioTrack。
android\frameworks\av\media\libaudioclient\AudioTrack.cpp
进到lib层，通过set()方法将参数设置进去
status_t AudioTrack::set()
创建IAudioTrack.
获取音频策略服务。
frameworks\av\media\libaudioclient\AudioSystem.cpp
通过binder机制绑定服务。
android\frameworks\av\media\libaudioclient\AudioTrack.cpp
进入AudioFlinger
android\frameworks\av\services\audioflinger\AudioFlinger.cpp
依据播放线程ID号查找出相应的PlaybackThread，依据客户端进程pid查找是否已经为该客户进程创建了Client对象。假设没有，则创建一个Client对象。
依据进程pid。为请求播放音频的client创建一个Client对象。
AudioFlinger的成员变量mClients以键值对的形式保存pid和Client对象。这里首先取出pid相应的Client对象，假设该对象为空。则为client进程创建一个新的Client对象。MemoryDealer是个工具类。用于分配共享内存。每个Client都拥有一个MemoryDealer对象，这就意味着每个client进程都是在自己独有的内存空间中分配共享内存。
创建了如同所示的内存大小。
返回继续看AudioFlinger::createTrack()
frameworks\av\services\audioflinger\Threads.cpp
创建Track对象
前面进行一系列的参数赋值，最后返回一个track对象。
进入Track的构造函数，由图可见，继承于TrackBase，因此先进入TrackBase的构造函数进行分析。
TrackBase()
thread,所属播放线程，client所属的客户端，sampleRate，采样率，format音频格式，channelMask，声道，frameCount，音频帧个数。sharedBuffer，共享内存。
得到应用进程id
计算存放音频的buffer大小。
Client不为空。就通过Client来分配buffer,为空，则通过mallc动态分配。
由此可见，TrackBase构造过程主要是为音频播放分配共享内存。
接着进入Track的构造函数进行分析。
为0创建AudioTrackServerProxy代理对象，不为0，创建StaticAudioTrackServerProxy代理对象；
接下来我们返回AudioFlinger的createTrack函数中，来看这个track对象到底做了什么事情。
android\frameworks\av\services\audioflinger\AudioFlinger.cpp
创建Track的binder对象TrackHandle，Track由于需要通过binder返回给AudioTrack，因此是个binder对象，该对象会包含share buffer的信息。由于share buffer不止会在AudioFlinger这端被读取，还会在AudioTrack这端被写入，因此创建出来的Track需要被传送回AudioTrack。而在binder间传送对象只有binder对象，因此需要构建binder对象TrackHandle，返回给AudioTrack。
frameworks\av\services\audioflinger\Tracks.cpp
至此，createTrack_l在AudioFlinger这端的工作基本完成了。
ps:这里我绕的不太清楚：可参考其他博客：[Android] createTrack_l
frameworks\av\media\libaudioclient\AudioTrack.cpp
返回AudioTrack.cpp中的creatTrack中。
实在走不到顶层去，不知道哪里走错了或者没有分析到
之后完全理清在修改是否有问题吧。
构造函数暂时分析至此。
