在上一篇《RkAi架構(gòu)篇》中，我們搭建了RkAi子系統(tǒng)的整體框架：Binder Service注冊(cè)、AIDL接口設(shè)計(jì)、客戶端API封裝。

本篇我們來追蹤兩條完整的數(shù)據(jù)流：

?ASR上行：麥克風(fēng)采集的音頻數(shù)據(jù)→ AudioFlinger → JNI → Java服務(wù)端→ App回調(diào)

?LLM下行：App發(fā)送的文本消息→ Binder →服務(wù)端廣播→各監(jiān)聽器

并深入分析JNI層的實(shí)現(xiàn)細(xì)節(jié)、線程模型、以及性能瓶頸。

思維導(dǎo)圖

1.前置知識(shí)

1.1 Android音頻系統(tǒng)概覽

Android音頻系統(tǒng)的核心構(gòu)件：

?AudioFlinger：音頻系統(tǒng)的服務(wù)端，管理音頻輸入輸出流

?AudioSystem：封裝AudioFlinger的客戶端API，包括回調(diào)注冊(cè)

?BnRkAiCallback：RK自定義的Binder回調(diào)接口，用于從音頻HAL實(shí)時(shí)獲取語音數(shù)據(jù)

1.2 JNI的JNI_OnLoad機(jī)制

當(dāng)Java代碼調(diào)用System.loadLibrary()時(shí)，Native庫的JNI_OnLoad()會(huì)被自動(dòng)調(diào)用。該函數(shù)有兩個(gè)職責(zé)：

1.通過RegisterNatives()注冊(cè)Java native方法的C實(shí)現(xiàn)

2.緩存jmethodID/jfieldID，避免運(yùn)行時(shí)重復(fù)查找

// onload.cppextern"C"jintJNI_OnLoad(JavaVM* vm,void*) { register_com_android_server_RkAiManagerService(env); register_com_android_server_rkdisplay_RkDisplayModes(env); returnJNI_VERSION_1_4;}

2. ASR上行數(shù)據(jù)路徑（Native → Java → App）

這是RkAi當(dāng)前唯一激活的通路。麥克風(fēng)采集到的音頻數(shù)據(jù)經(jīng)過層層傳遞，最終到達(dá)應(yīng)用層的OnRkAiListener。

2.1完整路徑圖

2.2第①步：音頻采集與回調(diào)注冊(cè)

RkAi服務(wù)啟動(dòng)時(shí)，nativeInit(true)做了兩件事：

// com_android_server_RkAiManagerService.cppstaticintnativeInit(JNIEnv* env, jobject obj, jboolean supportAsr){ if(supportAsr) {    mRkAiAsrCallback = sp::make();    AudioSystem::setRkAiCallback(mRkAiAsrCallback);  } return1;}

關(guān)鍵點(diǎn)：

?JRkAiAsrCallback繼承自BnRkAiCallback（Android Binder框架的Native端實(shí)現(xiàn)）

?通過AudioSystem::setRkAiCallback()注冊(cè)到AudioFlinger

?AudioFlinger在有音頻輸入時(shí)，回調(diào)onAsrBuffer()

2.3第②步：JNI回調(diào)與類型轉(zhuǎn)換

這是最核心的C++代碼：

// JRkAiAsrCallback 的構(gòu)造函數(shù)JRkAiAsrCallback() {  env = AndroidRuntime::getJNIEnv();  clazz = env->FindClass("com/android/server/RkAiManagerService");}// onAsrBuffer 回調(diào)binder::StatusonAsrBuffer(conststd::vector& buffer,int32_tlen)override{  JNIEnv* env = AndroidRuntime::getJNIEnv();  jshortArray jArray = env->NewShortArray(len);  jshort *jBuffer =newjshort[len]; if(jArray !=NULL&& jBuffer !=NULL) {   // 逐元素拷貝：vector → short[]   for(inti =0; i < len; ++i) {? ? ? ? ? ? jBuffer[i] =?static_cast(buffer[i]);    }    env->SetShortArrayRegion(jArray,0, len, jBuffer);    jint jLen =static_cast(len);   // 調(diào)用 Java 靜態(tài)方法    env->CallStaticVoidMethod(clazz, gClassInfo.asrBufferFromNative, jArray, jLen);    env->DeleteLocalRef(jArray);  } delete[] jBuffer; returnbinder::ok();}

值得注意的設(shè)計(jì)細(xì)節(jié)：

