《Defold游戏开发入门》3.3 网络、多平台与性能优化

3.3 网络、多平台与性能优化

“在我的电脑上能跑”只是开发的中点。网络会引入延迟和不可信输入，平台会带来屏幕、输入、内存和签名差异，性能问题会在资源最丰富的场景集中出现。成熟的做法不是等发布前再救火，而是在设计期建立测量、预算和目标设备验证的习惯。

网络：先确定谁拥有事实

多人游戏最重要的问题不是选择传输协议，而是谁有权决定游戏事实。若每个客户端都可自行宣布“我命中了敌人”“我的分数加了十”，作弊和不同步几乎不可避免。常见的权威模型是服务器维护关键世界状态，客户端发送输入或请求，服务器验证后广播结果。小型合作游戏可采用较轻模式，但仍应区分可预测的本地表现与必须确认的共享结果。

网络消息应是小而稳定的数据协议，包含类型、版本、必要字段和顺序信息。不要直接序列化整个 Lua self 表：其中可能有本地引用、临时缓存和无法兼容的字段。把协议写成文档，例如 move { tick, direction }、spawn { id, type, x, y }、damage { target_id, amount }，并在收到时验证类型、范围和权限。网络层只负责传输与编解码，游戏规则仍应由规则层决定。

延迟不能被消除，只能被设计。玩家移动等即时反馈可在本地预测，再由服务器校正；射击、命中和购买等关键操作需要明确确认；界面应在等待时显示适当状态而不是假装已经成功。先做一个网络延迟模拟开关，在 100ms、200ms 和丢包条件下观察体验，远比局域网顺畅时乐观得多。

跨平台从输入与显示开始

桌面、移动和 HTML5 的差异首先体现在输入。所有玩法使用动作名，UI 同时支持鼠标、触摸和键盘/手柄导航；不要把“鼠标悬停”作为唯一提示。触屏按钮要有足够热区，横竖屏切换需要明确策略，文本应考虑字体覆盖和小屏可读性。把这些要求放入每个功能的验收条件，而不是交给最后一次适配。

显示适配要区分世界与 UI。世界相机可以根据可见范围处理不同宽高比，UI 则使用 GUI 布局和调整策略保持边距与层级。选择几台代表设备或模拟尺寸：最窄屏、最长屏、低分辨率屏和桌面窗口。每次改 HUD、菜单或镜头后都至少检查这些尺寸，避免某一个安全区遮住关键按钮。

构建前检查 game.project 中的应用标识、图标、方向、启动集合、版本号及平台配置。Debug 构建适合诊断，Release 构建会移除部分开发信息和分析能力，不能仅用 Debug 的表现代表最终包。打包时生成构建报告，查看资源类型、目录和压缩后的占比；它能告诉你包体究竟大在图片、音频还是某个意外被引用的目录。

性能的测量顺序

优化的第一原则是先测量。先确认目标帧率和目标设备，再在最坏场景采样：屏幕上最多敌人、最多粒子、最大 UI、最长音频和复杂关卡同时存在的时刻。Defold 的调试构建提供运行时 profiler 和构建报告，可用于区分 CPU 帧时间、渲染、脚本、物理和资源问题。没有数据时的“优化”经常只是把代码变复杂。

当帧率下降，先判断瓶颈类型。脚本瓶颈常来自每帧大循环、频繁字符串/表分配、重复查找和过多消息；渲染瓶颈可能来自过多绘制调用、大纹理、复杂 Shader、透明重叠和粒子；物理瓶颈可能来自大量动态刚体或无意义的碰撞配对；加载瓶颈来自资源体积和同步初始化。不同瓶颈的修复方向完全不同，因此 profiler 截图和可复现场景应成为性能问题的第一附件。

内存、资源与生命周期

磁盘包体与运行时内存不是同一件事。小型压缩图片解码后可能占用大量纹理内存，大量短音效和 GUI 节点也会积累。观察资源在何时加载、何时不再需要，并让场景切换有明确清理边界。把所有关卡资源常驻以换取加载速度，通常会在移动端付出更高内存代价；频繁装卸又会带来卡顿。应根据真实关卡节奏选择预加载窗口。

