前面分析了main()函數的前面部分：Android Audio:main_audioserver.cpp中的main()函數啓動流程
接下來分析AudioFlinger的instantiate()
android\frameworks\av\services\audioflinger\AudioFlinger.cpp
對變量進行一系列的初始化。
實例化打開設備的接口和實例化音效的接口，啓動 MediaLogNotifier 進程，用於處理 audioflinger 的部份 binder call 工作，減少 audioFlinger log相關的工作。
首先看打開設備的接口。
android\frameworks\av\media\libaudiohal\DevicesFactoryHalInterface.cpp
如果是4.0走上，2.0走下。
此處選擇4.0來學習
android\frameworks\av\media\libaudiohal\4.0\DevicesFactoryHalHybrid.cpp
android\frameworks\av\media\libaudiohal\2.0\DevicesFactoryHalHybrid.cpp
最終通過設備名打開設備。
接着看音效實例接口處。跟設備大體相同，
android\frameworks\av\media\libaudiohal\2.0\EffectsFactoryHalHidl.cpp
在此處得到音效的服務，此處就不深究下去了。
因爲AudioFlinger繼承BnAudioFlinger，層層繼承下來最後繼承了RefBase。
android\system\core\libutils\RefBase.cpp
第一次引用，則調用onFirstRef，這個函數很重要，派生類可以重載這個函數，完成一些初始化工作。
構造一個 PatchPanel對象並修改mode爲normal。
首先看一下PatchPanel在android中的關係。
可以看出 PatchPanel 只爲AudioFlinger 服務，由AudioPolicy Manger 來管理的。
整個流程爲：AudioSystem（APP層） —> AudioPolicyManager（framwork層） —> AudioFlinger----> CreateAudioPatch() ----> Patchpanel ----> Thread->sendEvent() ----> ThreadBase -----> Hardware 層。
android\frameworks\av\services\audioflinger\PatchPanel.cpp
連接一個 patch
如果端口類型是 Device 的話獲得AudioFlinger對象。
只允許創建一個 souces,只有 AudioPolicyManger 才能創建2個Souces
如果當前已經有現成的 Patch 則依次遍歷，並且釋放刪除它（釋放 Audio Playback 或 Capture 線程，釋放 Audio Hardware 接口
Clear實現地方。
新建一個 patch對象
獲得playback對象並保存在mPlaybackThread中。
獲得輸入設備類型及對應的輸出設備地址彩陽路、聲道和數據格式。
創建輸入設備的線程，保存在 newPatch->mRecordThread 中
如果端口類型是 MIX 的話
如果創建成功，則給新建的 patch 分析一個 UID，並添加到 mPatchs中。
LINUX\android\frameworks\av\services\audioflinger\Threads.cpp
於是，接着看sendCreateAudioPatchConfigEvent，發送消息給AF。
將帶有信息的event發送出去。
