Defold 跨平台发布：iOS/Android/Web/桌面打包、签名与 Store 上架

Defold 的核心卖点之一是「一份工程，多平台一键发布」。(Defold publish docs) 但每个平台都有各自的打包、签名、审核与性能要求。本文从构建原理出发，逐平台讲解 iOS/Android/Web/桌面的打包流程、签名配置与商店上架要点，最后给出包体与性能优化清单。

前置建议：先读 Defold 游戏引擎介绍 了解平台矩阵，再配合 热更新与热重载 理解发布后运营。资源打包细节可参考 编辑器与资源管线。

一、发布流程总览

1. 从工程到安装包

Defold 的发布本质是「bob 构建 → 生成各平台安装包」：

编辑器 File → Bundle → 选择平台
等价命令：
  java -jar bob.jar --resolve --build --bundle --bundle-output build --platform ios

构建产物按平台生成：.ipa（iOS）、.apk/.aab（Android）、HTML5 目录（Web）、.dmg/.exe/.AppImage（桌面）。

2. game.project 中的平台配置

全局配置在 game.project，平台相关配置通常以平台名为 section 前缀：

[bootstrap]
main_collection = /main/main.collectionc

[display]
width = 1280
height = 720

[android]
package = com.example.mygame
version_code = 1

[ios]
bundle_identifier = com.example.mygame
version = 1.0.0

[html5]
run_archive = 1

3. 多平台差异矩阵

二、iOS 打包与签名

1. 前置条件

iOS 发布需要：

• Apple Developer 账号（$99/年）
• 一个 Bundle Identifier（如 com.example.mygame，需在 game.project 的 [ios] 中一致）
• 推送/内购等能力需在 Apple 后台配置

2. 签名流程

iOS 签名 = 开发者证书（.p12）+ 描述文件（Provisioning Profile）：

1. Apple Developer 后台创建 App ID，勾选所需 Capability
2. 生成证书请求 → 下载 .cer → 导入钥匙串导出 .p12
3. 创建开发/发布描述文件 .mobileprovision
4. bob 构建时通过 --identity 与描述文件签名

java -jar bob.jar --build --bundle --platform ios \
  --identity "iPhone Distribution: Leeting Yan (XXXXXX)" \
  --mobileprovisioning path/to/profile.mobileprovision

3. 构建与真机验证

• 编辑器 Bundle 生成 .ipa 后，可用 Xcode 的 Payload 目录直接安装到真机验证
• 建议先走 TestFlight 内测：用 App Store Connect 上传 .ipa，邀请测试者验证后再提交审核
• 模拟器构建与真机构建不同：真机需要 arm64 架构，bob 默认按平台生成

4. App Store 上架要点

• 启动图 / 图标：[ios] 中 app_icon 指向图标文件，大小须满足 Apple 规范
• 隐私：需要隐私政策链接；收集 IDFA 需说明
• 审核注意：提审前关闭测试入口、清理占位内容；Game Center/内购配置完整
• 版本号与构建号：CFBundleVersion 每次递增，与 [ios] 的 version 区分

三、Android 打包与签名

1. 构建 AAB/APK

Google Play 现已推荐 AAB（App Bundle），由商店生成分屏 APK：

java -jar bob.jar --build --bundle --platform android \
  --bundle-format aab \
  --keystore path/to/keystore.jks \
  --keystore-pass storepass --keystore-alias myalias

game.project 中 [android] 设置包名与版本：

[android]
package = com.example.mygame
version_code = 12        -- 每次上传递增

2. keystore 管理

Android 签名用自签名 keystore，一旦丢失无法恢复商店身份：

• 首次生成后备份多份，私钥密码妥善保管
• 上传 Google Play 用 .keystore，App 更新必须同一 keystore
• 支持内购/广告 SDK 时，包名须与 SDK 后台注册一致

3. 构建变体与渠道

通过 bob 的 --variant 与资源目录可实现多渠道（各商店或国内渠道）：