HTML5 还需要特别关注堆大小和下载体验。为最重场景测量内存余量，使用合理而非盲目的堆配置；对大资源评估初始下载、缓存和加载界面。移动端则应在真实设备上观察后台切换、内存压力和音频中断。平台问题常常无法只靠编辑器预览发现。

排查方法胜过猜测

遇到问题时先缩小范围：它只在某个平台发生吗，只在 Release 发生吗，只在某张地图发生吗，是否可由一个最小集合复现。保留错误日志、设备型号、构建版本、复现步骤和截图。把“偶尔卡住”改写成“Android 某机型，在第 3 关连续重开三次后，暂停按钮触发时帧时间从 16ms 升至 80ms”，才能让自己或他人有效调查。

为发布建立 checklist：新安装启动、升级覆盖、离线运行、不同语言字体、横竖屏、最重关卡、暂停与恢复、存档、失败重试、音量设置、网络断开、目标商店要求。每项标记设备、版本和结果。发布并不是一次构建命令，而是对玩家真实路径的系统验证。

本章练习是选择一个最重的测试场景，记录优化前后的帧时间、内存和包体；为三种输入设备验证同一套动作；生成一次构建报告并列出前三大资源；模拟网络延迟并写下哪些事件必须由权威端确认。完成这些工作后，你会以工程证据而不是感觉来推进项目。

为网络功能划定最小范围

第一次加入网络时，不要从实时对战开始。先完成一个低风险功能，例如上传高分、下载每日挑战配置、查询好友的幽灵记录，或在大厅显示房间列表。它们能让你练习请求、超时、重试、认证、版本兼容和失败 UI，却不会立刻要求处理实时同步。每一个请求都要有加载、成功、失败和取消路径；网络不可用是正常状态，不是异常到可以忽略的边角。

实时玩法的最小原型也应只同步一种交互。比如两名玩家各自移动一个方块，服务器每隔固定 tick 广播状态；先记录延迟、丢包和重连后的行为，再增加射击、伤害和复杂地图。用一个稳定的对象 id 映射网络实体，不要用本地创建顺序或内存地址当身份。断线时要定义对象是否冻结、是否由 AI 接管、是否立即结束对局，不能把这些决定留给某个偶然发生的回调。

安全与隐私同样是网络设计的一部分。客户端传来的分数、购买结果、解锁状态和匹配参数都应被视为不可信输入；密钥不要硬编码在可发布包中；日志不要打印令牌、个人资料或完整请求体。即使是小型原型，也应把敏感配置放到可替换的构建环境或受控服务端，养成正确边界后项目扩大才不会被迫重构。

平台测试矩阵

跨平台验证需要一张矩阵而非“在几个设备上点一下”。行可以是 Windows、macOS、Android、iOS、HTML5，列可以是冷启动、输入、显示比例、音频、后台恢复、存档、网络、性能和 Release 构建。项目不必一开始支持所有平台，但对每个承诺支持的平台都应写出最低系统、代表机型和已知限制。未验证的平台应明确标记为实验性，而不是让玩家承担猜测成本。

HTML5 特别值得单独检查：首次下载和缓存、浏览器音频自动播放限制、窗口焦点丢失、移动浏览器触摸、内存上限和页面嵌入尺寸。移动端要检查安全区、来电或后台恢复、横竖屏锁定、网络从 Wi-Fi 切到蜂窝的行为。桌面端则要检查多分辨率窗口、全屏切换、鼠标捕获和本地文件权限。统一动作和状态架构会减少适配成本，但不能消除这些真实差异。

建立性能预算

与其笼统要求“保持流畅”，不如为目标设备写出预算：目标帧时间、可接受的加载时长、内存上限、初始下载大小、单屏敌人数量、粒子最大并发、GUI 节点上限。预算不必一开始精确，但应能指导取舍。当设计希望同时增加两倍敌人、全屏模糊和高分辨率背景时，团队可以讨论哪个预算会被挤压，而不是等用户反馈卡顿后才争论。

每次优化记录基线、改动、测量环境和副作用。例如“Android A 设备，80 敌人场景，平均帧时间从 24ms 降到 17ms；通过合并图集和限制透明粒子；代价是背景动画密度降低”。这类记录让未来成员理解为何某个看似保守的限制存在，也能避免同一优化问题被反复试错。

性能问题的典型误区

