三亩地 三亩地SAN MU DI · CODE DIARY
交流投稿
ARTICLE DETAIL

日记详情

真实记录编程学习的某一天，欢迎挑你感兴趣的翻一翻。

首页/学习日记/日记详情

Unity应用签名全攻略：从原理到自动化实践

发布时间：2026/8/10 4:40:51 三亩地 编程学习日记
Unity应用签名全攻略：从原理到自动化实践

1. 项目概述：为什么你的Unity项目需要一个签名Demo？

最近在跟几个独立游戏开发的朋友聊天，发现一个挺普遍的现象：大家花大量时间打磨游戏玩法、优化美术效果，但一到打包发布，尤其是涉及到平台上线（比如Google Play、App Store）或者需要集成第三方SDK（比如微信登录、支付）时，就卡在了“签名”这个环节上。要么是打包出来的APK安装失败，提示“未签名应用”；要么是接入SDK后功能调不通，排查半天才发现是签名配置错了。这感觉就像精心装修好了房子，最后因为一把钥匙配不对，门都进不去。

这个“Unity 签名Demo”项目，就是为了解决这个痛点而生的。它不是一个简单的代码片段集合，而是一个完整的、可运行的、模块化的Unity工程。它的核心价值在于，为你提供一个关于“如何在Unity项目中正确、安全、自动化地处理应用签名”的最佳实践样板。无论你是要发布到安卓、iOS，还是打包Windows/macOS的PC版本，甚至是处理一些特殊的证书场景（比如企业内部分发），这个Demo都试图通过清晰的代码结构和详尽的注释，把背后的原理、常见的坑以及解决方案，直观地展示给你看。

简单来说，有了这个Demo，你可以：

  1. 快速上手：直接参考Demo中的配置，应用到自己的项目，避免从零开始摸索。
  2. 理解原理：不仅仅是“怎么做”，更重要的是“为什么这么做”。Demo会解释密钥库、证书、签名算法（如RSA、ECDSA）的作用。
  3. 规避风险：比如签名密钥丢失导致应用无法更新的“致命伤”，Demo会强调备份和安全存储的重要性。
  4. 实现自动化：教你如何结合CI/CD（如GitHub Actions, Jenkins）或Unity Cloud Build，让签名过程在构建流程中自动完成，提升团队协作效率。

这个Demo适合所有阶段的Unity开发者：新手可以把它当作避坑指南，老手可以从中提炼出适合自己项目的自动化脚本和配置规范。接下来，我们就一层层拆解这个Demo里到底藏了哪些干货。

2. 签名功能的核心价值与场景解析

在深入代码之前，我们必须先搞清楚：为什么签名如此重要？它到底在哪些场景下会跳出来“卡”你一下？理解了这些，你才能明白Demo里每个模块设计的用意。

2.1 应用签名的三大核心作用

签名绝不仅仅是一个“打包步骤”，它承担着三个关键使命：

  1. 身份认证与完整性校验：这是签名的根本。开发者使用自己的私钥对应用进行签名，用户设备上的系统则使用对应的公钥来验证。如果验证通过，就证明这个应用确实来自声称的开发者，并且在传输过程中没有被篡改过。想象一下，你收到一个盖了某公司公章的文件，你相信文件内容来自该公司且未被涂改，签名就是这个“数字公章”。
  2. 建立应用更新通道：无论是Android的包名（Bundle ID）加签名证书，还是iOS的Bundle ID加Provisioning Profile，系统都依靠它们来判断一个新版本是否是旧版本的合法升级。如果签名证书变了，系统会认为这是一个全新的应用，导致用户无法直接覆盖安装更新，数据也无法继承。这就是为什么保管好发布密钥库（Keystore）如此重要，Demo中会重点强调这一点。
  3. 权限与沙盒隔离的基础：在Android上，应用签名是权限共享的关键。两个应用如果使用相同的签名证书，它们可以共享数据、甚至运行在同一个进程里。在iOS上，签名和配置文件决定了应用能在哪些设备上安装、能访问哪些系统服务（如推送通知、iCloud）。

2.2 必须处理签名的典型开发场景

