Android Framework的音頻子系統中，每一個音頻流對應着一個AudioTrack類的一個實例，每個AudioTrack會在創建時註冊到AudioFlinger中，由AudioFlinger把所有的AudioTrack進行混合（Mixer），然後輸送到AudioHardware中進行播放。AudioTrack和AudioFlinger的通信機制通常，AudioTrack和AudioFlinger並不在同一個進程中，它們通過android中的binder機制建立聯繫。
Android音頻處理的基本接口
在Android開發中，根據不同的場景，出於衝突處理策略的考慮，開發者需要利用不同的接口來進行音頻資源的播放。
AudioManager爲上層應用提供了聲音設置管理接口.
AudioService爲所有的音頻相關的設置提供服務。他定義了了一個AudioSystemThread 的類，用來監控音頻控制相關的信號，當有請求時，它會通過調用AudioSystem 的接口實現音頻的控制，這裏的消息處理是異步的。此外在AudioService還抽象出了一套發送音頻控制信號的接口爲AudioManager提供支持。AudioManager通過音頻服務，爲上層提供了音量和鈴聲模式控制的接口，鈴聲模式控制包括揚聲器、耳機、藍牙等是否打開，麥克風是否靜音等。在開發多媒體應用時會經常用到AudioManager,關於Android AudioManager音量控制流程。
AudioSystem提供了音頻系統的基本類型定義，以及基本操作的接口。
對於音調，可以通過ToneGenerator來播放；ToneGenerator提供了對DTMF音（ITU-T Q.23），以及呼叫監督音（3GPP TS 22.001）、專用音（3GPP TS 31.111）中規定的音頻的支持，根據呼叫狀態和漫遊狀態，該文件產生的音頻路徑爲下行音頻或者傳輸給揚聲器或耳機。
對於提示音，可以通過Ringtone來播放；Ringtone和RingtoneManager爲鈴聲、提示音、鬧鐘等提供了快速播放，以及管理接口。實質是對媒體播放器提供了一個簡單的封裝。
對於錄音功能，則需要通過MediaRecorder和AudioRecord等來進行音頻記錄。
除了這些直接的音頻類外，對於音量調節、音頻設備的管理等，Android還提供了相關的類來處理。
對於遊戲中的音頻資源，可以通過SoundPool來播放。
SoundPool能夠播放音頻流的組合音，這對遊戲應用而言顯然非常有用。SoundPool可以從APK包中的資源文件或者文件系統中的文件將音頻資源加載到內存中。在底層的實現上，SoundPool通過媒體播放服務可以將音頻資源解碼爲一個16bit的單聲道或者立體聲的PCM流，這使得應用避免了在回放過程中進行解碼造成的延遲。除了回放過程中延遲小的優點外，SoundPool還能夠對一定數量的音頻流進行同時播放。當要播放的音頻流數量超過SoundPool所設定的最大值時，SoundPool將會停止已播放的一條低優先級的音頻流。SoundPool最大播放音頻流數量的設置，可以避免CPU過載和影響UI體驗。
Android平臺中關於音頻的播放還有另一種方式是MediaPlayer。MediaPlayer得特點是同一時間只能播放一個，適合較長但是對時間要求不高的情況。
二、MediaServer分析
MediaServer是整個android中media部分的核心和靈魂。幾乎所有與多媒體播放相關的內容都放在這裏。包括了音視頻的編解碼以及顯示輸出。
1. 先初始化AudioFlinger
其初始化通過AudioFlinger的父類BindService創建唯一的AudioFlinger實例。
2. 然後初始化MediaPlayerService
3. 最後初始化AudioPolicyService
三、AudioPolicyService 和 AudioPolicyManager分析
AudioPolicyService是Android音頻系統的兩大服務之一，另一個服務是AudioFlinger，這兩大服務都在系統啓動時有 MediaSever加載。
AudioPolicyService主要完成以下任務：
l JAVA應用層通過JNI，經由IAudioPolicyService接口，訪問AudioPolicyService提供的服務
l 輸入輸出設備的連接狀態
l 系統的音頻策略（strategy）的切換
l 音量/音頻參數的設置
AudioPolicyManager
AudioPolicyService的很大一部分管理工作都是在AudioPolicyManager中完成的。包括音量管理，音頻策略（strategy）管理，輸入輸出設備管理。
通過AudioPolicyService的 AudioCommandThread，最終會將設置應用到AudioFlinger的相應的Track中。
四、 AudioFlinger分析
AudioFlinger負責管理每個音軌AudioTrack及RecordTrack，主音量控制，每種聲音流的屬性設置，設備控制，音效控制。AudioFlinger是android中的一個service，在android啓動時就已經被加載。
播放線程實際上是MixerThread的一個實例，會把該線程中的各個Track進行混合，必要時還要進行ReSample(重採樣)的動作，轉換爲統一的採樣率（44.1K），然後通過音頻系統的AudioHardware層輸出音頻數據。
SRC[Sample Rate Converter，採樣頻率轉換] SRC的作用就是改變信號的採樣率，低採樣率往高採樣率轉換時就是一個重採樣的過程，重採樣對象不再是原始信號，而是這個低採樣率的信號，因爲採樣率不夠需要插入更多的採樣點以達到需要的採樣率和採樣大小。
三種平臺的音頻架構對比
一、android平臺
Android使用的是爲智能終端專門制定的ALSA（AdvancedLinux Sound Architecture，高級Linux聲音架構）框架。
從Android的音頻架構及流程分析，由於其驅動庫位於核心層，也就意味着音頻設備廠商、用戶無法象PC平臺那樣安裝驅動來改善音質。我們在實際的應用中也能感受到，Android設備音質普遍偏差。音質出現偏差一個主要的問題是處在SRC這裏。低採樣率往高採樣率轉換時就是一個重採樣的過程，重採樣對象不再是原始信號，而是這個低採樣率的信號，因爲採樣率不夠需要插入更多的採樣點以達到需要的採樣率和採樣大小
理論上SRC可以通過更換算法來實現音質提升，但卻不太現實，SRC需要大量的浮點運算的資源，即便有了高質量的SRC算法，其運算也是以犧牲設備性能和耗電量爲代價的，實用性差。
二、windowsphone平臺
通用音頻架構（UAA）
UAA分爲獨佔模式和共享模式，它最大程度的降低了音頻設備驅動對系統穩定性的影響，而且還能夠增加信號處理流程的透明度，處理環節可以得到控制，在理論上說，它可以實現更加優秀的音質，也能非常顯著的提升系統響應速度，大幅減低延時
應用程式在一般情況下都是走Shared Mode（共享模式）那條路徑，這個路徑被稱作通道，根據上面關於共享模式的介紹，所有的聲音訊號都會轉送至Audio Engine（音效引擎）部分，有軟件混音動作，就可能會經過SRC，使得聲音出現偏差。而當應用程序發出使用獨佔模式的需求後，系統會切斷共享模式這一條路徑，聲音訊號就會直接送達Kernel Mode最後到達底層的音頻設備後輸出，音頻設備在此時也會完全100%配合獨佔模式送來的音頻格式進行處理。
三、iOS平臺
我們再把目光投向iOS，iOS非常封閉，我們甚至無法獲知其架構的具體構成，但iOS設備不存在硬件設備多樣性的問題，因此要實現更好音質也會更加簡單。iOS可以實現針對性的開發和改良，以實現更好的音質。實際情況也是如此，目前爲止，還沒有一款Android設備的音質可以媲美任意一款iOS設備，這種差距，我們認爲不是來自硬件，而是操作系統。