1.類型不匹配— AudioFlinger送出vector（32位），但Java側(cè)期望short[]（16位）。JNI層做了int → short的逐元素截?cái)噢D(zhuǎn)換。這暗示音頻數(shù)據(jù)實(shí)際使用的就是16bit采樣（標(biāo)準(zhǔn)PCM 16bit格式），用vector是AudioFlinger回調(diào)接口的歷史設(shè)計(jì)。

2.手動(dòng)分配臨時(shí)緩沖區(qū)—new jshort[len]+SetShortArrayRegion的組合，沒有直接用NewShortArray的原生指針寫入。這里有一次額外的內(nèi)存拷貝（jBuffer→ JVM管理的jshortArray）。

3.JNIEnv線程問題—構(gòu)造函數(shù)中獲取的env在回調(diào)線程中可能無效，所以onAsrBuffer中每次都重新調(diào)用AndroidRuntime::getJNIEnv()獲取當(dāng)前線程的JNIEnv。這是一種防御性寫法。

4.static jmethodID緩存—gClassInfo.asrBufferFromNative在JNI_OnLoad時(shí)通過GetStaticMethodID緩存下來，避免了每次回調(diào)時(shí)重復(fù)查找。

2.4第③步：Java靜態(tài)方法asrBufferFromNative

// RkAiManagerService.javaprivatestaticvoidasrBufferFromNative(finalshort[] buffer,finalintlen){ Bundlebundle=newBundle();  bundle.putShortArray(RkAiManager.EXTRA_ASR_BUFFER, buffer);  bundle.putInt(RkAiManager.EXTRA_ASR_BUFFER_LEN, len);  sendRkAiMsg(newRkAiData(RkAiManager.RKAI_TYPE_ASR, bundle));}

這個(gè)方法有幾個(gè)重要設(shè)計(jì)：

?static方法—因?yàn)閺腏NI只能直接調(diào)用靜態(tài)方法，無需對(duì)象實(shí)例

?Bundle封裝—用Bundle作為靈活的數(shù)據(jù)容器，可以方便地?cái)U(kuò)展鍵值對(duì)

?final參數(shù)— final阻止方法將buffer重新指向另一個(gè)數(shù)組（不能buffer = new short[...]），加強(qiáng)代碼安全

2.5第④步：RemoteCallbackList廣播

// RkAiManagerService.javaprivatestaticvoidsendRkAiMsg(RkAiData data){ finalintnum=mListeners.beginBroadcast(); try{   for(inti=0; i < num; i++) {? ? ? ? ? ??try?{? ? ? ? ? ? ? ? mListeners.getBroadcastItem(i).dispatchRkAiListener(data);? ? ? ? ? ? }?catch?(Exception e) {? ? ? ? ? ? ? ? e.printStackTrace();? ? ? ? ? ? }? ? ? ? }? ? }?finally?{? ? ? ? mListeners.finishBroadcast();? ? }}

RemoteCallbackList是Android系統(tǒng)服務(wù)中管理跨進(jìn)程回調(diào)的標(biāo)準(zhǔn)方式：

?beginBroadcast()—鎖定內(nèi)部列表，獲取當(dāng)前注冊(cè)的listener快照

?getBroadcastItem(i)—獲取第i個(gè)listener的Binder代理

?finishBroadcast()—解鎖

廣播期間如果某個(gè)listener的進(jìn)程已死亡，調(diào)用dispatchRkAiListener()會(huì)拋出DeadObjectException，被catch塊捕獲后繼續(xù)廣播剩下listener。

2.6第⑤步：回到App主線程

IOnRkAiListener接口聲明為oneway，所以服務(wù)端的廣播調(diào)用是非阻塞的。在App端，Binder回調(diào)到達(dá)的線程是Binder線程池中的線程，不能直接做UI操作。

oneway關(guān)鍵字意味著：Binder調(diào)用在事務(wù)發(fā)送后立即返回，不等待服務(wù)端執(zhí)行完畢；不保證發(fā)送順序與服務(wù)端處理順序一致；服務(wù)端的DeadObjectException（進(jìn)程死亡）無法被oneway調(diào)用檢測(cè)到（Binder驅(qū)動(dòng)不會(huì)回復(fù)錯(cuò)誤）。

// RkAiManager.java — mServiceListenerprivatefinalIOnRkAiListener.StubmServiceListener=newIOnRkAiListener.Stub() { @Override publicvoiddispatchRkAiListener(RkAiData data){    mHandler.post(() -> {      reportRkAiMsg(data);    });  }};

