1. 项目概述为什么我们需要自动化构建在Unity游戏开发团队里打包这件事说多了都是泪。我见过太多项目每次出包都像一场小型战役美术同学在群里催着要测试包程序同学得停下手中的开发手动打开Unity切换平台检查构建设置点击“Build”然后盯着进度条祈祷不要报错。如果项目有多个分支比如开发分支、测试分支、线上分支或者需要同时打Android、iOS、Windows三个平台的包那这个流程就得重复好几遍一两个小时就这么耗进去了。更别提偶尔手滑选错构建设置或者忘记更新版本号导致打出来的包不能用又得重来一遍。“Unity自动化构建批处理脚本完整解决方案”这个标题直指的就是这个痛点。它的核心目标就是用脚本和工具链把我们从这种重复、繁琐、易错的手动打包工作中彻底解放出来。这不仅仅是“偷懒”更是提升团队协作效率、保证构建质量、实现持续集成/持续交付CI/CD的基石。想象一下美术提交资源后测试同学可以随时在Jenkins上点一下半小时后就能拿到一个包含最新资源、版本号自动递增的安装包这能省下多少沟通成本和等待时间。这个方案的核心是围绕“批处理脚本”展开的。它不依赖于某个特定的、昂贵的商业CI/CD服务而是基于Jenkins这类开源、可高度定制的自动化服务器结合Groovy脚本一种运行在JVM上的灵活脚本语言和Unity自身的命令行接口Command Line Interface, CLI搭建一套属于自己团队的、可维护、可扩展的自动化流水线。无论是独立开发者还是中小型团队都能基于此构建出适合自己工作流的自动化方案。2. 自动化构建的核心价值与设计思路2.1 自动化构建解决了哪些实际问题在深入技术细节之前我们先明确一下一套好的自动化构建系统到底能带来什么。从我多年的项目经验来看其价值主要体现在以下几个方面解放人力提升效率这是最直接的好处。将打包工作交给机器让开发者能专注于更有创造性的编码和调试工作。特别是对于需要频繁出包如每日构建、功能测试包的项目效率提升是指数级的。保证一致性减少人为错误手动操作难免出错比如忘记切换构建设置、填错版本号、漏选某个场景。自动化脚本每次都以完全相同的方式执行确保了每次构建产出的环境和结果都是一致的极大提升了交付物的可靠性。实现持续集成CI自动化构建是CI的第一步。它可以与版本控制系统如Git、SVN集成在代码提交后自动触发构建和基础测试快速发现集成错误实现“快速失败快速修复”。便于多环境、多平台管理一个项目往往需要为开发、测试、预发布、生产等不同环境以及Android、iOS、PC等不同平台出包。自动化系统可以通过参数化构建轻松管理这些复杂的矩阵一键生成所有需要的包体。构建过程可追溯自动化系统会记录每一次构建的日志、参数、代码版本和产出物。当某个版本出现问题时可以快速回溯到具体的构建任务查看当时的日志定位问题是出在代码、资源还是构建环境上。2.2 方案选型为什么是Jenkins Groovy Unity CLI市面上CI/CD工具很多比如GitLab CI、GitHub Actions、TeamCity等。为什么这个方案选择了Jenkins这背后有非常实际的考量。Jenkins的优势在于其极致的灵活性和可控性。它是一个开源、自托管的自动化服务器拥有海量的插件生态。这意味着完全自主你可以将它部署在内网的任何服务器上所有构建数据和流程都掌握在自己手中无需担心网络问题或第三方服务变更。高度定制通过Pipeline流水线和Groovy脚本你可以描述从代码拉取、编译、测试到打包、部署的整个复杂流程几乎没有任何限制。成本低廉对于预算有限的团队或独立开发者Jenkins的免费和开源特性是巨大的吸引力。Groovy脚本作为Jenkins Pipeline的DSL领域特定语言比传统的图形化配置更强大。它允许你将构建流程以代码的形式进行版本管理修改和回滚就像管理普通代码一样方便。这对于维护多个相似但略有不同的构建任务如不同分支、不同平台至关重要。Unity CLI是Unity引擎提供的命令行工具是自动化构建的基石。它允许你通过执行命令如Unity.exe -batchmode -quit -projectPath ... -executeMethod ...来以“静默”模式运行Unity编辑器执行指定的C#静态方法从而完成编译、打包等所有在编辑器内能完成的操作。这避免了启动图形界面节省了大量资源和时间。这个组合Jenkins作为调度和展示平台Groovy描述流程Unity CLI执行核心构建形成了一个稳定、可靠且易于扩展的技术栈特别适合对构建流程有定制化需求的游戏开发团队。3. 环境准备与核心工具链搭建在开始编写脚本之前我们必须先把“舞台”搭好。这个阶段的工作看似琐碎但却是整个自动化系统稳定运行的基石。一个配置不当的环境会让后续所有脚本都变得脆弱不堪。3.1 Unity编辑器与模块安装首先确保你的Unity编辑器版本符合项目要求。对于自动化构建机我强烈建议安装Unity Hub并通过它来管理不同版本的Unity编辑器。构建机通常只需要一个稳定的LTS长期支持版本比如2022.3.x。关键步骤安装目标版本Unity通过Unity Hub安装指定版本。记住安装路径后续脚本中会用到。安装必要的平台支持模块这步至关重要仅仅安装Unity本体是不够的。你需要根据打包目标平台在Unity Hub的安装界面勾选对应的模块。打Android包必须安装Android Build Support通常包含SDK、NDK和OpenJDK。虽然脚本中可以指定外部SDK但安装这个模块能确保环境基本完整。打iOS包在macOS上必须安装iOS Build Support。打Windows/Mac/Linux Standalone包如果项目使用IL2CPP后端特别是HybridCLR热更新方案必须安装对应平台的IL2CPP支持模块。Mono后端则不需要。验证安装安装完成后最好手动打开一次该版本的Unity确保能正常启动并创建项目这可以排除一些基础环境问题。注意构建机上的Unity版本、模块安装情况必须与项目开发所用的环境保持一致。否则可能出现“在开发机上能打包在构建机上失败”的诡异问题。建议将Unity版本号写入项目根目录的ProjectSettings/ProjectVersion.txt文件并在构建脚本中做一致性检查。3.2 Android SDK/NDK/JDK环境配置Android打包是环境配置的“重灾区”。Unity虽然自带了一套但为了灵活性和统一管理我们通常使用独立安装的SDK/NDK。下载与安装JDKUnity 2022 通常需要JDK 11或更高版本注意不是JRE。可以从Adoptium或Oracle官网下载。Jenkins本身也需要JDK建议使用同一个版本以避免冲突。Android SDK推荐通过Android Studio下载或者直接下载命令行工具包。关键是要获取platform-tools和build-tools。Android NDKUnity对NDK版本有特定要求。最稳妥的方法是在Unity编辑器中打开Edit - Preferences - External Tools查看它推荐的NDK版本然后去官网下载对应版本。环境变量配置JAVA_HOME指向你的JDK安装目录例如C:\Program Files\Eclipse Adoptium\jdk-11.0.xx。ANDROID_HOME或ANDROID_SDK_ROOT指向你的Android SDK根目录。将%JAVA_HOME%\bin、%ANDROID_HOME%\platform-tools、%ANDROID_HOME%\tools\bin添加到系统的PATH环境变量中。在Unity中指定路径即使配置了环境变量也建议在Unity编辑器的Preferences - External Tools中显式地设置SDK、NDK、JDK的路径。因为Unity CLI在批处理模式下有时读取环境变量会不太稳定显式指定是最可靠的。实操心得我习惯在构建服务器上创建一个专门的目录如D:\BuildTools将JDK、Android SDK、NDK都安装或解压到此目录下。这样路径清晰也方便备份和迁移。同时我会写一个简单的批处理脚本 (check_env.bat) 来验证环境echo off echo Checking Java... java -version echo. echo Checking Android SDK... where adb echo. echo Checking Unity... # 这里假设Unity安装路径已加入PATH或者使用绝对路径 C:\Program Files\Unity\Hub\Editor\2022.3.20f1\Editor\Unity.exe -version3.3 Jenkins的安装与基础配置Jenkins是我们的自动化指挥中心。它的安装相对简单但初始配置有几个坑点需要注意。获取与启动从Jenkins官网下载最新的jenkins.war文件Generic Java package。准备JDK环境同上需要JDK 11不能用JDK 8。在jenkins.war所在目录打开终端执行启动命令。为了处理可能的中文路径或日志编码问题最好指定编码# Windows (CMD) set JAVA_TOOL_OPTIONS-Dfile.encodingUTF-8 java -jar jenkins.war # macOS/Linux JAVA_TOOL_OPTIONS-Dfile.encodingUTF-8 java -jar jenkins.war初始访问与插件安装浏览器访问http://localhost:8080输入初始管理员密码在启动日志中查找。在插件安装页面选择“安装推荐的插件”。这会安装包括Git、Pipeline在内的许多基础插件省去后续手动查找的麻烦。关键系统配置管理员账户创建第一个管理员用户妥善保管密码。Jenkins URL将默认的http://localhost:8080改为你的构建服务器在内网的IP地址例如http://192.168.1.100:8080这样团队其他成员才能访问。全局工具配置虽然我们主要用系统环境变量但在这里配置JDK、Git等路径也是一个好习惯。全局安全配置重中之重进入Manage Jenkins - Security - Security。找到Access Control for Builds部分需要先安装Authorize Project插件。将策略设置为Run as specific user并指定一个系统用户如SYSTEM或具有必要权限的账户同时勾选Use Groovy Sandbox。这个设置允许Pipeline脚本以沙盒模式安全运行是后续使用Job DSL插件批量创建任务的前提。很多初学者卡在这里就是因为脚本没有执行权限。4. 核心脚本解析从Unity命令到完整流水线自动化构建的灵魂在于脚本。我们将拆解三个核心部分驱动Unity的批处理命令、组织构建流程的Groovy Pipeline脚本以及用于批量创建任务的Job DSL脚本。4.1 Unity命令行构建的核心参数与原理Unity的命令行接口功能非常强大。一个最基本的构建命令可能长这样Unity.exe -batchmode -quit -projectPath C:\MyProject -executeMethod MyEditorScript.PerformBuild -logFile build.log我们来分解一下关键参数-batchmode以批处理模式运行不显示图形界面不弹出对话框。这是自动化构建的核心。-quit执行完毕后自动退出Unity。如果不加这个参数Unity进程会挂起。-projectPath指定要打开的Unity项目绝对路径。-executeMethod指定要执行的C#静态方法格式为Namespace.ClassName.MethodName。这是自定义构建逻辑的入口。-logFile将日志输出到指定文件。强烈建议始终指定日志文件这是排查构建失败原因的最重要依据。但是仅有这些还不够。我们需要向这个静态方法传递参数比如打包平台、输出路径、版本号等。Unity命令行支持通过-开头的参数来传递这些参数在C#中可以通过System.Environment.GetCommandLineArgs()获取。一个更完整的例子Unity.exe -batchmode -quit -projectPath C:\MyProject -executeMethod BuildScript.Build -logFile build.log -buildTarget Android -outputPath C:\Builds\mygame.apk -version 1.0.1在C#脚本BuildScript.cs中我们需要解析这些参数using UnityEditor; using System.Linq; public static class BuildScript { public static void Build() { // 获取命令行参数 string[] args System.Environment.GetCommandLineArgs(); string buildTarget GetArgValue(args, -buildTarget); string outputPath GetArgValue(args, -outputPath); string version GetArgValue(args, -version); // 解析并设置构建目标 BuildTarget target (BuildTarget)System.Enum.Parse(typeof(BuildTarget), buildTarget); BuildPlayerOptions options new BuildPlayerOptions(); options.target target; options.locationPathName outputPath; options.scenes EditorBuildSettings.scenes.Where(s s.enabled).Select(s s.path).ToArray(); // 在构建前可以动态修改PlayerSettings如设置版本号 PlayerSettings.bundleVersion version; if (target BuildTarget.Android) { PlayerSettings.Android.bundleVersionCode; // 自动递增版本号 } // 执行构建 BuildPipeline.BuildPlayer(options); } private static string GetArgValue(string[] args, string argName) { for (int i 0; i args.Length; i) { if (args[i] argName i 1 args.Length) { return args[i 1]; } } return null; } }注意事项日志是生命线构建失败时第一时间查看-logFile指定的日志文件。里面会包含详细的错误堆栈信息。错误处理在批处理模式下Unity如果遇到编译错误或构建失败默认会以非0的退出码结束。Jenkins等CI工具会据此判断构建成功与否。因此你的C#构建脚本中要做好异常捕获和日志记录避免因未处理的异常导致进程崩溃日志却信息不全。资源清理在构建前最好调用AssetDatabase.Refresh()和EditorUtility.UnloadUnusedAssetsImmediate()来确保资源状态是最新的并释放内存。4.2 Groovy Pipeline脚本设计参数化与多平台支持有了驱动Unity的C#脚本我们需要一个“指挥官”来组织整个构建流程拉取代码、准备环境、调用Unity、处理构建产物、发送通知等。这就是Jenkins Pipeline脚本的工作。一个典型的unity_pipeline.groovy脚本结构如下pipeline { agent any // 指定在哪台机器上运行 parameters { // 定义构建参数这些会在Jenkins界面上显示为可输入项 choice(name: PLATFORM, choices: [Android, iOS, Windows], description: 选择构建平台) string(name: VERSION, defaultValue: 1.0.0, description: 版本号) booleanParam(name: DEVELOPMENT_BUILD, defaultValue: false, description: 是否打开发版) choice(name: SCRIPTING_BACKEND, choices: [Mono, IL2CPP], description: 脚本后端) } environment { // 定义环境变量如工具路径 UNITY_PATH C:/Program Files/Unity/Hub/Editor/2022.3.20f1/Editor/Unity.exe PROJECT_PATH ${env.WORKSPACE}/MyUnityProject // WORKSPACE是Jenkins提供的当前任务工作目录 OUTPUT_BASE D:/BuildOutput } stages { stage(Checkout) { steps { // 从版本库拉取代码 git branch: main, url: https://github.com/your-company/your-project.git } } stage(Prepare) { steps { script { // 根据平台参数准备不同的环境变量 if (params.PLATFORM Android) { env.OUTPUT_PATH ${OUTPUT_BASE}/Android/${env.BUILD_NUMBER}/mygame.apk env.BUILD_TARGET Android } else if (params.PLATFORM iOS) { env.OUTPUT_PATH ${OUTPUT_BASE}/iOS/${env.BUILD_NUMBER} env.BUILD_TARGET iOS } // 可以在这里执行一些预检查如目录清理 sh rm -rf ${env.OUTPUT_PATH} // 清理旧构建 } } } stage(Build with Unity) { steps { script { // 组装Unity命令行 def unityCmd \${UNITY_PATH}\ -batchmode -quit -nographics -projectPath \${PROJECT_PATH}\ -executeMethod BuildScript.Build -logFile \${PROJECT_PATH}/BuildLogs/build_${env.BUILD_NUMBER}.log\ -buildTarget ${env.BUILD_TARGET} -outputPath \${env.OUTPUT_PATH}\ -version \${params.VERSION}\ if (params.DEVELOPMENT_BUILD) { unityCmd -developmentBuild } // 执行构建命令 if (isUnix()) { // 判断是否是Unix-like系统macOS/Linux sh unityCmd } else { bat unityCmd } } } } stage(Post-Build) { steps { script { // 构建后处理如复制文件、生成版本信息、上传到内网服务器等 echo 构建完成输出路径${env.OUTPUT_PATH} // 例如将APK文件归档 archiveArtifacts artifacts: **/*.apk, fingerprint: true } } } } post { always { // 无论成功失败都执行例如清理临时文件、发送通知 echo 本次构建流程结束。 } success { // 构建成功时执行例如发送成功通知到钉钉/企业微信 echo 构建成功 } failure { // 构建失败时执行例如发送失败告警并附上日志链接 echo 构建失败 } } }设计要点参数化Parameters这是Pipeline的灵魂。它将构建过程中的可变因素平台、版本号、是否开发版等暴露给用户使得同一个脚本可以应对多种构建需求。环境变量Environment将路径、密钥等配置信息定义为环境变量使脚本更清晰也便于在不同环境中测试、生产切换配置。阶段Stages将整个流程划分为清晰的阶段如拉取代码、准备、构建、后处理。这让构建进度一目了然也便于定位问题发生在哪个环节。构建后处理Post善用post块进行收尾工作特别是发送通知能让团队及时了解构建状态。4.3 Job DSL脚本批量任务管理的利器当你的项目有多个分支main, develop, feature/xxx每个分支又要打多个平台Android, iOS, Windows的包时手动在Jenkins界面上创建几十个几乎相同的Job将是维护的噩梦。Job DSL插件就是为了解决这个问题。它的核心思想是“用代码生成Job”。你编写一个Groovy脚本例如create_jobs_dsl.groovy描述你想要创建的Job模板然后让Jenkins执行这个脚本就能批量生成或更新所有的构建任务。// create_jobs_dsl.groovy def projectName MyGame def branches [main, develop, release/1.0] def platforms [Android, iOS, Windows] branches.each { branch - platforms.each { platform - def jobName ${projectName}-${branch}-${platform} // 使用 pipelineJob 方法定义一个流水线任务 pipelineJob(jobName) { definition { cpsScm { scm { git { // 指向存放 unity_pipeline.groovy 的仓库 remote { url(https://github.com/your-company/your-build-scripts.git) } branch(main) } } scriptPath(pipelines/unity_pipeline.groovy) // 指定Pipeline脚本路径 } } parameters { // 为每个Job设置默认参数 stringParam(VERSION, 1.0.0, 版本号) choiceParam(PLATFORM, [platform], 构建平台) // 这里固定为当前平台 // 注意这里PLATFORM参数被固定了因为每个Job只负责一个平台。 // 但你可以保留其他参数如 DEVELOPMENT_BUILD booleanParam(DEVELOPMENT_BUILD, false, 是否打开发版) } properties { // 可以设置一些Job属性如禁用并发构建 disableConcurrentBuilds() } } } }如何使用在Jenkins中创建一个新的“流水线”类型任务命名为“Seed Job”或“DSL Generator”。在这个任务的配置中选择“Pipeline script from SCM”指向存放上述DSL脚本的Git仓库。运行这个Seed Job。它会读取你的DSL脚本并在Jenkins中自动创建出MyGame-main-Android,MyGame-main-iOS,MyGame-develop-Android等一系列任务。优势版本化管理Job的配置DSL脚本和项目代码一样可以提交到Git进行版本控制、代码审查和回滚。批量操作新增一个分支或平台只需修改DSL脚本中的数组重新运行Seed Job即可。一致性确保所有同类Job的配置如触发器、参数、构建后步骤完全一致避免手动配置的疏漏。5. 多平台构建的专项配置与避坑指南不同平台的构建有其特殊的配置和“坑点”。这里重点讲解Android和iOS这两个移动平台。5.1 Android构建签名、分包与版本管理Android打包的复杂性主要在于签名和适应不同设备架构。1. 自动签名手动打包时我们会在Unity的Player Settings里设置Keystore。在自动化构建中我们需要在脚本中动态指定。有两种安全的方式将Keystore文件放入版本库不推荐虽然方便但私钥泄露风险极高。使用Jenkins的Credentials管理这是最佳实践。将Keystore文件上传到Jenkins的“凭据”系统中并为其生成一个唯一的credentialsId。在Pipeline脚本中通过withCredentials指令来安全地获取并使用它。stage(Build Android) { steps { withCredentials([file(credentialsId: android-keystore, variable: KEYSTORE_FILE)]) { script { def unityCmd ... -executeMethod BuildScript.BuildAndroid -keystorePath \${KEYSTORE_FILE}\ -keystorePass ${KEYSTORE_PASS} // 密码也可以存为凭据 -keyaliasName myalias -keyaliasPass ${ALIAS_PASS} bat unityCmd } } } }在C#脚本中你需要解析这些参数并在构建前通过PlayerSettings.Android.keystoreName、keystorePass、keyaliasName、keyaliasPass来动态设置。2. 处理IL2CPP与架构如果使用IL2CPP后端需要在构建时指定目标CPU架构。Unity允许你为Android选择ARMv7、ARM64、x86等。为了减小包体通常只选择ARMv7和ARM64。在C#构建方法中可以通过PlayerSettings.Android.targetArchitectures来设置。3. 版本号自动递增一个常见的需求是每次构建的版本号bundleVersionCode自动加1。这可以在C#脚本中轻松实现int currentVersionCode PlayerSettings.Android.bundleVersionCode; PlayerSettings.Android.bundleVersionCode currentVersionCode 1; // 记得将这个新的版本号记录到某个文件或通过命令行回传给Jenkins以便在构建信息中展示。5.2 iOS构建证书、描述文件与Xcode工程处理iOS自动化构建必须在macOS系统上进行流程也更复杂涉及Xcode工程导出和签名。1. 导出Xcode工程Unity的iOS构建第一步是导出Xcode工程。在命令行中这通过指定-buildTarget iOS和输出路径为一个目录来实现。导出的工程包含了所有资源但尚未签名和编译成IPA。2. 自动签名配置关键难点iOS应用的签名依赖两个文件.p12证书和.mobileprovision描述文件。自动化签名的核心思路是在构建时用指定的证书和描述文件去替换Xcode工程中的自动签名配置。方案一使用xcodebuild命令。在导出Xcode工程后通过shell脚本调用xcodebuild进行编译和签名。你需要指定PROVISIONING_PROFILE、CODE_SIGN_IDENTITY等参数。这需要对Xcode构建命令比较熟悉。方案二使用Fastlane工具。Fastlane是一套非常流行的iOS/Android自动化工具链。它的gym命令可以极大地简化编译和打包流程。你只需要配置好Fastlane的Fastfile然后在Jenkins的shell步骤中调用fastlane ios build即可。这是更推荐的方式因为它处理了更多底层细节更稳定。3. 证书管理和Android一样绝不能将.p12证书和其密码硬编码在脚本或放入公开仓库。应该将证书文件上传到Jenkins的Credentials中类型为Secret file。将证书密码设置为Jenkins的Secret text。在Pipeline脚本中使用withCredentials将它们安全地注入到构建环境中并传递给后续的签名脚本或Fastlane。4. 重签名加速高级技巧对于测试阶段我们经常需要打多个不同签名的包如企业签、开发签。每次都从头编译Xcode工程非常耗时。一个优化技巧是先打出一个Release包如App Store签名的IPA然后对这个IPA进行重签名生成其他签名的版本。重签名只替换包内的签名信息不涉及重新编译速度极快。可以使用fastlane sigh或codesign命令配合脚本实现。5.3 常见构建失败问题排查实录即使一切配置就绪构建过程仍可能出错。以下是一些我踩过的坑和排查思路问题1Unity批处理模式构建失败日志显示“NullReferenceException”或编译错误。排查首先检查日志文件。这类错误通常和项目代码或资源有关在本地编辑器里可能也会出现。尝试在本地编辑器手动打包一次看是否成功。可能原因构建脚本中执行的Editor代码-executeMethod指向的方法依赖了某些只在编辑器运行时才初始化的数据。确保你的构建方法不依赖于Selection.activeObject或未初始化的静态变量。解决在构建方法的开始调用EditorUtility.DisplayProgressBar可能在不支持GUI的批处理模式下出错应移除或包裹在#if UNITY_EDITOR指令中。问题2Android构建成功但APK安装失败提示“无法解析”或“签名不一致”。排查检查Keystore和签名配置。确认自动化脚本中使用的签名信息和之前手动打包成功的签名信息是否一致。可以使用keytool -list -v -keystore your.keystore查看证书指纹。可能原因Jenkins构建环境中的JDK版本与生成Keystore时使用的版本不兼容或者构建脚本错误地覆盖了Player Settings中的签名信息。解决统一JDK版本。在构建脚本中打印出使用的签名信息进行核对。问题3iOS构建在xcodebuild阶段失败证书找不到。排查首先确认构建用的macOS机器上钥匙串Keychain中是否安装了对应的证书和私钥。可以通过命令行security find-identity -v -p codesigning查看。可能原因证书未导入或者导入到了“登录”钥匙串但xcodebuild命令在非交互环境下运行时可能无法访问“登录”钥匙串。解决将证书导入到“系统”钥匙串或者在使用xcodebuild前通过security unlock-keychain命令解锁“登录”钥匙串需要知道电脑密码安全性需权衡。更安全的方式是创建一个专用于CI的钥匙串将证书导入其中并在构建脚本中指定使用这个钥匙串。问题4构建时间过长特别是首次构建。分析首次构建慢主要是因为Unity需要导入整个项目资源。后续构建如果只改了代码增量编译会快很多。优化使用缓存Jenkins的Pipeline支持stash和unstash可以将导入后的Unity Library文件夹缓存起来下次构建时复用能极大缩短导入时间。但要注意如果项目资源或包管理器有更新需要清理缓存。分离资源构建对于大型项目可以将资源打包AssetBundle的步骤独立出来作为一个低频任务。代码构建则高频进行只编译脚本速度会快很多。优化项目减少项目中的冗余资源使用Addressables异步加载都能减少构建时的处理负担。构建自动化是一个不断迭代和优化的过程。初期搭建可能会遇到各种环境问题但一旦稳定运行它所带来的效率提升和流程规范价值是巨大的。建议从最简单的单平台构建开始逐步增加参数、平台和后续处理步骤让整个流程在可控的范围内演进。
