核心内容摘要
Excel邮件合并嵌入图片技巧
做 Unity Android 包你肯定遇到过这两个按钮/选项直接在 Unity 里 BuildUnity 内部调用 Gradle咔咔一顿跑吐出 APK/AABExport Project导出 Gradle 工程Unity 给你一个 Android Studio 能打开的工程让你自己再用 Gradle 打包表面看这就是“一个省事、一个麻烦”。
但真上项目、真接 SDK、真做多渠道你会发现它俩像两条平行宇宙有时候 Unity 内部能打包导出工程反而报错有时候导出工程一切正常Unity 内部打包却各种玄学有时候你只改了一个mainTemplate.gradle结果 Unity 内部没生效有时候你明明在 Android Studio 里改好了回到 Unity 又全没了被覆盖所以这篇文章咱们就用大白话把它讲透它俩到底区别在哪联系是什么各自适合什么场景大厂怎么用你怎么选不踩坑读完你应该能做到知道什么时候必须导出什么时候不需要知道 Unity 内部 Gradle 打包到底生成了啥知道模板mainTemplate.gradle 等在两种模式下如何生效知道多人协作、CI、渠道包下该怎么组织知道最常见坑怎么定位依赖冲突、manifest 合并、Gradle 版本、签名、混淆
先把话说得直白这俩模式的核心区别是“你接管程度不同”你可以把它理解成两种装修方式Unity 内部 Gradle 打包你把房子交给“装修公司Unity”你只能在它给的几个地方改点东西模板、设置项然后它帮你全包导出 Gradle 工程装修公司把“毛坯房工程”交给你你自己找水电工、木工、油漆工Android Studio/Gradle想怎么改怎么改所以区别不是 Gradle 本身——两者最终都是 Gradle。
区别是Gradle 工程由谁掌控、由谁生成、谁说了算。
它们的联系本质上是同一条生产线只是“是否把中间产物交给你”很多同学以为这是两套完全不同的构建方式。
其实不是。
无论你选哪个Unity 都会做相同的一堆前置工作把你的 C# 编译成 IL2CPP 或 Mono 产物生成 Android 工程结构launcher/unityLibrary 或旧版结构合并Assets/Plugins/Android下的 AAR/JAR、资源、Manifest 片段根据 Player Settings 填充包名、版本号、符号表等最终交给 Gradle 去assemble或bundle区别就在最后一步内部打包Unity 生成工程后直接在后台跑 Gradle然后把工程临时文件夹删掉或藏起来导出工程Unity 生成工程后把它保存在你指定目录让你自己去跑 Gradle大白话两者就像做包子Unity 都负责和面、拌馅、包好。
内部打包是它顺便帮你蒸好导出工程是它把生包子交给你你自己蒸想蒸多久、用多大火都行。
直接 Unity 内部 Gradle 打包优点是“快、省事、适合日常”缺点是“可控性有限”
1 内部打包的优点为什么大家都爱用优点 1开发效率高一键 Build少切工具很适合日常迭代、联调、提测包优点 2团队门槛低新人不需要懂太多 Android Studio、Gradle 配置上手快。
优点 3Unity 版本兼容性更好相对Unity 自己管理一些 Gradle、NDK、JDK 的默认组合当然也会翻车但整体更“傻瓜”。
2 内部打包的缺点真正大坑在这里缺点 1很多改动会被 Unity 重生成覆盖你如果在导出的临时工程里手改build.gradle下次 Build Unity 又重新生成等于白改。
缺点 2排查依赖冲突不直观比如Duplicate class你很想看依赖树gradlew dependencies。
内部打包也能看但路径难找、改动不方便。
缺点 3有些 SDK 要求的 Gradle 深度定制不好做比如加自定义 Gradle plugin改settings.gradle改gradle.properties多 module 工程、引入本地 module内部打包能做一部分通过 templates但遇到复杂需求会很别扭。
缺点 4构建环境受 Unity 限制比如 Unity 内置的 Gradle 版本/AGPAndroid Gradle Plugin组合有时跟你想用的不一致。
大白话内部打包像用电饭煲按一下就煮饭省心。
但你想做“炭火煲仔饭、火候分段、加料顺序”就难受。
导出 Gradle 工程优点是“可控、可调、可排坑”缺点是“流程重、容易被你玩坏”
1 导出工程的优点大厂为什么爱导出优点 1可视化、可调试、可查依赖树你能在 Android Studio 里看Gradle Dependencies跑dependencyInsight看 manifest merge 报告看资源冲突来源用adb logcat配合 source 定位用 build scan如果你会这对解决 AndroidX/Kotlin/Play Services 大乱斗特别关键。
优点 2可以做深度定制比如强制版本对齐resolutionStrategy引入自定义 Gradle 插件做多 flavor渠道包、地区包对接自动化签名、上传、mapping 管理处理 AAB、split、packagingOptions这些在导出工程里更自由。
优点 3更适合 Android 原生同学介入很多公司 Unity 客户端不一定懂 Gradle但 Android 同学一看导出工程就能帮你排坑。
2 导出工程的缺点别以为它完美缺点 1流程变长你 build 一次要Unity 导出一次Android Studio 同步 Gradle一次再 assemble/bundle一次频繁迭代很耗时间。
缺点 2你“手改工程”会造成不可复现经典翻车某个人在导出工程手点改了设置、能跑了但这些改动没回到 Unity 模板里别人导出就没了。
所以导出工程适合“排坑与验证”但最终改动最好固化到 Unity 的模板/脚本里。
缺点 3Unity 继续迭代时你得反复导出Unity 工程一变导出工程就旧了。
你要么重新导出覆盖要么手动同步改动很容易乱。
大白话导出工程像你自己开厨房想怎么做都行但你得洗菜切菜刷锅流程就是重。
更坑的是你改了厨房布局没写到装修图纸里下次装修队一来全给你还原了。
两者在“模板系统”上的关系关键在mainTemplate.gradle等文件是否启用Unity 为了让内部打包也能定制 Gradle提供了模板文件不同 Unity 版本细节略有差异常见模板包括mainTemplate.gradle主要依赖和 android 配置launcherTemplate.gradlebaseProjectTemplate.gradlegradleTemplate.propertiessettingsTemplate.gradleproguard-user.txt/proguard配置
1 内部打包模板是“你唯一的合法改造口”你想加依赖、加 maven 仓库、加 packagingOptions、加 resolutionStrategy主要靠模板。
2 导出工程模板 手改都可以但最终要回写模板导出工程你当然可以手改但正确姿势是用导出工程定位问题、验证方案然后把改动回写到 Unity 模板或 PostProcessBuild 脚本确保下次导出/内部打包也一致大白话模板就是“装修图纸”。
导出工程里手改相当于“现场临时加一堵墙”。
能救急但不改图纸下次又没了。
场景化对比到底什么时候用哪个最实用的一段下面用最常见的业务场景来选模式。
1 日常开发、功能联调、小版本提测建议Unity 内部 Gradle 打包原因快、够用、成本低。
2 新接 SDK、出现依赖冲突、manifest 合并冲突、资源冲突建议导出 Gradle 工程原因需要看依赖树、合并报告需要 Android Studio 强力工具链需要快速定位“是谁引入的冲突”
3 做多渠道、多 flavor、多环境国内渠道包那种两种路线如果你团队 Android 能力强、渠道体系复杂长期维护导出工程或基于导出工程做二次工程如果你希望仍以 Unity 为主、渠道逻辑简单内部打包 模板 自动化脚本大厂常见做法是Unity 负责生成基础工程CI 导出后再由脚本注入渠道 flavor 并构建也就是“混合路线”。
4 需要接入复杂 Gradle 插件如某些大厂质量/加固/热修复体系建议导出工程或混合路线因为这些东西往往要动 settings.gradle、buildscript、甚至多模块结构。
5 打 AAB、做拆包ABI split、density split、精细控制 packagingOptions建议简单拆分内部打包也能做模板支持复杂拆分 多模块导出更方便
最常见误区把导出工程当成“最终工程”长期手改大概率翻车很多团队一开始导出工程手改到能跑然后就一直在这个导出工程上加功能。
等 Unity 侧要升级版本、要改资源、要换 IL2CPP 选项时发现同步成本爆炸。
更好的模式大厂常用是Unity 是源头source of truth导出工程是“构建产物artifact”导出工程的修改要脚本化/模板化能自动重放大白话别把“烤好的面包”当成“面粉仓库”。
面包可以吃、可以研究口感但配方得回到仓库保存。
“联系”再讲深一点两者的差异常常来自 Unity 生成细节而不是 Gradle为什么你会遇到内部打包能过导出工程不过或导出工程能过内部打包不过常见原因不是 Gradle 玄学而是
1 模板未启用或模板版本不一致你以为改了mainTemplate.gradle但其实 Unity 没勾选“Custom Gradle Template”。
或者 Unity 版本升级后模板结构变了你改的位置不对。
2 导出工程的 module 名称/结构不同Unity 新版本常见launcherunityLibrary。
你脚本/命令跑错模块看错依赖树就以为不一致。
3 JDK/Gradle/AGP 版本组合不同Unity 内部可能带一套 JDK/Gradle导出工程你用 Android Studio 的又是另一套。
同一份工程不同工具链结果当然不同。
4 缓存导致差异Gradle 缓存、Unity Library 缓存、EDM4U 缓存都可能让你“看起来改了其实没生效”。
最佳实践大厂通常怎么“同时用好两种模式”大厂很少“二选一”更像这样
1 开发期内部打包为主保证效率大部分时间一键出包模板、依赖声明、插件管理都在 Unity 工程里
2 集成期/排坑期导出工程做诊断和验证依赖冲突、manifest 合并冲突、Kotlin/AndroidX 大乱斗时导出工程开 Android Studio 查用dependencyInsight、manifest merge report、Gradle scan 定位
3 固化期把“导出工程里的修复”写回模板/脚本确保以后内部打包也稳定确保 CI 可重复构建避免“只在某个导出工程上能跑”的局面
4 CI多采用“导出 构建”的混合流水线CI 常见流程Unity batchmode 导出工程在导出工程上执行脚本注入渠道/环境配置Gradle assemble/bundle收集 mapping、symbols、日志上传制品这种方式最可控也方便做渠道包矩阵。
大白话内部打包像你平时在家做饭快。
导出工程像你开餐厅备菜麻烦但标准化。
大厂的策略是家里怎么方便怎么来餐厅必须流程化。
给你一个“选择指南”一句话决策树你可以用这个快速判断只是想出个测试包→ 内部打包出现 Duplicate class / 依赖冲突→ 导出工程要看依赖树、做版本对齐、排除依赖→ 导出工程要做复杂渠道、多 flavor、多模块→ 导出工程或混合要把修复长期稳定下来→ 回写模板/脚本不要只手改导出工程团队里 Android 同学要介入→ 导出工程最友好
结语它俩不是对立关系而是“快刀”和“手术刀”最后用一句话收尾Unity 内部 Gradle 打包是快刀适合日常砍瓜切菜导出 Gradle 工程是手术刀适合开胸找病灶。
聪明的团队不是选一个而是把两者当成“不同场景下的两把工具”。