你的项目在以下阶段，一定会和签名打交道：

  • 场景一：接入任何需要校验签名的第三方SDK
    • 例如微信登录/支付、支付宝、Facebook SDK等。这些平台的后台都需要你配置应用签名的“指纹”（如MD5、SHA1、SHA256）。它们用这个指纹来验证请求是否来自你官方发布的应用。如果Demo里的签名和你打包上线的签名不一致，这些功能100%会失败。Demo会展示如何通过代码或工具正确提取这些签名信息。
  • 场景二：发布到官方应用商店
    • Google Play：要求使用非调试证书进行签名，并且鼓励使用Android App Bundle（AAB）格式，其签名机制略有不同。Demo会对比APK与AAB在签名上的差异。
    • Apple App Store：涉及更复杂的证书（Development/Distribution）、标识符（Bundle ID）和描述文件（Provisioning Profile）体系。Demo会模拟Xcode的自动签名流程，并解释手动管理证书的备选方案。
  • 场景三：内部分发与测试
    • 企业内测、渠道包：你可能需要为不同的渠道生成不同签名的包，用于数据统计。或者使用企业证书签名，让应用无需上架App Store就能直接安装。Demo会提供多环境签名配置的脚本示例。
  • 场景四：PC平台（Windows/macOS）发布
    • 虽然不像移动平台那样强制，但对应用进行代码签名（Code Signing）可以消除系统（如Windows SmartScreen， macOS Gatekeeper）弹出的“不明开发者”警告，提升用户信任度。Demo会包含使用Signtool（Windows）和codesign（macOS）进行签名的示例。

这个Demo的价值就在于，它把这些分散在不同平台文档里的知识点，用一个可运行的Unity项目串联了起来，让你能在一个地方看到全貌。

3. Demo工程结构设计与模块拆解

一个清晰的工程结构是理解和复用的前提。这个签名Demo的工程目录不是随意组织的，每一层都有其明确的职责。下面我们来拆解它的核心模块。

3.1 核心目录结构说明

SignatureDemo/ ├── Assets/ │ ├── Scripts/ │ │ ├── Editor/ # 编辑器扩展脚本，核心！ │ │ │ ├── BuildAutomation/ # 构建与签名自动化 │ │ │ ├── CertificateTools/ # 证书查看与提取工具 │ │ │ └── KeystoreManager/ # 密钥库创建与管理（模拟Unity内置功能） │ │ └── Runtime/ # 运行时获取签名信息的工具（如获取当前APK签名） │ ├── Plugins/ # 可能包含原生平台获取签名的插件（如Android Java库） │ └── Resources/ # 存放图标、默认配置等 ├── ProjectSettings/ # Unity项目设置 ├── Builds/ # 构建输出目录（通常.gitignore） ├── Configs/ # 配置文件目录（关键！） │ ├── keystore.properties # 安卓密钥库配置（密码不应提交！用模板） │ ├── ios_profiles.json # iOS描述文件与证书配置信息 │ └── windows_cert.pfx # Windows代码签名证书（示例，勿用真实私钥） ├── CI_Scripts/ # 持续集成脚本 │ ├── generate_keystore.sh # 自动生成调试密钥库 │ ├── android_sign_build.sh # 安卓自动签名脚本 │ └── ios_export_options.plist # iOS导出配置模板 └── README.md # 项目详细说明文档

设计思路：将配置（Configs）、代码（Assets/Scripts）、构建产物（Builds）和自动化脚本（CI_Scripts）分离。这样做的好处是：

  • 安全：敏感的签名配置（如keystore密码）可以通过环境变量或单独的配置文件（不提交到Git）来管理，Demo里只提供模板。
  • 清晰：编辑器脚本只负责逻辑，配置数据来自外部文件，易于维护和切换不同环境（开发、测试、生产）。
  • 复用：CI_Scripts里的脚本可以直接拷贝到你的Jenkins或GitHub Actions任务中使用。

3.2 关键脚本模块深度解析

3.2.1 Editor/BuildAutomation 构建自动化模块

这是Demo的“大脑”。它通过扩展Unity的BuildPlayerWindow或创建自定义的编辑器窗口，将签名流程集成到标准的构建流程中。