• 不同渠道包用不同 variant，动态注入渠道 ID
• 国内渠道（华为/小米等）有各自签名与审核要求，需分别打包
• 灰度与渠道配置见 热更新与热重载

4. 真机与审核注意

• 用 adb install 安装 APK 真机验证启动、网络与内购
• Google Play 政策：targetSdk 需达标（Defold 各版本有对应要求），外链、隐私政策齐全
• 包体大于 150MB 需走 Play Feature Delivery 或扩展文件策略

四、Web（HTML5）构建

1. HTML5 输出

Web 平台输出为一组静态文件（.html + .js + .wasm + 资源归档）：

java -jar bob.jar --build --bundle --platform html5 --bundle-output build/html5

产物可直接部署到任意静态托管：CDN、GitHub Pages、Vercel 等。(HTML5 官方手册)

2. 加载与进度

Web 游戏最忌「白屏等待」。Defold 支持配置加载画面与进度：

• [html5] 段 run_archive 控制是否从归档运行
• 自定义加载页面：编辑 custom.html 模板，显示进度条
• 归档较大时优先启用 collectionproxy 懒加载与 Live Update 外置资源

3. 移动端浏览器适配

• 设置 game.project 的 viewport 与旋转锁定（横屏游戏锁定 landscape）
• 触控输入用 input 绑定适配，虚拟按键用 GUI 实现（见 GUI/UI 开发)
• 自动暂停：页面切后台时处理 visibilitychange，暂停游戏计时器

4. 性能与兼容性

Web 平台的性能瓶颈主要在资源加载与渲染：

• 纹理格式：Web 下用 WebP/ASTC 压缩，控制显存
• 减少 Draw Call：图集合批是首要手段
• 兼容测试：Chrome/Safari/Firefox 与不同 GPU 下验证 shader（参见 图形学专题)

五、桌面平台打包

1. Windows / macOS / Linux

桌面构建同样一条命令：

java -jar bob.jar --build --bundle --platform win32     # Windows
java -jar bob.jar --build --bundle --platform macos     # macOS .app
java -jar bob.jar --build --bundle --platform linux     # Linux

2. 代码签名与分发

• macOS：Gatekeeper 要求签名与公证（notarization），否则用户需右键打开
• Windows：用 Authenticode 证书签名，减少 SmartScreen 拦截
• 分发渠道：Steam（建议原生 + 云存档）、itch.io、自建下载页

3. 桌面输入与窗口

• [display] 设置窗口尺寸、全屏模式与刷新率
• 桌面输入绑定键盘/鼠标/手柄，注意从移动触控输入迁移
• 存档路径：用 sys.get_save_file() 获取平台持久目录，避免硬编码

local path = sys.get_save_file("mygame", "save.dat")
local f = io.open(path, "w")
f:write("level=3")
f:close()

4. Steam 发行注意

Steam 对 Defold 游戏的支持度较高（官方有 Steamworks 扩展）：

• 用 Steamworks SDK 扩展接入成就、云存档与创意工坊
• 提交内容分为 Depot：主游戏内容 + 可选 DLC，可独立热更
• Steam 商店页需要质量承诺：截图、预告片、分类标签齐全才容易曝光
• 建议在早期版本就接入 Steam 云存档，避免上线后数据迁移

5. macOS 的 Gatekeeper 与公证

• 未签名/未公证的 .app 会被系统拦截，用户需右键「打开」绕过
• 正规分发用 Developer ID Application 证书签名，并通过 notarytool 公证：

xcrun notarytool submit build/macos/MyGame.app --apple-id $APPLE_ID --password $APP_PASSWORD

• 公证后产品上架 Mac App Store 或自托管分发都更顺畅

六、Store 发布与上架材料

1. 商店素材清单

各商店（App Store / Google Play / Steam）素材大同小异，提前准备：

• 图标：多种尺寸 PNG，含圆角/透明规范
• 截图：至少 5-8 张，按商店推荐分辨率
• 宣传图 / 视频：Google Play 需要短视频（可选），Steam 需要商店页
• 隐私政策：链接必须有，且内容与真实数据收集一致

2. 元数据与本地化

