Android多媒體：AudioSystem，AudioService和AudioManager
AudioSystem和AudioFlinger以及AudioPolicyService的雙向通訊機制
AudioSystem是Audio子系統面向framework的介面，這裡面有很多一竿子戳到底的函式。同樣，Audio子系統內部也往往使用AudioSystem進行通訊，比如AF和APM。
SystemServer新增AudioService到SM中，在AudioService的建構函式中，建立一個執行緒AudioSystemThread，名字就叫“AudioService”，它通過handler不停的接收訊息。AudioManager裡含有一個IAudioService型別的sService，它通過Binder讓AudioService做事情。
AudioSystem.cpp第一次獲取AF時，註冊一個AF的死亡通知，對於APS同理。
const sp<IAudioFlinger>&AudioSystem::get_audio_flinger()
{
binder =sm->getService(String16("media.audio_flinger"));
gAudioFlingerClient = new AudioFlingerClient();
binder->linkToDeath(gAudioFlingerClient);
}
const sp<IAudioPolicyService>& AudioSystem::get_audio_policy_service()
{
binder= sm->getService(String16("media.audio_policy"));
gAudioPolicyServiceClient = newAudioPolicyServiceClient();
binder->linkToDeath(gAudioPolicyServiceClient);
}
然後，在AF Binder Die的時候（如MediaServer程序被殺死），會呼叫：
void AudioSystem::AudioFlingerClient::binderDied(constwp<IBinder>& who __unused)
{
gAudioErrorCallback(DEAD_OBJECT);
}
最終在AudioService.java中處理訊息MSG_MEDIA_SERVER_DIED，要等待mediaserver重啟，並重新設定一遍引數等。
另外，AudioFlinger在audioConfigChanged的時候，會像所有的AudioFlingerClient傳送通知mNotificationClients.valueAt(i)->audioFlingerClient()->ioConfigChanged()。
IAudioService.Stub定義於IAudioService.aidl，後者編譯時可生成IAudioService.java。AudioManager利用IAudioService.Stub獲得AudioService的Bp，從而可以跨程序的使用AudioService的服務。
private static IAudioService getService(){
IBinder b =ServiceManager.getService(Context.AUDIO_SERVICE);
sService =IAudioService.Stub.asInterface(b);
return sService;
}
AudioService服務由SystemServer建立，並且擁有一個自己的執行緒，這個執行緒一直利用mAudioHandler處理收到的訊息。所以不耗時的事情是SystemServer做的，而耗時的事情是AudioService執行緒做的。
AudioService通過對AudioSystem進行函式呼叫與Audio系統進行通訊。