// 示例：一个简化的自定义构建管道 using UnityEditor; using UnityEditor.Build; using UnityEditor.Build.Reporting; using System.Diagnostics; public class CustomBuildProcessor : IPreprocessBuildWithReport, IPostprocessBuildWithReport { public int callbackOrder { get { return 0; } } // 构建开始前：检查并准备签名配置 public void OnPreprocessBuild(BuildReport report) { BuildTarget target = report.summary.platform; if (target == BuildTarget.Android) { // 1. 检查是否配置了Keystore string keystorePath = EditorPrefs.GetString("AndroidKeystorePath"); if (string.IsNullOrEmpty(keystorePath)) { // 提示用户配置，或从Configs/keystore.properties读取 bool useAuto = EditorUtility.DisplayDialog("签名配置", "未找到发布密钥库，是否使用自动生成的调试密钥库？", "使用调试", "取消构建"); if (!useAuto) throw new BuildFailedException("用户取消了构建：缺少签名配置。"); // 调用脚本自动生成调试Keystore GenerateDebugKeystore(); } else { // 2. 验证Keystore密码和Key别名是否有效（可以通过调用命令行工具keytool） if (!ValidateKeystore(keystorePath)) { throw new BuildFailedException("密钥库验证失败，请检查路径和密码。"); } // 3. 自动将配置应用到PlayerSettings ApplyAndroidSigningSettings(keystorePath); } } else if (target == BuildTarget.iOS) { // 处理iOS自动签名或手动配置文件选择 ConfigureiOSSigning(); } } // 构建完成后：可选步骤，如对输出包进行二次签名或生成报告 public void OnPostprocessBuild(BuildReport report) { if (report.summary.platform == BuildTarget.StandaloneWindows) { // 调用外部工具（如signtool）对.exe进行代码签名 SignWindowsExecutable(report.summary.outputPath); } // 记录本次构建使用的签名指纹，用于后续追踪 LogSignatureInfo(report); } private void GenerateDebugKeystore() { // 调用CI_Scripts/generate_keystore.sh或直接使用C# Process调用keytool ProcessStartInfo psi = new ProcessStartInfo(); psi.FileName = "keytool"; psi.Arguments = "-genkeypair -v -keystore debug.keystore -alias androiddebugkey -keyalg RSA -keysize 2048 -validity 10000 -storepass android -keypass android -dname \"CN=Android Debug, O=Android, C=US\""; psi.UseShellExecute = false; psi.RedirectStandardOutput = true; Process p = Process.Start(psi); p.WaitForExit(); EditorUtility.DisplayDialog("提示", "调试密钥库已生成。", "确定"); } }

实操心得：

  • IPreprocessBuildWithReport接口非常强大，它允许你在Unity官方构建流程的特定节点插入自定义逻辑。务必注意callbackOrder，如果你的操作依赖其他预处理（比如一些资源处理插件），需要调整执行顺序。
  • 在OnPreprocessBuild中抛出BuildFailedException可以优雅地终止构建并给出明确错误信息，比构建出一个无效的包要好得多。
  • 调用外部命令行工具（如keytool,signtool,codesign）时，务必处理好路径空格和特殊字符，并考虑跨平台兼容性（在Demo中，可能会分别编写.sh和.ps1脚本）。
3.2.2 Editor/CertificateTools 证书工具模块

这个模块主要用于“查看”和“提取”签名信息，对于调试SDK集成问题至关重要。

  • 功能一：提取Android签名指纹
    • 实现一个编辑器工具窗口，通过读取已配置的Keystore或已打包的APK/AAB文件，计算并显示其MD5、SHA1、SHA256指纹。这比让你在命令行里敲keytool -list -v -keystore xxx要直观得多。
    • 关键代码：本质上还是封装对keytool或apksigner（用于AAB）的命令行调用，并解析其文本输出。
  • 功能二：解析iOS Provisioning Profile
    • Provisioning Profile（.mobileprovision文件）是个plist文件，但经过编码。这个工具可以解密并展示其内容：包含的证书、允许的设备列表、App ID、功能授权等。让你清楚知道当前配置是否包含了测试设备的UDID。
    • 实现方法：在macOS上，可以使用security cms -D -i profile.mobileprovision命令来解码。在C#中，可以调用这个进程并解析输出的XML。

注意：处理证书和私钥时，Demo中的所有代码都应遵循“只读”和“不存储”原则，即只用于展示信息，绝不将私钥或密码硬编码在代码中或上传到版本库。所有敏感操作都应通过Unity的PlayerSettings接口或由用户在编辑器中输入。

4. 多平台签名配置实操详解

理论说再多，不如实际配置一遍。这部分我们将以Android和iOS为例，一步步拆解在Unity Editor中以及通过Demo脚本进行签名的具体操作和背后的原理。

4.1 Android平台签名全流程

Android签名主要围绕一个核心文件：Keystore（密钥库）。你可以把它理解为一个装了钥匙（私钥）的保险箱。

4.1.1 创建与保管发布密钥库

