对于AF的分析,先看其所在层的位置以及相关的交互类,
之前的版本,AF在Main_MediaServer.cpp里面启动,在android N,AF在main_audioserver.cpp里面启动,
/// ALOGI("ServiceManager: %p", sm.get()); AudioFlinger::instantiate(); AudioPolicyService::instantiate(); RadioService::instantiate(); SoundTriggerHwService::instantiate(); . ProcessState::self()->startThreadPool(); IPCThreadState::self()->joinThreadPool(); |
在android N, audioserver进程的启动也发生了一些变化,
init.zygote64.rc
/// service zygote /system/bin/app_process64 -Xzygote /system/bin --zygote --start-system-server class main socket zygote stream 660 root system onrestart write /sys/android_power/request_state wake onrestart write /sys/power/state on onrestart restart audioserver onrestart restart cameraserver onrestart restart media onrestart restart netd. writepid /dev/cpuset/foreground/tasks /dev/stune/foreground/tasks. |
init.target.rc
/// service audiod /system/bin/audiod class late_start user system group system . |
在AudioFlinger.cpp的类创建过程中,AudioFlinger::instantiate()函数实例化AudioFlinger,instantiate在其父类BinderService里实现(frameworks/base/include/binder/BinderService.h头文件中),这里可以看到它被添加到系统服务里面了,之后,就存在一个AF的类实例,可以通过系统服务的方式被访问,再之后onFirstRef会被执行。
构造函数和onFirstRef里面没有创建和关联太多相关类,只创建了PatchPanel,
/// void AudioFlinger::onFirstRef() { … mPatchPanel = new PatchPanel(this);
mMode = AUDIO_MODE_NORMAL; } . |
在AF内部,由于和他交互的模块较多,所以实现了不同的服务端、客户端,为了达到实现不同功能的目的,其本身还维护多个线程。
关于内部线程方面,各线程的关系如下,
这些线程实现在\frameworks\av\services\audioflinger\ Threads.cpp ,主要的实现在PlaybackThread,在我们前面分析AT的时候,会在AF的openOutput_l里面new一个PlaybackThread(或其子类),这样就创建了线程实例,然后在其onFirstRef里启动线程,
/// void AudioFlinger::PlaybackThread::onFirstRef() { run(mThreadName, ANDROID_PRIORITY_URGENT_AUDIO);. } |
线程的Looper为boolAudioFlinger::PlaybackThread::threadLoop(),这个函数很大,不展开分析,简单说就是它负责处理播放过程,相应相关事件,收到外部通知或播放结束就结束线程。
AudioFlinger::RecordThread::RecordThread为输入线程,也不展开分析了。
|
线程的上下交互关系如下,
对于输出部分,可以看到针对不同的OUTPUT FLAG,在AF和HAL层有不同的Thread来进行播放。
对于音量控制,其框图如下
输入部分,则为