• 标题与描述本地化到目标市场语言，关键词优化（ASO）
• 年龄分级问卷如实填写（有暴力/抽卡内容影响分级）
• 版本说明（What’s New）记录每次更新，配合 热更新与热重载 的节奏

3. 上架后的验证

• 下载商店正式包，验证安装、更新、内购与广告 SDK 回调
• 监测崩溃（Crashlytics / Sentry 等 SDK 接入）
• 关注商店控制台的安装量、卸载率与评分，指导下一次迭代

七、自动化发布与 CI/CD

1. bob 的 headless 构建

bob 可在无编辑器环境下运行，天然适合 CI。一个完整的发布流水线：

#!/usr/bin/env bash
set -euo pipefail

VERSION="${1:-1.0.0}"
PLATFORM="${2:-html5}"

# 1. 拉取依赖（扩展模块）
java -jar bob.jar --resolve
# 2. 构建
java -jar bob.jar --build
# 3. 打出目标平台包
java -jar bob.jar --bundle --bundle-output "build/$PLATFORM" --platform "$PLATFORM" --variant release
# 4. 生成热更产物
java -jar bob.jar --build-resources "build/liveupdate"
# 5. 上传
aws s3 sync "build/$PLATFORM" "s3://cdn/mygame/$VERSION/$PLATFORM/" --acl public-read

在 CI（GitHub Actions 等）中按 tag 触发，即实现「打 tag → 自动出包 → 自动上传 CDN」。完整流水线实践可参考 DevOps 专题。

2. 版本号与构建号管理

• 用环境变量注入版本号：bob 支持从 game.project 读取，也可在 CI 中动态替换
• 构建产物按版本归档（build/1.0.3/ios/），与热更 manifest 的版本一一对应
• 维护一份 versions.json 记录「当前商店版本 / 热更版本 / 内容版本」三元组，便于运营与回滚（见 热更新与热重载)

3. 签名密钥的安全存放

CI 中签名材料属于敏感信息：

• keystore / .p12 存入 CI 的 Secret 仓库，构建时挂载
• 私钥不进 git，构建机隔离；必要时用 KMS 托管
• 每次构建记录签名指纹，审计「哪个构建用了哪把钥匙」

4. 发布后的自动化验证

• CI 出包后跑冒烟脚本：HTML5 用 Playwright 打开页面确认加载；Android 装模拟器启动
• 校验包体大小、资源清单完整性（对比 manifest 与预期哈希）
• 自动上报构建产物到内部发布页，供测试人员取包

八、性能与包体优化

1. 包体优化清单

• 资源压缩：图片转压缩纹理、音频开启压缩（见 编辑器与资源管线)
• 去除冗余：构建日志检查未引用资源，bob --exclude 排除调试内容
• 按平台裁剪：不同平台用不同资源目录（如移动端低清、桌面高清）
• 引擎体积：Defold runtime 本身极小（<2MB），体积主要来自资源

2. 运行时性能

• 用 Profiler 定位 CPU 热点：Lua 脚本 vs 物理 vs 渲染
• 图集合批降 Draw Call；粒子数量与对象池管理（见 复杂逻辑与状态管理)
• 移动端控制全屏分辨率与后处理成本

3. 平台专项优化

4. 发布前检查清单

• game.project 各平台 package/bundle 正确
• 图标、启动图、商店素材就位
• 签名/keystore 可重复构建
• 热更 manifest 可拉取、可回滚
• 真机安装验证通过
• 隐私政策、内购、广告配置完整

九、总结

Defold 的跨平台发布是一条「配置驱动」的流水线：game.project 声明平台参数，bob 生成产物，签名/证书分别解决各商店的身份要求，HTML5 则天然免审核。真正决定发布成败的不是构建本身，而是前期的资源规划（包体）、平台的配置细节（签名/元数据）以及发布后的运营（热更与监控）。

从引擎介绍到脚本、物理、UI、热更，再到本文的发布收尾，Defold 专题已覆盖一条完整的独立开发链路。祝你在各平台顺利交付作品。