永远不要使用Unity默认的调试密钥库（debug.keystore）发布应用！它的密码公开（android），且在不同电脑上生成的不同，会导致签名不一致。

正确做法：

  1. 使用Demo提供的工具创建：在Unity Editor菜单栏，Signature Demo -> Keystore Manager -> Create New Keystore。工具会引导你填写：
    • Keystore路径和密码：选择一个安全的位置，密码强度要高。
    • Key Alias（密钥别名）和密码：一个Keystore里可以有多对密钥，用别名区分。通常发布用release_key。
    • 有效期（Validity）：Google Play要求至少到2033年10月22日之后。建议设长一些，如25年（9125天）。
    • ** Distinguished Name（识别名）**：按提示填写公司/个人名称、地区等信息。
  2. 安全备份：创建成功后，Demo会弹窗强烈提醒你将.keystore文件备份到多个安全的地方（如加密U盘、密码管理器、安全的云存储）。丢失它等于丢失了更新应用的权力。
  3. 配置到Unity项目：
    • 手动：在Project Settings -> Player -> Android -> Publishing Settings下，勾选Custom Keystore，填入路径和密码。
    • 通过Demo脚本自动：在Configs/keystore.properties模板文件中配置路径（密码建议用环境变量），运行构建脚本时会自动应用。
// 示例：从配置文件读取并应用Keystore设置（编辑器脚本中） [MenuItem("Signature Demo/Apply Android Signing Config")] public static void ApplyFromConfig() { string configPath = "Configs/keystore.properties"; if (File.Exists(configPath)) { // 解析properties文件（这里简化，实际可用Dictionary） string[] lines = File.ReadAllLines(configPath); string keystorePath = null, keystorePass = null, keyAlias = null, keyPass = null; // ... 解析逻辑 ... keystorePass = Environment.GetEnvironmentVariable("ANDROID_KEYSTORE_PASS"); // 密码从环境变量读 if (!string.IsNullOrEmpty(keystorePath)) { PlayerSettings.Android.keystoreName = keystorePath; PlayerSettings.Android.keystorePass = keystorePass; PlayerSettings.Android.keyaliasName = keyAlias; PlayerSettings.Android.keyaliasPass = keyPass; Debug.Log("Android签名配置已从配置文件应用。"); } } }
4.1.2 构建格式选择：APK vs AAB 与签名影响

从2021年8月起，Google Play要求新应用必须使用Android App Bundle（AAB）格式上传。这对签名有什么影响？

  • APK（Android Package）：直接签名的就是最终的安装包。使用jarsigner（较老）或apksigner工具签名。
  • AAB（Android App Bundle）：它是一个“应用束”，包含所有代码和资源，但Google Play会针对不同设备动态生成最优化的APK。你签名的是整个AAB文件，而不是最终用户下载的APK。Unity在构建AAB时，签名流程是内置的，你只需要像配置APK一样配置好Keystore即可。

Demo中的体现：构建脚本会区分构建目标（APK或AAB），但签名配置的来源是统一的。Demo还会展示如何通过命令行调用bundletool（Google提供的工具）来本地测试AAB的签名和安装。

4.2 iOS平台签名配置详解

iOS的签名体系更复杂，涉及三样东西：证书（Certificate）、标识符（Identifier）、描述文件（Provisioning Profile）。Unity本身不管理这些，它依赖Xcode和Apple Developer账户。

4.2.1 自动签名 vs 手动签名

Demo会教你如何配置这两种模式：

  1. 自动签名（推荐给大多数开发者）：

    • 在Project Settings -> Player -> iOS -> Other Settings下，找到Signing Team ID，填入你的Apple开发者团队ID（一串10字符的字母数字）。
    • 构建项目生成Xcode工程后，不要改动Xcode中的签名设置。打开Xcode，在Signing & Capabilities选项卡中，勾选Automatically manage signing，Xcode会自动为你处理证书和描述文件的创建、下载。
    • Demo的辅助：Demo的构建后处理脚本（OnPostprocessBuild）可以检查Xcode工程中的project.pbxproj文件，确保PROVISIONING_PROFILE_SPECIFIER等设置符合预期，避免自动签名失败。

  2. 手动签名（需要更精细的控制时使用）：

    • 适用于需要管理多个证书、企业分发或复杂的自动化构建环境。
    • 你需要先在Apple Developer网站创建好iOS Distribution证书和对应的Provisioning Profile，并下载到本地。
    • 在Unity中，除了设置Team ID，还可以指定：
      • Provisioning Profile ID：描述文件的UUID。
      • iOS Manual Provisioning Profile：描述文件的具体路径。
    • Demo的辅助：Demo提供了一个编辑器窗口，可以扫描本地~/Library/MobileDevice/Provisioning Profiles/目录下的所有描述文件，并列出其名称、ID和过期日期，方便你选择和配置。
