1. 项目概述为什么Unity 2019导出安卓项目成了“卡点工程”Unity 2019.4是LTS长期支持版本中真正走向工业级稳定的关键分水岭——它首次将Android Gradle PluginAGP3.4、JDK 11、Android SDK 29Android 10作为默认组合纳入官方构建链彻底告别了Unity 2017时代靠手动替换gradle-wrapper.jar、硬改build.gradle、甚至用文本编辑器暴力搜索替换“compileSdkVersion”来蒙混过关的野路子。但正因这套新链路更规范、更现代它对开发者的知识结构提出了隐性升级要求你不再只是个会拖拽脚本的Unity开发者你得懂一点Gradle的依赖解析逻辑得明白AndroidManifest.xml里 标签的android:usesCleartextTraffic属性为什么在Android 9上突然变成强制项还得能看懂Build Output窗口里那一长串“Duplicate class androidx.core.xxx found in modules…”的报错到底指向哪个插件冲突。我带过的几个团队里有位做了八年Unity的老手在2021年第一次用2019.4.37f1导出一个带AdMob和Firebase的项目时卡在“Failed to re-package resources”整整三天最后发现是某国产SDK自带的旧版support-v4库和Unity内置的androidx.core库版本不兼容而解决方案不是删库而是通过gradle.properties里加一行android.useAndroidXtrue和android.enableJetifiertrue来触发自动迁移——这种细节Unity官方文档不会写Stack Overflow的高票答案可能已经过期三年只有踩过坑的人才记得住。所以这篇内容不是教你怎么点“Build And Run”而是帮你把整个安卓导出流程拆成可诊断、可干预、可复现的模块从JDK路径校验到Keystore签名策略从Minify混淆配置到ARM64架构适配每一步都附带真实报错截图背后的原理推演和绕过方案。适合所有正在用Unity 2019.2及以上版本、目标平台为Android、且遇到构建失败/安装崩溃/功能异常的开发者无论你是独立开发者还是团队主程只要你的项目还没上线这篇就是你的构建流水线急救包。2. 构建环境链路深度拆解Unity、JDK、SDK、NDK、Gradle五层依赖关系2.1 Unity内部构建引擎如何调度外部工具链Unity 2019的安卓构建不再是“打包器”而是一个协调中枢。当你点击Build Settings里的“Build”按钮Unity实际执行的是一个四阶段流水线第一阶段资源预处理Pre-BuildUnity扫描Assets目录下的所有脚本、Shader、Texture生成中间产物如*.dll、.so、.jar。关键点在于Unity 2019.4开始所有C#脚本默认编译为.NET Standard 2.0这意味着你不能再引用System.Drawing等桌面专属API同时IL2CPP后端会将C#代码转为C再由NDK编译为ARMv7或ARM64指令集——这直接决定了你最终APK里lib/armeabi-v7a/和lib/arm64-v8a/两个文件夹是否同时存在。第二阶段Gradle工程生成Gradle GenerationUnity根据Player Settings里的配置如Package Name、Minimum API Level自动生成一个临时的Android Studio工程结构核心文件包括launcher/build.gradle定义compileSdkVersion、targetSdkVersion、dependenciesgradle.properties控制AndroidX迁移开关、NDK路径、JVM内存参数AndroidManifest.xml合并所有插件声明的 、 、这里埋着第一个雷Unity生成的build.gradle里com.android.tools.build:gradle插件版本是硬编码的。比如2019.4.37f1默认用AGP 3.4.3而如果你本地Android Studio装的是AGP 4.2Gradle Sync就会失败——因为AGP 3.4.x只兼容Gradle 5.1.1而AGP 4.2要求Gradle 6.7.1。解决方案不是升级Unity而是修改gradle/wrapper/gradle-wrapper.properties里的distributionUrlhttps\://services.gradle.org/distributions/gradle-5.1.1-all.zip这是Unity允许你安全干预的唯一Gradle版本入口。第三阶段Gradle构建执行Gradle ExecutionUnity调用系统PATH里的gradle命令或内置gradle wrapper执行assembleRelease任务。此时真正的编译、打包、签名发生在Gradle层面javac编译Java代码如插件的Activityaapt2处理资源生成R.java、压缩图片d8或r8进行字节码优化Minify开启时zipalign对齐APK资源提升IO性能apksigner用Keystore签名未签名APK无法安装这个阶段的错误日志全在Unity Console的“Gradle Build Failed”下方展开但真正有用的线索藏在Temp/gradleOut/launcher/build/outputs/logs/里的manifest-merger-release-report.txt——它会告诉你哪两个插件在争抢同一个 的authorities属性。第四阶段APK后处理Post-BuildUnity对生成的APK做最后检查验证签名是否有效、检查是否包含ARM64原生库如果勾选了对应架构、校验AndroidManifest里是否有重复的 标签。一旦失败Unity会抛出“APK validation failed”并终止流程但不会告诉你具体哪行XML错了——这时候你需要用aapt dump badging your-app.apk命令手动解析APK元信息。2.2 JDK版本陷阱为什么JDK 8和JDK 11不能混用Unity 2019.4官方文档写着“支持JDK 8/11”但实际运行中JDK版本必须与Gradle版本严格匹配。我们实测过三组组合Unity版本JDK版本Gradle Wrapper版本结果原因2019.4.37f1JDK 8u291gradle-5.1.1✅ 成功AGP 3.4.3的编译器前端兼容JDK 82019.4.37f1JDK 11.0.12gradle-5.1.1❌ 失败JDK 11的javac编译器在gradle-5.1.1里触发Unsupported class file major version 55错误2019.4.37f1JDK 11.0.12gradle-6.7.1✅ 成功gradle-6.7.1内置了JDK 11兼容的编译器插件关键原理在于Gradle本身是个Java应用它的gradle.bat脚本会读取系统JAVA_HOME环境变量来启动JVM而Gradle内部调用的javac又依赖于该JVM的版本。Unity在调用Gradle前会把Player Settings里设置的JDK路径注入到环境变量但如果你的系统PATH里有多个JDKGradle可能优先读取PATH里的旧版本。解决方案是在Unity Preferences → External Tools → JDK Path绝对路径指定到JDK 11的根目录如C:\Program Files\Java\jdk-11.0.12不要指向jre子目录在gradle.properties里添加org.gradle.java.homeC\:\\Program Files\\Java\\jdk-11.0.12强制Gradle使用该JDK删除系统PATH里的JDK 8路径避免干扰。提示JDK 11比JDK 8多出的--add-opensJVM参数用于反射访问内部API在Unity构建中毫无作用反而可能触发Gradle的非法参数警告因此不要在gradle.properties里手动添加。2.3 Android SDK/NDK/Gradle三者版本协同表Unity 2019的构建失败70%源于SDK/NDK/Gradle三者版本不匹配。我们整理了2019.2至2019.4.37f1全系列的黄金组合经实测无冲突Unity版本推荐Android SDK推荐NDK版本推荐Gradle Wrapper对应AGP版本关键适配点2019.2.0f128 (Android 9)r16bgradle-5.1.13.4.0支持AndroidX迁移但不支持targetSdkVersion292019.3.15f129 (Android 10)r19cgradle-5.6.43.6.4强制启用android:usesCleartextTraffic需在AndroidManifest里显式声明2019.4.37f129 (Android 10)r21dgradle-6.7.14.1.0支持ARM64原生库自动分离解决部分设备闪退问题特别注意NDK版本Unity 2019.4默认NDK路径是Android/Sdk/ndk-bundle但r21d之后NDK改用Android/Sdk/ndk/21.4.7075529这样的语义化路径。如果你手动下载了r21d必须在Unity Preferences → External Tools → NDK Path里精确指向到21.4.7075529这个子目录而不是父级ndk目录否则Unity会报“NDK not found”。另外NDK r21d开始废弃了arm-linux-androideabi-gcc全面转向aarch64-linux-android-clang这意味着你自定义的C插件如果还用GCC编译必须重写Makefile。2.4 Gradle构建缓存机制与清理策略Gradle的构建缓存~/.gradle/caches/是双刃剑首次构建慢后续快但一旦缓存损坏会导致“class not found”或“duplicate class”这类玄学错误。我们遇到过最典型的案例某团队在2019.4.12f1里集成一个支付SDK构建成功升级到2019.4.37f1后Gradle报错Could not resolve com.google.android.material:material:1.1.0而该依赖明明在build.gradle里声明了。排查发现旧版Gradle缓存里存着material:1.0.0的二进制新版Gradle尝试解析1.1.0时缓存索引错乱导致依赖树断裂。解决方案不是删整个缓存那要重下2GB依赖而是精准清理进入Temp/gradleOut/目录Unity生成的临时工程根目录执行gradlew --stop停止所有Gradle守护进程删除Temp/gradleOut/.gradle/目录仅删这个不影响全局缓存在Unity里勾选“Custom Gradle Template”Player Settings → Publishing Settings → Build让Unity重新生成build.gradle模板避免旧模板残留的maven { url https://jitpack.io }等已失效仓库。注意勾选“Custom Gradle Template”后Unity会在Assets/Plugins/Android/mainTemplate.gradle生成一份可编辑的模板你可以在这里安全地添加repositories { mavenCentral() }或排除冲突模块比如configurations.all { exclude group: com.android.support, module: support-v4 }。3. 核心配置与实操步骤从零搭建可复现的安卓构建环境3.1 环境初始化五步完成纯净构建基线我们设计了一套“五步归零法”确保每次构建都在已知状态下开始避免环境污染第一步卸载所有非必要JDK控制面板 → 卸载程序 → 删除所有JDK 7、JDK 8除8u291外、JDK 12。只保留JDK 11.0.12LTS版安装时取消勾选“Public JRE”避免PATH污染。第二步重置Android SDK路径删除Android/Sdk整个目录从Android Studio官网下载最新Command line tools如sdk-tools-windows-4333796.zip解压到空文件夹运行sdkmanager --install platform-tools platforms;android-29 build-tools;29.0.3 ndk;21.4.7075529在Unity Preferences → External Tools里全部重新指定路径SDK指向Android/SdkNDK指向Android/Sdk/ndk/21.4.7075529JDK指向JDK 11.0.12。第三步创建专用Keystore不要用Unity自动生成的debug.keystore生产环境必须用正式签名keytool -genkeypair -v -storetype PKCS12 -keystore my-release-key.keystore -alias alias_name -keyalg RSA -keysize 2048 -validity 10000在Player Settings → Publishing Settings里填入Keystore:my-release-key.keystore的绝对路径Keystore password: 创建时设的密码Key alias:alias_nameKey password: 同Keystore密码或单独设提示Key alias必须小写且不含空格否则Gradle会报Invalid key alias。第四步配置Player Settings关键参数Other Settings → Identification → Package Name: 必须符合Java包名规范如com.companyname.appname且与Google Play注册的包名完全一致Other Settings → Target API Level: 设为Android 10 (API Level 29)这是2019.4的推荐值Publishing Settings → Build → Custom Gradle Template: ✅ 勾选启用可编辑模板Publishing Settings → Build → Minify: Release模式下务必勾选否则APK体积暴增50%且可能被反编译。第五步验证Gradle模板完整性打开Assets/Plugins/Android/mainTemplate.gradle确认以下三处存在android.useAndroidXtrue和android.enableJetifiertrue在gradle.properties里buildFeatures { viewBinding true }在android块内支持ViewBinding插件dependencies { implementation androidx.appcompat:appcompat:1.2.0 }在dependencies块内强制使用AndroidX。如果缺失手动补全——这是防止support库与AndroidX冲突的最后防线。3.2 ARM64架构适配为什么你的游戏在三星S21上闪退Unity 2019.4默认只生成ARMv732位库而Android 11设备如三星S21、小米11强制要求64位应用。如果你的APK里没有lib/arm64-v8a/libunity.so用户安装后点开就闪退Logcat里只有一行FATAL EXCEPTION: main Process: com.xxx, PID: 12345 java.lang.UnsatisfiedLinkError: dlopen failed: library libunity.so not found。解决方案分三步第一步在Player Settings → Other Settings → Configuration → Scripting Backend必须选IL2CPPMono后端不支持ARM64第二步在Player Settings → Other Settings → Target Architectures勾选ARM64ARMv7可选但建议同时勾选以兼容旧设备第三步在Build Settings里勾选Development Build暂时关闭因为Development Build会禁用IL2CPP的64位优化导致生成的so文件不完整。实测数据某FPS Demo在勾选ARM64后APK体积从42MB增至68MB增加26MB但三星S21安装成功率从0%升至100%。额外收益是ARM64指令集让物理计算速度提升17%这是Unity官方白皮书里没写的隐藏性能红利。3.3 Minify混淆配置保护代码不被反编译的实操细节Unity 2019.4的Minify基于R8Google官方混淆器比旧版ProGuard更激进。默认配置会误杀反射调用的类导致JsonUtility.FromJsonT失败或Resources.Load返回null。我们必须在mainTemplate.gradle里定制规则android { buildTypes { release { minifyEnabled true useProguard false // 强制用R8 proguardFiles getDefaultProguardFile(proguard-android-optimize.txt), proguard-unity.txt } } }然后在Assets/Plugins/Android/proguard-unity.txt里添加# 保留Unity核心类 -keep class com.unity3d.** { *; } -keep class android.** { *; } # 保留JsonUtility序列化的类按你的命名空间修改 -keep class com.companyname.game.** { *; } -keepclassmembers class com.companyname.game.** { public fields; public methods; } # 保留Resources.Load加载的AssetBundle名避免被混淆成a.b.c -keep class com.companyname.game.AssetBundleName { *; }关键点在于-keep class保留整个类-keepclassmembers只保留字段和方法后者更安全。我们曾有个项目因漏写-keepclassmembers导致角色动画控制器里的Animator参数名被混淆游戏里角色永远僵直不动——Logcat里没有任何错误只有Animator: Parameter speed not found这一行被淹没在千行日志里。3.4 AndroidManifest合并冲突解决三招定位插件打架当集成5个以上插件如Facebook SDK、Firebase Analytics、OneSignal时AndroidManifest.xml合并几乎必然失败。Unity的合并逻辑是以Assets/Plugins/Android/AndroidManifest.xml为base叠加所有插件里的AndroidManifest.xml。冲突类型有三类型一权限重复声明插件A声明uses-permission android:nameandroid.permission.INTERNET/插件B也声明。Gradle会报Attribute uses-permission#android:name conflict。解决方案在base manifest里用tools:replaceandroid:name但更稳妥的是删除所有插件里的重复权限声明只在base里留一份。类型二Activity/Provider authority冲突插件A的provider android:authoritiescom.xxx.fileprovider和插件B的provider android:authoritiescom.yyy.fileprovider在合并时Gradle会报Attribute provider#android:authorities conflict。这是因为Unity强制所有provider用同一个authority解决方案是在mainTemplate.gradle里添加android { defaultConfig { applicationId com.companyname.appname // 强制所有provider用统一authority manifestPlaceholders [androidAuthority: ${applicationId}.fileprovider] } }然后在每个插件的AndroidManifest里把android:authorities值改为${androidAuthority}。类型三Application类冲突插件A要求继承com.facebook.FacebookApplication插件B要求继承io.fabric.unity.android.FabricApplication。Unity只允许一个Application类。终极方案是写一个代理Application// Assets/Plugins/Android/src/com/companyname/ProxyApplication.java package com.companyname; import android.app.Application; import com.facebook.FacebookSdk; import io.fabric.sdk.android.Fabric; public class ProxyApplication extends Application { Override public void onCreate() { super.onCreate(); FacebookSdk.setApplicationId(your-app-id); Fabric.with(this, new Crashlytics()); } }然后在base manifest里声明application android:name.ProxyApplication。这样所有插件的初始化逻辑都收口到一个类里可控性大幅提升。4. 构建失败诊断与高频问题速查表4.1 Gradle构建失败从日志定位根因的三层次分析法当Unity Console显示“Gradle build failed”时别急着百度错误关键词。我们用三层次法快速定位第一层看Unity Console最后一行红字例如CommandInvokationFailure: Gradle build failed.这只是表象真正的线索在它下面的堆栈里。重点找以stderr[开头的行比如stderr[ D8: Program type already present: android.arch.core.internal.SafeIterableMap$IteratorWithAdd]这说明D8R8的前身在合并类时发现重复——android.arch.core.internal.SafeIterableMap$IteratorWithAdd这个类被两个不同版本的android.arch.core库同时提供。第二层查Temp/gradleOut/launcher/build/reports/dependency-tree/里的release.txt用文本编辑器打开它搜索SafeIterableMap你会看到--- androidx.lifecycle:lifecycle-viewmodel:2.0.0 | \--- androidx.arch.core:arch-core-common:2.0.0 \--- com.android.support:support-core-utils:28.0.0 \--- com.android.support:support-compat:28.0.0 \--- androidx.arch.core:arch-core-common:2.0.0原来support库和AndroidX库都提供了同名类但版本号不同28.0.0 vs 2.0.0。第三层用./gradlew app:dependencies --configuration releaseRuntimeClasspath命令深挖进入Temp/gradleOut/目录执行该命令输出会显示完整的依赖树找到冲突源头的插件名如com.someplugin:sdk:1.2.3然后在mainTemplate.gradle里排除它configurations.all { exclude group: com.android.support, module: support-core-utils exclude group: androidx.arch.core, module: arch-core-common }实操心得我们给团队定了一条铁律——任何Gradle错误必须先跑./gradlew app:dependencies再决定怎么改。跳过这步直接改gradle.properties90%会引入新问题。4.2 APK安装失败ADB日志里的真相Unity显示“Build completed”但手机安装时提示“Parse error”或“App not installed”。这时必须用ADB抓日志adb install -r your-app.apk # 如果失败立即执行 adb logcat -d | findstr PackageManager典型错误及对策ADB日志关键词根本原因解决方案INSTALL_FAILED_NO_MATCHING_ABISAPK里没有当前CPU架构的so库检查Player Settings → Target Architectures是否勾选了设备对应的架构ARM64设备必须有arm64-v8aINSTALL_PARSE_FAILED_NO_CERTIFICATESAPK未签名或签名损坏重新生成Keystore或在Player Settings里确认Keystore路径正确密码无误INSTALL_FAILED_CONFLICTING_PROVIDER两个APP用了相同的ContentProvider authority在AndroidManifest里为provider添加android:authorities${applicationId}.fileprovider确保唯一性INSTALL_FAILED_DEXOPTAndroid 5.0以下设备Dex优化失败降低Minify强度或在proguard-unity.txt里添加-dontoptimize特别提醒华为鸿蒙OS 2.0设备对android:exported属性极其敏感。Android 12要求所有activity、service、receiver必须显式声明android:exportedtrue/false否则安装直接失败。解决方案是在base AndroidManifest里为所有组件补全该属性activity android:name.MainActivity android:exportedtrue intent-filter action android:nameandroid.intent.action.MAIN / category android:nameandroid.intent.category.LAUNCHER / /intent-filter /activity4.3 运行时崩溃Logcat里找崩溃点的黄金组合APK能安装但一打开就闪退Logcat是唯一真相源。我们固定用这组命令# 清空日志缓冲区 adb logcat -c # 实时过滤Unity相关崩溃 adb logcat -s Unity ActivityManager AndroidRuntime # 或更精准地过滤你的包名 adb logcat | findstr com.companyname.appname高频崩溃场景及修复场景一java.lang.UnsatisfiedLinkError: dalvik.system.PathClassLoader这是so库加载失败的通用错误。根源可能是so库名字拼写错误如libMyPlugin.so写成libmyplugin.soLinux区分大小写so库放在了错误目录必须在Assets/Plugins/Android/libs/arm64-v8a/不能放在Assets/Plugins/Android/根目录so库编译时用了不兼容的NDK版本如用NDK r23编译的so在NDK r21d环境下加载失败。场景二NullReferenceException: Object reference not set to an instance of an object看起来是C#代码问题但2019.4里常因Minify混淆导致。比如public class PlayerData { public string name; public int level; } // JsonUtility.FromJsonPlayerData(json) 返回null因为level字段被混淆成a解决方案在proguard-unity.txt里添加-keep class com.companyname.PlayerData { *; }。场景三E/Unity: Unable to find AudioPluginMsHRTF这是Unity 2019.4的音频插件加载bug不影响功能但刷屏日志。解决方案在Player Settings → Other Settings → Configuration → Audio → Disable Audio Plugins把MsHRTF插件禁用即可。4.4 网络请求失败Cleartext Traffic与HTTPS强制策略Android 9默认禁止明文HTTP请求如果你的游戏用WWW或UnityWebRequest访问http://api.example.comLogcat会报Cleartext HTTP traffic to api.example.com not permitted这不是Unity的bug而是Android系统的安全策略。解决方案有二方案一推荐全站升级HTTPS联系后端把API域名切到HTTPSUnity代码里把http://改成https://。这是最彻底的解法。方案二临时允许HTTP仅测试用在base AndroidManifest的application标签里添加android:usesCleartextTraffictrue但注意Google Play从2021年11月起拒绝接受android:usesCleartextTraffictrue的APK所以此方案仅限本地调试。踩坑记录某团队为赶工期在AndroidManifest里加了android:usesCleartextTraffictrue测试通过后忘了删结果APK被Google Play拒审三次。后来我们定了个自动化检查在CI流程里用aapt dump xmltree your-app.apk AndroidManifest.xml | findstr cleartext命中即失败。5. 生产环境构建流水线从手动点击到CI/CD的平滑迁移5.1 Unity命令行构建脱离编辑器的自动化基石手动点Build只能应付小项目量产必须用命令行。Unity 2019.4的命令行构建语法是Unity.exe -batchmode -nographics -silent-crashes -logfile build.log -projectPath C:\MyProject -executeMethod Builder.BuildAndroid -buildTarget Android -buildPath C:\MyProject\Builds\app-release.apk其中-executeMethod Builder.BuildAndroid调用的是C#静态方法// Assets/Editor/Builder.cs using UnityEditor; public class Builder { public static void BuildAndroid() { string[] scenes {Assets/Scenes/Main.unity}; string targetPath Builds/app-release.apk; // 强制设置PlayerSettings避免依赖UI操作 PlayerSettings.Android.targetArchitectures AndroidArchitecture.ARM64 | AndroidArchitecture.ARMv7; PlayerSettings.Android.minSdkVersion AndroidSdkVersions.AndroidApiLevel28; PlayerSettings.Android.targetSdkVersion AndroidSdkVersions.AndroidApiLevel29; BuildPipeline.BuildPlayer(scenes, targetPath, BuildTarget.Android, BuildOptions.None); } }关键点PlayerSettings的所有参数必须在代码里显式设置不能依赖Unity Editor里的UI状态否则CI服务器上构建会用默认值如只生成ARMv7。5.2 Jenkins集成三步搭建无人值守构建机我们用Jenkins Windows Server 2019搭建了稳定运行2年的构建机配置要点第一步安装Unity Hub CLI在Jenkins节点上安装Unity Hub然后用hub --version验证。Unity Hub CLI能自动管理多版本Unity比硬编码Unity.exe路径更可靠。第二步配置Jenkins JobSource Code Management: Git指定分支如release/2019.4Build: Execute Windows batch commandecho off set UNITY_PATHC:\Program Files\Unity\Hub\Editor\2019.4.37f1\Editor\Unity.exe set PROJECT_PATHC:\Jenkins\workspace\MyGame set BUILD_PATHC:\Jenkins\workspace\MyGame\Builds %UNITY_PATH% -batchmode -nographics -silent-crashes -logfile %BUILD_PATH%\build.log -projectPath %PROJECT_PATH% -executeMethod Builder.BuildAndroid -buildTarget Android -buildPath %BUILD_PATH%\app-release.apk if %ERRORLEVEL% NEQ 0 ( echo Build failed! exit /b %ERRORLEVEL% )第三步构建后处理归档APKArchive the artifacts: Builds/*.apk发送企业微信通知用Jenkins插件WeCom Notifier推送构建结果和APK下载链接自动上传Google Play用google-play-deploy插件配置Service Account密钥。实操心得Jenkins节点必须用Windows服务方式运行而非当前用户登录否则Unity GUI线程会卡死。我们吃过亏——某次更新Jenkins后构建机在Building Library阶段挂住重启服务才恢复。5.3 构建产物验证清单发布前的最后十道关卡一个APK从构建完成到上架必须过这十关缺一不可签名验证jarsigner -verify -verbose -certs app-release.apk | findstr sm输出含sm表示已签名架构检查aapt list app-release.apk | findstr lib/arm64-v8a/libunity.so必须存在API等级验证aapt dump badging app-release.apk | findstr targetSdkVersion应为targetSdkVersion29权限精简aapt dump permissions app-release.apk对比需求删除多余权限如ACCESS_FINE_LOCATION资源压缩用zip -sf app-release.apk查看APK内各文件大小纹理资源应占70%以上代码类.so、.jar应15%启动时间测试在真机上用adb shell am start -W com.companyname.appname/.MainActivity冷启动时间1.5秒内存占用adb shell dumpsys meminfo com.companyname.appname | findstr TOTAL首屏后内存150MB网络请求测试用Charles抓包确认所有请求走HTTPS无HTTP明文崩溃率监控集成Firebase Crashlytics发布后24小时内崩溃率0.5%Google Play预检上传到Play Console的Internal Testing轨道等待Google自动扫描通过后再推到Production。这套清单我们迭代了17个版本现在团队新人入职第一天就要背熟。它把模糊的“感觉差不多”变成了可量化的“十项全绿”这才是工业化开发的底气。6. 长期维护策略如何让2019.4项目在未来三年持续可用Unity 2019.4的LTS支持到2022年9月但我们的项目要活到2025年。为此我们制定了三条生存法则法则一冻结Gradle生态不追新绝不升级AGP和Gradle版本哪怕新版本宣称“更快更稳”。我们实测过把AGP从3.4.3升到4.1.0构建时间从217秒降到192秒但引入了androidx.core:core-ktx的版本冲突修复耗时16小时。结论稳定压倒一切用gradle-5.1.1AGP 3.4.3组合