简介面向需要在原生 Android 应用中集成 Unity 3D 内容的开发者这份压缩包围绕 Unity 嵌入 Android 原工程的全流程展开覆盖从 Unity 导出配置、生成 Android Library Project、导入 Android Studio到原生工程配置、Java/Kotlin 与 Unity 桥接交互、性能优化、错误调试及发布准备等关键环节。资源以 rar 格式打包大小约 323.39MB文件总数与内部文件类型暂未在平台标注。已有 304 人学习。内容聚焦实际接入中的高频问题适合具备一定 Android 基础、希望将 Unity 场景无缝融入原生应用的工程师学习参考可帮助理解工程级集成的完整链路减少在依赖配置、Activity 层次、消息通信和打包发布等环节的踩坑成本。1. Unity嵌入Android原工程导出姿势对了后面才不翻车做混合应用时很多团队会遇到这个需求原生App已经有完整的用户体系和支付流程要用Unity渲染一个3D交互场景。把Unity单独打包成APK再通过Intent跳转安装包冲突、数据无法共享体验很差正确做法是把Unity工程作为Library工程嵌入到Android Studio原工程中。这份《Unity嵌入到Android原工程》资源包讲的就是从Unity导出、Android Studio导入到双向通信的完整链路包含我实际操作中的参数和踩坑记录。适合正在做Unity混合工程、被黑白屏和Activity生命周期折磨的Android与Unity开发者新手能照着走通熟手可以直接看参数和边界。2. 导出前的Unity配置IL2CPP和Player Settings一个都不能省2.1 为什么必须用IL2CPPMono与IL2CPP的选型理由在Unity里脚本后端有Mono和IL2CPP两种。Mono是JIT方案运行时需要解析.NET中间语言Android设备上需要额外携带Mono运行时库导致包体增大、冷启动变慢而且在一些国产ROM上兼容性不稳定。IL2CPP则先把C#代码转成C再交叉编译成.so库运行时直接执行本地指令启动速度更快包体通常也更小。更重要的是原生Android工程运行在ART/Dalvik虚拟机里没有完整的.NET框架支持如果Unity模块带着Mono运行时嵌入几乎必然会碰到ClassNotFoundException和莫名其妙的崩溃。所以在导出给Android原工程集成时脚本后端只能选IL2CPP。这也是我第一次做Unity嵌入时踩到的最大的坑当时想省事用默认的Mono输出结果打出的library在Android Studio里编译通过一跑就崩溃Logcat指向libmono.so缺失。换成IL2CPP后一次通过。要开启IL2CPP打开Unity的File - Build Settings - Player Settings在Other Settings面板里把Scripting Backend从Mono改成IL2CPP。同时把Target Architecture设置为ARM64。现在的Google Play要求新应用和更新必须支持64位新装机设备也基本都是64位处理器只保留ARM64能显著减少.so体积。为了让这个过程可重复我一般会写一个编辑脚本用命令行参数动态控制导出。这样CI机器上也能一键构建。下面这个C#脚本放在Editor文件夹里using UnityEditor; using UnityEngine; public static class AndroidLibraryBuilder { public static void Build() { // 强制切换到Android平台 EditorUserBuildSettings.SwitchActiveBuildTarget(BuildTargetGroup.Android, BuildTarget.Android); // 脚本后端选IL2CPP避免Mono在原生工程中的兼容问题 PlayerSettings.SetScriptingBackend(BuildTargetGroup.Android, ScriptingImplementation.IL2CPP); // 0ARMv7, 1ARM64, 2ARMv7ARM64这里按发布需要选1 PlayerSettings.SetArchitecture(BuildTargetGroup.Android, 1); // 关键一步把构建类型指定为Android Library而不是App EditorUserBuildSettings.androidBuildType AndroidBuildType.Library; // 列出需要打包的场景 string[] scenes { Assets/Scenes/Main.unity }; // 输出到Build/UnityExport目录AcceptExternalModificationsToPlayer是关键 BuildPipeline.BuildPlayer(scenes, Build/UnityExport, BuildTarget.Android, BuildOptions.AcceptExternalModificationsToPlayer); Debug.Log(Unity Library 导出完成); } }这段脚本有几个参数必须说清楚。PlayerSettings.SetScriptingBackend的第一个参数固定传BuildTargetGroup.Android因为脚本后端是按平台区分设置的如果漏了这句可能Unity还是用上一次的Mono配置。SetArchitecture的第二个参数1代表ARM64如果你的应用还想兼容老设备可以传2但最终APK里会同时带上两种架构的so包体会大12MB左右。BuildPlayer最后一个参数BuildOptions.AcceptExternalModificationsToPlayer是一个开关只有加上它Unity才会生成一个可供Android Studio二次开发的Library工程而不是直接生成APK。运行这段脚本的方式很直接在Unity菜单栏的Window - General - Test Runner旁边的命令行窗口执行或者直接在命令行带参数调用Unity可执行文件。我常用的是这个/path/to/Unity -batchmode -quit -projectPath /your/project -executeMethod AndroidLibraryBuilder.Build这样可以让CI在无头模式下完成导出省掉人工打开Unity的步骤。如果脚本报错先确认Android模块已经通过Unity Hub安装否则SetScriptingBackend这行会抛MissingMethodException。2.2 Player Settings里的关键参数API Level、纹理压缩与包名IL2CPP只是第一步Player Settings里的另外几项如果不正确导入Android Studio后还会出问题。第一项是Minimum API Level。Unity默认可能是19或21而原生工程可能早就把minSdkVersion设到了26。两个module共存时Gradle会取其中较高的值所以如果Unity设置太低没有影响但如果Unity设置的minSdk高于原生工程低版本设备就无法安装。稳妥做法是把原生工程和Unity的minSdk设为一致我一般统一用24兼容性足够又避开了Android 5.0权限模型的旧坑。第二项是Target API Level。这个最好和Android Studio里compileSdkVersion保持一致。如果原生工程用compileSdk 33Unity的Target API Level却是29运行时一些系统行为差异会变得难以排查。具体位置在Player Settings - Other Settings里的Target API Level。第三项是Texture Compression。可选ASTC、ETC2、ETC等。现代旗舰芯片对ASTC支持很好纹理压缩率高、画质损失小但一些中低端GPU老设备可能不支持ASTC运行时会花屏。如果你的App最低支持Android 8.0以上直接用ASTC否则用ETC2兼容性更强。这个选择不影响集成流程但影响最终包体和画面效果。第四项是包名配置。Unity导出的library工程有自己的AndroidManifest.xml里面会写一个package属性。需要确认这个package是否和原生工程有冲突。比较安全的做法是Unity工程的Bundle Identifier设置成和原生工程applicationId相同的值或者干脆用独立的内部包名如com.yourcompany.unitylib然后在导入Android Studio后再统一调整。注意原生App最终对外发布的applicationId是app模块里的那个Unity模块的包名只是内部标识不要因此搞混。下面这张表是我每次导出前都会检查一遍的参数参数推荐值原因Scripting BackendIL2CPP原生Android无法承载Mono运行时Target ArchitectureARM64满足Google Play 64位要求Minimum API Level24与原生工程协调取较高值Target API Level与compileSdk一致避免系统行为差异Texture CompressionASTC或ETC2按最低机型支持度选Graphic APIOpenGLES3或Vulkan与Unity渲染管线匹配这些参数不是越多越好关键是和原生工程对齐。如果原生工程还在用旧的compileSdk不必升级到最新只要两边不互相覆盖就行。这套配置做完点下Build得到的是一个带UnityExport名字的文件夹里面已经有AndroidManifest.xml、src、libs、res等目录。下一章就把它接进Android Studio。3. 把UnityExport塞进Android Studio从导入到Activity替换3.1 导入UnityExport与Gradle依赖配置拿到UnityExport目录后不要直接用Android Studio的Import Project去打开它。Unity生成的目录虽然看起来是个Android工程但它是针对老式Eclipse结构生成的直接导入后Gradle同步必报错。我踩过一次把时间全耗在修AGP版本上。常见做法是把它作为原生工程里的一个library module。具体操作先把UnityExport文件夹复制到原生工程的根目录和app同级。然后在settings.gradle里注册这个模块。以Android Studio新模板为例settings.gradle内容类似这样rootProject.name MyNativeApp include :app // 注册Unity导出的库模块 include :unityLibrary project(:unityLibrary).projectDir new File(UnityExport)这里UnityExport目录下要有一个build.gradle文件Unity导出时已经生成了这个文件里面有它自己的compileSdkVersion和minSdkVersion。如果你生成的Unity版本比较老build.gradle里可能用的是老版AGP插件同步时会提示版本冲突这时需要手动把插件版本改成和app模块一致。注册完成后再打开app/build.gradle在dependencies里加上对unityLibrary的依赖dependencies { implementation project(:unityLibrary) }如果你打开UnityExport目录发现build.gradle里的内容不是标准的模块化格式而是一堆sourceSets那就按下面这样在unityLibrary的build.gradle里手动指定源文件位置android { compileSdkVersion 33 defaultConfig { minSdkVersion 24 targetSdkVersion 33 consumerProguardFiles proguard-unity.txt } sourceSets { main { // Unity的so库都在libs目录下Gradle默认不会打包必须显式指定 jniLibs.srcDirs [libs] // Unity的manifest也要参与合并声明src路径 manifest.srcFile AndroidManifest.xml } } }这里sourceSets里的jniLibs.srcDirs是最容易漏的一项。Unity导出的所有so文件都在UnityExport/libs/arm64-v8a里如果不在build.gradle里指定Gradle会以为没有本地库最终APK里缺少libunity.so运行到Unity界面直接UnsatisfiedLinkError。manifest.srcFile同样重要Unity的AndroidManifest里有UnityPlayerActivity的注册信息不并进去应用就会因为找不到Activity而崩溃。配置完之后在Android Studio里点击Sync Now。如果Gradle报错说“Namespace not specified”就在unityLibrary的build.gradle里加上android { namespace com.yourcompany.unitylib }这里namespace可以随便写但要保证和UnityExport里的AndroidManifest.xml的package属性一致。我一般统一改成com.yourcompany.unitylib避免和app模块冲突。3.2 Activity生命周期与UnityPlayer的整合依赖配置好后最核心的是处理好UnityPlayer和Activity生命周期。Unity导出的UnityPlayerActivity本质上是一个持有UnityPlayer实例的Activity。如果我们直接让用户从原生MainActivity跳转到这个UnityPlayerActivity那Unity就变成了一个全屏页面这通常已经满足大部分需求。当然如果App本来就有多个tab要求Unity页面嵌入到某个tab里那就得用更细的方式把UnityPlayer.View塞进Fragment。先说简单方式直接启动UnityPlayerActivity。在原生MainActivity里写val intent Intent(this, UnityPlayerActivity::class.java) startActivity(intent)这里有个前提UnityPlayerActivity已经在UnityExport的AndroidManifest.xml中注册了。我们可以直接继续用它的默认实现也可以继承它写子类在onCreate里预先加载场景、设置启动参数。UnityPlayerActivity默认继承自Activity它会自己创建UnityPlayer并加载Unity场景。再进阶一点需要在原生页面里嵌入一个区域显示Unity画面。此时不能用UnityPlayerActivity而是要自己创建UnityPlayer对象然后在Fragment的onCreateView里返回UnityPlayer的View。写法类似class UnityFragment : Fragment() { private lateinit var unityPlayer: UnityPlayer override fun onCreateView(inflater: LayoutInflater, container: ViewGroup?, savedInstanceState: Bundle?): View? { // 创建UnityPlayerTheme设置成NoTitleBar避免状态栏干扰 unityPlayer UnityPlayer(requireContext()) return unityPlayer } override fun onResume() { super.onResume() unityPlayer.resume() } override fun onPause() { super.onPause() unityPlayer.pause() } override fun onDestroyView() { super.onDestroyView() // 注意这里不要直接quitquit要等Activity真正销毁时再调用 unityPlayer.quit() } override fun onDestroy() { super.onDestroy() unityPlayer.quit() } }这段代码里有两个特别容易翻车的点。第一onResume里必须调unityPlayer.resume()不然Unity场景在不活动之后回到前台渲染线程没有继续画面会卡在最后一帧。第二onDestroyView里调了quitonDestroy里又调了一次其实多次调用quit是安全的但如果你把Fragment加入回退栈onDestroyView可能被调用多次导致UnityPlayer被提前释放再次显示时初始化失败。所以我常见的做法是在Fragment的onDestroyView中只暂停和释放View真正quit放在onDestroy里并通过一个标志位确保只quit一次。Activity的启动方向也要注意如果UnityPlayerActivity是竖屏而MainActivity是横屏启动时会出现短暂旋转。解决方式是在UnityPlayerActivity的onCreate里锁定方向requestedOrientation ActivityInfo.SCREEN_ORIENTATION_LANDSCAPE最后是AndroidManifest.xml里要补的权限。Unity导出时已经带了几个基础权限我们自己在原生工程里加一个位置uses-permission android:nameandroid.permission.INTERNET / uses-permission android:nameandroid.permission.WRITE_EXTERNAL_STORAGE android:maxSdkVersion29 /注意WRITE_EXTERNAL_STORAGE在Android 10以上不需要加上maxSdkVersion可以避免审核时的权限声明问题。如果Unity场景需要加载网络资源INTERNET是必须的不需要的话删掉减少隐私风险。4. 双向通信UnitySendMessage和UnityPlayer.currentActivity的配合4.1 原生调用UnityUnitySendMessage与GameObject绑定原生代码要驱动Unity场景里的行为最直接的方式是UnityPlayer.UnitySendMessage。这个方法的作用是把一条字符串消息发给指定的GameObject然后Unity侧会调用该GameObject上所有组件中匹配名称的方法。方法签名必须是void MethodName(string message)也就是说只能传一个字符串参数。使用前先约定好通信协议在Unity场景里创建了一个空GameObject名字叫CommunicationBridge挂一个脚本里面定义一个可被原生调用的方法。这个GameObject在场景加载后必须是激活状态否则消息收不到。脚本大致这样using UnityEngine; public class CommunicationBridge : MonoBehaviour { void Start() { // 初始化时自动注册方便原生侧随时调用 DontDestroyOnLoad(gameObject); } // 原生层通过UnitySendMessage调用这个方法 public void OnNativeMessage(string data) { // data一般是JSON字符串解析后分发到具体业务 Debug.Log(Unity收到原生消息: data); // 这里可以切换场景、播放动画、更新UI } }原生Kotlin调用的方式// 注意unityPlayer必须在初始化之后才能使用否则会抛异常 UnityPlayer.UnitySendMessage(CommunicationBridge, OnNativeMessage, {\action\:\switchScene\,\sceneName\:\home\})三个参数分别对应GameObject名、方法名、消息内容。如果Unity里没有这个名字的GameObject或者方法名不对调用不会有任何报错但Unity侧也没反应这是最难排查的黑匣子。所以我一般会在OnNativeMessage的Start里打印一条日志确认桥接对象确实活着。再说参数序列化的问题。UnitySendMessage只接受String复杂结构必须先序列化成JSON。在原生侧我用Gson或者org.json拼字符串在Unity侧用JsonUtility或Newtonsoft解析。注意JsonUtility不能直接解析字典我习惯定义一个包装类[System.Serializable] public class NativeMessage { public string action; public string payload; }然后用JsonUtility.FromJson (data)。这样原生侧只需要传action和payload两个字段扩展新业务时不用改桥接层。4.2 Unity调用原生UnityPlayer.currentActivity与静态方法反方向通信Unity需要调用原生Android代码。常见做法是使用Unity的AndroidJavaClass和AndroidJavaObject在C#侧反射调用Java/Kotlin对象。Unity内部提供了一个静态字段UnityPlayer.currentActivity保存了当前承载Unity的Activity实例。在C#里可以这样拿到它using UnityEngine; public class NativeBridge { public static string GetDeviceId() { if (Application.platform ! RuntimePlatform.Android) { Debug.LogWarning(只在Android平台运行); return ; } AndroidJavaClass unityPlayer new AndroidJavaClass(com.unity3d.player.UnityPlayer); AndroidJavaObject activity unityPlayer.GetStaticAndroidJavaObject(currentActivity); AndroidJavaClass nativeBridge new AndroidJavaClass(com.yourcompany.nativebridge.NativeBridge); string deviceId nativeBridge.CallStaticstring(getDeviceId, activity); // AndroidJavaObject和AndroidJavaClass都是Java对象的包装用完后要Dispose释放 nativeBridge.Dispose(); activity.Dispose(); unityPlayer.Dispose(); return deviceId; } }先解释这段代码的要点。new AndroidJavaClass(com.unity3d.player.UnityPlayer)是Unity官方提供的入口类GetStatic (currentActivity)拿到的是原生工程里当前承载Unity的Activity实例。如果UnityPlayer是在一个Fragment里而不是Activity里currentActivity返回的是宿主Activity仍然可用。然后通过AndroidJavaClass加载原生工程里我们自己写的类CallStatic 调用它的静态方法参数把activity传过去作为Context。对应的原生Kotlin类需要写在app模块里注意类名和包名必须和C#里传的一致package com.yourcompany.nativebridge import android.content.Context import android.provider.Settings object NativeBridge { JvmStatic fun getDeviceId(context: Context): String { return Settings.Secure.getString(context.contentResolver, Settings.Secure.ANDROID_ID) } }这里有个参数类型问题CallStatic 只匹配返回值是String的方法如果原生方法返回int或boolean会崩溃。所以我在C#侧统一只接收String类型复杂数据用JSON字符串返回。调用完成后立刻Dispose防止Java对象引用泄漏导致内存占用增长。4.3 统一桥接协议避免双向调用变成意大利面条在实际项目里Unity和原生的交互多达几十种如果每个功能单独加方法两边代码会很难维护。我的习惯是在原生侧定义一个统一入口类和出口类所有通信都走固定的路由。原生往Unity统一通过UnityPlayer.UnitySendMessage发送消息格式固定为JSON{ action: showToast, payload: { text: hello from native } }Unity侧收到后先用一个分发器解析action再调用对应的handler。反过来Unity往原生调用统一走NativeBridge.callStatic原生侧也做一个分发逻辑。这样做的好处是新增业务时只需改分发器不用在底层反复加API排查问题时抓Logcat两边的日志也能对上。5. 避坑与常见问题黑白屏、崩溃、纹理丢失这三个坎5.1 黑白屏与Activity启动缓慢现象从原生界面跳Unity时先黑屏或白屏几秒甚至ANR。原因UnityPlayer初始化没有提前做首次加载需要解析场景、加载着色器、初始化图形引擎耗时2-5秒。在低端机上这个时间还会更长如果主线程被阻塞系统会直接弹ANR对话框。解决把UnityPlayer的初始化提前到应用启动时用一个后台线程预加载UnityPlayer实例或者做一个带Loading图的原生页面等Unity场景准备好后再切换。注意不能在冷启动时阻塞主线程。我建议用一个UnityPlayerManager单例启动时先创建但resume/quit时机要控制好。class UnityPlayerManager private constructor(context: Context) { val player: UnityPlayer UnityPlayer(context) fun loadScene(sceneName: String) { // 用UnityPlayer.LoadScene加载指定场景 player.LoadScene(sceneName) } companion object { Volatile private var instance: UnityPlayerManager? null fun getInstance(context: Context): UnityPlayerManager { return instance ?: synchronized(this) { UnityPlayerManager(context.applicationContext).also { instance it } } } } }这个单例的优点是UnityPlayer在Application启动时就创建后续跳转Unity页面时直接复用黑屏时间明显缩短。缺点是一旦创建Unity资源就常驻内存如果App本身内存吃紧需要评估是否值得。我一般只在App内Unity场景出现频率高时才用这招。5.2 Unity纹理丢失或场景黑屏现象从原生返回Unity场景后画面全黑或者纹理变粉紫色。原因UnityPlayer.pause后OpenGL上下文未被正确恢复或者原生Activity被回收UnityPlayer的surface被销毁。粉紫色纹理通常代表着色器编译失败或纹理格式不兼容。解决在onResume里调用unityPlayer.resume在onPause里调用unityPlayer.pause不要在onDestroy之前forceQuit。另外如果嵌在Fragment中不要在Fragment销毁时直接unityPlayer.quit要等宿主Activity真正销毁时再quit。经验是把UnityPlayer.View和UnityPlayer的生命周期完全交给一个专门的Fragment管理不要和原生Fragment混在一起。粉紫色问题则需要检查Unity侧的Shader是否支持目标GPU特别是用了一些自定义Shader或后处理效果时。可以先在Unity Editor里把Graphics API设置成OpenGLES3试一遍再切到Vulkan对比看是否是API兼容问题。5.3 崩溃java.lang.ClassNotFoundException或UnsatisfiedLinkError现象运行时找不到UnityPlayer类或找不到libunity.so。原因Gradle没有把unity-classes.jar和jniLibs打包进去或者unityLibrary的build.gradle中的sourceSets没配置正确。解决用第3章的sourceSets配置确保jniLibs.srcDirs指向UnityExport/libs。还要确认app/build.gradle中指定了packagingOptions避免so文件重复。如果用的是Unity 2021版本还会遇到一个典型问题Unity导出的jar不在libs目录而在unityLibrary/libs/unity-classes.jar需要检查这个文件是否被Gradle打包进APK。可以在Android Studio的Build - Analyze APK里确认最终APK是否包含lib/arm64-v8a/libunity.so和classes.jar。如果缺unity-classes.jar可以在unityLibrary/build.gradle里加dependencies { implementation files(libs/unity-classes.jar) }这样确保这个jar被当作依赖打进最终包。5.4 签名冲突与同包名问题现象安装时提示“应用未安装”或签名不一致。原因Unity导出的library工程的applicationId和原生工程不一致导致在设备上被系统当作两个包或者签名没有覆盖所有模块。另外如果UnityExport目录里残留了Unity自动生成的签名文件也可能干扰最终打包。解决确保最终APK的applicationId是原生工程的包名UnityLibrary模块中manifest的package属性可以保留但applicationId必须统一。另外用同一证书签名。具体操作是在unityLibrary/build.gradle里确认没有设置applicationId或者在app/build.gradle里统一使用release签名配置android { signingConfigs { release { storeFile file(release.keystore) storePassword yourpass keyAlias alias keyPassword yourpass } } buildTypes { release { signingConfig signingConfigs.release } } }Unity模块本身不参与签名最终签名只由app模块决定所以只要app模块的签名配置正确一般不会出现这个问题。但如果从Unity侧开启了Custom Main Manifest并指定了其他包名就需要在导入后手动检查。5.5 内存泄漏UnityActivity销毁后后台仍占内存现象退出Unity页面后内存不释放来回切换几次后卡顿。原因没有正确调用unityPlayer.quit或UnityPlayer在被GC前没有释放。UnityPlayer对象持有Native层资源Java层GC不会自动回收Native内存。解决在宿主Activity.onDestroy中调用unityPlayer.quit并将引用置空。此外不要在Unity场景里持有Android Context或Activity的静态引用这会导致原生Activity无法回收。排查内存泄漏可以借助Android Studio的Memory Profiler在Unity页面进入和退出各抓一次Heap Dump对比看是否有Activity实例残留。我遇到过一个典型问题Unity侧用了AndroidJavaObject包装的MainActivity存进了静态字段退出Unity页面后原生Activity一直被持有导致内存只增不减。后来统一改成弱引用private static System.WeakReferenceAndroidJavaObject _activityCache;这样就避免了强引用导致的内存泄漏。6. 验证与进阶用Profiler和Logcat把问题压在发布前集成完成后不要急着打正式包。我会先跑一轮完整的验证清单这套流程能帮我挡掉至少一半的线上崩溃。第一步是验证单向通信。进入Unity页面后在原生侧调用UnitySendMessage看Unity日志是否有输出然后在Unity里点一个按钮调用原生方法看Logcat是否有对应日志。两边打通后再测业务逻辑避免把桥接问题混在业务代码里。第二步是验证生命周期。快速进出Unity页面十次观察内存占用是否稳定Logcat有没有Activity泄漏记录。如果发现内存曲线一直上涨优先检查quit时机和静态引用。第三步是性能基线。在目标真机上用Unity Profiler采集渲染耗时和DrawCall数量重点关注加载场景时的峰值。如果峰值超过200ms说明资源加载策略需要调整比如把大纹理改为异步加载或者把不需要的模型拆到另一个场景。第四步是兼容性测试。至少找一台低端Android 9设备和一台中端Android 13设备跑一遍重点看纹理格式、Vulkan兼容性、16K纹理限制等问题。之前遇到过一台老平板在Vulkan下场景黑屏切换到OpenGLES3后恢复正常从此我在Player Settings里默认选OpenGLES3除非确认目标设备全部支持Vulkan。除了这些我还会在发布前用AAPT工具检查最终APK里Unity相关的文件是否齐全aapt dump badging app-release.apk | grep -E package|native-code看看native-code是否包含arm64-v8a以及包名是否正确。如果native-code为空说明so库没打进去装到设备上必崩。从那以后我每次做Unity嵌入原生工程都强制走一遍这个清单导出时检查IL2CPP、导入后先跑通单向通信、压测时来回切换Activity十次看内存最后再用aapt确认so库齐全。这份《Unity嵌入到Android原工程》资源包把这一整套流程和脚本都打包好了按里面的步骤走能省去不少来回查文档的功夫。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/26 16:47:15 · 阅读 1.2k Unity嵌入Android原工程：从IL2CPP导出到双向通信的完整实践
简介面向需要在原生 Android 应用中集成 Unity 3D 内容的开发者这份压缩包围绕 Unity 嵌入 Android 原工程的全流程展开覆盖从 Unity 导出配置、生成 Android Library Project、导入 Android Studio到原生工程配置、Java/Kotlin 与 Unity 桥接交互、性能优化、错误调试及发布准备等关键环节。资源以 rar 格式打包大小约 323.39MB文件总数与内部文件类型暂未在平台标注。已有 304 人学习。内容聚焦实际接入中的高频问题适合具备一定 Android 基础、希望将 Unity 场景无缝融入原生应用的工程师学习参考可帮助理解工程级集成的完整链路减少在依赖配置、Activity 层次、消息通信和打包发布等环节的踩坑成本。1. Unity嵌入Android原工程导出姿势对了后面才不翻车做混合应用时很多团队会遇到这个需求原生App已经有完整的用户体系和支付流程要用Unity渲染一个3D交互场景。把Unity单独打包成APK再通过Intent跳转安装包冲突、数据无法共享体验很差正确做法是把Unity工程作为Library工程嵌入到Android Studio原工程中。这份《Unity嵌入到Android原工程》资源包讲的就是从Unity导出、Android Studio导入到双向通信的完整链路包含我实际操作中的参数和踩坑记录。适合正在做Unity混合工程、被黑白屏和Activity生命周期折磨的Android与Unity开发者新手能照着走通熟手可以直接看参数和边界。2. 导出前的Unity配置IL2CPP和Player Settings一个都不能省2.1 为什么必须用IL2CPPMono与IL2CPP的选型理由在Unity里脚本后端有Mono和IL2CPP两种。Mono是JIT方案运行时需要解析.NET中间语言Android设备上需要额外携带Mono运行时库导致包体增大、冷启动变慢而且在一些国产ROM上兼容性不稳定。IL2CPP则先把C#代码转成C再交叉编译成.so库运行时直接执行本地指令启动速度更快包体通常也更小。更重要的是原生Android工程运行在ART/Dalvik虚拟机里没有完整的.NET框架支持如果Unity模块带着Mono运行时嵌入几乎必然会碰到ClassNotFoundException和莫名其妙的崩溃。所以在导出给Android原工程集成时脚本后端只能选IL2CPP。这也是我第一次做Unity嵌入时踩到的最大的坑当时想省事用默认的Mono输出结果打出的library在Android Studio里编译通过一跑就崩溃Logcat指向libmono.so缺失。换成IL2CPP后一次通过。要开启IL2CPP打开Unity的File - Build Settings - Player Settings在Other Settings面板里把Scripting Backend从Mono改成IL2CPP。同时把Target Architecture设置为ARM64。现在的Google Play要求新应用和更新必须支持64位新装机设备也基本都是64位处理器只保留ARM64能显著减少.so体积。为了让这个过程可重复我一般会写一个编辑脚本用命令行参数动态控制导出。这样CI机器上也能一键构建。下面这个C#脚本放在Editor文件夹里using UnityEditor; using UnityEngine; public static class AndroidLibraryBuilder { public static void Build() { // 强制切换到Android平台 EditorUserBuildSettings.SwitchActiveBuildTarget(BuildTargetGroup.Android, BuildTarget.Android); // 脚本后端选IL2CPP避免Mono在原生工程中的兼容问题 PlayerSettings.SetScriptingBackend(BuildTargetGroup.Android, ScriptingImplementation.IL2CPP); // 0ARMv7, 1ARM64, 2ARMv7ARM64这里按发布需要选1 PlayerSettings.SetArchitecture(BuildTargetGroup.Android, 1); // 关键一步把构建类型指定为Android Library而不是App EditorUserBuildSettings.androidBuildType AndroidBuildType.Library; // 列出需要打包的场景 string[] scenes { Assets/Scenes/Main.unity }; // 输出到Build/UnityExport目录AcceptExternalModificationsToPlayer是关键 BuildPipeline.BuildPlayer(scenes, Build/UnityExport, BuildTarget.Android, BuildOptions.AcceptExternalModificationsToPlayer); Debug.Log(Unity Library 导出完成); } }这段脚本有几个参数必须说清楚。PlayerSettings.SetScriptingBackend的第一个参数固定传BuildTargetGroup.Android因为脚本后端是按平台区分设置的如果漏了这句可能Unity还是用上一次的Mono配置。SetArchitecture的第二个参数1代表ARM64如果你的应用还想兼容老设备可以传2但最终APK里会同时带上两种架构的so包体会大12MB左右。BuildPlayer最后一个参数BuildOptions.AcceptExternalModificationsToPlayer是一个开关只有加上它Unity才会生成一个可供Android Studio二次开发的Library工程而不是直接生成APK。运行这段脚本的方式很直接在Unity菜单栏的Window - General - Test Runner旁边的命令行窗口执行或者直接在命令行带参数调用Unity可执行文件。我常用的是这个/path/to/Unity -batchmode -quit -projectPath /your/project -executeMethod AndroidLibraryBuilder.Build这样可以让CI在无头模式下完成导出省掉人工打开Unity的步骤。如果脚本报错先确认Android模块已经通过Unity Hub安装否则SetScriptingBackend这行会抛MissingMethodException。2.2 Player Settings里的关键参数API Level、纹理压缩与包名IL2CPP只是第一步Player Settings里的另外几项如果不正确导入Android Studio后还会出问题。第一项是Minimum API Level。Unity默认可能是19或21而原生工程可能早就把minSdkVersion设到了26。两个module共存时Gradle会取其中较高的值所以如果Unity设置太低没有影响但如果Unity设置的minSdk高于原生工程低版本设备就无法安装。稳妥做法是把原生工程和Unity的minSdk设为一致我一般统一用24兼容性足够又避开了Android 5.0权限模型的旧坑。第二项是Target API Level。这个最好和Android Studio里compileSdkVersion保持一致。如果原生工程用compileSdk 33Unity的Target API Level却是29运行时一些系统行为差异会变得难以排查。具体位置在Player Settings - Other Settings里的Target API Level。第三项是Texture Compression。可选ASTC、ETC2、ETC等。现代旗舰芯片对ASTC支持很好纹理压缩率高、画质损失小但一些中低端GPU老设备可能不支持ASTC运行时会花屏。如果你的App最低支持Android 8.0以上直接用ASTC否则用ETC2兼容性更强。这个选择不影响集成流程但影响最终包体和画面效果。第四项是包名配置。Unity导出的library工程有自己的AndroidManifest.xml里面会写一个package属性。需要确认这个package是否和原生工程有冲突。比较安全的做法是Unity工程的Bundle Identifier设置成和原生工程applicationId相同的值或者干脆用独立的内部包名如com.yourcompany.unitylib然后在导入Android Studio后再统一调整。注意原生App最终对外发布的applicationId是app模块里的那个Unity模块的包名只是内部标识不要因此搞混。下面这张表是我每次导出前都会检查一遍的参数参数推荐值原因Scripting BackendIL2CPP原生Android无法承载Mono运行时Target ArchitectureARM64满足Google Play 64位要求Minimum API Level24与原生工程协调取较高值Target API Level与compileSdk一致避免系统行为差异Texture CompressionASTC或ETC2按最低机型支持度选Graphic APIOpenGLES3或Vulkan与Unity渲染管线匹配这些参数不是越多越好关键是和原生工程对齐。如果原生工程还在用旧的compileSdk不必升级到最新只要两边不互相覆盖就行。这套配置做完点下Build得到的是一个带UnityExport名字的文件夹里面已经有AndroidManifest.xml、src、libs、res等目录。下一章就把它接进Android Studio。3. 把UnityExport塞进Android Studio从导入到Activity替换3.1 导入UnityExport与Gradle依赖配置拿到UnityExport目录后不要直接用Android Studio的Import Project去打开它。Unity生成的目录虽然看起来是个Android工程但它是针对老式Eclipse结构生成的直接导入后Gradle同步必报错。我踩过一次把时间全耗在修AGP版本上。常见做法是把它作为原生工程里的一个library module。具体操作先把UnityExport文件夹复制到原生工程的根目录和app同级。然后在settings.gradle里注册这个模块。以Android Studio新模板为例settings.gradle内容类似这样rootProject.name MyNativeApp include :app // 注册Unity导出的库模块 include :unityLibrary project(:unityLibrary).projectDir new File(UnityExport)这里UnityExport目录下要有一个build.gradle文件Unity导出时已经生成了这个文件里面有它自己的compileSdkVersion和minSdkVersion。如果你生成的Unity版本比较老build.gradle里可能用的是老版AGP插件同步时会提示版本冲突这时需要手动把插件版本改成和app模块一致。注册完成后再打开app/build.gradle在dependencies里加上对unityLibrary的依赖dependencies { implementation project(:unityLibrary) }如果你打开UnityExport目录发现build.gradle里的内容不是标准的模块化格式而是一堆sourceSets那就按下面这样在unityLibrary的build.gradle里手动指定源文件位置android { compileSdkVersion 33 defaultConfig { minSdkVersion 24 targetSdkVersion 33 consumerProguardFiles proguard-unity.txt } sourceSets { main { // Unity的so库都在libs目录下Gradle默认不会打包必须显式指定 jniLibs.srcDirs [libs] // Unity的manifest也要参与合并声明src路径 manifest.srcFile AndroidManifest.xml } } }这里sourceSets里的jniLibs.srcDirs是最容易漏的一项。Unity导出的所有so文件都在UnityExport/libs/arm64-v8a里如果不在build.gradle里指定Gradle会以为没有本地库最终APK里缺少libunity.so运行到Unity界面直接UnsatisfiedLinkError。manifest.srcFile同样重要Unity的AndroidManifest里有UnityPlayerActivity的注册信息不并进去应用就会因为找不到Activity而崩溃。配置完之后在Android Studio里点击Sync Now。如果Gradle报错说“Namespace not specified”就在unityLibrary的build.gradle里加上android { namespace com.yourcompany.unitylib }这里namespace可以随便写但要保证和UnityExport里的AndroidManifest.xml的package属性一致。我一般统一改成com.yourcompany.unitylib避免和app模块冲突。3.2 Activity生命周期与UnityPlayer的整合依赖配置好后最核心的是处理好UnityPlayer和Activity生命周期。Unity导出的UnityPlayerActivity本质上是一个持有UnityPlayer实例的Activity。如果我们直接让用户从原生MainActivity跳转到这个UnityPlayerActivity那Unity就变成了一个全屏页面这通常已经满足大部分需求。当然如果App本来就有多个tab要求Unity页面嵌入到某个tab里那就得用更细的方式把UnityPlayer.View塞进Fragment。先说简单方式直接启动UnityPlayerActivity。在原生MainActivity里写val intent Intent(this, UnityPlayerActivity::class.java) startActivity(intent)这里有个前提UnityPlayerActivity已经在UnityExport的AndroidManifest.xml中注册了。我们可以直接继续用它的默认实现也可以继承它写子类在onCreate里预先加载场景、设置启动参数。UnityPlayerActivity默认继承自Activity它会自己创建UnityPlayer并加载Unity场景。再进阶一点需要在原生页面里嵌入一个区域显示Unity画面。此时不能用UnityPlayerActivity而是要自己创建UnityPlayer对象然后在Fragment的onCreateView里返回UnityPlayer的View。写法类似class UnityFragment : Fragment() { private lateinit var unityPlayer: UnityPlayer override fun onCreateView(inflater: LayoutInflater, container: ViewGroup?, savedInstanceState: Bundle?): View? { // 创建UnityPlayerTheme设置成NoTitleBar避免状态栏干扰 unityPlayer UnityPlayer(requireContext()) return unityPlayer } override fun onResume() { super.onResume() unityPlayer.resume() } override fun onPause() { super.onPause() unityPlayer.pause() } override fun onDestroyView() { super.onDestroyView() // 注意这里不要直接quitquit要等Activity真正销毁时再调用 unityPlayer.quit() } override fun onDestroy() { super.onDestroy() unityPlayer.quit() } }这段代码里有两个特别容易翻车的点。第一onResume里必须调unityPlayer.resume()不然Unity场景在不活动之后回到前台渲染线程没有继续画面会卡在最后一帧。第二onDestroyView里调了quitonDestroy里又调了一次其实多次调用quit是安全的但如果你把Fragment加入回退栈onDestroyView可能被调用多次导致UnityPlayer被提前释放再次显示时初始化失败。所以我常见的做法是在Fragment的onDestroyView中只暂停和释放View真正quit放在onDestroy里并通过一个标志位确保只quit一次。Activity的启动方向也要注意如果UnityPlayerActivity是竖屏而MainActivity是横屏启动时会出现短暂旋转。解决方式是在UnityPlayerActivity的onCreate里锁定方向requestedOrientation ActivityInfo.SCREEN_ORIENTATION_LANDSCAPE最后是AndroidManifest.xml里要补的权限。Unity导出时已经带了几个基础权限我们自己在原生工程里加一个位置uses-permission android:nameandroid.permission.INTERNET / uses-permission android:nameandroid.permission.WRITE_EXTERNAL_STORAGE android:maxSdkVersion29 /注意WRITE_EXTERNAL_STORAGE在Android 10以上不需要加上maxSdkVersion可以避免审核时的权限声明问题。如果Unity场景需要加载网络资源INTERNET是必须的不需要的话删掉减少隐私风险。4. 双向通信UnitySendMessage和UnityPlayer.currentActivity的配合4.1 原生调用UnityUnitySendMessage与GameObject绑定原生代码要驱动Unity场景里的行为最直接的方式是UnityPlayer.UnitySendMessage。这个方法的作用是把一条字符串消息发给指定的GameObject然后Unity侧会调用该GameObject上所有组件中匹配名称的方法。方法签名必须是void MethodName(string message)也就是说只能传一个字符串参数。使用前先约定好通信协议在Unity场景里创建了一个空GameObject名字叫CommunicationBridge挂一个脚本里面定义一个可被原生调用的方法。这个GameObject在场景加载后必须是激活状态否则消息收不到。脚本大致这样using UnityEngine; public class CommunicationBridge : MonoBehaviour { void Start() { // 初始化时自动注册方便原生侧随时调用 DontDestroyOnLoad(gameObject); } // 原生层通过UnitySendMessage调用这个方法 public void OnNativeMessage(string data) { // data一般是JSON字符串解析后分发到具体业务 Debug.Log(Unity收到原生消息: data); // 这里可以切换场景、播放动画、更新UI } }原生Kotlin调用的方式// 注意unityPlayer必须在初始化之后才能使用否则会抛异常 UnityPlayer.UnitySendMessage(CommunicationBridge, OnNativeMessage, {\action\:\switchScene\,\sceneName\:\home\})三个参数分别对应GameObject名、方法名、消息内容。如果Unity里没有这个名字的GameObject或者方法名不对调用不会有任何报错但Unity侧也没反应这是最难排查的黑匣子。所以我一般会在OnNativeMessage的Start里打印一条日志确认桥接对象确实活着。再说参数序列化的问题。UnitySendMessage只接受String复杂结构必须先序列化成JSON。在原生侧我用Gson或者org.json拼字符串在Unity侧用JsonUtility或Newtonsoft解析。注意JsonUtility不能直接解析字典我习惯定义一个包装类[System.Serializable] public class NativeMessage { public string action; public string payload; }然后用JsonUtility.FromJson (data)。这样原生侧只需要传action和payload两个字段扩展新业务时不用改桥接层。4.2 Unity调用原生UnityPlayer.currentActivity与静态方法反方向通信Unity需要调用原生Android代码。常见做法是使用Unity的AndroidJavaClass和AndroidJavaObject在C#侧反射调用Java/Kotlin对象。Unity内部提供了一个静态字段UnityPlayer.currentActivity保存了当前承载Unity的Activity实例。在C#里可以这样拿到它using UnityEngine; public class NativeBridge { public static string GetDeviceId() { if (Application.platform ! RuntimePlatform.Android) { Debug.LogWarning(只在Android平台运行); return ; } AndroidJavaClass unityPlayer new AndroidJavaClass(com.unity3d.player.UnityPlayer); AndroidJavaObject activity unityPlayer.GetStaticAndroidJavaObject(currentActivity); AndroidJavaClass nativeBridge new AndroidJavaClass(com.yourcompany.nativebridge.NativeBridge); string deviceId nativeBridge.CallStaticstring(getDeviceId, activity); // AndroidJavaObject和AndroidJavaClass都是Java对象的包装用完后要Dispose释放 nativeBridge.Dispose(); activity.Dispose(); unityPlayer.Dispose(); return deviceId; } }先解释这段代码的要点。new AndroidJavaClass(com.unity3d.player.UnityPlayer)是Unity官方提供的入口类GetStatic (currentActivity)拿到的是原生工程里当前承载Unity的Activity实例。如果UnityPlayer是在一个Fragment里而不是Activity里currentActivity返回的是宿主Activity仍然可用。然后通过AndroidJavaClass加载原生工程里我们自己写的类CallStatic 调用它的静态方法参数把activity传过去作为Context。对应的原生Kotlin类需要写在app模块里注意类名和包名必须和C#里传的一致package com.yourcompany.nativebridge import android.content.Context import android.provider.Settings object NativeBridge { JvmStatic fun getDeviceId(context: Context): String { return Settings.Secure.getString(context.contentResolver, Settings.Secure.ANDROID_ID) } }这里有个参数类型问题CallStatic 只匹配返回值是String的方法如果原生方法返回int或boolean会崩溃。所以我在C#侧统一只接收String类型复杂数据用JSON字符串返回。调用完成后立刻Dispose防止Java对象引用泄漏导致内存占用增长。4.3 统一桥接协议避免双向调用变成意大利面条在实际项目里Unity和原生的交互多达几十种如果每个功能单独加方法两边代码会很难维护。我的习惯是在原生侧定义一个统一入口类和出口类所有通信都走固定的路由。原生往Unity统一通过UnityPlayer.UnitySendMessage发送消息格式固定为JSON{ action: showToast, payload: { text: hello from native } }Unity侧收到后先用一个分发器解析action再调用对应的handler。反过来Unity往原生调用统一走NativeBridge.callStatic原生侧也做一个分发逻辑。这样做的好处是新增业务时只需改分发器不用在底层反复加API排查问题时抓Logcat两边的日志也能对上。5. 避坑与常见问题黑白屏、崩溃、纹理丢失这三个坎5.1 黑白屏与Activity启动缓慢现象从原生界面跳Unity时先黑屏或白屏几秒甚至ANR。原因UnityPlayer初始化没有提前做首次加载需要解析场景、加载着色器、初始化图形引擎耗时2-5秒。在低端机上这个时间还会更长如果主线程被阻塞系统会直接弹ANR对话框。解决把UnityPlayer的初始化提前到应用启动时用一个后台线程预加载UnityPlayer实例或者做一个带Loading图的原生页面等Unity场景准备好后再切换。注意不能在冷启动时阻塞主线程。我建议用一个UnityPlayerManager单例启动时先创建但resume/quit时机要控制好。class UnityPlayerManager private constructor(context: Context) { val player: UnityPlayer UnityPlayer(context) fun loadScene(sceneName: String) { // 用UnityPlayer.LoadScene加载指定场景 player.LoadScene(sceneName) } companion object { Volatile private var instance: UnityPlayerManager? null fun getInstance(context: Context): UnityPlayerManager { return instance ?: synchronized(this) { UnityPlayerManager(context.applicationContext).also { instance it } } } } }这个单例的优点是UnityPlayer在Application启动时就创建后续跳转Unity页面时直接复用黑屏时间明显缩短。缺点是一旦创建Unity资源就常驻内存如果App本身内存吃紧需要评估是否值得。我一般只在App内Unity场景出现频率高时才用这招。5.2 Unity纹理丢失或场景黑屏现象从原生返回Unity场景后画面全黑或者纹理变粉紫色。原因UnityPlayer.pause后OpenGL上下文未被正确恢复或者原生Activity被回收UnityPlayer的surface被销毁。粉紫色纹理通常代表着色器编译失败或纹理格式不兼容。解决在onResume里调用unityPlayer.resume在onPause里调用unityPlayer.pause不要在onDestroy之前forceQuit。另外如果嵌在Fragment中不要在Fragment销毁时直接unityPlayer.quit要等宿主Activity真正销毁时再quit。经验是把UnityPlayer.View和UnityPlayer的生命周期完全交给一个专门的Fragment管理不要和原生Fragment混在一起。粉紫色问题则需要检查Unity侧的Shader是否支持目标GPU特别是用了一些自定义Shader或后处理效果时。可以先在Unity Editor里把Graphics API设置成OpenGLES3试一遍再切到Vulkan对比看是否是API兼容问题。5.3 崩溃java.lang.ClassNotFoundException或UnsatisfiedLinkError现象运行时找不到UnityPlayer类或找不到libunity.so。原因Gradle没有把unity-classes.jar和jniLibs打包进去或者unityLibrary的build.gradle中的sourceSets没配置正确。解决用第3章的sourceSets配置确保jniLibs.srcDirs指向UnityExport/libs。还要确认app/build.gradle中指定了packagingOptions避免so文件重复。如果用的是Unity 2021版本还会遇到一个典型问题Unity导出的jar不在libs目录而在unityLibrary/libs/unity-classes.jar需要检查这个文件是否被Gradle打包进APK。可以在Android Studio的Build - Analyze APK里确认最终APK是否包含lib/arm64-v8a/libunity.so和classes.jar。如果缺unity-classes.jar可以在unityLibrary/build.gradle里加dependencies { implementation files(libs/unity-classes.jar) }这样确保这个jar被当作依赖打进最终包。5.4 签名冲突与同包名问题现象安装时提示“应用未安装”或签名不一致。原因Unity导出的library工程的applicationId和原生工程不一致导致在设备上被系统当作两个包或者签名没有覆盖所有模块。另外如果UnityExport目录里残留了Unity自动生成的签名文件也可能干扰最终打包。解决确保最终APK的applicationId是原生工程的包名UnityLibrary模块中manifest的package属性可以保留但applicationId必须统一。另外用同一证书签名。具体操作是在unityLibrary/build.gradle里确认没有设置applicationId或者在app/build.gradle里统一使用release签名配置android { signingConfigs { release { storeFile file(release.keystore) storePassword yourpass keyAlias alias keyPassword yourpass } } buildTypes { release { signingConfig signingConfigs.release } } }Unity模块本身不参与签名最终签名只由app模块决定所以只要app模块的签名配置正确一般不会出现这个问题。但如果从Unity侧开启了Custom Main Manifest并指定了其他包名就需要在导入后手动检查。5.5 内存泄漏UnityActivity销毁后后台仍占内存现象退出Unity页面后内存不释放来回切换几次后卡顿。原因没有正确调用unityPlayer.quit或UnityPlayer在被GC前没有释放。UnityPlayer对象持有Native层资源Java层GC不会自动回收Native内存。解决在宿主Activity.onDestroy中调用unityPlayer.quit并将引用置空。此外不要在Unity场景里持有Android Context或Activity的静态引用这会导致原生Activity无法回收。排查内存泄漏可以借助Android Studio的Memory Profiler在Unity页面进入和退出各抓一次Heap Dump对比看是否有Activity实例残留。我遇到过一个典型问题Unity侧用了AndroidJavaObject包装的MainActivity存进了静态字段退出Unity页面后原生Activity一直被持有导致内存只增不减。后来统一改成弱引用private static System.WeakReferenceAndroidJavaObject _activityCache;这样就避免了强引用导致的内存泄漏。6. 验证与进阶用Profiler和Logcat把问题压在发布前集成完成后不要急着打正式包。我会先跑一轮完整的验证清单这套流程能帮我挡掉至少一半的线上崩溃。第一步是验证单向通信。进入Unity页面后在原生侧调用UnitySendMessage看Unity日志是否有输出然后在Unity里点一个按钮调用原生方法看Logcat是否有对应日志。两边打通后再测业务逻辑避免把桥接问题混在业务代码里。第二步是验证生命周期。快速进出Unity页面十次观察内存占用是否稳定Logcat有没有Activity泄漏记录。如果发现内存曲线一直上涨优先检查quit时机和静态引用。第三步是性能基线。在目标真机上用Unity Profiler采集渲染耗时和DrawCall数量重点关注加载场景时的峰值。如果峰值超过200ms说明资源加载策略需要调整比如把大纹理改为异步加载或者把不需要的模型拆到另一个场景。第四步是兼容性测试。至少找一台低端Android 9设备和一台中端Android 13设备跑一遍重点看纹理格式、Vulkan兼容性、16K纹理限制等问题。之前遇到过一台老平板在Vulkan下场景黑屏切换到OpenGLES3后恢复正常从此我在Player Settings里默认选OpenGLES3除非确认目标设备全部支持Vulkan。除了这些我还会在发布前用AAPT工具检查最终APK里Unity相关的文件是否齐全aapt dump badging app-release.apk | grep -E package|native-code看看native-code是否包含arm64-v8a以及包名是否正确。如果native-code为空说明so库没打进去装到设备上必崩。从那以后我每次做Unity嵌入原生工程都强制走一遍这个清单导出时检查IL2CPP、导入后先跑通单向通信、压测时来回切换Activity十次看内存最后再用aapt确认so库齐全。这份《Unity嵌入到Android原工程》资源包把这一整套流程和脚本都打包好了按里面的步骤走能省去不少来回查文档的功夫。希望帮到你。本文还有配套的精品资源点击获取