简介这是一份面向Unity开发者的安卓原生交互入门参考工具集重点解决Unity工程中调用Android底层功能时接口繁琐、资料零散的问题适合刚接触Unity与原生安卓互通的中初级开发者。资源共45个文件包括7个C#脚本、15个Unity资源文件、2个XML配置与1个JAR包并附带测试场景与示例文本。脚本覆盖UnityActivity、UnityAppContext、PackageManager、RunOnUIThread等基础方法封装了Toast、Log、Java与C#字符串互转、获取应用列表、判断服务或应用是否运行、打开/安装/卸载App、发送广播等功能同时提供系统信息获取工具可读取WiFi状态、安卓版本、原生类型ID及内置SD卡路径。压缩包整体仅48KB小巧实用便于读者逐文件对照学习。目前已有743人浏览学习可作为日常Unity安卓混合开发时的速查手册和排错参考。 Unity 项目做久了你迟早会遇到一个绕不开的坎纯 C# 实现不了的功能比如读取系统蓝牙状态、唤起系统相册、调用硬件扫描头、对接推送 SDK这时候就得亲手去碰安卓原生层。很多人在这一步卡住不是因为代码写不出来而是被各种前置知识绊倒——API Level 怎么配、AndroidJavaClass 和 AndroidJavaObject 到底怎么选、AAR 打包后为什么找不到类、UnitySendMessage 为什么回调不触发。这套东西零散地分布在 Unity 文档、Stack Overflow 和无数个群里翻半天拼出一条能用的链路极其耗时。这篇东西就是把我这些年做 Unity 调安卓原生的经验整理成一个可复用的工具集。我会从环境配置、四套互调通路、一个完整示例、常用工具链再到高频报错排查一条龙讲清楚。适合两类人看一类是刚接触 Unity 安卓开发的客户端同学需要快速建立起整体认知框架另一类是已经在写 Java/Kotlin 桥接但经常被细节坑到的人可以直接跳到后面的问题排查章节对照症状。1. 为什么 Unity 开发者绕不开安卓原生层先说一个事实Unity 的 Android 支持已经很强了摄像头、麦克风、定位、振动这些高频能力都有现成接口。但真实业务里总有一些需求落在引擎封装的边界之外。我自己遇到过的场景包括打印机 SDK 只能通过 Java 层初始化、某厂商的扫码枪需要注册系统广播接收器、业务方要求读取设备 IMEI 或者判断当前是否开启了“开发者选项”、想获取系统壁纸缩略图塞进 UI。这些功能你用 Unity 原生 API 找不到入口只能写一个 Java/Kotlin 桥接类再用 C# 反射调用。另一个典型场景是把 Unity 作为渲染层嵌入到已有的安卓工程里或者反过来把安卓原生页面当作弹窗盖在 Unity 视图上。这时候你必须要理解 UnityPlayer 在安卓侧的宿主机制。很多做混合开发的同学第一次看到 UnityPlayerActivity 时一脸懵其实它就是 Unity 提供的一个安卓 Activity里面挂了一个 UnityPlayer 视图你的 Unity 游戏画面都渲染在这个视图上。理解了这一层你后续所有关于“原生 Activity 和 UnityActivity 怎么切”的疑问都能迎刃而解。还有一个更现实的理由插件市场里的第三方 SDK 质量参差不齐。有些厂商只提供了安卓原生 SDK 文档根本没有 Unity 封装版有些虽然给了 Unity 包但年久失修API 版本落后甚至和你的主工程 AndroidX 依赖冲突。这种情况下自己写一套原生桥接反而比依赖现成插件更可控。所以不管你是不是打算长期做安卓方向只要你在 Unity 里做过上架安卓的应用这关迟早要过。2. 动手写代码前的安卓构建配置这一关先过好我见过太多人代码写对了最后卡在构建阶段。Unity 导出安卓 APK 时涉及的可配置项比想象中多而且每个版本变化都很大。如果你用的是 Unity 2022 LTS 或 2021 LTS建议从一开始就把这几项设定好后面能省大量排查时间。2.1 把 Minimum API Level 和 Target API Level 调到合理位置Unity 的 Player Settings 里有两项经常被忽略Minimum API Level 和 Target API Level。前者决定了你的 App 最低能跑在哪个安卓版本上后者则会影响系统对 App 的行为约束。从 2023 年开始国内应用商店普遍对 Target API 有硬性要求很多游戏被迫从 API 30 往上提。如果你的项目计划上架国内安卓渠道建议直接设到 33 或 34一步到位避开渠道审核弹窗。注意Target API Level 抬高之后Android 6.0 以上的一切危险权限都需要运行时申请你的 Java 桥接代码里必须处理权限回调不能只依赖 Unity 的权限弹窗。热词里有人提到“unity 提高 minimum api level target api level 到 api35”这个方向是对的但别一门心思追新——Unity 版本如果太老AGP 版本跟不上反而会把构建流程搞挂。稳妥做法是Unity 2021 LTS 用 API 30~32Unity 2022 LTS 可以尝试 API 33~34API 35 最好搭配 Unity 6 或最新的 2022 补丁版。2.2 构建方式选择Gradle 构建还是导出工程Unity 构建安卓有两种路径直接在 Unity 里勾选 Build App Bundle / Gradle让它生成 APK/AAB或者勾选 Export Project导出完整安卓工程再用 Android Studio 做最终构建。开发阶段强烈建议用 Export Project 模式因为这样你能直接运行 Logcat看到 Java/Kotlin 层的完整崩溃堆栈改起代码来效率高得多。正式出包时再切回 Unity 直接构建也不迟。还有一点如果你们项目里有多个原生插件彼此之间可能存在 AAR 冲突导出工程后在 Gradle 里统一分析依赖关系会清晰很多。2.3 AndroidManifest 合并机制不要手动改 Unity 自动生成的 ManifestUnity 在构建时会自动合成一份 AndroidManifest.xml把插件里带的 manifest 片段和主工程的声明合并在一起。新手最常见的错误是直接去修改 unityLibrary 下的 manifest改完发现重新构建后又被打回原形或者权限被别的基础组件莫名其妙地“合并”丢了。正确姿势是在 Unity 的 Plugins/Android 目录下放一份自定义的 AndroidManifest.xml或者用 Android Studio 在 library 模块里声明你需要的权限和组件让它在合并阶段自然生效。如果你需要增加 Activity 或者自定义 Application 类也必须走这个合并机制不要直接动 Unity 生成的最终文件。3. 四套互调通路按场景选型不纠结“Unity 调安卓原生”其实是一组能力的合集不同需求对应不同方案。很多人一上来就在搜“AndroidJavaClass 怎么用”这未必是你真正需要的。我把常见的通路梳理成四类你对照实际场景选就行。3.1 AndroidJavaClass 与 AndroidJavaObject轻量级反射调用这是 Unity 新手最先接触到的方案。AndroidJavaClass 用于调用 Java 中的静态方法或访问静态字段而 AndroidJavaObject 用于实例化对象并调用其实例方法。两者本质都是通过 JNI 反射实现Unity 帮你封装好了。适用场景调用一次性功能比如判断某个系统服务是否开启、读取设备信息、调用一个不常驻的静态方法。下面是一段典型代码using UnityEngine; public class AndroidBridgeDemo : MonoBehaviour { void Start() { // 获取当前安卓 SDK 版本 AndroidJavaClass buildVersion new AndroidJavaClass(android.os.Build$VERSION); int sdkInt buildVersion.GetStaticint(SDK_INT); Debug.Log(Android SDK Version: sdkInt); // 调用 Toast 显示一段文字 AndroidJavaClass unityPlayer new AndroidJavaClass(com.unity3d.player.UnityPlayer); AndroidJavaObject currentActivity unityPlayer.GetStaticAndroidJavaObject(currentActivity); AndroidJavaClass toastClass new AndroidJavaClass(android.widget.Toast); AndroidJavaObject context currentActivity.CallAndroidJavaObject(getApplicationContext); toastClass.CallStaticAndroidJavaObject( makeText, context, Hello from C#, toastClass.GetStaticint(LENGTH_SHORT) ).Call(show); } }这段代码虽然能跑但要注意几点。第一AndroidJavaClass 和 AndroidJavaObject 都是 IDisposable 实现频繁调用时一定要在 finally 或 using 代码块里释放否则 JNI 全局引用会堆积最终导致 native 层崩溃。第二C# 和 Java 之间的字符串、数组等类型转换是隐式完成的但如果你传的是自定义对象Unity 并不认识只能通过 JSON 字符串序列化后传递接收端再做反序列化。第三这段代码在主线程调用还好如果从子线程发起 JNI 调用部分安卓接口会直接抛异常后续细说。这种反射方案的优点是不用额外打包 AAR 或 jar随写随用适合原型验证。缺点是反射开销不可忽略高频调用每帧取状态、批量写数据不建议用它字符串拼接类操作也会有 GC 压力。3.2 自定义 AAR / JAR 插件正规军路线如果你的原生逻辑比较多比如要封装一个 SDK、要维护复杂的业务状态、要处理多个回调那就别再堆 C# 反射代码了。正确的做法是在 Android Studio 里建一个 library module把 Java/Kotlin 代码打成一个 AAR包含清单、资源文件再丢进 Unity 的 Plugins/Android 目录。Unity 构建时会自动把这个 AAR 合并进 APK。AAR 方案的几个硬性收益可以自由使用第三方依赖和 AndroidX 库只要在 build.gradle 里声明构建时 Unity 的 Gradle 会把它们拉下来。代码可测试性大幅提升Java 层逻辑可以用单元测试覆盖而不用每次改一点都要跑一次 Unity 构建。类名、方法名都不会被 Unity 混淆器误伤前提是你自己处理好 proguard 规则整体稳定性比反射方案高一个量级。写 AAR 时的几个细节值得注意。一个是包名要规划好比如 com.yourcompany.bridge后续 Unity 那边 AndroidJavaClass 要写完全一致的类路径。另一个是所有需要被 C# 调用的方法建议用一个静态入口类暴露避免让 Unity 端去接触你复杂的内部类结构。下面是静态入口的典型写法package com.example.bridge; import android.content.Context; import android.widget.Toast; public class Bridge { private static Context appContext; public static void init(Context context) { appContext context.getApplicationContext(); } public static void showToast(final String message) { Toast.makeText(appContext, message, Toast.LENGTH_SHORT).show(); } }在 Unity 里调用时AndroidJavaClass bridgeClass new AndroidJavaClass(com.example.bridge.Bridge); AndroidJavaClass unityPlayer new AndroidJavaClass(com.unity3d.player.UnityPlayer); AndroidJavaObject currentActivity unityPlayer.GetStaticAndroidJavaObject(currentActivity); bridgeClass.CallStatic(init, currentActivity); bridgeClass.CallStatic(showToast, AAR call successful);注意这里 init 一定在调用其他业务方法之前执行因为很多 SDK 都需要 Context。建议在整个游戏的启动阶段完成初始化比如在一个不销毁的 GameObject 上做。3.3 自定义 Activity 与 UnityPlayer 的互动有些功能要求你改变 Activity 的行为比如拦截返回键、处理 onActivityResult、接管 onNewIntent。这时候你需要在 AAR 里声明一个自定义 Activity并把 Unity 的启动入口指向它。最经典的做法是继承 UnityPlayerActivity然后重写生命周期方法。package com.example.bridge; import com.unity3d.player.UnityPlayer; import com.unity3d.player.UnityPlayerActivity; public class MainActivity extends UnityPlayerActivity { Override protected void onActivityResult(int requestCode, int resultCode, android.content.Intent data) { super.onActivityResult(requestCode, resultCode, data); UnityPlayer.UnitySendMessage(GameManager, OnNativeResult, activity result received); } }上面的 UnitySendMessage 是 Unity 提供的反向调用通道参数分别是 GameObject 名称、脚本方法名、消息内容。注意 GameManager 这个物体必须存在且激活否则消息会丢失。这个方法名大小写敏感建议在 Java 侧常量里保持一致避免以后改 C# 方法名时忘了同步。这种自定义 Activity 方案还有一个优势你可以通过重写 onCreate 在 Unity 启动前准备环境比如初始化广告 SDK 或者申请危险权限。但要注意不要过分阻塞主线程否则 Unity 画面初始化会被拖慢表现为启动黑屏时间偏长。3.4 UnitySendMessage从原生反向通知 Unity 的正确姿势第四类通路其实是把前三类连接起来的闭环。在很多场景下你从 C# 调用 Java 发起一个异步任务比如选一张系统相册照片、扫一个二维码任务完成后需要把结果传回 C#。此时 UnitySendMessage 就是最通用的桥。它的原理相当朴素相当于在原生层找到 Unity 当前的活动实例往指定名字的 GameObject 上发送一条消息Unity 会根据消息名找到挂载的 MonoBehaviour 方法并调用。这里有个隐含要求接收消息的脚本方法必须是 public且参数只能是 string、int、float 或这三种的组合没法直接传复杂对象。所以约定俗成的做法是把结果序列化成 JSON 字符串再传。public class GameManager : MonoBehaviour { public void OnNativeResult(string jsonResult) { Debug.Log(Native callback: jsonResult); // 在这里解析 JSON刷新业务逻辑 } }传参长度方面UnitySendMessage 对消息长度有限制一般几百个字符以内安全。如果你要从安卓往 C# 传一段很长的日志或者整个文件内容别硬塞进消息里先写文件再通过字符串传文件路径。否则会出现消息被截断或者卡死主线程的问题。总结一下四套通路的选用逻辑一次性的系统服务调用用反射稍复杂但仍是无状态的原生方法把公共代码塞进 AAR 的静态入口需要生命周期控制的做自定义 Activity异步结果回传用 UnitySendMessage。四者不冲突通常一个项目里会同时用到。4. 从 Java 到 C# 再到原生回调一个真实示例走通全链路光讲原理不够我拿最近做蓝牙打印机对接的简化版流程来做样本展示全链路长什么样。这个例子虽然业务简单但把环境配置、反射调用、权限处理、回调通知都覆盖到了。4.1 原生侧Java 类里做好权限检查与回调假设我要实现一个“获取设备蓝牙 MAC 地址并回传 C#”的功能。按现在的安卓版本蓝牙相关操作需要 BLUETOOTH_CONNECT 权限而且这个权限属于危险权限需要在运行时动态申请。我写一个 Java 静态方法package com.example.bridge; import android.Manifest; import android.bluetooth.BluetoothAdapter; import android.content.Context; import android.content.pm.PackageManager; import android.os.Build; import androidx.core.app.ActivityCompat; import com.unity3d.player.UnityPlayer; public class BluetoothBridge { public static void getBluetoothAddress(String gameObjectName) { Context context UnityPlayer.currentActivity; if (context null) return; if (Build.VERSION.SDK_INT Build.VERSION_CODES.S ActivityCompat.checkSelfPermission(context, Manifest.permission.BLUETOOTH_CONNECT) ! PackageManager.PERMISSION_GRANTED) { // 没有权限则回调 C#由 C# 统一处理权限申请流程 UnityPlayer.UnitySendMessage(gameObjectName, OnBluetoothAddressResult, PERMISSION_DENIED); return; } BluetoothAdapter adapter BluetoothAdapter.getDefaultAdapter(); if (adapter null) { UnityPlayer.UnitySendMessage(gameObjectName, OnBluetoothAddressResult, NO_BLUETOOTH); return; } String address adapter.getAddress(); UnityPlayer.UnitySendMessage(gameObjectName, OnBluetoothAddressResult, address null ? UNKNOWN : address); } }注意我把 gameObjectName 作为参数传进来而不是在 Java 类里写死一个字符串。这样 C# 端可以灵活控制消息要发给哪个对象不用为每个页面单独写一个 Java 方法。4.2 Unity 侧封装一个 Manager 脚本C# 侧我通常建一个 NativeBridgeManager做成一个不销毁的单例负责接收来自 Java 的回调并转发给业务层事件using System; using UnityEngine; public class NativeBridgeManager : MonoBehaviour { public static NativeBridgeManager Instance { get; private set; } private void Awake() { if (Instance ! null Instance ! this) { Destroy(gameObject); return; } Instance this; DontDestroyOnLoad(gameObject); } public void RequestBluetoothAddress() { AndroidJavaClass bridgeClass new AndroidJavaClass(com.example.bridge.BluetoothBridge); bridgeClass.CallStatic(getBluetoothAddress, gameObject.name); } public void OnBluetoothAddressResult(string result) { Debug.Log(Bluetooth address result: result); // 根据 result 内容走不同分支 } }这里有个细节RequestBluetoothAddress 里调用 CallStatic 时传的 gameObject.name必须是当前挂载 NativeBridgeManager 脚本的这个物体名字。如果你用了 DontDestroyOnLoad 但是名字在场景里被改过记得统一处理不然回调会打到别的同名对象上非常难查。4.3 权限申请为什么建议在 C# 层统一处理上面 Java 代码里如果权限缺失就直接回调了 PERMISSION_DENIED我并没有在 Java 层去弹系统权限申请框。原因是权限申请涉及 onRequestPermissionsResult 回调处理起来牵扯 Activity 生命周期放在 Java 层会让 AAR 内部状态变得更复杂。统一在 C# 层用 Unity 的权限 APIUnityEngine.Android.Permission来申请申请结果后再重新调用 Java 方法流程会清晰很多。private void RequestBluetoothAddressWithPermission() { if (Permission.HasUserAuthorizedPermission(android.permission.BLUETOOTH_CONNECT)) { RequestBluetoothAddress(); return; } var permissionCallback new PermissionCallbacks(); permissionCallback.PermissionGranted _ RequestBluetoothAddress(); permissionCallback.PermissionDenied _ Debug.LogWarning(Permission denied); Permission.RequestUserPermission(android.permission.BLUETOOTH_CONNECT, permissionCallback); }这个方案有几层含义第一如果以后把 Bridge 迁移到别的平台比如 iOS 的 URL Scheme 方案C# 层这套权限状态机还能复用第二所有权限结果都由 C# 侧可靠记录不容易发生“Java 层弹窗了但 Unity 层不知道”的偶发问题第三你在 C# 侧打日志排查权限问题时比翻 Logcat 舒服太多。4.4 字符串以外的数据传递JSON 序列化约定蓝牙地址这种简单字符串直接用 UnitySendMessage 传没问题但如果业务再复杂一点比如要从原生拿一个设备列表里面包含名称、信号强度、MAC 地址多个字段那就得用 JSON。我的习惯是Java 侧用 org.json 自带的 JSONObject 拼装字符串C# 侧用 JsonUtility 或者 Newtonsoft Json.NET 解析。别在 C# 侧用手写字符串解析容易被字段顺序坑也容易遇到转义问题。另外强调一个反直觉的点从 Java 传到 C# 的字符串如果有中文比如设备名称里带了汉字UnitySendMessage 也能正常传递但你不要在中间环节做额外的 URLEncode/Decode反而容易造成双重编码乱码。保持原样传到了 C# 侧如果显示乱码优先检查 Java 侧源字符串的编码而不是在桥接层做转换。5. 工具集开发时能明显提效的几个装备这部分是锦上添花但对日常开发效率提升非常大。我不是推荐你买付费插件说的是那些免费且稳定的工具组合。5.1 Unity 内置的 Android Logcat 窗口Unity 从 2019 版本开始内置了一个 Android Logcat 面板路径在 Window Analysis Android Logcat。连接上真机后可以直接在这里看 Logcat按包名过滤还能查看崩溃堆栈。不用再开 Android Studio 或者命令行 adb少一个工具切换步骤。这里机子连接不上的时候优先检查 USB 驱动和手机是否开启 USB 调试跟 Unity 版本关系不大。5.2 远程真机调试三件套adb、scrcpy、剪贴板同步很多 Unity 开发者在 Windows 环境下做安卓开发手机连着 USB 线每次看日志都要弯腰摸手机。我习惯用 scrcpy 把手机画面投到电脑屏幕上直接用鼠标操作手机配合 adb 命令一起用。比如想查看 Unity 游戏里某个界面打开时原生层打了什么日志我只需要在电脑上点击手机屏幕重现操作路径然后在 Logcat 面板按时间筛选比反复拔插手机体验好太多。剪贴板同步是个小功能把手机上的报错文本复制下来非常方便不用手动敲。5.3 构建辅助脚本自动切换平台和设置包名每次手动在 Build Settings 里切平台是一个低效且容易出错的步骤。我维护了一个编辑器脚本一键完成以下操作切换 Build Target 到 Android、设置 Company Name 和 Bundle ID、开启 IL2CPP、设定目标 API Level、然后触发构建。这样团队里任何成员按一下菜单就能打出标准包不再出现有人用 Mono 脚本后端构建导致原生插件不兼容的问题。代码如下按你们的需求增删using UnityEditor; using UnityEditor.Build; public static class AndroidBuildHelper { [MenuItem(Tools/Build/Configure Android)] public static void ConfigureAndroid() { EditorUserBuildSettings.SwitchActiveBuildTarget( BuildTargetGroup.Android, BuildTarget.Android); PlayerSettings.companyName YourCompany; PlayerSettings.productName Unity Native Bridge Demo; PlayerSettings.SetApplicationIdentifier(BuildTargetGroup.Android, com.yourcompany.demo); PlayerSettings.SetScriptingBackend(BuildTargetGroup.Android, ScriptingImplementation.IL2CPP); PlayerSettings.Android.targetArchitectures AndroidArchitecture.ARM64 | AndroidArchitecture.ARMv7; PlayerSettings.Android.minSdkVersion AndroidSdkVersions.AndroidApiLevel30; } }targetArchitectures 这里设置 ARM64 和 ARMv7 就够用了如果你的原生库只提供了一部分 ABI 的 so 文件记得做筛选不然会出现设备运行时找不到 so 库的崩溃。5.4 崩溃栈符号化脚本如果开了 IL2CPP 构建Release 包崩溃时拿到的堆栈是地址不是行号。Unity 在构建时如果在 Build Settings 里勾选了 Create symbols.zip会在导出目录生成符号文件。崩溃后把堆栈地址和符号文件一起丢到 Unity 的符号解析器里就能还原出具体函数名。这个步骤在原生调用不畅的调试期特别有用因为很多时候问题并不出在 Unity 层而是 AAR 内部 native 崩溃你不符号化根本定位不到位置。6. 高频问题排查记录几年前掉过的坑一个个说清楚最后这部分相当于一个速查手册。我根据平时在群里看到的问题结合自己的排查经历把频率最高的几类整理出来。6.1 DLLNotFoundException: Unable to load DLL slua这个报错的典型场景是项目里用了 Lua 热更方案比如 slua、tolua、xLua突然某一天出包后运行提示找不到 slua 的 native 库。原因各不相同但排查路径是有规律的。先在打包机上确认勾选的 Architecture 是否和库的 ABI 匹配。slua 这类插件一般会在 Plugins/Android 下放若干个 ABI 文件夹如果你的构建只勾选了 ARM64但插件只提供了 armeabi-v7a 的 so运行时就会报这个错。其次看 so 文件名和 C# 侧的 DllImport 声明是否严格一致尤其是大小写和扩展名。最后确认这个 so 有没有被 Unity 识别为 Android 平台的 Plugin。你可以点中 so 文件看 Inspector 面板里的 Platform Settings如果没勾选 Android 平台构建时会直接被扔出去。解决办法是勾上对应平台或者在你的构建配置脚本里强制设置 PluginImporter 的平台开关。6.2 混淆导致 ClassNotFoundException 和 NoSuchFieldError如果你的项目做了代码混淆ProGuard / R8 / 腾讯乐固之类的加固方案原生层和 Unity 层的反射链路非常容易被踩断。C# 侧的 AndroidJavaClass 是通过字符串类名去找 Java 类的一旦你 Java 侧的桥接类被混淆改成 a.b.c 这种简短名字C# 侧自然找不到。排查思路先确认混淆开关是否真的默认开启很多 Unity 插件在 release 构建时会默认启用 minify。然后在混淆规则里加入 keep 声明把需要被 C# 反射调用的类名和方法名保留下来。一个常见的规则模板-keep class com.example.bridge.** { *; } -keep class com.unity3d.player.** { *; } -keepclassmembers class * { android.webkit.JavascriptInterface methods; }必须强调一点混淆规则要在 AAR 模块和主工程的 proguard 文件里同时检查因为有些插件自带的 consumerProguardFiles 可能在 Unity 的构建流程中不生效。最稳的方案是把你自己的桥接类名写得独特一点方便在混淆规则里一网打尽。6.3 UnitySendMessage 收不到回调先查 GameObject 状态UnitySendMessage 看起来简单但有三个隐藏条件。第一目标 GameObject 必须存在且激活第二接收方法必须是 public第三消息名和接收方法名大小写必须完全一致。这三个条件任何一个不满足消息就会静默丢失不会报错也不会打日志。排查时先在这些静态条件上逐一核对再考虑是不是 Java 层线程问题调用了 UnitySendMessage。UnitySendMessage 建议在主线程调用如果你在子线程里调用有些设备上会没问题有些设备上直接崩。稳妥做法是在 Java 侧用 runOnUiThread 跑把消息发送放到主线程队列里。6.4 Pico4 等 XR 设备上的 indexOutOfRangeException在 Pico4 上开发 Unity 应用时如果遇到 renderPassIndex 相关的 IndexOutOfRangeException多数情况是 OpenXR 渲染路径和 Unity 渲染图层的兼容性问题。检查 OpenXR 插件版本是否和 Unity 版本匹配升级到官方推荐的版本组合。另外如果项目里用了 SRP 或自定义渲染管线要确认 XR 渲染时是否用到了不存在的渲染 Pass。这类问题通常不会出现在 Editor 模拟器只能真机复现建议先在空场景里跑一遍官方 XR 示例确定插件本身没问题再逐步加入自己的渲染脚本二分定位。6.5 想用微信小游戏打包原生调用边界要提前弄清楚Unity 项目转微信小游戏时引擎跑在浏览器环境里安卓原生层的 JNI 调用并不可直接复用。就算你想办法在 Unity 的 WebGL 构建里做了一些桥接微信小游戏容器也有一套独立的 JSBridge 机制。所以如果在立项阶段就确定要发微信小游戏原生功能尽量在 C# 侧做抽象让上层逻辑依赖接口而不是依赖 AndroidJavaClass 的具体实现。这样后面做微信小游戏适配时只需要替换实现层不用把业务逻辑重写一遍。6.6 插件之间的 Activity 和 Application 冲突提到一个场景项目里同时集成了推送 SDK 和自定义扫码插件各自都修改了 AndroidManifest 的 application 标签构建的时候 Unity 会提示 manifest merger failed。这是因为 MainActivity 或 Application 类只能有一个优先声明。解决思路是不要用继承不同 UnityPlayerActivity 子类的方案而是改成在同一个自定义 Activity 里处理所有插件初始化或者用一个空壳 Container Activity把插件初始化和业务原生实现都放在这个容器里统一管理生命周期。这种做法的好处是以后新增插件时不用再动 Unity 构建配置只要在容器里增加初始化代码就行。写在最后Unity 调安卓原生这件事本质上没有太多高深的技术全都是细节堆起来的。行业里对这块的文档又特别零散很多刚接触的人被浪费时间在配置和构建上。我一直觉得做原生桥接最重要的是先建立清晰的调用通路模型再动手写代码不然你很容易陷入“改一行代码、打一个包、装一次真机、看一次日志”的低效循环里。开发时尽量保持 Java/Kotlin 侧和 C# 侧解耦用信息量明确的回调事件来驱动业务而不是让双方互相侵入对方的结构。遇到问题优先看 Logcat配合符号表和混淆规则一起排查多数疑难杂症都能在几小时内解决。希望这套工具集能让你少走一些我当年绕过的弯路。本文还有配套的精品资源点击获取