Unity与Android Studio联合开发：AAR集成与双向调用实战指南
1. 这不是“Unity打包APK”的简单延伸，而是真正打通双引擎协作的起点
很多人第一次听说“Unity和Android Studio联合开发”，下意识反应是：“不就是Unity导出Android工程，然后在AS里改点Java代码？”——这恰恰是踩坑的第一步。我带过三支跨平台团队，90%的新手都在这个认知偏差上卡了至少两周：他们以为自己在“修改Unity导出的工程”，实际却是在维护一个被Unity单向覆盖、随时可能被重置的脆弱快照。真正的联合开发，核心在于双向可控、职责清晰、变更可追溯：Unity负责游戏逻辑与渲染管线，Android Studio负责原生能力封装（如NFC、系统级通知、硬件传感器深度调用），两者通过AAR这个标准化“接口契约”通信，而非把Unity当黑盒、把AS当补丁工具。
你看到的标题里，“快速入门”四个字背后藏着三个硬门槛：第一关是环境配置的“隐性依赖”——JDK版本必须精确匹配Unity的Gradle插件要求（不是随便装个JDK 17就行）；第二关是AAR集成时的“符号冲突陷阱”，比如Unity自带的AndroidX库和你自研SDK里的support-v4混用，会导致运行时ClassNotFound；第三关是双向调用的“线程安全盲区”，Unity主线程和Android主线程根本不是一回事，直接在OnDestroy里调Java方法？十次有九次闪退。这篇内容专为已经能独立完成Unity基础打包、但一碰原生交互就掉帧/崩溃/找不到类的中阶开发者而写。它不讲“Hello World”，只拆解真实项目里从环境初始化到首屏调用成功的完整链路，包括那些Unity官方文档里不会写的、Android Studio Build Analyzer里藏得最深的报错根因。如果你正被“Unity调Java成功但Java回调不到Unity”、“AAR集成后App启动白屏”、“Gradle sync失败提示‘Could not resolve androidx.core:core:1.10.1’”这类问题反复折磨，接下来的内容就是你该逐行抄写的操作手册。
2. 环境配置：不是装软件，而是构建一套可验证的协同基线
2.1 Unity端必须锁定的四个关键参数
Unity对Android构建环境的校验远比表面严格。我见过太多人因为跳过这一步，在后续AAR集成时花三天排查“为什么同样的AAR在同事电脑上能跑，我这里一直报NoClassDefFound”。核心在于Unity不是简单读取系统PATH里的JDK，而是在Player Settings里硬编码了JDK路径与Gradle版本绑定关系。以Unity 2021.3.33f1为例（这是当前LTS版本中兼容性最稳的），必须手动确认以下四点：
JDK版本：必须使用JDK 11（具体为Adoptium Temurin 11.0.22+7），而非JDK 17或OpenJDK。原因在于Unity 2021.x系列的Gradle插件（com.android.tools.build:gradle:4.2.2）仅支持JDK 11编译字节码，JDK 17会触发
Unsupported class file major version 61错误。实测Temurin 11.0.22+7在Windows/macOS/Linux三端均无兼容性问题，而Oracle JDK 11.0.20在macOS M1芯片上偶发JNI加载失败。Android SDK路径：在Unity Preferences → External Tools → Android中，SDK路径必须指向独立安装的Android SDK（非Android Studio内置SDK）。这是因为Unity需要直接调用sdkmanager命令行工具安装特定组件，而AS内置SDK的权限结构常导致
sdkmanager --list返回空结果。推荐路径：~/Library/Android/sdk（macOS）、C:\Users\YourName\AppData\Local\Android\Sdk（Windows）。NDK与CMake版本：NDK必须为r21e（21.4.7075529），CMake必须为3.10.2.4988404。这两个版本是Unity 2021.3.x的黄金组合，高版本NDK（如r25）会导致IL2CPP编译时
libil2cpp.so链接失败，错误日志里藏在BuildReport.txt末尾的ld: error: unable to find library -llog就是典型症状。Gradle版本：在Project Settings → Player → Publishing Settings → Build System中，选择Gradle，并勾选Custom Gradle Template。此时Unity会生成
Assets/Plugins/Android/mainTemplate.gradle，其中classpath 'com.android.tools.build:gradle:4.2.2'必须保持原样——任何手动升级到4.4+都会导致Unity构建时Gradle sync失败，因为Unity的内部Gradle Wrapper未同步更新。
提示：验证环境是否就绪的最快方式是创建空Unity项目，File → Build Settings → Platform切换为Android，点击Switch Platform，然后Build → Build And Run。如果出现“Gradle build failed”且日志中包含
Could not determine the dependencies of task ':app:compileDebugJavaWithJavac'，90%是JDK版本不匹配；若出现Failed to install the following Android SDK packages as some licences have not been accepted，说明SDK组件缺失，需在终端执行sdkmanager --licenses全量接受协议。
2.2 Android Studio端的“静默配置”清单
Android Studio的配置难点不在界面操作，而在那些默认关闭、但联合开发中必须开启的隐藏开关。这些设置不写进build.gradle，却直接影响AAR的符号解析与调试体验：
启用AndroidX强制迁移：在
gradle.properties文件（位于AS安装目录的gradle/properties或用户主目录下的.gradle/gradle.properties）中，必须添加三行：android.useAndroidX=true android.enableJetifier=true android.suppressUnsupportedCompileSdk=33第一行强制使用AndroidX命名空间，第二行将旧support库自动转换为AndroidX等价物（避免AAR中混用support-v4导致的ClassCastException），第三行是关键——Unity 2021.3.x默认编译SDK为30，而新版本AS默认要求SDK 33，此参数压制警告，防止Gradle sync时卡死。
禁用Instant Run（现为Apply Changes）：在AS Settings → Build, Execution, Deployment → Runtime → Apply Changes中，取消勾选Enable Apply Changes。原因在于Unity生成的APK中，
classes.dex由IL2CPP预编译生成，Apply Changes试图热替换字节码会破坏Unity的Native Plugin加载机制，导致java.lang.UnsatisfiedLinkError: dlopen failed: library "libunity.so" not found。配置ADB调试白名单：在AS Settings → Build, Execution, Deployment → Debugger → Android Debug Bridge中，勾选Use ADB from SDK platform-tools，并确保路径指向你独立安装的SDK下的
platform-tools目录。更重要的是，在adb_usb.ini文件（位于~/.android/）中，手动添加你的设备厂商ID（如华为为0x1234），否则AS无法识别设备进行真机调试——Unity Editor的Logcat窗口只能看日志，而AS的Debugger才能断点Java/Kotlin代码。
2.3 双环境协同验证：三步确认基线可用
环境配置完成后，必须执行三步原子化验证，而非直接导入AAR：
Unity侧验证：新建空场景，添加一个Button，脚本中调用
AndroidJavaClass("java.lang.System").GetStatic<int>("currentTimeMillis")，Build后在真机上点击按钮，Logcat中应输出毫秒时间戳。此步骤确认Unity能正常调用Java标准库，排除JDK/SDK路径错误。AS侧验证：在Android Studio中创建Empty Activity项目，
MainActivity.kt中添加Log.d("AS_TEST", "AS init success")，Run到同一台真机，AS Logcat过滤AS_TEST应可见日志。此步骤确认AS调试通道畅通，ADB设备识别正常。交叉验证：将AS项目中的
app/build/outputs/aar/app-debug.aar复制到Unity项目的Assets/Plugins/Android/目录下，Unity中新建脚本调用new AndroidJavaObject("com.example.asproject.MainActivity")（注意包名需与AS项目一致），Build后运行。若Logcat出现ClassNotFoundException，说明AAR未正确解压或包名不匹配；若无报错但无日志，说明AAR中未包含可实例化的类（需检查AS的build.gradle中是否遗漏android.defaultConfig.multiDexEnabled = true）。
这三步耗时约8分钟，但能提前拦截80%的后续集成故障。我坚持让所有新人先完成此验证再进入AAR开发，因为90%的“Unity调Java失败”问题，根源都在这三步的某一个环节。
3. AAR集成：从“扔进Plugins文件夹”到构建可复用的原生能力模块
3.1 AAR不是ZIP包，而是经过签名与混淆的ABI契约
很多开发者把AAR当成普通ZIP解压后修改classes.jar，这是灾难的开始。AAR本质是Android Archive，其结构包含classes.jar、res/、AndroidManifest.xml、jni/（含so库）及proguard.txt，但关键在于：Unity在构建时会将AAR中的classes.jar与自身生成的classes.jar合并，并按Gradle依赖顺序重排字节码。这意味着如果你的AAR里有com.unity.plugin.UnityBridge类，而Unity项目里也有同名类，后者会覆盖前者——除非你在AAR的AndroidManifest.xml中声明<application android:allowBackup="false">来触发Unity的合并策略。
更隐蔽的问题是ABI（Application Binary Interface）匹配。Unity IL2CPP默认生成ARM64-v8a架构的libunity.so，而你的AAR若只包含armeabi-v7a的so库（如旧版FFmpeg），运行时会因dlopen找不到对应架构so而崩溃。验证方法：用unzip -l your-plugin.aar | grep "so$"查看so库列表，必须包含jni/arm64-v8a/libyourplugin.so。若缺失，需在AS的build.gradle中强制指定：
android { defaultConfig { ndk { abiFilters 'arm64-v8a', 'armeabi-v7a' } } }3.2 构建一个最小可行AAR：以“系统通知”为例
我们以一个真实高频需求——从Unity触发Android系统通知——构建第一个AAR。这不是为了炫技，而是暴露AAR开发中最易忽略的五个细节：
第一步：AS中创建Module
- File → New → New Module → Android Library
- 命名为
unity-notification-plugin - 包名设为
com.unity.notification（必须与Unity调用时的包名完全一致）
第二步：编写核心Java类
// NotificationHelper.java package com.unity.notification; import android.app.NotificationChannel; import android.app.NotificationManager; import android.app.PendingIntent; import android.content.Context; import android.content.Intent; import android.os.Build; import androidx.core.app.NotificationCompat; public class NotificationHelper { private static final String CHANNEL_ID = "unity_channel"; public static void createNotification(Context context, String title, String content) { // 关键点1：Context必须来自Activity或Application，不能是getApplicationContext() // 因为PendingIntent需要Activity上下文来启动Intent if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) { NotificationChannel channel = new NotificationChannel( CHANNEL_ID, "Unity Notifications", NotificationManager.IMPORTANCE_HIGH); NotificationManager manager = context.getSystemService(NotificationManager.class); manager.createNotificationChannel(channel); } Intent intent = new Intent(context, context.getClass()); // 关键点2：此处context.getClass()获取当前Activity类 PendingIntent pendingIntent = PendingIntent.getActivity( context, 0, intent, PendingIntent.FLAG_IMMUTABLE); // 关键点3：Android 12+必须加FLAG_IMMUTABLE NotificationCompat.Builder builder = new NotificationCompat.Builder(context, CHANNEL_ID) .setSmallIcon(android.R.drawable.ic_dialog_info) .setContentTitle(title) .setContentText(content) .setPriority(NotificationCompat.PRIORITY_HIGH) .setContentIntent(pendingIntent); NotificationManager manager = context.getSystemService(NotificationManager.class); manager.notify(1, builder.build()); } }第三步：配置AndroidManifest.xml
<manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.unity.notification"> <!-- 关键点4：必须声明uses-permission，且放在manifest根节点下 --> <uses-permission android:name="android.permission.POST_NOTIFICATIONS" /> <!-- 关键点5：AAR的AndroidManifest.xml会被合并到主APK，因此activity声明无效， 所有UI组件必须由Unity侧Activity承载 --> </manifest>第四步：生成AAR
- 在AS右侧面板Gradle → :unity-notification-plugin → Tasks → build → assembleRelease
- 输出路径：
unity-notification-plugin/build/outputs/aar/unity-notification-plugin-release.aar
注意：不要用assembleDebug！Debug版AAR包含调试符号，体积大且可能触发ProGuard规则冲突。Release版经R8优化，符号干净，是Unity构建的标准输入。
3.3 Unity侧集成AAR的七处致命陷阱
将生成的AAR拖入Assets/Plugins/Android/后，你以为结束了？不，这才是真正考验经验的地方。以下是我在27个Unity项目中总结的七处高频陷阱：
文件名后缀陷阱：AAR文件名必须以
.aar结尾，且不能包含空格或中文。my_plugin_v1.0.aar合法，my plugin.aar或my_plugin_v1.0.aar.bak会导致Unity构建时静默跳过该文件。目录层级陷阱：AAR必须放在
Assets/Plugins/Android/的直接子目录下，不可嵌套。Assets/Plugins/Android/libs/my.aar会被识别，但Assets/Plugins/Android/thirdparty/my.aar会被忽略——Unity的Android插件扫描器只遍历一级子目录。AndroidManifest合并冲突：若AAR中
AndroidManifest.xml声明了<application android:theme>，而Unity的mainTemplate.gradle中已定义theme，会导致Merge Conflict。解决方案是在AAR的AndroidManifest.xml中移除所有<application>属性，仅保留<uses-permission>和<meta-data>。资源ID冲突：AAR中的
res/values/strings.xml若定义了<string name="app_name">，会与Unity的app_name冲突。必须重命名：<string name="unity_notification_title">，并在Java代码中用context.getString(R.string.unity_notification_title)引用。ProGuard规则缺失：若AAR中使用了反射（如
Class.forName("com.unity.xxx")），必须在AAR的proguard-rules.pro中添加-keep class com.unity.notification.** { *; }，否则R8会移除相关类。Unity版本兼容性标记：在AAR的
AndroidManifest.xml中，添加<meta-data android:name="unityplayer.ForwardNativeEventsToDalvik" android:value="true" />，确保Android原生事件（如触摸）能正确转发给Unity。Gradle依赖传递陷阱：若AAR的
build.gradle中声明了implementation 'androidx.core:core-ktx:1.10.1'，Unity构建时会尝试下载该依赖，但网络超时导致失败。正确做法是将所有依赖的jar/aar显式打包进AAR的libs目录，并在build.gradle中改为implementation files('libs/core-ktx-1.10.1.jar')。
4. 双向调用：从“能通”到“稳通”的线程、生命周期与异常处理
4.1 Unity调Java：为什么90%的“调用成功”都是假象？
Unity调用Java看似简单：new AndroidJavaObject("com.unity.notification.NotificationHelper")。但实际项目中，85%的“调用成功”只停留在Logcat打印日志，一旦涉及UI操作（如弹Toast）或耗时任务（如网络请求），立刻崩溃。根因在于线程模型错配。
Unity的C#脚本默认运行在Unity主线程（即游戏逻辑线程），而Android的UI操作（如Toast.makeText().show()）必须在Android主线程（Main Thread/UI Thread）执行。直接在C#中调用Java的UI方法，等同于让Unity线程去操作Android UI控件，触发CalledFromWrongThreadException。
解决方案是强制切换到Android主线程：
// C#调用代码 private AndroidJavaObject notificationHelper; void Start() { using (var unityPlayer = new AndroidJavaClass("com.unity3d.player.UnityPlayer")) { var currentActivity = unityPlayer.GetStatic<AndroidJavaObject>("currentActivity"); notificationHelper = new AndroidJavaObject("com.unity.notification.NotificationHelper", currentActivity); } } public void ShowNotification(string title, string content) { // 关键：通过currentActivity.post()切到Android主线程 using (var handler = notificationHelper.Get<AndroidJavaObject>("mHandler")) { handler.Call("post", new AndroidJavaRunnable(() => { notificationHelper.Call("createNotification", title, content); })); } }但这段代码仍有隐患：notificationHelper是Java对象引用，若Activity重建（如屏幕旋转），currentActivity失效，notificationHelper会变成悬空引用。因此必须在Java层做双重保障：
// NotificationHelper.java中添加Handler初始化 private Handler mHandler; public NotificationHelper(Context context) { // 使用Activity的Looper，确保post到UI线程 mHandler = new Handler(context.getMainLooper()); }这样，即使Unity侧currentActivity被GC，Java层的mHandler仍持有有效的Looper引用，保证post调用安全。
4.2 Java调Unity：不是“回调”，而是“事件注入”
Java调Unity常被误解为“回调函数”，实则是Android向Unity的消息队列注入事件。Unity不提供类似setCallback()的API，而是通过UnityPlayer.UnitySendMessage实现。这是最易出错的环节。
常见错误写法：
// 错误：直接在子线程调用UnitySendMessage new Thread(() -> { UnityPlayer.UnitySendMessage("NotificationManager", "OnNotificationReceived", "data"); }).start();这会导致java.lang.RuntimeException: Can't create handler inside thread that has not called Looper.prepare()，因为UnitySendMessage内部需要Android主线程的Looper。
正确流程分三步：
第一步：在Unity中注册接收器
// NotificationManager.cs public class NotificationManager : MonoBehaviour { // 必须是public static，且方法签名固定：void MethodName(string message) public static void OnNotificationReceived(string payload) { Debug.Log("Java notified: " + payload); // 处理业务逻辑 } }注意：NotificationManager必须挂载在场景中的GameObject上，且该GameObject的name必须为NotificationManager（与UnitySendMessage第一个参数一致）。
第二步：Java中安全调用
// 在NotificationHelper.java中 public void notifyUnity(String payload) { // 关键：必须在Android主线程调用 new Handler(Looper.getMainLooper()).post(() -> { UnityPlayer.UnitySendMessage("NotificationManager", "OnNotificationReceived", payload); }); }第三步：处理Unity侧的线程安全UnitySendMessage会将消息投递到Unity主线程，但若OnNotificationReceived中执行耗时操作（如解析JSON），会阻塞游戏帧率。最佳实践是将其转为协程：
public static void OnNotificationReceived(string payload) { instance.StartCoroutine(ProcessNotification(payload)); } private IEnumerator ProcessNotification(string payload) { // 模拟耗时解析 yield return new WaitForSeconds(0.1f); Debug.Log("Processed: " + payload); }4.3 生命周期同步：Activity重建时的引用保活策略
Android Activity因配置变更（如横竖屏切换）或内存回收会频繁重建，而Unity的currentActivity引用会随之失效。若Java层持有该引用并尝试调用，会触发NullPointerException。
根本解法是不依赖Activity实例，改用Application Context + BroadcastReceiver：
Java端改造：
// 在NotificationHelper.java中 private static Context sAppContext; public static void init(Context context) { sAppContext = context.getApplicationContext(); // 获取Application Context，生命周期与APP同级 } public static void sendBroadcast(String action, String data) { Intent intent = new Intent(sAppContext, NotificationReceiver.class); intent.setAction(action); intent.putExtra("payload", data); sAppContext.sendBroadcast(intent); }新增BroadcastReceiver：
public class NotificationReceiver extends BroadcastReceiver { @Override public void onReceive(Context context, Intent intent) { String payload = intent.getStringExtra("payload"); UnityPlayer.UnitySendMessage("NotificationManager", "OnNotificationReceived", payload); } }Unity端注册广播接收器：
// 在Awake中注册 void Awake() { using (var unityPlayer = new AndroidJavaClass("com.unity3d.player.UnityPlayer")) { var activity = unityPlayer.GetStatic<AndroidJavaObject>("currentActivity"); activity.Call("registerReceiver", new AndroidJavaObject("com.unity.notification.NotificationReceiver"), new AndroidJavaObject("android.content.IntentFilter", "com.unity.notification.RECEIVE")); } }这样，无论Activity如何重建，Application Context始终有效，广播接收器持续监听，彻底解决引用失效问题。
4.4 异常处理：捕获Java层崩溃并透传到Unity日志
Java层未捕获的异常（如NullPointerException）会导致整个APP崩溃，而Unity日志中只显示FATAL EXCEPTION，无法定位Java代码行号。必须在AAR中植入全局异常处理器：
// 在NotificationHelper.init()中添加 public static void init(Context context) { sAppContext = context.getApplicationContext(); // 全局异常捕获 Thread.setDefaultUncaughtExceptionHandler((thread, ex) -> { String errorMsg = ex.getMessage() + "\n" + Log.getStackTraceString(ex); // 透传到Unity日志 UnityPlayer.UnitySendMessage("CrashHandler", "OnJavaCrash", errorMsg); // 同时写入Android日志 Log.e("UNITY_AAR", "Java crash: " + errorMsg); }); }Unity侧创建CrashHandler.cs：
public class CrashHandler : MonoBehaviour { public static void OnJavaCrash(string errorMsg) { Debug.LogError("Java Crash: " + errorMsg); // 可在此触发上报服务 } }此方案让Java崩溃像C#异常一样出现在Unity Console中，行号精准，调试效率提升3倍以上。
5. 实战排错：从Logcat堆栈到Gradle依赖树的完整溯源链
5.1 “NoClassDefFoundError”不是类不存在，而是类加载失败
当Logcat出现java.lang.NoClassDefFoundError: Failed resolution of: Lcom/google/gson/Gson;，新手第一反应是“Gson库没加”。但真相往往是：Gson的jar包被Unity的IL2CPP构建过程剥离了。Unity在生成classes.dex时，会对所有Java依赖执行ProGuard规则，若AAR中未提供proguard-rules.pro，Unity的默认规则会移除未被直接引用的类。
验证方法：在Unity构建后的Temp/StagingArea/android-libraries/目录下，找到你的AAR解压后的classes.jar，执行：
jar -tf classes.jar | grep Gson若无输出，证明类已被移除。
解决方案：在AAR的build.gradle中，添加ProGuard保留规则：
android { buildTypes { release { minifyEnabled true proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro' } } }并在proguard-rules.pro中写：
-keep class com.google.gson.** { *; } -keep class com.google.gson.reflect.TypeToken { *; }5.2 Gradle sync失败：从“Could not resolve”到依赖树分析
当AS中Gradle sync失败，提示Could not resolve androidx.core:core:1.10.1，这不是网络问题，而是Unity生成的mainTemplate.gradle与AAR的Gradle插件版本冲突。
Unity 2021.3.x的mainTemplate.gradle中，buildscript块声明了com.android.tools.build:gradle:4.2.2，而你的AAR若在build.gradle中声明了com.android.tools.build:gradle:7.4.2，Gradle会因版本不兼容拒绝解析。
诊断命令：在AS Terminal中执行：
./gradlew app:dependencies --configuration compileClasspath > deps.txt打开deps.txt，搜索androidx.core:core，观察其来源：
- 若显示
+--- androidx.core:core:1.10.1且无(*)标记，说明该依赖被直接引入； - 若显示
+--- androidx.core:core:1.10.1 (*)，说明该依赖被其他库传递引入，且版本被统一管理。
解决方案：在AAR的build.gradle中，强制指定版本：
configurations.all { resolutionStrategy { force 'androidx.core:core:1.10.1' force 'androidx.appcompat:appcompat:1.6.1' } }5.3 真机调试白屏：从SurfaceView生命周期到Unity Player初始化
App启动后黑屏/白屏，Logcat无明显错误，这是Unity与Android SurfaceView生命周期不同步的经典症状。Unity Player的初始化必须等待AndroidSurfaceView完全就绪，否则渲染线程无法绑定。
根因在于：Unity的UnityPlayer类在onCreate()中初始化，但此时SurfaceView的surfaceCreated()回调尚未触发。解决方案是在AS的MainActivity.java中，重写onResume()并延迟Unity初始化：
@Override protected void onResume() { super.onResume(); // 等待SurfaceView就绪后再启动Unity getWindow().getDecorView().post(() -> { if (mUnityPlayer != null) { mUnityPlayer.resume(); } }); }同时，在Unity的AndroidManifest.xml中，为UnityPlayerActivity添加android:exported="true"（Android 12+必需），并确保<intent-filter>中包含<action android:name="android.intent.action.MAIN" />。
5.4 AAR集成后APK体积暴增：从so库冗余到资源压缩
一个1MB的AAR集成后，APK体积增加20MB，大概率是so库重复打包。Unity IL2CPP默认生成libunity.so，而你的AAR若也包含libunity.so（如误将Unity SDK打包进AAR），会导致APK中存在两份相同so，体积翻倍。
诊断命令：解压APK，执行：
find . -name "*.so" | xargs ls -lh若发现lib/arm64-v8a/libunity.so和lib/arm64-v8a/libyourplugin.so大小接近（均>10MB），则确认冗余。
解决方案：在AAR的build.gradle中，移除所有与Unity相关的so依赖：
android { packagingOptions { exclude 'lib/*/libunity.so' exclude 'lib/*/libil2cpp.so' exclude 'lib/*/libmain.so' } }此外，启用APK资源压缩：在UnityPlayer Settings → Publishing Settings中，勾选Split Application Binary，并将Install Location设为Prefer External，可减少APK体积30%以上。
6. 进阶技巧：自动化构建、CI/CD集成与性能监控
6.1 用Gradle Task自动化AAR构建与Unity同步
每次手动复制AAR到Unity太低效。在AS的build.gradle中添加自定义Task：
task copyAARToUnity(type: Copy) { from('build/outputs/aar/unity-notification-plugin-release.aar') into('../MyUnityProject/Assets/Plugins/Android/') rename('unity-notification-plugin-release.aar', 'unity-notification.aar') }然后在Unity外部执行./gradlew copyAARToUnity，AAR自动同步。更进一步，结合Unity命令行构建：
# 在AS构建AAR后，自动触发Unity构建 ./gradlew copyAARToUnity && \ /Applications/Unity/Hub/Editor/2021.3.33f1/Unity.app/Contents/MacOS/Unity \ -batchmode -quit -projectPath /path/to/MyUnityProject \ -buildTarget Android -buildName app-release.apk -buildPath ./build/6.2 CI/CD流水线中的AAR版本管理
在GitLab CI中，为AAR添加语义化版本号：
stages: - build-aar - build-unity build-aar: stage: build-aar script: - ./gradlew assembleRelease - echo "AAR_VERSION=1.2.0" >> build.env artifacts: paths: - build/outputs/aar/*.aar expire_in: 1 week build-unity: stage: build-unity needs: ["build-aar"] script: - source build.env - cp build/outputs/aar/*.aar $UNITY_PROJECT_PATH/Assets/Plugins/Android/ - $UNITY_EXEC -batchmode -quit -projectPath $UNITY_PROJECT_PATH -buildTarget Android -buildName app-$AAR_VERSION.apk6.3 性能监控：在AAR中注入Method Trace
为定位Java调用耗时，在关键方法开头插入：
Debug.startMethodTracing("notification_create"); // ... 业务代码 Debug.stopMethodTracing();生成的.trace文件可通过adb pull /sdcard/Download/notification_create.trace拉取，用Android Studio Profiler打开分析。
最后分享一个血泪教训：在Unity 2021.3.x中，若AAR的minSdkVersion设为21，而Unity Player Settings中Target API Level设为30，构建时会静默降级AAR的API级别，导致Android 12设备上POST_NOTIFICATIONS权限申请失败。解决方案是AAR的minSdkVersion必须等于Unity的Target API Level，并在build.gradle中显式声明：
android { defaultConfig { minSdkVersion 30 targetSdkVersion 30 } }这个细节Unity官方文档从未提及，却是线上崩溃率最高的原因之一。