我如何加速我的 Asset Store 发布流程
Source: Dev.to
请提供您希望翻译的具体文本内容，我将为您翻译成简体中文。
问题：等待 Unity
传统的创建 .unitypackage 的方式是通过 Unity 编辑器和 Asset Store Publisher 工具。虽然可行，但会产生大量等待时间。
- Unity 仅仅启动并准备项目就可能需要 几分钟。
- 之后它会刷新资源、重新编译脚本，最后才会打开导出窗口。
- 只有在这一步之后，你才能选择资产并进行打包。
如果你经常发布更新或维护多个资产，这些等待时间会迅速累积。我意识到自己花在等待 Unity 上的时间比实际改进资产的时间还要多。
更快的方法：自动化打包
与其依赖 Unity 编辑器，我分析了 Unity 包的构建方式并实现了自动化。该工具从命令行运行，且可以完全脚本化。
流程对比
| 步骤 | Unity 编辑器 | 自动化 |
|---|---|---|
| 启动 | 3 分钟 | – |
| 编译 | 1 分钟 | – |
| 打包 | 1 分钟 | 10 秒 |
| 总计 | 5 分钟 | 10 秒 |
使用 Unity 时，即使是微小的改动也可能需要 数分钟 才能生成一个包。采用自动化方法，同样的任务只需 约 10 秒。无需编辑器启动、脚本编译，也不需要 UI 交互。由于一切都是自动化的，流程可靠且易于集成到构建服务器或 CI 流水线中。自从我切换到这种工作流后，打包不再需要我专门安排——它会自动完成。
什么是 .unitypackage，真的？
.unitypackage 文件本质上是一个 gzipped tarball（.tar.gz）：一种具有非常特定结构的压缩归档。
当你解压 .unitypackage 时，你不会看到类似 Assets/Scripts/Player.cs 的文件夹。相反，你会看到一系列以 Unity GUID 命名的文件夹，每个 GUID 代表一个资源。
root/
├── [GUID_1]/
│ ├── asset
│ ├── asset.meta
│ └── pathname
├── [GUID_2]/
│ ├── asset
│ ├── asset.meta
│ └── pathname
└── …每个文件夹包含
asset– 资源的原始二进制或文本数据asset.meta– Unity 用于导入设置和引用的元数据pathname– 一个文本文件，告诉 Unity 在导入时应将资源放置在哪里
当 Unity 导入该包时，它会读取这些数据并重新构建原始的文件夹结构。只要格式正确，Unity 并不关心该包是如何创建的。
Source: …
打包过程：寻找合适的资源
打包不仅仅是复制文件。Unity 资源之间关联紧密，缺少依赖很容易导致包损坏。
资源发现
- 确定需要包含的资源（例如，来自某个文件夹或模式，如
Assets/MyTool）。 - 对每个资源，检查是否存在
.meta文件——Unity 依赖 meta 文件来分配和追踪 GUID。
GUID 定义在 meta 文件的顶部：
guid: a1b2c3d4e5f6...所有 GUID 都会被收集，用来构建文件夹结构，并在后续的依赖分析中进行匹配。
依赖分析
许多 Unity 资源（预制体、材质、场景等）以 YAML 文本文件形式存储。在这些文件中，引用表现为 fileID‑GUID 对，例如：
fileID: 123456, guid: a1b2c3d4e5f6...为了高效查找，我使用正则表达式：
var regex = new Regex(@"fileID: ([\-0-9]+), guid: ([a-z0-9]+)", RegexOptions.Compiled);RegexOptions.Compiled 会将模式编译成 MSIL 代码，最大化运行时性能，代价是一次性的初始化开销。频繁使用时，编译后的正则非常快。
随后，将每个引用到的 GUID 与 .meta 文件中定义的 GUID 进行匹配。
打包
分析完成后，构建依赖图。任何被引用的资源——无论是直接还是间接——都会自动包含在包中。这样可以确保预制体保留其材质，脚本保留其依赖，包能够开箱即用。
实际的打包步骤很简单：
- 遍历所有已发现的 GUID。
- 为每个 GUID 创建一个目录。
- 添加相应的
asset、asset.meta和pathname文件。 - 对整个结构进行 Gzip 压缩。
生成的归档布局：
root/
├── [GUID_1]/
│ ├── asset
│ ├── asset.meta
│ └── pathname
├── [GUID_2]/
│ ├── asset
│ ├── asset.meta
│ └── pathname
└── …我节省了多少时间
我将发布流程缩短了90%以上。
我构建不同的资产，主要是网络安全解决方案。
例如，我的Obfuscator面向 Unity 2021、2023 和 6000 发布——共三个 Unity 版本。每个版本都有三个层级：Free、Pro 和 Source。总计9 次上传。
使用 Unity 编辑器时，每个包大约需要5 分钟。使用自动化工具，每个包在**≈10 秒**内即可完成，将原本 45 分钟的手动工作压缩到几秒钟。
TL;DR
- Unity 包实际上是 GUID 命名文件夹的 gzip 压缩 tar 包。
- 通过解析
.meta文件和 YAML 资产文件，你可以发现所有必需的 GUID。 - 一个小型命令行工具可以在几秒钟内构建正确的文件夹结构并进行 gzip 压缩，从而无需启动 Unity 编辑器进行打包。
试一试吧，重新夺回你在 Unity 上等待的时间！
结果： 总计大约45 分钟。使用我描述的自动化流程，我将整个工作流缩短到约30 秒。
PowerShell 脚本
# Export-UnityPackages.ps1
param (
[Parameter(Mandatory = $true)]
[string]$OutputDirectory,
[Parameter(Mandatory = $true)]
[string[]]$Versions
)
# Ensure output directory exists
if (!(Test-Path $OutputDirectory)) {
New-Item -ItemType Directory -Path $OutputDirectory | Out-Null
}
foreach ($version in $Versions) {
$sourcePath = "..\$version"
$outputPackage = Join-Path $OutputDirectory "$version.unitypackage"
Write-Host "Exporting Unity package for version $version..."
dotnet UnityPackageExporter.dll `
$sourcePath `
$outputPackage `
--assets "Assets/MyTool/**.*" `
--skip-dependency-check
}运行脚本：
.\Export-UnityPackages.ps1 -OutputDirectory "..\packed" -Versions "1.0.0","1.1.0","2.0.0"结果：
packed/
├─ 1.0.0.unitypackage
├─ 1.1.0.unitypackage
└─ 2.0.0.unitypackage亲自尝试一下
如果你正在为 Unity 构建资源，打包不应该是工作流中最慢的环节。通过完全跳过 Unity 编辑器，资源导出变得快速、可重复且易于自动化。
我已经将该工具 免费、开源且采用 MIT 许可证。你可以尝试它，检查其工作原理，或根据自己的需求进行改造。
👉 了解更多并在此尝试：
https://www.guardingpearsoftware.com/tool/package-export
希望这能帮助你减少在 Unity 上等待的时间，投入更多精力创作出色的资源。
阅读我的博客了解更多信息：www.guardingpearsoftware.com