?mHandler.post()—通過Handler將reportRkAiMsg()投遞到創(chuàng)建RkAiManager時(shí)所在的線程（通常是App的主線程）

?這意味著App不需要額外做線程同步——回調(diào)的最終分發(fā)總在主線程

2.7第⑥步：reportRkAiMsg分發(fā)

// RkAiManager.javavoidreportRkAiMsg(RkAiData data){  Object[] listeners; synchronized(mListeners) {   finalintN=mListeners.size();   if(N <=?0)?return;? ? ? ? listeners = mListeners.toArray(); ?// 快照，避免遍歷時(shí)被修改? ? }? ??for?(int?i?=?0; i < listeners.length; i++) {? ? ? ??switch?(data.getType()) {? ? ? ? ? ??case?RKAI_TYPE_ASR: {? ? ? ? ? ? ? ??Bundle?info?=?data.getInfo();? ? ? ? ? ? ? ??if?(null?!= info) {? ? ? ? ? ? ? ? ? ??short[] buffer = info.getShortArray(EXTRA_ASR_BUFFER);? ? ? ? ? ? ? ? ? ??int?len?=?info.getInt(EXTRA_ASR_BUFFER_LEN,?0);? ? ? ? ? ? ? ? ? ? ((OnRkAiListener)listeners[i]).onRkAiAsrBuffer(buffer, len);? ? ? ? ? ? ? ? }? ? ? ? ? ? ? ??break;? ? ? ? ? ? }? ? ? ? ? ??// LLM 類型同理處理? ? ? ? }? ? }}

這里用了Copy-on-Write模式：在synchronized塊內(nèi)調(diào)用toArray()拿到監(jiān)聽器列表的快照，然后在鎖外出逐個(gè)調(diào)用回調(diào)。這樣：

?添加/刪除listener的操作與回調(diào)互不干擾

?即使遍歷過程中有l(wèi)istener被移除，已拿到的快照依然有效

3. LLM下行數(shù)據(jù)路徑（App → Service →廣播）

ASR是Native → Java的上行方向，LLM則是App → Service的下行方向。不過當(dāng)前SUPPORT_RKAI_LLM = false，所以這條路徑處于"有代碼但未啟用"狀態(tài)。

3.1路徑圖

3.2 LLM消息的獨(dú)特之處

與ASR不同，LLM消息的源是App本身：

// RkAiManager.javapublicvoidsendRkAiLlmMsg(StringselectText,StringcontextText) { Bundlebundle =newBundle();  bundle.putString(EXTRA_SELECT_TEXT, selectText);  bundle.putString(EXTRA_CONTEXT_TEXT, contextText); RkAiDatadata =newRkAiData(RKAI_TYPE_LLM, bundle);  mService.sendRkAiMsg(data, ...);}

當(dāng)前SUPPORT_RKAI_LLM = false，但這套代碼的架構(gòu)思路是：

1.App通過Binder把選中文本和上下文文本發(fā)給服務(wù)端

2.服務(wù)端廣播給所有注冊(cè)的listener

3.監(jiān)聽器（比如另一個(gè)App進(jìn)程的后臺(tái)服務(wù)）解析文本，調(diào)用LLM推理

4.推理結(jié)果再通過另一個(gè)通道返回

這種"發(fā)一條消息播報(bào)給所有人"的模式與ASR的"單路采集多路分發(fā)"本質(zhì)上是相同的。

4.線程模型深度分析

理解RkAi的線程模型，對(duì)排查音頻延遲、卡頓、ANR問題至關(guān)重要。

4.1各線程的角色

4.2 "切線程"的設(shè)計(jì)考量

從Native到App回調(diào)，經(jīng)歷了兩次線程切換：

AudioFlinger線程 → (1) JNI 回調(diào) → (2) Binder IPC → (3) Handler Post

為什么不在JNI直接廣播？
因?yàn)镽emoteCallbackList的操作（beginBroadcast）需要在Java線程上下文中執(zhí)行，且Binder調(diào)用本身就需要線程池。JNI層只做類型轉(zhuǎn)換和Java靜態(tài)方法調(diào)用，是合理的設(shè)計(jì)選擇。

為什么App端要用Handler？
因?yàn)镮OnRkAiListener雖然是oneway（非阻塞），但回調(diào)仍然在Binder線程池中執(zhí)行。如果App直接在Binder回調(diào)中處理音頻數(shù)據(jù)：

