簡(jiǎn)介一份面向Unity開(kāi)發(fā)者的原生安卓調(diào)用入門(mén)工具集圍繞UnityActivity、UnityAppContext、PackageManager、RunOnUIThread等核心方法覆蓋Toast、Log、Java與C#字符串互轉(zhuǎn)等基礎(chǔ)交互并整合網(wǎng)上常用方式與自制封裝提供獲取App列表、判斷服務(wù)/應(yīng)用運(yùn)行狀態(tài)、打開(kāi)/安裝/卸載App、發(fā)送廣播以及獲取WiFi狀態(tài)、安卓版本、原生類(lèi)型ID、內(nèi)置SD卡路徑等系統(tǒng)信息。壓縮包共45個(gè)文件以cs腳本、asset場(chǎng)景資源、meta配置文件為主另有unity場(chǎng)景、xml配置、txt說(shuō)明和jar包整體僅48KB結(jié)構(gòu)清晰便于按需取用。目前已有743人學(xué)習(xí)瀏覽。借助該工具集可減少原生插件開(kāi)發(fā)的前期摸索直接復(fù)用現(xiàn)成方法快速集成到自己的Unity項(xiàng)目中同時(shí)可作為入門(mén)參考理解Unity與安卓原生交互的常見(jiàn)調(diào)用方式與封裝思路。1. Unity調(diào)用原生安卓這件事值得先搞清邊界再動(dòng)手很多開(kāi)發(fā)者第一次在 Unity 里遇到需要調(diào)用安卓原生能力時(shí)想的都是趕緊搜一段 AndroidJavaClass(android.widget.Toast) 的示例代碼貼上去。某開(kāi)發(fā)者在做一個(gè)跨平臺(tái)工具時(shí)也這么干過(guò)結(jié)果項(xiàng)目能編譯通過(guò)真機(jī)上一跑就崩最終發(fā)現(xiàn)是 Activity 引用為 null。Unity 調(diào)用原生安卓不是一句用 AndroidJavaClass 就行那么輕巧它涉及 JNI 橋接、Activity 生命周期、構(gòu)建產(chǎn)物aar/jar如何進(jìn)入最終 APK 等一系列前提。這份工具集適合已經(jīng)在 Unity 里做過(guò)基礎(chǔ)功能、卻卡在原生互通這一步的從業(yè)者它能幫你快速搭出可運(yùn)行的調(diào)用鏈路也把最容易踩的坑預(yù)先標(biāo)出來(lái)。2. 橋接原理與工程準(zhǔn)備JNI 鏈路和三個(gè)前置配置2.1 Unity 與安卓之間那層 JNIAndroidJavaClass 到底做了什么Unity 在安卓側(cè)不是簡(jiǎn)單地反射調(diào)用。每個(gè) AndroidJavaClass / AndroidJavaObject 實(shí)例背后都對(duì)應(yīng)一個(gè) JNI 全局引用。JNI 是 Java 與 C/C 之間的橋梁而 Unity 的 C# 層通過(guò)一組內(nèi)部封裝的 JNI 接口把類(lèi)型信息、方法簽名、參數(shù)值一層層傳到 Java 虛擬機(jī)里。當(dāng)一個(gè) C# 腳本寫(xiě)下AndroidJavaClass jc new AndroidJavaClass(com.unity3d.player.UnityPlayer); AndroidJavaObject activity jc.GetStaticAndroidJavaObject(currentActivity);這里實(shí)際發(fā)生了兩件事第一JNI 層根據(jù)類(lèi)名com.unity3d.player.UnityPlayer去已加載的類(lèi)里查找第二讀取靜態(tài)字段 currentActivity 并返回一個(gè) JNI 引用。這個(gè)引用在 C# 側(cè)被包裝成 AndroidJavaObject底層指針指向 Java 堆上的 Activity 實(shí)例。理解這一點(diǎn)很重要如果你持有這個(gè)引用而 Activity 已經(jīng)被系統(tǒng)回收那后續(xù)任何 Call 都可能拋異常。從調(diào)用模型上看Unity 側(cè)所有對(duì) Java 的調(diào)用都是單向、同步的除非你主動(dòng)開(kāi)線程。也就是說(shuō)C# 調(diào)用 Java 方法后線程會(huì)卡在 JNI 調(diào)用點(diǎn)上直到 Java 方法返回。這給后續(xù)的性能優(yōu)化留下了一個(gè)課題第5章會(huì)專(zhuān)門(mén)講。2.2 工程側(cè)三個(gè)前置配置SDK、Player Settings 和 Plugins/Android 目錄在我經(jīng)手的幾個(gè) Unity安卓互通項(xiàng)目里大部分跑不通的第一原因不是代碼寫(xiě)錯(cuò)而是工程配置不完整。需要先整理好三件事。第一Android SDK 路徑。Unity 的 Preferences 里 External Tools 面板需要正確指向 SDK 位置。如果你同時(shí)裝了 Android StudioSDK 路徑一般在 Android/Sdk 目錄。如果路徑不對(duì)Unity 打包時(shí)會(huì)直接報(bào)SDK not found這個(gè)一般難不倒人。第二Player Settings。打開(kāi) Edit Project Settings Player切換到 Android 標(biāo)簽頁(yè)。重點(diǎn)檢查三項(xiàng)Package Name包名必須與之后 Android 工程里要合并的 manifest 包名兼容避免沖突。Minimum API LevelUnity 會(huì)以此為準(zhǔn)來(lái)決定哪些 API 可直接調(diào)用。設(shè)置太低Java 側(cè)一些新接口會(huì)因 NoSuchMethodError 掛掉設(shè)置太高又會(huì)壓縮可覆蓋的機(jī)型范圍。Scripting BackendIL2CPP 和 Mono 在跨語(yǔ)言調(diào)用上的行為其實(shí)不一樣。IL2CPP 對(duì) AOT 的限制更嚴(yán)格如果后續(xù)要在 IL2CPP 下做裁剪strip engine code某些反射調(diào)用會(huì)被裁掉需要加 link.xml。這點(diǎn)容易被忽略后面避坑章節(jié)會(huì)有一個(gè)專(zhuān)門(mén)案例。第三Plugins/Android 目錄。Unity 在構(gòu)建 APK/AAB 時(shí)會(huì)把這個(gè)目錄下的內(nèi)容合并進(jìn)最終工程。最常見(jiàn)的路徑是 Assets/Plugins/Android。要注意的是這個(gè)目錄里如果同時(shí)存在同名不同版本的文件比如兩個(gè)版本的 support 庫(kù)最終行為完全取決于 Unity 內(nèi)部的合并順序這在后面也會(huì)細(xì)說(shuō)。2.3 最小調(diào)用鏈路從 Unity 發(fā)一條 Toast 驗(yàn)證通路工程配置完成后先別急著寫(xiě)業(yè)務(wù)代碼。我用一條最簡(jiǎn)單的 Toast 驗(yàn)證整條通路。創(chuàng)建一個(gè) C# 腳本掛在場(chǎng)景主物體上using UnityEngine; public class NativeBridge : MonoBehaviour { void Start() { ShowToast(Hello from Unity); } public void ShowToast(string msg) { AndroidJavaClass unityPlayer new AndroidJavaClass(com.unity3d.player.UnityPlayer); AndroidJavaObject currentActivity unityPlayer.GetStaticAndroidJavaObject(currentActivity); AndroidJavaClass toastClass new AndroidJavaClass(android.widget.Toast); // 最后一個(gè)參數(shù) 0 表示 LENGTH_SHORT1 表示 LENGTH_LONG AndroidJavaObject toast toastClass.CallStaticAndroidJavaObject(makeText, currentActivity, msg, 0); toast.Call(show); } }這里解釋一下關(guān)鍵點(diǎn)com.unity3d.player.UnityPlayer 是 Unity 在安卓側(cè)的核心類(lèi)currentActivity 這個(gè)靜態(tài)字段在任何標(biāo)準(zhǔn) Unity Activity 生命周期內(nèi)都可訪問(wèn)。makeText 是 Toast 的靜態(tài)方法接收三個(gè)參數(shù)Context、CharSequence、duration。C# 傳字符串、int 時(shí)JNI 層會(huì)自動(dòng)映射到對(duì)應(yīng)的 Java 類(lèi)型。toast.Call(show) 調(diào)用的是實(shí)例方法返回值是 void所以直接 Call 即可。代碼是通了但有個(gè)細(xì)節(jié)必須說(shuō)不要在任何回調(diào)、協(xié)程恢復(fù)、或者事件系統(tǒng)里反復(fù) new AndroidJavaClass。這是因?yàn)槊?new 一次JNI 全局引用表里就會(huì)多一條引用長(zhǎng)期運(yùn)行可能把引用表?yè)伪＿@個(gè)坑很隱蔽實(shí)際項(xiàng)目里遇到過(guò)一次排查了一整天才定位到。3. 三種集成方式與參數(shù)透?jìng)鲝姆瓷湔{(diào)用到導(dǎo)出 aar3.1 方式一運(yùn)行時(shí)反射——適合輕量調(diào)用不碰 Android Studio如果你只是調(diào)用系統(tǒng) APIToast、振動(dòng)、剪貼板或者調(diào)用一個(gè)不常改動(dòng)的第三方 Java 靜態(tài)方法運(yùn)行時(shí)反射方式最省事。它不需要你在 Android Studio 里建工程也不需要導(dǎo)出 aar直接把類(lèi)名、方法名、參數(shù)寫(xiě)在 C# 里。比如讀取設(shè)備 Android IDpublic string GetAndroidId() { AndroidJavaClass unityPlayer new AndroidJavaClass(com.unity3d.player.UnityPlayer); AndroidJavaObject activity unityPlayer.GetStaticAndroidJavaObject(currentActivity); AndroidJavaObject resolver activity.CallAndroidJavaObject(getContentResolver); AndroidJavaClass settingsSecure new AndroidJavaClass(android.provider.Settings$Secure); // 第二個(gè)參數(shù)是默認(rèn)值當(dāng)系統(tǒng)未開(kāi)啟時(shí)返回的兜底字符串 string androidId settingsSecure.CallStaticstring(getString, resolver, android_id); return androidId; }這種方式的好處是靈活C# 改完直接跑。壞處也明顯沒(méi)有任何編譯期檢查方法名拼錯(cuò)、參數(shù)類(lèi)型傳錯(cuò)都得運(yùn)行時(shí)報(bào)異常而且異常信息被 JNI 層包了一層Logcat 里往往是 UnsatisfiedLinkError 或 NoSuchMethodError對(duì)新人來(lái)說(shuō)排查成本高。所以我一般會(huì)在方法入口包一層 try-catch把異常信息帶出來(lái)try { // ... 調(diào)用邏輯 } catch (System.Exception e) { Debug.LogError($[NativeBridge] JNI 調(diào)用失敗: {e.Message}); }這樣至少能看到是類(lèi)找不到、方法找不到還是參數(shù)類(lèi)型不匹配。3.2 方式二導(dǎo)出 aar——功能復(fù)雜時(shí)更穩(wěn)的工程化路徑當(dāng)你的原生代碼里開(kāi)始有多個(gè)類(lèi)、有 Activity 跳轉(zhuǎn)、有回調(diào)接口的時(shí)候運(yùn)行時(shí)反射方式會(huì)變得很脆每改一次 Java 代碼都要重新打包、替換文件。這個(gè)階段就要轉(zhuǎn)到 Android Library 工程上去。常見(jiàn)做法是在 Android Studio 里新建一個(gè) Library Module然后編寫(xiě)原生邏輯。我用一個(gè)最小示例模塊名比如叫 nativebridgepackage com.example.nativebridge; import android.content.Context; import android.widget.Toast; public class Bridge { private Context context; public Bridge(Context ctx) { this.context ctx.getApplicationContext(); } public void show(String message) { Toast.makeText(context, message, Toast.LENGTH_SHORT).show(); } public int add(int a, int b) { return a b; } }模塊的 build.gradle 需要做兩處關(guān)鍵配置android { defaultConfig { // 這兩項(xiàng)必須和 Unity 的 Player Settings 匹配或更低 minSdkVersion 22 targetSdkVersion 34 } }導(dǎo)出的 aar 文件位置一般在 build/outputs/aar/ 下。把這個(gè) aar 復(fù)制到 Unity 工程的 Assets/Plugins/Android 目錄后在 C# 側(cè)這樣調(diào)用public class NativeBridge : MonoBehaviour { private AndroidJavaObject bridgeObj; void Start() { AndroidJavaClass unityPlayer new AndroidJavaClass(com.unity3d.player.UnityPlayer); AndroidJavaObject activity unityPlayer.GetStaticAndroidJavaObject(currentActivity); // 構(gòu)造 Bridge 實(shí)例傳入當(dāng)前 Activity 的 ApplicationContext bridgeObj new AndroidJavaObject(com.example.nativebridge.Bridge, activity); bridgeObj.Call(show, bridge ready); int sum bridgeObj.Callint(add, 3, 5); Debug.Log([NativeBridge] sum sum); } void OnDestroy() { // 顯式釋放 JNI 引用長(zhǎng)期項(xiàng)目尤其重要 bridgeObj?.Dispose(); } }這段代碼里有兩個(gè)值得說(shuō)的點(diǎn)。第一new AndroidJavaObject(com.example.nativebridge.Bridge, activity) 的第二個(gè)參數(shù)會(huì)被 JNI 當(dāng)作構(gòu)造函數(shù)的第一個(gè)參數(shù)。因?yàn)?Bridge 的構(gòu)造器接收 Context這里傳 activity 正好匹配。如果構(gòu)造函數(shù)是重載的JNI 會(huì)根據(jù)傳入?yún)?shù)類(lèi)型去匹配簽名匹配不到會(huì)拋 NoSuchMethodError。第二OnDestroy 里做 Dispose。不看 GC 的情況下C# 側(cè)的 AndroidJavaObject 回收是不確定的顯式 Dispose 能防止 JNI 引用表泄漏。3.3 數(shù)據(jù)類(lèi)型映射表與帶參調(diào)用示例跨語(yǔ)言調(diào)用最容易出錯(cuò)的是類(lèi)型映射。下表是我從項(xiàng)目里總結(jié)出來(lái)的一份常用映射按C# - Java方向C# 側(cè)類(lèi)型Java 側(cè)接收類(lèi)型說(shuō)明stringString自動(dòng)轉(zhuǎn)換為 UTF-16 序列注意不要傳 nullintint32 位整型longlong64 位整型被 JNI 當(dāng)作 jlongfloatfloat32 位浮點(diǎn)doubledouble64 位浮點(diǎn)boolbooleanJNI 層用 z 表示AndroidJavaObject任意對(duì)象傳遞的是 JNI 引用不是拷貝有一個(gè)隱蔽的坑C# 的 string 在傳給 Java 時(shí)如果值是 nullJNI 層有時(shí)候會(huì)拋 NullPointerException 而不是友好提示。我在給某個(gè)功能傳剪切板文案時(shí)翻過(guò)一次車(chē)文案是空的Java 側(cè)收到的直接是 NPE。從那以后所有跨層字符串參數(shù)我都會(huì)先做空串兜底。再看一個(gè)帶數(shù)組參數(shù)的例子。假設(shè) Java 側(cè)有一個(gè)方法接收 int[] 和 String[]public void processArray(int[] values, String[] names) { // 業(yè)務(wù)邏輯 }C# 側(cè)調(diào)用路徑是int[] values { 10, 20, 30 }; string[] names { alpha, beta }; bridgeObj.Call(processArray, values, names);注意這里不能傳 List 或 List JNI 不會(huì)幫你做集合到數(shù)組的轉(zhuǎn)換。你需要手動(dòng)轉(zhuǎn)一次Liststring nameList new Liststring { alpha, beta }; bridgeObj.Call(processArray, values, nameList.ToArray());3.4 從安卓側(cè)拿返回值同步調(diào)用與異常捕獲前面 add 的例子已經(jīng)展示了 Call 同步拿返回值。這里的同步要再次強(qiáng)調(diào)Unity 的調(diào)用線程會(huì)阻塞直到 Java 方法執(zhí)行完。如果 Java 方法里有耗時(shí)操作比如網(wǎng)絡(luò)請(qǐng)求Unity 的 Update 循環(huán)會(huì)卡住表現(xiàn)就是游戲畫(huà)面掉幀甚至看起來(lái)像卡死。情況再極端一點(diǎn)如果 Java 方法內(nèi)部真正做的是阻塞在主線程上的東西而 Unity 側(cè)恰好是在主線程調(diào)用那連 Activity 的 UI 事件都處理不了最終可能觸發(fā) ANR。處理方式是讓 Java 側(cè)把耗時(shí)操作放到子線程或者 C# 側(cè)用異步包裝。C# 側(cè)異步包裝的一個(gè)簡(jiǎn)單方式是用協(xié)程輪詢(xún)結(jié)果。Java 側(cè)先啟動(dòng)任務(wù)C# 側(cè)每幀檢查一個(gè)是否完成的標(biāo)記IEnumerator WaitForNativeResult() { bool done bridgeObj.Callbool(isTaskDone); while (!done) { yield return null; done bridgeObj.Callbool(isTaskDone); } string result bridgeObj.Callstring(getResult); Debug.Log([NativeBridge] async result: result); }這段輪詢(xún)代碼適合低頻任務(wù)但如果每幀檢查頻繁JNI 調(diào)用開(kāi)銷(xiāo)會(huì)累積。更高效的做法是讓 Java 側(cè)在任務(wù)完成時(shí)主動(dòng)回調(diào) Unity這個(gè)到第5章展開(kāi)。4. 高頻踩坑與排查五個(gè)典型問(wèn)題的現(xiàn)象和根因這一章是我實(shí)際調(diào)試中遇到最多的問(wèn)題。每條都按現(xiàn)象 - 原因 - 解決來(lái)寫(xiě)讀的時(shí)候可以對(duì)照自己的項(xiàng)目逐條排除。4.1 現(xiàn)象調(diào)用 Java 方法直接閃退Logcat 提示 currentActivity 為 null原因UnityPlayer 的 currentActivity 靜態(tài)字段會(huì)在 Activity 的早期生命周期階段未被賦值。如果調(diào)用發(fā)生在 Application.onCreate比如你在自定義 Application 里初始化 SDK或者發(fā)生在 Activity.onDestroy 之后那拿到的引用就是 null。JNI 把 null 傳給 Java 方法時(shí)很多原生方法會(huì)直接拋空指針。解決把初始化時(shí)機(jī)推遲到第一個(gè)場(chǎng)景加載完成后或者緩存當(dāng)前 activity 之后手動(dòng)判空if (currentActivity null) { Debug.LogError([NativeBridge] currentActivity 為空檢查調(diào)用時(shí)機(jī)); return; }另外如果你的項(xiàng)目里啟用了自定義的 Intent Filter 或者使用了別的安卓組件currentActivity 在不同進(jìn)程里可能不一致這時(shí)候不要依賴(lài)它做操作改成傳 Application Context 更穩(wěn)。4.2 現(xiàn)象aar 文件放在 Assets/Plugins/Android 下打包出來(lái)類(lèi)找不到原因這類(lèi)問(wèn)題我遇到三種情況。第一aar 里的 AndroidManifest.xml 與 Unity 主工程 manifest 沖突導(dǎo)致整個(gè) aar 沒(méi)有被打進(jìn)最終包第二aar 的 minSdkVersion 高過(guò) Unity 項(xiàng)目的 Minimum API LevelGradle 合并時(shí)直接跳過(guò)第三Unity 版本太老2019 之前對(duì) aar 原生產(chǎn)物的支持有缺陷需要改成導(dǎo)出 Project 再通過(guò) Android Studio 集成。解決先檢查 aar 是否存在用壓縮工具打開(kāi)確認(rèn)里面 classes.jar 是否包含你的類(lèi)。再在 Player Settings 里調(diào)高 Minimum API Level 到至少和 aar 持平。如果還不行用 Unity 的 Export Project 導(dǎo)出 Gradle 工程然后在 Android Studio 里手動(dòng)添加 aar 依賴(lài)看 Android Studio 的 Gradle 面板輸出會(huì)更明確。4.3 現(xiàn)象從 Java 子線程調(diào)用 UnitySendMessageUnity 側(cè)偶爾收到、偶爾崩潰原因UnitySendMessage 這個(gè)接口在部分版本下要求必須從 Unity 主線程GL 線程調(diào)用。Java 子線程直接調(diào)時(shí)如果正好趕上 Unity 渲染管線切換會(huì)觸發(fā)一個(gè)未定義行為表現(xiàn)就是時(shí)好時(shí)壞。解決Java 側(cè)不要在子線程直接調(diào)而是先用 Handler 把回調(diào) post 到主線程再在主線程里調(diào)用 UnitySendMessageHandler mainHandler new Handler(Looper.getMainLooper()); mainHandler.post(new Runnable() { Override public void run() { UnityPlayer.UnitySendMessage(BridgeObject, OnNativeResult, done); } });這段代碼把真正調(diào)用 UnitySendMessage 的時(shí)機(jī)鎖定在安卓主線程規(guī)避了跨線程同步問(wèn)題。4.4 現(xiàn)象C# 傳 longJava 方法簽名是 int方法能調(diào)到但參數(shù)值不對(duì)原因JNI 的參數(shù)匹配是按照方法簽名嚴(yán)格來(lái)的C# 的 long 會(huì)映射成 Java 的 long而 Java 的 int 需要的是 C# 的 int兩者簽名的類(lèi)型描述符不同本來(lái)應(yīng)該拋 NoSuchMethodError。但某些 API特別是系統(tǒng) API可能有重載JNI 匹配到了另一個(gè)重載參數(shù)被靜默截?cái)?。表現(xiàn)就是代碼能跑結(jié)果錯(cuò)得離譜。解決嚴(yán)格按第3章的映射表來(lái)。不確定 Java 方法簽名時(shí)用 javap -s 查看真實(shí)簽名然后回到 C# 側(cè)比對(duì)。再補(bǔ)充一條這個(gè)方法在編譯時(shí)不會(huì)報(bào)錯(cuò)因?yàn)?AndroidJavaObject.Call 的泛型參數(shù)只決定了返回值的轉(zhuǎn)換不決定參數(shù)匹配。很多人在這一步翻車(chē)最后只能用日志排查。4.5 現(xiàn)象Release 構(gòu)建在真機(jī)上跑報(bào) NoClassDefFoundErrorDebug 構(gòu)建正常原因這是混淆或裁剪把類(lèi)丟了。兩個(gè)方向R8/ProGuard 把 Java 側(cè)類(lèi)名混淆了Unity 側(cè)再用反射查找原始類(lèi)名自然找不到另一個(gè)是 IL2CPP 的 Managed DLL 裁剪把 Unity 側(cè)調(diào)用 JNI 的 C# 類(lèi)裁掉了Unity 側(cè)代碼直接不存在。解決如果是 Android 側(cè)混淆在 proguard-rules.pro 里加保留規(guī)則-keep class com.example.nativebridge.** { *; }如果是 IL2CPP 裁剪在 Unity 里添加 link.xml保留包含 JNI 調(diào)用的程序集linker assembly fullnameAssembly-CSharp type fullnameNativeBridge preserveall / /assembly /linker這兩種處理方式在很多項(xiàng)目里是同時(shí)要做的缺一不可。5. 進(jìn)階把回調(diào)鏈路理順再做一次 JNI 調(diào)用瘦身5.1 用 UnitySendMessage 做雙向通信的完整閉環(huán)前面提到 Java 側(cè)要主動(dòng)通知 Unity 時(shí)用 UnitySendMessage。雙向通信在業(yè)務(wù)上往往是這樣閉環(huán)的Unity 發(fā)起一個(gè)請(qǐng)求Java 側(cè)在后臺(tái)執(zhí)行完成后回傳結(jié)果。Java 側(cè)關(guān)鍵代碼public void startAsyncWork(final String param) { new Thread(new Runnable() { Override public void run() { // 模擬耗時(shí) String result process(param); // 回調(diào)到 Unity 側(cè) runOnMainThread(new Runnable() { Override public void run() { UnityPlayer.UnitySendMessage(BridgeObject, OnNativeResult, result); } }); } }).start(); }Unity 側(cè)對(duì)應(yīng)接收方法public class BridgeObject : MonoBehaviour { void OnNativeResult(string json) { // 這里天然在主線程可以直接操作 Unity API ResultData data JsonUtility.FromJsonResultData(json); Debug.Log([NativeBridge] data.code data.message); } }注意 UnitySendMessage 的第一個(gè)參數(shù)是場(chǎng)景里的 GameObject 名稱(chēng)第二個(gè)是掛在它上面的組件里的方法名。GO 沒(méi)找到或者方法名不存在時(shí)Unity 只在 Logcat 里打一條 warning不會(huì)崩潰這也會(huì)讓問(wèn)題更難發(fā)現(xiàn)。我的習(xí)慣是在 Start 里顯式檢查一次if (FindObjectOfTypeBridgeObject() null) { Debug.LogError([NativeBridge] BridgeObject 不存在回調(diào)會(huì)靜默丟失); }5.2 高頻調(diào)用場(chǎng)景下的引用緩存與批量透?jìng)髯詈笠粋€(gè)貼士關(guān)于性能。高頻調(diào)用時(shí)別每幀 new AndroidJavaClass。把類(lèi)引用和實(shí)例引用緩存起來(lái)即可private static AndroidJavaClass sBridgeClass; private static AndroidJavaObject sBridgeObj; public static AndroidJavaObject GetBridge() { if (sBridgeObj null) { sBridgeClass new AndroidJavaClass(com.example.nativebridge.Bridge); // 初始化實(shí)例只做一次 } return sBridgeObj; }至于批量透?jìng)靼讯鄠€(gè)參數(shù)拼成 JSON 字符串給 Java 側(cè)解析可以把多次 JNI 調(diào)用合并成一次。我在某個(gè)模擬項(xiàng)目 X 里實(shí)踐過(guò)用 dispatch(json) 統(tǒng)一入口后原來(lái)每幀 20 次 JNI 調(diào)用降到 1 次。JNI 單次調(diào)用成本在微秒級(jí)一幀幾十次就會(huì)明顯吃掉主線程時(shí)間。從那個(gè)第一次跑 Toast 就閃退的項(xiàng)目到現(xiàn)在我每次接安卓原生功能都強(qiáng)制先走一遍最小鏈路驗(yàn)證再談業(yè)務(wù)擴(kuò)展。閾值設(shè)得很簡(jiǎn)單Toast 能彈出來(lái)通路就通了通路不通后面所有功能都等于白搭。這個(gè)習(xí)慣幫我省下過(guò)很多個(gè)下午。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取