4.2.2 处理常见的iOS签名错误

Demo的文档或工具提示中会包含对以下错误的排查指南：

  • “No profiles for ‘com.xxx.xxx’ were found”：Bundle ID不匹配。检查Unity中的Bundle Identifier和描述文件中包含的App ID是否完全一致。
  • “Failed to create provisioning profile.”：设备未添加。确保测试设备的UDID已添加到开发者账户并包含在描述文件中。
  • “Code Signing Entitlements file do not match.”：能力（Capabilities）配置不匹配。在Xcode中检查推送、iCloud等服务的开关是否与描述文件中的权限一致。

5. 持续集成（CI）中的自动化签名实践

个人开发可以手动操作，但团队协作或需要频繁构建测试包时，自动化是必由之路。这部分是Demo的进阶价值所在。

5.1 基于命令行（Headless）的构建与签名

Unity支持以无界面的命令行模式执行构建。Demo的CI_Scripts文件夹下提供了样板脚本。

一个简化的Android自动化构建脚本（CI_Scripts/build_android.sh）：

#!/bin/bash # 这是一个示例脚本，实际使用需要根据CI环境调整 UNITY_PATH="/Applications/Unity/Hub/Editor/2022.3.25f1/Unity.app/Contents/MacOS/Unity" PROJECT_PATH="/Users/ci/workspace/YourUnityProject" OUTPUT_PATH="./Builds/Android" BUILD_LOG="build_android.log" # 从CI环境变量或加密文件中读取敏感信息 KEYSTORE_PATH="$PROJECT_PATH/Configs/release.keystore" KEYSTORE_PASS=${ANDROID_KEYSTORE_PASSWORD} # 从CI环境变量读取 KEY_ALIAS="release_key" KEY_PASS=${ANDROID_KEY_PASSWORD} echo "开始构建Android APK..." $UNITY_PATH -batchmode \ -quit \ -nographics \ -projectPath "$PROJECT_PATH" \ -executeMethod SignatureDemo.Editor.BuildAutomation.CI_BuildAndroid \ -logFile "$BUILD_LOG" \ -buildTarget Android \ -keystorePath "$KEYSTORE_PATH" \ -keystorePass "$KEYSTORE_PASS" \ -keyaliasName "$KEY_ALIAS" \ -keyaliasPass "$KEY_PASS" # 检查构建结果 if grep -q "Build succeeded" "$BUILD_LOG"; then echo "构建成功！APK位于：$OUTPUT_PATH" # 可选：上传到内部分发平台（如Fir.im, Diawi） else echo "构建失败！请查看日志：$BUILD_LOG" exit 1 fi

关键点：

  • -executeMethod参数指定了Demo中一个静态方法，该方法接收命令行参数并驱动整个构建和签名流程。
  • 所有密码等敏感信息都通过环境变量（${}）传入，绝不能硬编码在脚本里。
  • -batchmode和-quit确保构建完成后Unity自动退出。

5.2 与主流CI/CD平台集成示例

Demo会提供如何将上述脚本集成到GitHub Actions和Jenkins的配置片段。

GitHub Actions 示例（.github/workflows/build_android.yml）：

