5.4 平台发布与常见问题排查：出厂验收单

5.4 平台发布与常见问题排查：出厂验收单

本节摘要：发布是把编辑器里的世界交到玩家手里的最后一步：目标平台设置、打包、签名、真机验收，一步都不能省。本节给 Android 与 WebGL 两条主流路线的打包要点，再附一张上线后高频故障的排查清单，覆盖性能、崩溃、资源与构建四类问题。

出厂不是点一个按钮

打包（Build）在概念上只是"把工程编译成目标平台的产物"，但验收出厂的完整流程要长得多：先定目标平台的玩家设置（方向、权限、图标、包名），再处理平台差异（输入方式、文件系统、性能水位），然后打包、签名、真机回归，最后才有资格谈上架。每换一个平台，前面五章积累的"默认假设"都要重新审一遍——开发机的输入是键鼠，手机是触屏；开发机的资源在本地磁盘，WebGL 要走浏览器下载。

平台差异里最容易被低估的是 WebGL：没有文件系统写权限、主线程单线程、内存受浏览器限制。这意味着 PlayerPrefs 受限、多线程被禁、包体要精打细算，压缩格式与首包策略都要按浏览器的脾气来。VR 与主机平台则是另一个量级：前者多出帧率硬指标（必须稳定到头显刷新率）与舒适度设计，后者需要厂商资质与专用工具链，本节不展开，只提醒在立项时把资质周期算进排期。

动手：Android 打包全流程实录

背景：把跟到现在的平台跳跃项目打出一个能在安卓真机上跑的安装包。

操作：第一步，切换目标平台到 Android（文件菜单的构建设置里切换，等待资源重导）；第二步，填玩家设置：公司名与产品名决定包结构，包名按域名倒置惯例填写，最小 API 级别按目标用户机型选；第三步，纹理压缩格式选适配目标机型的通用格式；第四步，构建签名——创建或导入密钥库，正式包与调试包用不同签名；第五步，点构建，产出安装包，真机安装验收。

这一套流程值得固化成编辑器脚本，一键出包：

using UnityEditor;
using UnityEngine;

public static class BuildScript
{
    // 菜单一键构建：打包前自动切场景列表、打场景包
    [MenuItem("Build/Android 发布包")]
    public static void BuildAndroid()
    {
        // 场景列表以代码维护，避免漏加新场景
        string[] scenes = { "Assets/Scenes/Menu.unity", "Assets/Scenes/Level01.unity" };

        BuildPlayerOptions opt = new BuildPlayerOptions
        {
            scenes = scenes,
            locationPathName = "Builds/game.apk",   // 输出文件
            target = BuildTarget.Android,
            options = BuildOptions.None
        };

        var report = BuildPipeline.BuildPlayer(opt);
        if (report.summary.result == UnityEditor.Build.Reporting.BuildResult.Succeeded)
        {
            Debug.Log("打包成功，体积 " + report.summary.totalSize / 1048576 + " MB");
        }
        else
        {
            Debug.LogError("打包失败，查看控制台错误列表");
        }
    }
}
​

结果：菜单里多出 Build 一项，一键产出安装包；真机安装后运行，帧率、触控、UI 适配逐项过验收单。

解读：脚本化打包的价值不止省几次点击：场景列表写死在代码里，"新场景忘了加进打包列表"这类经典事故（编辑器里能跑、包里黑屏）从根上杜绝；构建参数进版本控制，全团队出包配置一致。真机验收重点看三件事——帧率是否达标（编辑器估值不算数）、触控区域有没有按分辨率适配（不同长宽比的安全区）、首次加载时长（Addressables 的首包策略此时见真章）。

变式：同一工程切到 WebGL 出包：关闭开发版选项减小包体、启用压缩、测试目标浏览器的加载时长与内存水位。两次打包对照，能直观感受平台差异不是参数差异，而是运行环境的根本不同。

上线后的排查清单

发布只是开始，运营期的故障排查按四类归档，每类都有固定的第一现场：

性能类（玩家说"卡"）
  第一现场：真机 Profiler 与云端性能监控曲线
  高频病因：低端机纹理过大、实时阴影未关、每帧内存分配引发 GC
  处方：画质分档（低中高三档画质预设），低端机默认低档

崩溃类（玩家说"闪退"）
  第一现场：崩溃聚合平台的堆栈排行（符号化后按出现次数排序）
  高频病因：空引用（资源缺失未判空）、内存不足被系统杀进程、
            某机型专有的图形接口兼容问题
  处方：先修出现频率最高的前五个，频率低于千分之一的低优先

资源类（玩家说"加载失败"或"图没了"）
  第一现场：资源加载报错日志与网络请求状态
  高频病因：远程资源地址失效、首包校验失败、版本更新后旧缓存残留
  处方：加载失败必须可重试，版本号与资源校验做进启动流程

构建类（团队说"包打不出来"）
  第一现场：构建日志的最后一个报错
  高频病因：场景列表含已删除场景、脚本编译错误、签名配置漂移
  处方：打包脚本化加构建机固定环境，失败信息截全存档
​

排查的通用心法与第 5.1 节一致：先看第一现场，再归因，最后动手——线上事故尤其忌讳"凭感觉改一版试试"，每次热更都有再次翻车的风险。

发布前的最后一轮自检

正式出厂前的验收单按勾选执行：所有场景在打包列表内且可独立进入；玩家设置齐全（图标、名称、权限说明）；真机上完整通过一次主流程（启动、进关卡、死亡重开、暂停退出）；弱网或断网状态下游戏不崩（哪怕功能降级）；崩溃监控与性能监控已接入并在真实上报数据。这五项全绿，才有底气把包交给玩家。

发布后：监控不是可选项

清单之外，还要把"上线不等于结束"落成机制。崩溃监控接入后，先约定两个运营指标：崩溃率（崩溃会话占总会话比例，一般产品线卡在百分之一以下）与 ANR 率（应用无响应，移动平台尤其要盯主线程阻塞）。性能侧至少上报三张曲线：启动时长、平均帧率、内存峰值——真机分布比单机测试残酷得多，低端机用户的数据只有靠上报才能看见。这些监控接好后，每一次热更的效果都能用数据复验，排查不再是"玩家说卡、我们猜"。

本节要点回顾

• 发布是流程不是按钮：平台设置、差异处理、打包签名、真机回归，四段不可跳；
• 打包脚本化：场景列表与构建参数进代码，杜绝漏场景与配置漂移；
• WebGL 是另一个世界：无文件系统、单线程、内存受限，按浏览器脾气设计；
• 线上排查看第一现场：性能、崩溃、资源、构建四类各有固定起点；
• 出厂五项自检：场景列表、玩家设置、主流程真机、弱网容错、监控接入。

出厂流程齐了，还差一次全员上场的完整演练。最后一节，把全书知识拧成一个成品。