?會(huì)占用Binder線程，影響跨進(jìn)程通信的吞吐

?Binder線程不能進(jìn)行UI操作

?線程不匹配可能導(dǎo)致App內(nèi)部死鎖

mHandler.post()保證了App的回調(diào)總在預(yù)期線程（主線程或自定義Looper線程）中執(zhí)行。

5.性能分析與優(yōu)化思考

5.1性能熱點(diǎn)

每次回調(diào)涉及的主要開銷（按從左到右）：

5.2可優(yōu)化點(diǎn)

1.消除逐元素拷貝
當(dāng)前代碼for (int i=0; i

2.流控機(jī)制缺失
當(dāng)前onAsrBuffer不做任何流控——AudioFlinger以多快頻率回調(diào)，JNI就以多快頻率廣播。如果App端的listener消費(fèi)速度跟不上，沒有背壓機(jī)制，可能導(dǎo)致App側(cè)的Handler消息隊(duì)列堆積。
可以考慮的方案：在JNI層實(shí)現(xiàn)一個(gè)環(huán)形緩沖區(qū)+降采樣邏輯。

3. Binder死亡重連缺失
如果系統(tǒng)服務(wù)重啟（比如SystemServer crash），RkAiManager持有的mServiceBinder代理會(huì)變成死對(duì)象。當(dāng)前代碼沒有重試或重連機(jī)制，所有后續(xù)API調(diào)用會(huì)拋出RemoteException。

4. AudioSystem回調(diào)線程優(yōu)先級(jí)
如果onAsrBuffer中執(zhí)行了太重的操作（比如Java靜態(tài)方法調(diào)用中的Bundle分配），可能拖慢AudioFlinger的處理線程。建議在JNI層就做一次線程切換，用獨(dú)立的Native線程接收回調(diào)，再異步轉(zhuǎn)發(fā)到Java層。

5.3內(nèi)存開銷

為分析每次ASR回調(diào)的內(nèi)存分配路徑：

AudioFlinger:  vector (4*lenbytes)JNI:       jshort[]  (2*lenbytes, JVM heap)         + jBuffer (2*lenbytes, native heap, 臨時(shí))Java:      Bundle    (內(nèi)部數(shù)組)Binder:     Parcel    (序列化后的數(shù)據(jù))App:       Handler msg + dispatch

實(shí)際上每次回調(diào)會(huì)有4-5倍于原始數(shù)據(jù)量的臨時(shí)內(nèi)存分配。如果ASR頻率很高（如10ms一次），這些臨時(shí)對(duì)象的GC壓力不小。

6.調(diào)試方法

6.1 ASR路徑驗(yàn)證

# 開啟所有 RkAi 相關(guān)日志adb logcat -s RkAiManager RkAiManagerService RkAiManagerNative# 確認(rèn)服務(wù)已注冊(cè)adb shell service check rkai_management# 查看 ASR 數(shù)據(jù)流# 關(guān)鍵詞：asrBufferFromNative — JNI 到 Java 的入口#     sendRkAiMsg — 廣播#     dispatchRkAiListener — 回調(diào)到 App# 監(jiān)測(cè) ASR 回調(diào)頻率adb logcat -s RkAiManagerNative | grep -o"onAsrBuffer"|wc-l

6.2 Native層調(diào)試

# JNI 回調(diào)是否生效# 正常 logcat 應(yīng)有：# RkAiManagerNative: nativeInit supportAsr=1# 如果 ASR 回調(diào)沒到 Java，檢查：# 1. AudioSystem::setRkAiCallback 是否成功# 2. BnRkAiCallback 的 onAsrBuffer 是否命中

6.3常見問題排查

7.總結(jié)

通過本篇的詳細(xì)追蹤，可以看到RkAi子系統(tǒng)在兩個(gè)方向上的數(shù)據(jù)流：

完整的調(diào)用鏈及每層的職責(zé)：

改進(jìn)空間總結(jié)：

1.JNI層的int→short逐元素拷貝可以優(yōu)化

2.缺少ASR數(shù)據(jù)的流控/背壓機(jī)制

3.RkAiManager缺少Binder死亡重連

4.高頻ASR回調(diào)下的GC壓力需要評(píng)估

5.服務(wù)端不對(duì)callingPackage做權(quán)限校驗(yàn)

審核編輯 黃宇