全解析：從AudioTrack到AAudio，架構(gòu)、API與性能優(yōu)化實(shí)戰(zhàn))
1. 項(xiàng)目概述為什么我們需要一篇全面的Android Audio梳理干了這么多年Android開發(fā)音頻這塊兒絕對(duì)是讓很多開發(fā)者又愛又恨的領(lǐng)域。愛的是它幾乎是所有多媒體應(yīng)用、游戲、社交軟件的基石不可或缺恨的是它的知識(shí)體系龐雜涉及Framework、Native、硬件驅(qū)動(dòng)多個(gè)層面API繁多且歷史包袱重一個(gè)不小心就容易踩坑。你可能會(huì)用AudioTrack播放一段PCM用AudioRecord錄個(gè)音但當(dāng)你需要處理低延遲音頻、實(shí)現(xiàn)混音、適配五花八門的設(shè)備或者解決那些“在我手機(jī)上好好的怎么到他那就沒聲了”的玄學(xué)問題時(shí)就會(huì)發(fā)現(xiàn)之前的知識(shí)都是零散的碎片。網(wǎng)上關(guān)于Android Audio的資料不少但要么是官方文檔的直譯過于抽象要么是某個(gè)具體API的簡單示例缺乏系統(tǒng)性的串聯(lián)和深度原理剖析。很多開發(fā)者包括幾年前的我都是在“面向搜索引擎編程”和“試錯(cuò)法”中摸索效率低下且難以建立穩(wěn)固的知識(shí)體系。所以這篇梳理的目的就是把我這些年趟過的坑、讀過的源碼、總結(jié)的經(jīng)驗(yàn)進(jìn)行一次系統(tǒng)性的整合。它不是API文檔的羅列而是一個(gè)一線開發(fā)者視角的、貫穿上下文的“地圖”。我會(huì)從最核心的音頻基礎(chǔ)概念講起深入到AudioTrack、AudioRecord、AudioManager等關(guān)鍵類的內(nèi)部機(jī)制再拓展到音頻焦點(diǎn)、低延遲、音頻路由等高級(jí)話題。目標(biāo)是讓你看完之后不僅能“會(huì)用”更能“懂為什么這么用”以及“出了問題知道怎么查”。無論是剛接觸音頻的新手還是希望深化理解的資深開發(fā)者都能從中找到你需要的東西。2. Android音頻系統(tǒng)架構(gòu)全景解析要玩轉(zhuǎn)Android Audio不能只停留在Java API的調(diào)用層面必須對(duì)其整體架構(gòu)有個(gè)清晰的認(rèn)知。Android的音頻系統(tǒng)是一個(gè)典型的分層架構(gòu)自下而上可以分為Linux內(nèi)核層、硬件抽象層HAL、Native框架層、Java框架層和應(yīng)用層。理解每一層的職責(zé)是解決復(fù)雜音頻問題的鑰匙。2.1 從應(yīng)用層到內(nèi)核一次音頻播放的旅程當(dāng)我們調(diào)用AudioTrack.write()方法播放一段音樂時(shí)背后發(fā)生了一系列復(fù)雜的交互。應(yīng)用層Java你的App代碼在這里。你創(chuàng)建了一個(gè)AudioTrack對(duì)象設(shè)置了采樣率、聲道、數(shù)據(jù)格式等參數(shù)然后循環(huán)調(diào)用write方法將PCM數(shù)據(jù)塊推送出去。對(duì)于應(yīng)用開發(fā)者而言世界到此為止。但AudioTrack只是一個(gè)“客戶端”。Java框架層AudioTrack類本身并不處理音頻數(shù)據(jù)。它的核心是一個(gè)JNIJava Native Interface橋接。當(dāng)你調(diào)用write時(shí)數(shù)據(jù)通過JNI被傳遞到了Native層。同時(shí)Java層還管理著音頻焦點(diǎn)AudioManager、音量控制、設(shè)備路由等策略性的邏輯。Native框架層C/C這是Android音頻系統(tǒng)的“大腦”和“中樞神經(jīng)”位于frameworks/av/media目錄下。關(guān)鍵組件包括AudioFlinger 音頻系統(tǒng)的核心服務(wù)一個(gè)常駐進(jìn)程mediaserver。它負(fù)責(zé)混音Mix、音頻流的路由、效果器Effect的管理。所有應(yīng)用的音頻流最終都匯聚到這里。AudioTrack在Native層的對(duì)應(yīng)物會(huì)與AudioFlinger建立連接形成一個(gè)“播放線程Playback Thread”和“共享內(nèi)存緩沖區(qū)”。AudioPolicyService 音頻策略的決策者。它根據(jù)當(dāng)前系統(tǒng)狀態(tài)如有線耳機(jī)插入、藍(lán)牙連接、電話接入、應(yīng)用請(qǐng)求的音頻屬性如USAGE_MEDIA,USAGE_VOICE_COMMUNICATION來決定音頻流應(yīng)該輸出到哪個(gè)設(shè)備揚(yáng)聲器、聽筒、藍(lán)牙耳機(jī)等。它告訴AudioFlinger“該怎么走”。TinyALSA / AAudio 這是更底層的接口。傳統(tǒng)路徑上AudioFlinger通過TinyALSA庫與HAL交互。而在Android O8.0之后引入的AAudio則提供了一條繞過AudioFlinger的“高速通道”專為需要超低延遲的音頻應(yīng)用設(shè)計(jì)如專業(yè)音樂軟件、實(shí)時(shí)語音處理。硬件抽象層HAL這是為了屏蔽不同硬件廠商如高通、聯(lián)發(fā)科芯片差異而設(shè)的接口層。AudioFlinger通過標(biāo)準(zhǔn)的Audio HAL接口與硬件驅(qū)動(dòng)對(duì)話。廠商會(huì)實(shí)現(xiàn)具體的HAL將標(biāo)準(zhǔn)指令翻譯成自家芯片能懂的命令。Linux內(nèi)核層最底層包含音頻驅(qū)動(dòng)如ALSA驅(qū)動(dòng)和實(shí)際的音頻編解碼器Codec硬件。驅(qū)動(dòng)負(fù)責(zé)管理DMA直接內(nèi)存訪問將音頻數(shù)據(jù)從內(nèi)存搬運(yùn)到Codec最終轉(zhuǎn)換成模擬電信號(hào)推動(dòng)喇叭發(fā)聲。整個(gè)過程可以簡化為App (AudioTrack) - JNI - AudioFlinger (混音) - Audio HAL - Kernel Driver - Hardware Codec - Speaker。理解這個(gè)鏈條當(dāng)出現(xiàn)無聲、雜音、延遲大等問題時(shí)你就能系統(tǒng)地定位問題可能出在哪個(gè)環(huán)節(jié)。2.2 AudioFlinger與AudioPolicyService核心服務(wù)深度剖析這兩個(gè)服務(wù)是Native層的靈魂值得深入了解一下。AudioFlinger的工作模式是“生產(chǎn)者-消費(fèi)者”。每個(gè)AudioTrack生產(chǎn)者將PCM數(shù)據(jù)寫入一塊共享內(nèi)存Shared Memory。AudioFlinger內(nèi)部的各個(gè)播放線程消費(fèi)者從不同的共享內(nèi)存中讀取數(shù)據(jù)按照一定的規(guī)則如音量、平衡進(jìn)行混合Mix生成最終的PCM流再通過HAL輸出。它內(nèi)部維護(hù)著一個(gè)“混音器Mixer”這是計(jì)算密集型操作尤其在多路音頻同時(shí)播放時(shí)。注意AudioFlinger的混音是在一個(gè)固定的“輸出采樣率”和“音頻格式”下進(jìn)行的。如果你創(chuàng)建的AudioTrack參數(shù)如采樣率44.1kHz與系統(tǒng)當(dāng)前輸出設(shè)備如藍(lán)牙耳機(jī)可能只支持48kHz不匹配AudioFlinger會(huì)使用“重采樣Resampler”進(jìn)行轉(zhuǎn)換這會(huì)引入輕微的音質(zhì)損失和CPU開銷。在開發(fā)音樂類App時(shí)應(yīng)盡量使用設(shè)備支持的通用采樣率如48kHz。AudioPolicyService管理著一套復(fù)雜的規(guī)則引擎。它定義了“音頻場景”。例如當(dāng)媒體音樂正在播放時(shí)插入有線耳機(jī)音頻自動(dòng)路由到耳機(jī)。當(dāng)有電話打入時(shí)媒體音樂會(huì)自動(dòng)降低音量Ducking或暫停這是通過音頻焦點(diǎn)Audio Focus機(jī)制實(shí)現(xiàn)的而策略的執(zhí)行者就是AudioPolicyService。當(dāng)你啟動(dòng)一個(gè)語音通話應(yīng)用如微信語音時(shí)它會(huì)請(qǐng)求USAGE_VOICE_COMMUNICATION屬性的音頻流AudioPolicyService會(huì)優(yōu)先將其路由到聽筒或藍(lán)牙耳機(jī)并可能啟動(dòng)回聲消除AEC等音頻效果。它的配置通常保存在audio_policy_configuration.xml文件中定義了設(shè)備上所有的輸入/輸出設(shè)備端口如揚(yáng)聲器、聽筒、藍(lán)牙A2DP、藍(lán)牙SCO、以及不同場景下的路由策略。在系統(tǒng)定制或深度優(yōu)化時(shí)經(jīng)常會(huì)修改這個(gè)文件。3. 核心API精講與實(shí)戰(zhàn)避坑指南掌握了架構(gòu)我們再來啃最常用的幾個(gè)“硬骨頭”API。這里不講簡單的Hello World而是聚焦于高階用法和那些容易栽跟頭的細(xì)節(jié)。3.1 AudioTrack不僅僅是播放AudioTrack是播放PCM數(shù)據(jù)的主要工具。它的構(gòu)造函數(shù)參數(shù)眾多但最關(guān)鍵的是streamType在API 21后逐漸被attributes替代和mode。Mode的選擇STATIC vs STREAMMODE_STATIC 一次性將所有音頻數(shù)據(jù)加載到內(nèi)存。適用于短促的提示音如按鈕點(diǎn)擊聲。優(yōu)點(diǎn)是延遲極低因?yàn)閿?shù)據(jù)早已就緒。調(diào)用write后只需play即可。// 靜態(tài)模式示例 byte[] soundData loadShortSound(); // 加載短音頻數(shù)據(jù) AudioTrack track new AudioTrack.Builder() .setAudioAttributes(new AudioAttributes.Builder() .setUsage(AudioAttributes.USAGE_MEDIA) .setContentType(AudioAttributes.CONTENT_TYPE_MUSIC) .build()) .setAudioFormat(new AudioFormat.Builder() .setEncoding(AudioFormat.ENCODING_PCM_16BIT) .setSampleRate(44100) .setChannelMask(AudioFormat.CHANNEL_OUT_STEREO) .build()) .setBufferSizeInBytes(soundData.length) .setTransferMode(AudioTrack.MODE_STATIC) // 靜態(tài)模式 .build(); track.write(soundData, 0, soundData.length); track.play(); // 數(shù)據(jù)已就緒直接播放MODE_STREAM 需要建立一個(gè)數(shù)據(jù)流不斷調(diào)用write來補(bǔ)充緩沖區(qū)。適用于音樂、網(wǎng)絡(luò)音頻流等大容量或?qū)崟r(shí)數(shù)據(jù)。這是最常用的模式。Buffer Size的計(jì)算與延遲控制緩沖區(qū)大小是個(gè)權(quán)衡藝術(shù)。太小會(huì)導(dǎo)致write操作頻繁如果數(shù)據(jù)供給不及時(shí)就會(huì)發(fā)生“欠載Underrun”產(chǎn)生卡頓或爆音。太大則會(huì)導(dǎo)致播放延遲Latency增加。 一個(gè)常見的計(jì)算公式是緩沖區(qū)大小字節(jié) 采樣率 × 聲道數(shù) × 每采樣字節(jié)數(shù) × 期望緩沖時(shí)間秒。 例如對(duì)于44.1kHz立體聲16位PCM希望有100ms緩沖44100 * 2 * 2 * 0.1 17640字節(jié)。在實(shí)際使用中AudioTrack提供了一個(gè)getMinBufferSize方法可以獲取系統(tǒng)建議的最小緩沖區(qū)大小通常以此作為參考。實(shí)操心得對(duì)于需要低延遲的交互式音頻如鋼琴App僅僅調(diào)整緩沖區(qū)大小可能不夠。此時(shí)應(yīng)優(yōu)先考慮使用AAudio APIAndroid O及以上。AAudio提供了更簡單的接口和更可控的路徑能顯著降低延遲。如果必須用AudioTrack確保在STREAM模式下使用獨(dú)立的線程高頻次例如每10-20ms調(diào)用write并監(jiān)控PlaybackHeadPosition來同步。播放狀態(tài)管理與資源釋放AudioTrack的狀態(tài)機(jī)STATE_INITIALIZED,STATE_NO_STATIC_DATA,STATE_STOPPED等需要小心處理。一個(gè)常見的錯(cuò)誤是在stop()或pause()后沒有flush()就再次write數(shù)據(jù)這可能導(dǎo)致音頻混亂。正確的生命周期是new AudioTrack()-STATE_INITIALIZEDwrite()(對(duì)于STATIC模式) -STATE_NO_STATIC_DATA變?yōu)閿?shù)據(jù)就緒play()-STATE_PLAYINGpause()-STATE_PAUSED(緩沖區(qū)數(shù)據(jù)保留)stop()-STATE_STOPPED(播放頭復(fù)位但緩沖區(qū)數(shù)據(jù)可能保留)flush()- 清空緩沖區(qū)在STOPPED狀態(tài)調(diào)用release()- 釋放所有資源對(duì)象不可再用。務(wù)必在Activity/Fragment的onDestroy或Service的onDestroy中調(diào)用release()否則會(huì)導(dǎo)致音頻設(shè)備被占用其他應(yīng)用無法發(fā)聲甚至引起系統(tǒng)音頻異常。3.2 AudioRecord捕獲音頻的細(xì)節(jié)AudioRecord用于從麥克風(fēng)等輸入設(shè)備采集PCM數(shù)據(jù)。其核心是不斷從環(huán)形緩沖區(qū)中讀取數(shù)據(jù)。音頻源AudioSource的選擇MediaRecorder.AudioSource中定義了多種音頻源選錯(cuò)會(huì)導(dǎo)致錄制效果天差地別。MIC 主麥克風(fēng)默認(rèn)選項(xiàng)。CAMCORDER 指向與相機(jī)方向一致的麥克風(fēng)用于錄像時(shí)獲得更好的方向性收音。VOICE_COMMUNICATION/VOICE_RECOGNITION 用于語音通話或語音識(shí)別。系統(tǒng)可能會(huì)為這些源自動(dòng)啟用回聲消除AEC、噪聲抑制NS等預(yù)處理效果。這是實(shí)現(xiàn)高質(zhì)量語音錄制的關(guān)鍵。UNPROCESSED 請(qǐng)求盡可能原始的、未經(jīng)任何處理的音頻數(shù)據(jù)。適用于需要自己進(jìn)行音頻處理的專業(yè)應(yīng)用。配置與權(quán)限除了采樣率、聲道通常單聲道CHANNEL_IN_MONO已足夠、位深還需要注意bufferSizeInBytes。和AudioTrack類似可以使用getMinBufferSize獲取建議值。權(quán)限方面需要android.permission.RECORD_AUDIO并且從Android 6.0 (API 23)開始需要在運(yùn)行時(shí)動(dòng)態(tài)申請(qǐng)。讀取數(shù)據(jù)的正確姿勢AudioRecord的典型使用模式是在一個(gè)后臺(tái)線程中循環(huán)讀取// 假設(shè) audioRecord 已正確初始化 byte[] buffer new byte[bufferSize]; audioRecord.startRecording(); while (isRecording) { int bytesRead audioRecord.read(buffer, 0, buffer.length); if (bytesRead 0) { // 處理 buffer 中的數(shù)據(jù)例如寫入文件、編碼、發(fā)送網(wǎng)絡(luò)等 processAudioData(buffer, bytesRead); } else { // 處理錯(cuò)誤bytesRead可能是 ERROR, ERROR_BAD_VALUE, ERROR_INVALID_OPERATION Log.e(AudioRecord, Error reading audio data: bytesRead); break; } } audioRecord.stop(); audioRecord.release();避坑指南read方法是阻塞的直到有數(shù)據(jù)可讀。如果處理processAudioData太慢會(huì)導(dǎo)致讀取線程阻塞可能丟失音頻數(shù)據(jù)。因此處理邏輯要高效或者將數(shù)據(jù)快速轉(zhuǎn)移到另一個(gè)隊(duì)列如LinkedBlockingQueue中由其他線程慢慢處理。另外確保在結(jié)束錄制時(shí)調(diào)用stop()否則麥克風(fēng)會(huì)一直處于占用狀態(tài)其他應(yīng)用無法使用。3.3 AudioManager音頻系統(tǒng)的指揮官AudioManager是一個(gè)系統(tǒng)服務(wù)的客戶端用于管理全局音頻行為和策略。它的很多方法調(diào)用最終都會(huì)影響到前面提到的AudioPolicyService。音頻焦點(diǎn)Audio Focus這是Android上協(xié)調(diào)多個(gè)App音頻播放的核心機(jī)制。當(dāng)一個(gè)App開始播放音頻時(shí)它應(yīng)該請(qǐng)求音頻焦點(diǎn)。當(dāng)另一個(gè)App也請(qǐng)求焦點(diǎn)時(shí)系統(tǒng)會(huì)根據(jù)焦點(diǎn)策略如AUDIOFOCUS_GAIN表示長期持有AUDIOFOCUS_GAIN_TRANSIENT表示短暫持有和當(dāng)前焦點(diǎn)持有者的屬性決定如何處理。焦點(diǎn)持有者會(huì)收到回調(diào)OnAudioFocusChangeListener告知焦點(diǎn)丟失AUDIOFOCUS_LOSS或暫時(shí)丟失AUDIOFOCUS_LOSS_TRANSIENT此時(shí)應(yīng)該暫停播放或降低音量。正確實(shí)現(xiàn)音頻焦點(diǎn)是應(yīng)用“有禮貌”的表現(xiàn)。音樂播放器在開始播放前請(qǐng)求AUDIOFOCUS_GAIN在接到電話另一個(gè)App請(qǐng)求AUDIOFOCUS_GAIN_TRANSIENT時(shí)自動(dòng)暫停電話掛斷后收到AUDIOFOCUS_GAIN回調(diào)自動(dòng)恢復(fù)播放。導(dǎo)航App的提示音則應(yīng)該請(qǐng)求AUDIOFOCUS_GAIN_TRANSIENT_MAY_DUCK讓背景音樂只是降低音量Ducking而不是完全停止。音量控制與鈴聲模式AudioManager提供了調(diào)整不同音頻流類型的音量的方法如setStreamVolume。但注意直接調(diào)整音量可能會(huì)影響用戶體驗(yàn)通常應(yīng)該提供UI控件讓用戶自己調(diào)節(jié)。getRingerMode()和setRingerMode()可以獲取和設(shè)置鈴聲模式靜音、振動(dòng)、正常。設(shè)備連接與路由監(jiān)聽通過AudioManager可以獲取當(dāng)前連接的音頻設(shè)備列表getDevices并監(jiān)聽設(shè)備連接狀態(tài)的變化registerAudioDeviceCallback。這對(duì)于需要根據(jù)輸出設(shè)備調(diào)整音頻策略的應(yīng)用非常有用例如連接到藍(lán)牙耳機(jī)時(shí)自動(dòng)切換到更適合的音頻編碼格式。4. 高級(jí)話題與性能優(yōu)化實(shí)戰(zhàn)掌握了基礎(chǔ)API和架構(gòu)我們可以探討一些更深入的話題這些往往是打造高質(zhì)量音頻應(yīng)用的關(guān)鍵。4.1 低延遲音頻AAudio vs OpenSL ES對(duì)于音樂游戲、實(shí)時(shí)合成器、專業(yè)錄音等場景音頻延遲從觸發(fā)事件到聽到聲音的時(shí)間至關(guān)重要。Android上主要有兩套原生音頻APIOpenSL ES 一個(gè)跨平臺(tái)的多媒體API在Android早期版本API 16中引入。它功能強(qiáng)大但接口相對(duì)復(fù)雜緩沖區(qū)隊(duì)列管理繁瑣且延遲表現(xiàn)因廠商實(shí)現(xiàn)而異。AAudio Android OAPI 26引入的新API設(shè)計(jì)目標(biāo)就是高性能、低延遲。它提供了更簡潔的流式接口并鼓勵(lì)使用“回調(diào)模式”數(shù)據(jù)驅(qū)動(dòng)而非“阻塞讀寫模式”讓應(yīng)用能在音頻數(shù)據(jù)需要時(shí)被精確喚醒減少不必要的等待和緩沖區(qū)。AAudio實(shí)戰(zhàn)要點(diǎn)流構(gòu)建器 使用AAudioStreamBuilder來配置流指定設(shè)備ID、方向輸入/輸出、格式、采樣率等?？梢哉?qǐng)求性能模式AAUDIO_PERFORMANCE_MODE_LOW_LATENCY?；卣{(diào)模式 實(shí)現(xiàn)AAudioStream_dataCallback當(dāng)音頻引擎需要數(shù)據(jù)輸出或有新數(shù)據(jù)可用輸入時(shí)回調(diào)函數(shù)會(huì)被觸發(fā)。這是實(shí)現(xiàn)最低延遲的關(guān)鍵。設(shè)備選擇 可以查詢并指定特定的輸入/輸出設(shè)備如內(nèi)置麥克風(fēng)、USB音頻接口。使用AAudioStream_getDeviceId可以獲取當(dāng)前流使用的設(shè)備。錯(cuò)誤處理 AAudio有完善的狀態(tài)和錯(cuò)誤碼。當(dāng)發(fā)生AAUDIO_ERROR_DISCONNECTED設(shè)備斷開時(shí)需要關(guān)閉舊流重新基于新設(shè)備創(chuàng)建流。經(jīng)驗(yàn)之談如果你的應(yīng)用目標(biāo)API在26以上且對(duì)延遲敏感毫不猶豫地選擇AAudio。對(duì)于需要兼容舊版本的應(yīng)用可以采取“AAudio優(yōu)先OpenSL ES降級(jí)”的策略。在支持AAudio的設(shè)備上延遲通常可以穩(wěn)定在10-20毫秒以內(nèi)而舊的AudioTrack在MODE_STREAM下很難做到低于50毫秒。4.2 音頻數(shù)據(jù)處理與編解碼AudioTrack和AudioRecord處理的是原始的PCM數(shù)據(jù)。但實(shí)際應(yīng)用中我們經(jīng)常需要處理壓縮格式如MP3, AAC, OGG或進(jìn)行音頻處理。解碼播放 使用MediaExtractor分離容器中的音頻軌再用MediaCodec進(jìn)行解碼得到PCM數(shù)據(jù)后喂給AudioTrack或AAudioStream。這是一個(gè)異步、緩沖區(qū)隊(duì)列管理的復(fù)雜過程涉及InputBuffer、OutputBuffer、dequeueInputBuffer、queueInputBuffer、dequeueOutputBuffer、releaseOutputBuffer等一系列調(diào)用。務(wù)必處理好BUFFER_FLAG_END_OF_STREAM標(biāo)志和緩沖區(qū)的時(shí)間戳信息以實(shí)現(xiàn)平滑播放和同步。編碼錄制 過程相反。從AudioRecord獲取PCM送入MediaCodec編碼器獲取編碼后的數(shù)據(jù)如AAC幀再寫入文件如MP4或發(fā)送網(wǎng)絡(luò)。需要注意配置編碼器的比特率、采樣率、聲道數(shù)等參數(shù)以及處理關(guān)鍵幀。音頻處理 如果需要在播放或錄制過程中實(shí)時(shí)處理PCM如變聲、加混響、均衡器有幾種方案在Java層處理 簡單但性能差僅適用于非常輕量的操作。使用Android內(nèi)置的音頻效果器 通過AudioEffect類如Equalizer,BassBoost,Virtualizer可以附加到AudioTrack或MediaPlayer上。這是系統(tǒng)級(jí)的高效實(shí)現(xiàn)。Native層處理推薦 使用C/C庫如WebRTC的音頻處理模塊、SpeexDSP、自己寫的NEON優(yōu)化代碼在Native層處理?？梢詫⑻幚磉壿嫹旁贏Audio的回調(diào)函數(shù)中或者放在AudioRecord讀取線程和AudioTrack寫入線程之間。這是實(shí)現(xiàn)復(fù)雜、高性能實(shí)時(shí)處理的唯一途徑。4.3 音頻路由與多設(shè)備管理現(xiàn)代Android設(shè)備音頻出口眾多。管理好路由才能保證聲音從正確的地方出來。監(jiān)聽路由變化 如前所述注冊AudioDeviceCallback。當(dāng)用戶插入耳機(jī)、連接藍(lán)牙音箱時(shí)你的應(yīng)用可以收到通知。此時(shí)你可能需要更新UI 顯示當(dāng)前音頻輸出設(shè)備圖標(biāo)。重新初始化音頻流 特別是使用AAudio時(shí)不同的物理設(shè)備可能支持不同的最優(yōu)配置采樣率、緩沖區(qū)大小。收到設(shè)備變更后最好關(guān)閉舊流用新設(shè)備ID重新創(chuàng)建流。調(diào)整音頻策略 例如切換到藍(lán)牙耳機(jī)時(shí)由于藍(lán)牙編解碼如SBC, AAC, aptX會(huì)引入額外延遲對(duì)于節(jié)奏游戲可能需要調(diào)整判定窗口。手動(dòng)指定輸出設(shè)備 從Android O開始AudioManager提供了setCommunicationDevice等方法但更通用的方式是在創(chuàng)建AudioTrack或AAudioStream時(shí)通過AudioAttributes或AAudioStreamBuilder指定AudioDeviceInfo。這要求你先通過AudioManager.getDevices枚舉設(shè)備。處理通話與錄音沖突 這是另一個(gè)復(fù)雜場景。當(dāng)系統(tǒng)正在進(jìn)行VoIP通話使用AudioManager.MODE_IN_COMMUNICATION模式時(shí)普通的AudioRecord錄制可能會(huì)失敗或錄到的是通話聲音。此時(shí)需要確保你的錄音請(qǐng)求使用了正確的音頻源如VOICE_COMMUNICATION并妥善處理音頻焦點(diǎn)。5. 疑難雜癥排查與調(diào)試技巧即使理解了所有原理實(shí)際開發(fā)中依然會(huì)遇到各種光怪陸離的問題。這里分享一些常見的“坑”和排查手段。5.1 常見問題速查表問題現(xiàn)象可能原因排查步驟與解決方案播放無聲1. 權(quán)限未申請(qǐng)Android 6.0。2.AudioTrack未調(diào)用play()。3. 寫入的數(shù)據(jù)全是0或格式錯(cuò)誤。4. 音頻焦點(diǎn)被其他應(yīng)用持有且你的應(yīng)用未正確處理焦點(diǎn)丟失。5. 輸出設(shè)備路由錯(cuò)誤如應(yīng)在揚(yáng)聲器卻路由到了聽筒。6. 系統(tǒng)音量或媒體音量為0。1. 檢查RECORD_AUDIO權(quán)限錄制時(shí)和運(yùn)行時(shí)申請(qǐng)。2. 添加日志確認(rèn)play()被調(diào)用且狀態(tài)正確。3. 檢查PCM數(shù)據(jù)源用工具如Audacity查看波形。確認(rèn)采樣率、聲道、位深與AudioFormat匹配。4. 實(shí)現(xiàn)AudioManager.OnAudioFocusChangeListener檢查焦點(diǎn)狀態(tài)。5. 監(jiān)聽AudioDeviceCallback檢查當(dāng)前輸出設(shè)備。嘗試用AudioManager調(diào)整路由。6. 檢查AudioManager.getStreamVolume(AudioManager.STREAM_MUSIC)。錄音無聲或雜音1. 權(quán)限未申請(qǐng)。2. 音頻源AudioSource選擇錯(cuò)誤例如在通話中用了MIC而非VOICE_COMMUNICATION。3. 緩沖區(qū)大小不合適導(dǎo)致數(shù)據(jù)丟失或重疊。4. 麥克風(fēng)被其他應(yīng)用獨(dú)占。5. 設(shè)備硬件或驅(qū)動(dòng)問題。1. 同上檢查權(quán)限。2. 根據(jù)場景選擇合適的AudioSource語音場景優(yōu)先嘗試VOICE_COMMUNICATION。3. 使用getMinBufferSize獲取建議值并適當(dāng)增大。4. 嘗試重啟應(yīng)用或設(shè)備排除占用。5. 使用系統(tǒng)自帶的錄音機(jī)測試硬件是否正常。播放延遲高1.AudioTrack緩沖區(qū)設(shè)置過大。2. 使用MODE_STREAM但write調(diào)用間隔不穩(wěn)定。3. 系統(tǒng)負(fù)載高AudioFlinger混音線程調(diào)度延遲。4. 輸出設(shè)備本身有延遲如某些藍(lán)牙音箱。1. 在保證不欠載的前提下減小緩沖區(qū)大小。使用getMinBufferSize。2. 確保在獨(dú)立的高優(yōu)先級(jí)線程中穩(wěn)定、及時(shí)地調(diào)用write?？紤]使用Choreographer或固定頻率的定時(shí)器。3.切換到AAudio API并啟用低延遲模式這是最有效的方案。4. 檢測當(dāng)前輸出設(shè)備對(duì)藍(lán)牙設(shè)備用戶教育或游戲內(nèi)做延遲補(bǔ)償校準(zhǔn)。音頻播放卡頓、爆音1.write數(shù)據(jù)不及時(shí)緩沖區(qū)欠載Underrun。2.AudioTrack的播放線程優(yōu)先級(jí)不夠被系統(tǒng)搶占。3. GC垃圾回收導(dǎo)致線程暫停。4. PCM數(shù)據(jù)本身有問題如采樣率不匹配導(dǎo)致重采樣異常。1. 增大緩沖區(qū)或優(yōu)化數(shù)據(jù)供給線程的性能和優(yōu)先級(jí)。2. 創(chuàng)建AudioTrack的線程或數(shù)據(jù)寫入線程可以適當(dāng)提高優(yōu)先級(jí)。3. 避免在音頻線程中分配大量小對(duì)象使用對(duì)象池或直接內(nèi)存ByteBuffer.allocateDirect。4. 確保數(shù)據(jù)格式與AudioTrack配置完全一致特別是采樣率。多路音頻混合時(shí)音量或優(yōu)先級(jí)異常1. 未正確設(shè)置AudioAttributesusage, contentType。2. 未正確請(qǐng)求和管理音頻焦點(diǎn)。3. AudioPolicy策略配置問題系統(tǒng)級(jí)。1. 為不同的音頻流設(shè)置正確的AudioAttributes例如媒體用USAGE_MEDIA警報(bào)用USAGE_ALARM。2. 嚴(yán)格遵循音頻焦點(diǎn)協(xié)議在播放前請(qǐng)求在失去焦點(diǎn)時(shí)暫停/停止在獲得焦點(diǎn)時(shí)恢復(fù)。3. 作為應(yīng)用開發(fā)者此問題通常無法直接解決但可以檢查系統(tǒng)日志中AudioPolicy相關(guān)的錯(cuò)誤。5.2 高級(jí)調(diào)試工具與方法當(dāng)問題比較棘手時(shí)需要借助更強(qiáng)大的工具。查看系統(tǒng)日志adb logcat是首選。重點(diǎn)關(guān)注AudioTrack,AudioFlinger,AudioPolicyManager,AAudio等Tag的日志。例如搜索“underrun”可以找到播放卡頓的直接證據(jù)搜索“setParameters”可以看到音頻路由的變化。使用dumpsysadb shell dumpsys audio命令可以打印出當(dāng)前整個(gè)音頻系統(tǒng)的完整狀態(tài)信息量巨大。包括所有活躍的AudioTrack及其客戶端、采樣率、緩沖區(qū)狀態(tài)。音頻焦點(diǎn)持有者棧。當(dāng)前所有輸入/輸出設(shè)備及其狀態(tài)。AudioPolicy的配置和當(dāng)前策略。這對(duì)于分析復(fù)雜的多應(yīng)用音頻交互問題非常有用。性能跟蹤Systrace/Perfetto 使用Android Studio的Profiler或命令行工具perfetto/systrace可以捕捉一段時(shí)間內(nèi)的系統(tǒng)活動(dòng)。在音頻問題排查時(shí)關(guān)注音頻線程 查看你的應(yīng)用音頻線程AudioTrack寫入線程、AAudio回調(diào)線程的調(diào)度情況是否被長時(shí)間阻塞。binder調(diào)用 應(yīng)用與AudioFlinger/AudioPolicyService的Binder通信是否耗時(shí)過長。CPU頻率 是否因?yàn)榻殿l導(dǎo)致數(shù)據(jù)處理不及時(shí)。編寫單元測試與模擬測試 對(duì)于核心的音頻處理邏輯如解碼后PCM數(shù)據(jù)的校驗(yàn)、自定義音頻算法的輸出盡量編寫本地單元測試JUnit。對(duì)于涉及硬件交互的部分如AudioRecord/AudioTrack可以嘗試使用AndroidX的androidx.test.core.app.ApplicationProvider和模擬上下文進(jìn)行集成測試或者使用依賴注入如Dagger在測試時(shí)替換真實(shí)的音頻組件為Mock對(duì)象。音頻開發(fā)就像在一條多層的立交橋上開車你需要知道自己在哪一層目標(biāo)出口在哪里并遵守交通規(guī)則音頻焦點(diǎn)。希望這篇超長的梳理能成為你手上的詳細(xì)導(dǎo)航地圖。從宏觀架構(gòu)到微觀API從基礎(chǔ)使用到高級(jí)優(yōu)化從原理到實(shí)戰(zhàn)避坑內(nèi)容雖多但都是實(shí)踐中一點(diǎn)一滴積累起來的。真正的掌握還需要你在具體的項(xiàng)目中反復(fù)實(shí)踐、踩坑、總結(jié)。當(dāng)你再遇到音頻問題時(shí)能夠冷靜地根據(jù)現(xiàn)象沿著“應(yīng)用層-Java層-Native層-HAL-驅(qū)動(dòng)”這條鏈去思考和分析那這篇梳理的目的就達(dá)到了。最后記住兩個(gè)黃金法則一是生命周期管理務(wù)必嚴(yán)謹(jǐn)及時(shí)release二是對(duì)延遲敏感就上AAudio。 Android音頻開發(fā)全解析：從AudioTrack到AAudio，架構(gòu)、API與性能優(yōu)化實(shí)戰(zhàn)
1. 項(xiàng)目概述為什么我們需要一篇全面的Android Audio梳理干了這么多年Android開發(fā)音頻這塊兒絕對(duì)是讓很多開發(fā)者又愛又恨的領(lǐng)域。愛的是它幾乎是所有多媒體應(yīng)用、游戲、社交軟件的基石不可或缺恨的是它的知識(shí)體系龐雜涉及Framework、Native、硬件驅(qū)動(dòng)多個(gè)層面API繁多且歷史包袱重一個(gè)不小心就容易踩坑。你可能會(huì)用AudioTrack播放一段PCM用AudioRecord錄個(gè)音但當(dāng)你需要處理低延遲音頻、實(shí)現(xiàn)混音、適配五花八門的設(shè)備或者解決那些“在我手機(jī)上好好的怎么到他那就沒聲了”的玄學(xué)問題時(shí)就會(huì)發(fā)現(xiàn)之前的知識(shí)都是零散的碎片。網(wǎng)上關(guān)于Android Audio的資料不少但要么是官方文檔的直譯過于抽象要么是某個(gè)具體API的簡單示例缺乏系統(tǒng)性的串聯(lián)和深度原理剖析。很多開發(fā)者包括幾年前的我都是在“面向搜索引擎編程”和“試錯(cuò)法”中摸索效率低下且難以建立穩(wěn)固的知識(shí)體系。所以這篇梳理的目的就是把我這些年趟過的坑、讀過的源碼、總結(jié)的經(jīng)驗(yàn)進(jìn)行一次系統(tǒng)性的整合。它不是API文檔的羅列而是一個(gè)一線開發(fā)者視角的、貫穿上下文的“地圖”。我會(huì)從最核心的音頻基礎(chǔ)概念講起深入到AudioTrack、AudioRecord、AudioManager等關(guān)鍵類的內(nèi)部機(jī)制再拓展到音頻焦點(diǎn)、低延遲、音頻路由等高級(jí)話題。目標(biāo)是讓你看完之后不僅能“會(huì)用”更能“懂為什么這么用”以及“出了問題知道怎么查”。無論是剛接觸音頻的新手還是希望深化理解的資深開發(fā)者都能從中找到你需要的東西。2. Android音頻系統(tǒng)架構(gòu)全景解析要玩轉(zhuǎn)Android Audio不能只停留在Java API的調(diào)用層面必須對(duì)其整體架構(gòu)有個(gè)清晰的認(rèn)知。Android的音頻系統(tǒng)是一個(gè)典型的分層架構(gòu)自下而上可以分為Linux內(nèi)核層、硬件抽象層HAL、Native框架層、Java框架層和應(yīng)用層。理解每一層的職責(zé)是解決復(fù)雜音頻問題的鑰匙。2.1 從應(yīng)用層到內(nèi)核一次音頻播放的旅程當(dāng)我們調(diào)用AudioTrack.write()方法播放一段音樂時(shí)背后發(fā)生了一系列復(fù)雜的交互。應(yīng)用層Java你的App代碼在這里。你創(chuàng)建了一個(gè)AudioTrack對(duì)象設(shè)置了采樣率、聲道、數(shù)據(jù)格式等參數(shù)然后循環(huán)調(diào)用write方法將PCM數(shù)據(jù)塊推送出去。對(duì)于應(yīng)用開發(fā)者而言世界到此為止。但AudioTrack只是一個(gè)“客戶端”。Java框架層AudioTrack類本身并不處理音頻數(shù)據(jù)。它的核心是一個(gè)JNIJava Native Interface橋接。當(dāng)你調(diào)用write時(shí)數(shù)據(jù)通過JNI被傳遞到了Native層。同時(shí)Java層還管理著音頻焦點(diǎn)AudioManager、音量控制、設(shè)備路由等策略性的邏輯。Native框架層C/C這是Android音頻系統(tǒng)的“大腦”和“中樞神經(jīng)”位于frameworks/av/media目錄下。關(guān)鍵組件包括AudioFlinger 音頻系統(tǒng)的核心服務(wù)一個(gè)常駐進(jìn)程mediaserver。它負(fù)責(zé)混音Mix、音頻流的路由、效果器Effect的管理。所有應(yīng)用的音頻流最終都匯聚到這里。AudioTrack在Native層的對(duì)應(yīng)物會(huì)與AudioFlinger建立連接形成一個(gè)“播放線程Playback Thread”和“共享內(nèi)存緩沖區(qū)”。AudioPolicyService 音頻策略的決策者。它根據(jù)當(dāng)前系統(tǒng)狀態(tài)如有線耳機(jī)插入、藍(lán)牙連接、電話接入、應(yīng)用請(qǐng)求的音頻屬性如USAGE_MEDIA,USAGE_VOICE_COMMUNICATION來決定音頻流應(yīng)該輸出到哪個(gè)設(shè)備揚(yáng)聲器、聽筒、藍(lán)牙耳機(jī)等。它告訴AudioFlinger“該怎么走”。TinyALSA / AAudio 這是更底層的接口。傳統(tǒng)路徑上AudioFlinger通過TinyALSA庫與HAL交互。而在Android O8.0之后引入的AAudio則提供了一條繞過AudioFlinger的“高速通道”專為需要超低延遲的音頻應(yīng)用設(shè)計(jì)如專業(yè)音樂軟件、實(shí)時(shí)語音處理。硬件抽象層HAL這是為了屏蔽不同硬件廠商如高通、聯(lián)發(fā)科芯片差異而設(shè)的接口層。AudioFlinger通過標(biāo)準(zhǔn)的Audio HAL接口與硬件驅(qū)動(dòng)對(duì)話。廠商會(huì)實(shí)現(xiàn)具體的HAL將標(biāo)準(zhǔn)指令翻譯成自家芯片能懂的命令。Linux內(nèi)核層最底層包含音頻驅(qū)動(dòng)如ALSA驅(qū)動(dòng)和實(shí)際的音頻編解碼器Codec硬件。驅(qū)動(dòng)負(fù)責(zé)管理DMA直接內(nèi)存訪問將音頻數(shù)據(jù)從內(nèi)存搬運(yùn)到Codec最終轉(zhuǎn)換成模擬電信號(hào)推動(dòng)喇叭發(fā)聲。整個(gè)過程可以簡化為App (AudioTrack) - JNI - AudioFlinger (混音) - Audio HAL - Kernel Driver - Hardware Codec - Speaker。理解這個(gè)鏈條當(dāng)出現(xiàn)無聲、雜音、延遲大等問題時(shí)你就能系統(tǒng)地定位問題可能出在哪個(gè)環(huán)節(jié)。2.2 AudioFlinger與AudioPolicyService核心服務(wù)深度剖析這兩個(gè)服務(wù)是Native層的靈魂值得深入了解一下。AudioFlinger的工作模式是“生產(chǎn)者-消費(fèi)者”。每個(gè)AudioTrack生產(chǎn)者將PCM數(shù)據(jù)寫入一塊共享內(nèi)存Shared Memory。AudioFlinger內(nèi)部的各個(gè)播放線程消費(fèi)者從不同的共享內(nèi)存中讀取數(shù)據(jù)按照一定的規(guī)則如音量、平衡進(jìn)行混合Mix生成最終的PCM流再通過HAL輸出。它內(nèi)部維護(hù)著一個(gè)“混音器Mixer”這是計(jì)算密集型操作尤其在多路音頻同時(shí)播放時(shí)。注意AudioFlinger的混音是在一個(gè)固定的“輸出采樣率”和“音頻格式”下進(jìn)行的。如果你創(chuàng)建的AudioTrack參數(shù)如采樣率44.1kHz與系統(tǒng)當(dāng)前輸出設(shè)備如藍(lán)牙耳機(jī)可能只支持48kHz不匹配AudioFlinger會(huì)使用“重采樣Resampler”進(jìn)行轉(zhuǎn)換這會(huì)引入輕微的音質(zhì)損失和CPU開銷。在開發(fā)音樂類App時(shí)應(yīng)盡量使用設(shè)備支持的通用采樣率如48kHz。AudioPolicyService管理著一套復(fù)雜的規(guī)則引擎。它定義了“音頻場景”。例如當(dāng)媒體音樂正在播放時(shí)插入有線耳機(jī)音頻自動(dòng)路由到耳機(jī)。當(dāng)有電話打入時(shí)媒體音樂會(huì)自動(dòng)降低音量Ducking或暫停這是通過音頻焦點(diǎn)Audio Focus機(jī)制實(shí)現(xiàn)的而策略的執(zhí)行者就是AudioPolicyService。當(dāng)你啟動(dòng)一個(gè)語音通話應(yīng)用如微信語音時(shí)它會(huì)請(qǐng)求USAGE_VOICE_COMMUNICATION屬性的音頻流AudioPolicyService會(huì)優(yōu)先將其路由到聽筒或藍(lán)牙耳機(jī)并可能啟動(dòng)回聲消除AEC等音頻效果。它的配置通常保存在audio_policy_configuration.xml文件中定義了設(shè)備上所有的輸入/輸出設(shè)備端口如揚(yáng)聲器、聽筒、藍(lán)牙A2DP、藍(lán)牙SCO、以及不同場景下的路由策略。在系統(tǒng)定制或深度優(yōu)化時(shí)經(jīng)常會(huì)修改這個(gè)文件。3. 核心API精講與實(shí)戰(zhàn)避坑指南掌握了架構(gòu)我們再來啃最常用的幾個(gè)“硬骨頭”API。這里不講簡單的Hello World而是聚焦于高階用法和那些容易栽跟頭的細(xì)節(jié)。3.1 AudioTrack不僅僅是播放AudioTrack是播放PCM數(shù)據(jù)的主要工具。它的構(gòu)造函數(shù)參數(shù)眾多但最關(guān)鍵的是streamType在API 21后逐漸被attributes替代和mode。Mode的選擇STATIC vs STREAMMODE_STATIC 一次性將所有音頻數(shù)據(jù)加載到內(nèi)存。適用于短促的提示音如按鈕點(diǎn)擊聲。優(yōu)點(diǎn)是延遲極低因?yàn)閿?shù)據(jù)早已就緒。調(diào)用write后只需play即可。// 靜態(tài)模式示例 byte[] soundData loadShortSound(); // 加載短音頻數(shù)據(jù) AudioTrack track new AudioTrack.Builder() .setAudioAttributes(new AudioAttributes.Builder() .setUsage(AudioAttributes.USAGE_MEDIA) .setContentType(AudioAttributes.CONTENT_TYPE_MUSIC) .build()) .setAudioFormat(new AudioFormat.Builder() .setEncoding(AudioFormat.ENCODING_PCM_16BIT) .setSampleRate(44100) .setChannelMask(AudioFormat.CHANNEL_OUT_STEREO) .build()) .setBufferSizeInBytes(soundData.length) .setTransferMode(AudioTrack.MODE_STATIC) // 靜態(tài)模式 .build(); track.write(soundData, 0, soundData.length); track.play(); // 數(shù)據(jù)已就緒直接播放MODE_STREAM 需要建立一個(gè)數(shù)據(jù)流不斷調(diào)用write來補(bǔ)充緩沖區(qū)。適用于音樂、網(wǎng)絡(luò)音頻流等大容量或?qū)崟r(shí)數(shù)據(jù)。這是最常用的模式。Buffer Size的計(jì)算與延遲控制緩沖區(qū)大小是個(gè)權(quán)衡藝術(shù)。太小會(huì)導(dǎo)致write操作頻繁如果數(shù)據(jù)供給不及時(shí)就會(huì)發(fā)生“欠載Underrun”產(chǎn)生卡頓或爆音。太大則會(huì)導(dǎo)致播放延遲Latency增加。 一個(gè)常見的計(jì)算公式是緩沖區(qū)大小字節(jié) 采樣率 × 聲道數(shù) × 每采樣字節(jié)數(shù) × 期望緩沖時(shí)間秒。 例如對(duì)于44.1kHz立體聲16位PCM希望有100ms緩沖44100 * 2 * 2 * 0.1 17640字節(jié)。在實(shí)際使用中AudioTrack提供了一個(gè)getMinBufferSize方法可以獲取系統(tǒng)建議的最小緩沖區(qū)大小通常以此作為參考。實(shí)操心得對(duì)于需要低延遲的交互式音頻如鋼琴App僅僅調(diào)整緩沖區(qū)大小可能不夠。此時(shí)應(yīng)優(yōu)先考慮使用AAudio APIAndroid O及以上。AAudio提供了更簡單的接口和更可控的路徑能顯著降低延遲。如果必須用AudioTrack確保在STREAM模式下使用獨(dú)立的線程高頻次例如每10-20ms調(diào)用write并監(jiān)控PlaybackHeadPosition來同步。播放狀態(tài)管理與資源釋放AudioTrack的狀態(tài)機(jī)STATE_INITIALIZED,STATE_NO_STATIC_DATA,STATE_STOPPED等需要小心處理。一個(gè)常見的錯(cuò)誤是在stop()或pause()后沒有flush()就再次write數(shù)據(jù)這可能導(dǎo)致音頻混亂。正確的生命周期是new AudioTrack()-STATE_INITIALIZEDwrite()(對(duì)于STATIC模式) -STATE_NO_STATIC_DATA變?yōu)閿?shù)據(jù)就緒play()-STATE_PLAYINGpause()-STATE_PAUSED(緩沖區(qū)數(shù)據(jù)保留)stop()-STATE_STOPPED(播放頭復(fù)位但緩沖區(qū)數(shù)據(jù)可能保留)flush()- 清空緩沖區(qū)在STOPPED狀態(tài)調(diào)用release()- 釋放所有資源對(duì)象不可再用。務(wù)必在Activity/Fragment的onDestroy或Service的onDestroy中調(diào)用release()否則會(huì)導(dǎo)致音頻設(shè)備被占用其他應(yīng)用無法發(fā)聲甚至引起系統(tǒng)音頻異常。3.2 AudioRecord捕獲音頻的細(xì)節(jié)AudioRecord用于從麥克風(fēng)等輸入設(shè)備采集PCM數(shù)據(jù)。其核心是不斷從環(huán)形緩沖區(qū)中讀取數(shù)據(jù)。音頻源AudioSource的選擇MediaRecorder.AudioSource中定義了多種音頻源選錯(cuò)會(huì)導(dǎo)致錄制效果天差地別。MIC 主麥克風(fēng)默認(rèn)選項(xiàng)。CAMCORDER 指向與相機(jī)方向一致的麥克風(fēng)用于錄像時(shí)獲得更好的方向性收音。VOICE_COMMUNICATION/VOICE_RECOGNITION 用于語音通話或語音識(shí)別。系統(tǒng)可能會(huì)為這些源自動(dòng)啟用回聲消除AEC、噪聲抑制NS等預(yù)處理效果。這是實(shí)現(xiàn)高質(zhì)量語音錄制的關(guān)鍵。UNPROCESSED 請(qǐng)求盡可能原始的、未經(jīng)任何處理的音頻數(shù)據(jù)。適用于需要自己進(jìn)行音頻處理的專業(yè)應(yīng)用。配置與權(quán)限除了采樣率、聲道通常單聲道CHANNEL_IN_MONO已足夠、位深還需要注意bufferSizeInBytes。和AudioTrack類似可以使用getMinBufferSize獲取建議值。權(quán)限方面需要android.permission.RECORD_AUDIO并且從Android 6.0 (API 23)開始需要在運(yùn)行時(shí)動(dòng)態(tài)申請(qǐng)。讀取數(shù)據(jù)的正確姿勢AudioRecord的典型使用模式是在一個(gè)后臺(tái)線程中循環(huán)讀取// 假設(shè) audioRecord 已正確初始化 byte[] buffer new byte[bufferSize]; audioRecord.startRecording(); while (isRecording) { int bytesRead audioRecord.read(buffer, 0, buffer.length); if (bytesRead 0) { // 處理 buffer 中的數(shù)據(jù)例如寫入文件、編碼、發(fā)送網(wǎng)絡(luò)等 processAudioData(buffer, bytesRead); } else { // 處理錯(cuò)誤bytesRead可能是 ERROR, ERROR_BAD_VALUE, ERROR_INVALID_OPERATION Log.e(AudioRecord, Error reading audio data: bytesRead); break; } } audioRecord.stop(); audioRecord.release();避坑指南read方法是阻塞的直到有數(shù)據(jù)可讀。如果處理processAudioData太慢會(huì)導(dǎo)致讀取線程阻塞可能丟失音頻數(shù)據(jù)。因此處理邏輯要高效或者將數(shù)據(jù)快速轉(zhuǎn)移到另一個(gè)隊(duì)列如LinkedBlockingQueue中由其他線程慢慢處理。另外確保在結(jié)束錄制時(shí)調(diào)用stop()否則麥克風(fēng)會(huì)一直處于占用狀態(tài)其他應(yīng)用無法使用。3.3 AudioManager音頻系統(tǒng)的指揮官AudioManager是一個(gè)系統(tǒng)服務(wù)的客戶端用于管理全局音頻行為和策略。它的很多方法調(diào)用最終都會(huì)影響到前面提到的AudioPolicyService。音頻焦點(diǎn)Audio Focus這是Android上協(xié)調(diào)多個(gè)App音頻播放的核心機(jī)制。當(dāng)一個(gè)App開始播放音頻時(shí)它應(yīng)該請(qǐng)求音頻焦點(diǎn)。當(dāng)另一個(gè)App也請(qǐng)求焦點(diǎn)時(shí)系統(tǒng)會(huì)根據(jù)焦點(diǎn)策略如AUDIOFOCUS_GAIN表示長期持有AUDIOFOCUS_GAIN_TRANSIENT表示短暫持有和當(dāng)前焦點(diǎn)持有者的屬性決定如何處理。焦點(diǎn)持有者會(huì)收到回調(diào)OnAudioFocusChangeListener告知焦點(diǎn)丟失AUDIOFOCUS_LOSS或暫時(shí)丟失AUDIOFOCUS_LOSS_TRANSIENT此時(shí)應(yīng)該暫停播放或降低音量。正確實(shí)現(xiàn)音頻焦點(diǎn)是應(yīng)用“有禮貌”的表現(xiàn)。音樂播放器在開始播放前請(qǐng)求AUDIOFOCUS_GAIN在接到電話另一個(gè)App請(qǐng)求AUDIOFOCUS_GAIN_TRANSIENT時(shí)自動(dòng)暫停電話掛斷后收到AUDIOFOCUS_GAIN回調(diào)自動(dòng)恢復(fù)播放。導(dǎo)航App的提示音則應(yīng)該請(qǐng)求AUDIOFOCUS_GAIN_TRANSIENT_MAY_DUCK讓背景音樂只是降低音量Ducking而不是完全停止。音量控制與鈴聲模式AudioManager提供了調(diào)整不同音頻流類型的音量的方法如setStreamVolume。但注意直接調(diào)整音量可能會(huì)影響用戶體驗(yàn)通常應(yīng)該提供UI控件讓用戶自己調(diào)節(jié)。getRingerMode()和setRingerMode()可以獲取和設(shè)置鈴聲模式靜音、振動(dòng)、正常。設(shè)備連接與路由監(jiān)聽通過AudioManager可以獲取當(dāng)前連接的音頻設(shè)備列表getDevices并監(jiān)聽設(shè)備連接狀態(tài)的變化registerAudioDeviceCallback。這對(duì)于需要根據(jù)輸出設(shè)備調(diào)整音頻策略的應(yīng)用非常有用例如連接到藍(lán)牙耳機(jī)時(shí)自動(dòng)切換到更適合的音頻編碼格式。4. 高級(jí)話題與性能優(yōu)化實(shí)戰(zhàn)掌握了基礎(chǔ)API和架構(gòu)我們可以探討一些更深入的話題這些往往是打造高質(zhì)量音頻應(yīng)用的關(guān)鍵。4.1 低延遲音頻AAudio vs OpenSL ES對(duì)于音樂游戲、實(shí)時(shí)合成器、專業(yè)錄音等場景音頻延遲從觸發(fā)事件到聽到聲音的時(shí)間至關(guān)重要。Android上主要有兩套原生音頻APIOpenSL ES 一個(gè)跨平臺(tái)的多媒體API在Android早期版本API 16中引入。它功能強(qiáng)大但接口相對(duì)復(fù)雜緩沖區(qū)隊(duì)列管理繁瑣且延遲表現(xiàn)因廠商實(shí)現(xiàn)而異。AAudio Android OAPI 26引入的新API設(shè)計(jì)目標(biāo)就是高性能、低延遲。它提供了更簡潔的流式接口并鼓勵(lì)使用“回調(diào)模式”數(shù)據(jù)驅(qū)動(dòng)而非“阻塞讀寫模式”讓應(yīng)用能在音頻數(shù)據(jù)需要時(shí)被精確喚醒減少不必要的等待和緩沖區(qū)。AAudio實(shí)戰(zhàn)要點(diǎn)流構(gòu)建器 使用AAudioStreamBuilder來配置流指定設(shè)備ID、方向輸入/輸出、格式、采樣率等?？梢哉?qǐng)求性能模式AAUDIO_PERFORMANCE_MODE_LOW_LATENCY?；卣{(diào)模式 實(shí)現(xiàn)AAudioStream_dataCallback當(dāng)音頻引擎需要數(shù)據(jù)輸出或有新數(shù)據(jù)可用輸入時(shí)回調(diào)函數(shù)會(huì)被觸發(fā)。這是實(shí)現(xiàn)最低延遲的關(guān)鍵。設(shè)備選擇 可以查詢并指定特定的輸入/輸出設(shè)備如內(nèi)置麥克風(fēng)、USB音頻接口。使用AAudioStream_getDeviceId可以獲取當(dāng)前流使用的設(shè)備。錯(cuò)誤處理 AAudio有完善的狀態(tài)和錯(cuò)誤碼。當(dāng)發(fā)生AAUDIO_ERROR_DISCONNECTED設(shè)備斷開時(shí)需要關(guān)閉舊流重新基于新設(shè)備創(chuàng)建流。經(jīng)驗(yàn)之談如果你的應(yīng)用目標(biāo)API在26以上且對(duì)延遲敏感毫不猶豫地選擇AAudio。對(duì)于需要兼容舊版本的應(yīng)用可以采取“AAudio優(yōu)先OpenSL ES降級(jí)”的策略。在支持AAudio的設(shè)備上延遲通常可以穩(wěn)定在10-20毫秒以內(nèi)而舊的AudioTrack在MODE_STREAM下很難做到低于50毫秒。4.2 音頻數(shù)據(jù)處理與編解碼AudioTrack和AudioRecord處理的是原始的PCM數(shù)據(jù)。但實(shí)際應(yīng)用中我們經(jīng)常需要處理壓縮格式如MP3, AAC, OGG或進(jìn)行音頻處理。解碼播放 使用MediaExtractor分離容器中的音頻軌再用MediaCodec進(jìn)行解碼得到PCM數(shù)據(jù)后喂給AudioTrack或AAudioStream。這是一個(gè)異步、緩沖區(qū)隊(duì)列管理的復(fù)雜過程涉及InputBuffer、OutputBuffer、dequeueInputBuffer、queueInputBuffer、dequeueOutputBuffer、releaseOutputBuffer等一系列調(diào)用。務(wù)必處理好BUFFER_FLAG_END_OF_STREAM標(biāo)志和緩沖區(qū)的時(shí)間戳信息以實(shí)現(xiàn)平滑播放和同步。編碼錄制 過程相反。從AudioRecord獲取PCM送入MediaCodec編碼器獲取編碼后的數(shù)據(jù)如AAC幀再寫入文件如MP4或發(fā)送網(wǎng)絡(luò)。需要注意配置編碼器的比特率、采樣率、聲道數(shù)等參數(shù)以及處理關(guān)鍵幀。音頻處理 如果需要在播放或錄制過程中實(shí)時(shí)處理PCM如變聲、加混響、均衡器有幾種方案在Java層處理 簡單但性能差僅適用于非常輕量的操作。使用Android內(nèi)置的音頻效果器 通過AudioEffect類如Equalizer,BassBoost,Virtualizer可以附加到AudioTrack或MediaPlayer上。這是系統(tǒng)級(jí)的高效實(shí)現(xiàn)。Native層處理推薦 使用C/C庫如WebRTC的音頻處理模塊、SpeexDSP、自己寫的NEON優(yōu)化代碼在Native層處理?？梢詫⑻幚磉壿嫹旁贏Audio的回調(diào)函數(shù)中或者放在AudioRecord讀取線程和AudioTrack寫入線程之間。這是實(shí)現(xiàn)復(fù)雜、高性能實(shí)時(shí)處理的唯一途徑。4.3 音頻路由與多設(shè)備管理現(xiàn)代Android設(shè)備音頻出口眾多。管理好路由才能保證聲音從正確的地方出來。監(jiān)聽路由變化 如前所述注冊AudioDeviceCallback。當(dāng)用戶插入耳機(jī)、連接藍(lán)牙音箱時(shí)你的應(yīng)用可以收到通知。此時(shí)你可能需要更新UI 顯示當(dāng)前音頻輸出設(shè)備圖標(biāo)。重新初始化音頻流 特別是使用AAudio時(shí)不同的物理設(shè)備可能支持不同的最優(yōu)配置采樣率、緩沖區(qū)大小。收到設(shè)備變更后最好關(guān)閉舊流用新設(shè)備ID重新創(chuàng)建流。調(diào)整音頻策略 例如切換到藍(lán)牙耳機(jī)時(shí)由于藍(lán)牙編解碼如SBC, AAC, aptX會(huì)引入額外延遲對(duì)于節(jié)奏游戲可能需要調(diào)整判定窗口。手動(dòng)指定輸出設(shè)備 從Android O開始AudioManager提供了setCommunicationDevice等方法但更通用的方式是在創(chuàng)建AudioTrack或AAudioStream時(shí)通過AudioAttributes或AAudioStreamBuilder指定AudioDeviceInfo。這要求你先通過AudioManager.getDevices枚舉設(shè)備。處理通話與錄音沖突 這是另一個(gè)復(fù)雜場景。當(dāng)系統(tǒng)正在進(jìn)行VoIP通話使用AudioManager.MODE_IN_COMMUNICATION模式時(shí)普通的AudioRecord錄制可能會(huì)失敗或錄到的是通話聲音。此時(shí)需要確保你的錄音請(qǐng)求使用了正確的音頻源如VOICE_COMMUNICATION并妥善處理音頻焦點(diǎn)。5. 疑難雜癥排查與調(diào)試技巧即使理解了所有原理實(shí)際開發(fā)中依然會(huì)遇到各種光怪陸離的問題。這里分享一些常見的“坑”和排查手段。5.1 常見問題速查表問題現(xiàn)象可能原因排查步驟與解決方案播放無聲1. 權(quán)限未申請(qǐng)Android 6.0。2.AudioTrack未調(diào)用play()。3. 寫入的數(shù)據(jù)全是0或格式錯(cuò)誤。4. 音頻焦點(diǎn)被其他應(yīng)用持有且你的應(yīng)用未正確處理焦點(diǎn)丟失。5. 輸出設(shè)備路由錯(cuò)誤如應(yīng)在揚(yáng)聲器卻路由到了聽筒。6. 系統(tǒng)音量或媒體音量為0。1. 檢查RECORD_AUDIO權(quán)限錄制時(shí)和運(yùn)行時(shí)申請(qǐng)。2. 添加日志確認(rèn)play()被調(diào)用且狀態(tài)正確。3. 檢查PCM數(shù)據(jù)源用工具如Audacity查看波形。確認(rèn)采樣率、聲道、位深與AudioFormat匹配。4. 實(shí)現(xiàn)AudioManager.OnAudioFocusChangeListener檢查焦點(diǎn)狀態(tài)。5. 監(jiān)聽AudioDeviceCallback檢查當(dāng)前輸出設(shè)備。嘗試用AudioManager調(diào)整路由。6. 檢查AudioManager.getStreamVolume(AudioManager.STREAM_MUSIC)。錄音無聲或雜音1. 權(quán)限未申請(qǐng)。2. 音頻源AudioSource選擇錯(cuò)誤例如在通話中用了MIC而非VOICE_COMMUNICATION。3. 緩沖區(qū)大小不合適導(dǎo)致數(shù)據(jù)丟失或重疊。4. 麥克風(fēng)被其他應(yīng)用獨(dú)占。5. 設(shè)備硬件或驅(qū)動(dòng)問題。1. 同上檢查權(quán)限。2. 根據(jù)場景選擇合適的AudioSource語音場景優(yōu)先嘗試VOICE_COMMUNICATION。3. 使用getMinBufferSize獲取建議值并適當(dāng)增大。4. 嘗試重啟應(yīng)用或設(shè)備排除占用。5. 使用系統(tǒng)自帶的錄音機(jī)測試硬件是否正常。播放延遲高1.AudioTrack緩沖區(qū)設(shè)置過大。2. 使用MODE_STREAM但write調(diào)用間隔不穩(wěn)定。3. 系統(tǒng)負(fù)載高AudioFlinger混音線程調(diào)度延遲。4. 輸出設(shè)備本身有延遲如某些藍(lán)牙音箱。1. 在保證不欠載的前提下減小緩沖區(qū)大小。使用getMinBufferSize。2. 確保在獨(dú)立的高優(yōu)先級(jí)線程中穩(wěn)定、及時(shí)地調(diào)用write?？紤]使用Choreographer或固定頻率的定時(shí)器。3.切換到AAudio API并啟用低延遲模式這是最有效的方案。4. 檢測當(dāng)前輸出設(shè)備對(duì)藍(lán)牙設(shè)備用戶教育或游戲內(nèi)做延遲補(bǔ)償校準(zhǔn)。音頻播放卡頓、爆音1.write數(shù)據(jù)不及時(shí)緩沖區(qū)欠載Underrun。2.AudioTrack的播放線程優(yōu)先級(jí)不夠被系統(tǒng)搶占。3. GC垃圾回收導(dǎo)致線程暫停。4. PCM數(shù)據(jù)本身有問題如采樣率不匹配導(dǎo)致重采樣異常。1. 增大緩沖區(qū)或優(yōu)化數(shù)據(jù)供給線程的性能和優(yōu)先級(jí)。2. 創(chuàng)建AudioTrack的線程或數(shù)據(jù)寫入線程可以適當(dāng)提高優(yōu)先級(jí)。3. 避免在音頻線程中分配大量小對(duì)象使用對(duì)象池或直接內(nèi)存ByteBuffer.allocateDirect。4. 確保數(shù)據(jù)格式與AudioTrack配置完全一致特別是采樣率。多路音頻混合時(shí)音量或優(yōu)先級(jí)異常1. 未正確設(shè)置AudioAttributesusage, contentType。2. 未正確請(qǐng)求和管理音頻焦點(diǎn)。3. AudioPolicy策略配置問題系統(tǒng)級(jí)。1. 為不同的音頻流設(shè)置正確的AudioAttributes例如媒體用USAGE_MEDIA警報(bào)用USAGE_ALARM。2. 嚴(yán)格遵循音頻焦點(diǎn)協(xié)議在播放前請(qǐng)求在失去焦點(diǎn)時(shí)暫停/停止在獲得焦點(diǎn)時(shí)恢復(fù)。3. 作為應(yīng)用開發(fā)者此問題通常無法直接解決但可以檢查系統(tǒng)日志中AudioPolicy相關(guān)的錯(cuò)誤。5.2 高級(jí)調(diào)試工具與方法當(dāng)問題比較棘手時(shí)需要借助更強(qiáng)大的工具。查看系統(tǒng)日志adb logcat是首選。重點(diǎn)關(guān)注AudioTrack,AudioFlinger,AudioPolicyManager,AAudio等Tag的日志。例如搜索“underrun”可以找到播放卡頓的直接證據(jù)搜索“setParameters”可以看到音頻路由的變化。使用dumpsysadb shell dumpsys audio命令可以打印出當(dāng)前整個(gè)音頻系統(tǒng)的完整狀態(tài)信息量巨大。包括所有活躍的AudioTrack及其客戶端、采樣率、緩沖區(qū)狀態(tài)。音頻焦點(diǎn)持有者棧。當(dāng)前所有輸入/輸出設(shè)備及其狀態(tài)。AudioPolicy的配置和當(dāng)前策略。這對(duì)于分析復(fù)雜的多應(yīng)用音頻交互問題非常有用。性能跟蹤Systrace/Perfetto 使用Android Studio的Profiler或命令行工具perfetto/systrace可以捕捉一段時(shí)間內(nèi)的系統(tǒng)活動(dòng)。在音頻問題排查時(shí)關(guān)注音頻線程 查看你的應(yīng)用音頻線程AudioTrack寫入線程、AAudio回調(diào)線程的調(diào)度情況是否被長時(shí)間阻塞。binder調(diào)用 應(yīng)用與AudioFlinger/AudioPolicyService的Binder通信是否耗時(shí)過長。CPU頻率 是否因?yàn)榻殿l導(dǎo)致數(shù)據(jù)處理不及時(shí)。編寫單元測試與模擬測試 對(duì)于核心的音頻處理邏輯如解碼后PCM數(shù)據(jù)的校驗(yàn)、自定義音頻算法的輸出盡量編寫本地單元測試JUnit。對(duì)于涉及硬件交互的部分如AudioRecord/AudioTrack可以嘗試使用AndroidX的androidx.test.core.app.ApplicationProvider和模擬上下文進(jìn)行集成測試或者使用依賴注入如Dagger在測試時(shí)替換真實(shí)的音頻組件為Mock對(duì)象。音頻開發(fā)就像在一條多層的立交橋上開車你需要知道自己在哪一層目標(biāo)出口在哪里并遵守交通規(guī)則音頻焦點(diǎn)。希望這篇超長的梳理能成為你手上的詳細(xì)導(dǎo)航地圖。從宏觀架構(gòu)到微觀API從基礎(chǔ)使用到高級(jí)優(yōu)化從原理到實(shí)戰(zhàn)避坑內(nèi)容雖多但都是實(shí)踐中一點(diǎn)一滴積累起來的。真正的掌握還需要你在具體的項(xiàng)目中反復(fù)實(shí)踐、踩坑、總結(jié)。當(dāng)你再遇到音頻問題時(shí)能夠冷靜地根據(jù)現(xiàn)象沿著“應(yīng)用層-Java層-Native層-HAL-驅(qū)動(dòng)”這條鏈去思考和分析那這篇梳理的目的就達(dá)到了。最后記住兩個(gè)黃金法則一是生命周期管理務(wù)必嚴(yán)謹(jǐn)及時(shí)release二是對(duì)延遲敏感就上AAudio。