不要把 print() 大量留在高频路径，调试日志本身可能改变性能形态；不要在未测量前把每个对象都改成对象池，复杂生命周期可能引入更严重 bug；不要只看平均帧率，卡顿常来自偶发峰值；不要只测试空白场景，资源和 UI 同时出现时才接近真实压力；不要用一次桌面测试推断移动端结论。性能工程的核心不是某个神奇技巧，而是可重复的场景、可靠的指标和一次只改变一个因素的纪律。

发布后的观察

发布不是测量终点。为合法且透明的错误报告、版本分布、启动失败和性能反馈建立渠道；将崩溃或卡顿报告与设备、构建号和复现路径关联。收到问题后先保留证据和受影响版本，再做最小修复并在相同条件回归。不要为了紧急修复跳过 Release 验证，否则很容易以新问题替换旧问题。稳定的发布节奏来自小改动、清楚说明、可回退构建和持续观察。

优化后的回归验证

一次性能改动可能改变画质、行为或资源生命周期，因此完成优化后不能只看指标。重新运行首启、完整一局、暂停恢复、场景切换、最重关卡和目标平台的 Release 构建；比较操作反馈、音频同步、碰撞与 UI 是否仍正常。若通过减少更新频率或延迟加载取得性能，应特别检查玩家是否感到输入滞后或出现可见加载空白。

把优化前后的构建报告、profiler 截图、设备信息和测试结果放在同一记录中。未来发现新瓶颈时，你可以判断它是旧问题复发、资源增长造成还是平台升级改变了行为。性能工作不是一次清扫，而是随着内容增加持续维护预算的过程。

团队化的发布节奏

即使是个人项目，也应把开发、测试和发布看成不同阶段。开发构建允许详细日志和诊断开关；测试构建让外部试玩者按固定版本反馈；发布候选构建冻结功能并集中处理阻断问题。每个阶段使用明确版本号，问题报告带上版本号和平台，才能避免“我已经修了”与“我仍复现”的沟通错位。

若项目使用自动构建或持续集成，应让它至少执行资源引用检查、最小构建、版本注入和产物归档。自动化不替代真机测试，但它能防止错误配置、遗漏文件和不可复现构建进入人工测试。把手工步骤逐步转化为可执行检查，是跨平台项目扩张后保持稳定的关键。

版本兼容与故障恢复

网络协议和存档都要考虑版本演进。请求中携带协议版本，服务端对不兼容版本给出可理解的升级提示；新增字段采用可选默认值，删除字段前统计旧版本使用情况。发生服务端短暂错误时，客户端应限制重试次数、使用退避并允许玩家取消，避免网络恢复后产生请求风暴。离线可玩的核心内容不应因为排行或配置服务不可用而完全无法进入。

性能故障也需要恢复策略。资源加载过慢时显示进度和可取消选项，内存接近限制时优先释放非关键装饰资源，低性能模式应能在设置中持久化。恢复策略必须在压力场景中实际演练；只在文档里写“发生时降级”不会让运行时自动安全。

将这些异常路径同样放入测试矩阵：断网后重连、版本升级后读取旧存档、低内存恢复、构建报告异常增长、目标设备首启失败。发布质量往往由异常路径决定，因为正常路径早已在开发者电脑上被反复走过。

团队还应为每项关键指标设定告警阈值。比如构建包体超过基线、首帧时间显著增加、最重关卡帧时间超过预算时，构建流程或发布评审应主动提示。早期发现趋势比临近发布时做大规模压缩更安全，也更能保护玩法迭代时间。

若某一平台长期无法达到同一视觉预算，应明确做平台分级：保留相同规则和关卡内容，替换非关键纹理、粒子、阴影或更新频率。用有意设计的降级保持一致体验，比让设备在高负荷下随机卡顿更尊重玩家。

所有平台差异都应在设置、商店描述或首次运行提示中如实说明。玩家能够理解的限制比隐蔽的行为差异更容易获得反馈，也让支持和排错有清晰起点。

在网络和性能问题修复后，重复验证离线核心循环。在线功能、统计和远程配置应该增强体验，而不应成为打开主菜单、进入练习关或读取本地存档的单点故障。

把这条原则写入发布准入条件，能避免功能扩展时无意削弱最基本的可玩性。

即使暂时没有自动化系统，手工清单也应明确执行者与验证设备。

责任清楚，发布风险才不会被无意遗漏。