name: Build Android on: push: tags: - 'v*' jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - name: Cache Unity Library uses: actions/cache@v3 with: path: Library key: library-${{ hashFiles('Assets/**', 'Packages/**', 'ProjectSettings/**') }} - name: Build Android APK run: | chmod +x ./CI_Scripts/build_android.sh ./CI_Scripts/build_android.sh env: ANDROID_KEYSTORE_PASSWORD: ${{ secrets.ANDROID_KEYSTORE_PASSWORD }} ANDROID_KEY_PASSWORD: ${{ secrets.ANDROID_KEY_PASSWORD }} - name: Upload APK Artifact uses: actions/upload-artifact@v3 with: name: android-apk path: Builds/Android/*.apk

安全提醒：在GitHub仓库的Settings -> Secrets中设置ANDROID_KEYSTORE_PASSWORD等机密信息。密钥库文件本身可以作为一个加密的“秘密文件”上传，或者在构建时从安全的存储中下载。

6. 常见问题排查与实战经验分享

即使按照Demo操作，在实际项目中你还是可能遇到各种奇怪的问题。这里分享几个我踩过的坑和排查思路。

6.1 “Signature Verification Failed” 类问题

场景：接入微信SDK时，登录一直失败，后台提示签名错误。

排查步骤：

  1. 确认对比的签名是什么：微信开放平台要求配置的是“应用签名”（一个32位的MD5字符串，去除冒号）。这个签名来自于你发布到应用商店的正式包的签名，而不是调试包的。
  2. 使用Demo工具提取正确签名：
    • 用你的发布密钥库，打包一个Release版本的APK。
    • 打开Demo中的CertificateTools窗口，选择这个APK文件，工具会计算出其MD5签名。
    • 将这个签名填写到微信开放平台的后台。
  3. 特别注意：如果你在微信平台填的是调试签名的MD5，那么只有用调试密钥库打的包才能调通微信。一旦换成发布密钥库，签名就变了，功能立刻失效。务必用发布包签名去配置第三方平台。

6.2 升级Unity版本或构建系统后签名失效

场景：Unity版本从2021升级到2022后，同样的Keystore配置，打出来的包安装失败。

可能原因与解决：

  1. 构建Gradle版本变化：新版本Unity可能升级了内置的Gradle或Android SDK Build-Tools。不同的工具链对签名算法有细微差异。确保你使用的keytool和apksigner版本与构建环境匹配。Demo中建议在CI脚本里固定这些工具的版本号。
  2. PlayerSettings中的新选项：新版本Unity可能会引入新的签名相关选项（如Use APK Signature Scheme v2）。检查Project Settings -> Player -> Android -> Publishing Settings下的所有选项，与旧版本项目进行对比。Demo的版本迁移指南会记录这些关键变更点。
  3. 密钥库损坏：极小概率事件。如果你有备份，恢复备份。如果没有，那就只能使用新密钥库，并接受无法覆盖更新旧版应用的事实。再次强调备份的重要性！

6.3 iOS打包：证书与描述文件管理混乱

场景：Xcode报错“No matching provisioning profiles found”，但明明在Apple Developer网站上都配置好了。

终极清理大法（在Mac上执行）：

  1. 关闭Xcode和Unity。
  2. 打开钥匙串访问（Keychain Access），在“登录”和“系统”钥匙串中，删除所有旧的、过期的Apple Development/Apple Distribution证书（注意别删错）。
  3. 删除~/Library/MobileDevice/Provisioning Profiles/目录下所有描述文件。
  4. 重启Xcode，在Preferences -> Accounts里，重新登录你的Apple ID，并点击“Download Manual Profiles”。
  5. 重新打开Unity项目构建。

这个流程可以解决90%因本地缓存混乱导致的iOS签名问题。Demo的故障排除文档里应该包含这个“核武器”步骤。

6.4 多环境（开发、测试、生产）签名管理

对于中型以上项目，你需要为不同环境准备不同的签名配置。

推荐方案：

  1. 使用不同的Bundle ID（包名）：这是最清晰的方式。例如：
    • 开发版：com.company.app.dev
    • 测试版：com.company.app.staging
    • 生产版：com.company.app这样可以在同一设备上同时安装三个版本，且签名可以完全独立。
  2. 使用不同的密钥库：为每个环境创建独立的Keystore。虽然管理成本稍高，但最安全，互不影响。
  3. 通过Demo的配置系统管理：在Configs/目录下创建多个配置文件，如keystore.dev.properties,keystore.prod.properties。构建时通过命令行参数或环境变量指定使用哪个配置。
# 在CI脚本中 if [ "$BUILD_ENV" = "production" ]; then CONFIG_FILE="keystore.prod.properties" else CONFIG_FILE="keystore.dev.properties" fi

签名是Unity项目通向发布的“最后一道关卡”，也是安全与可信的基石。这个“Unity 签名Demo”项目试图将这道关卡从一堵黑墙，变成一扇有清晰说明书的大门。它提供的不是魔法，而是经过实践检验的工具、脚本和知识体系。希望你在参考它的时候，不仅能解决眼前“打包失败”的问题，更能建立起一套适合自己团队的安全、高效的发布流程。毕竟，让玩家顺利玩上游戏，才是我们所有工作的最终目的。

编程学习 学习日记 实战经验
← 返回列表