跳转至

附加包性能优化

来源信息
译文信息

说明

本文内容主要基于多方社区反馈整理，因此可能存在概括性、主观性或彼此矛盾之处。优化附加包时应始终结合实际测试判断，本文不能替代在多种设备上的真机验证。

附加包性能至关重要。即使技术上最完整的附加包，如果大多数玩家设备无法流畅运行，也很难称得上成功。开发附加包时，应始终考虑到很多玩家使用的设备性能远低于开发设备，移动端尤为明显。因此，设计时就应预留性能空间，并尽可能在低端设备上测试。

本文按基岩版各子系统分类，列出若干常见的性能考量。这些条目并不构成铁律，只适合作为排查和优化方向的参考。

生物群系与特征生成

生物群系

  • 生物群系系统整体效率较高。
  • 通常能较好处理高度图的大数值。
  • climate组件会产生大量粒子风暴。

特征生成

  • 生物群系生成通常比特征生成更少卡顿。
  • 单个区块内执行数百次多方块特征迭代，性能损耗较低。
  • 单个区块内执行数千次多方块特征迭代，会显著影响游戏体验。
  • 单个区块内执行数十万次单方块特征迭代，性能损耗较低。
  • 单个区块内执行数千个特征实例，性能成本较低。
  • 单个区块内执行数万个特征实例，会显著影响区块加载。
  • 单个区块内执行数十万个特征实例，将导致区块加载极度缓慢。

方块

材质

  • 应始终使用渲染需求最低的材质类型。

alpha_blend的性能差于alpha_test，后者又差于opaque。

数量与类型

  • 应尽量避免并减少流动液体。

更新

  • 应尽量减少方块更新。

命令

数量与类型

  • 应尽量减少每刻执行的命令数量。

应避免每刻执行/effect和/gamemode等命令，这些操作对性能影响显著。

  • 应避免在运行时进行大规模clone、fill和结构加载。

将大型操作拆分为多刻执行的多个命令，可以避免卡顿。建议使用结构加载动画。

选择器

  • 应避免对过多实体执行函数，导致执行次数过多。
  • 执行记分板命令的成本高于多次运行实体选择器。
  • 使用c=1确保选择器在找到第一个实体后停止，可以提升性能。
  • 当多个命令共享相同选择器时，应改用函数，避免重复解析。

标签与记分板

  • 在大规模使用时，记分板的性能通常优于标签。

实体

  • 实体通常是各子系统中性能影响最大的要素，应尽可能减少。

组件

  • 飞行生物寻路计算的性能消耗显著。
  • 飞行生物通常更容易暴露性能问题。

如有可能，建议通过动画模拟飞行生物。

虚拟实体

  • 在不包含寻路等重型组件时，虚拟实体与常规实体的性能影响相当。

几何结构

骨骼

  • 骨骼数量未观测到明显性能影响。

元素

  • 除极端情况（数千元素）外，元素数量通常不成问题。

材质

  • 应始终使用实现预期效果所需的最低材质。
  • 不确定时，可参考材质定义文件，同时考虑材质继承系统。

数量

  • 应尽量减少任意时刻加载的实体数量。

保持30个以下为最佳。

光照

地图设计

  • 空心区域即使不可见，也仍会导致光照计算卡顿。

填充未使用的封闭空间可以避免此问题。

  • 保持昼夜恒定可以避免光照重新计算。

光源

  • 基岩版会动态计算光照，不同光源的性能成本并不相同。

光源方块的性能最佳，因为它没有粒子、渲染和特殊状态逻辑。

火把因为存在粒子、渲染和连接状态逻辑，性能问题略多。

含最少组件的自定义光源方块，是性能与美观之间的合理折中。

对比表格

光源类型 评分 红石更新 动画纹理 光照更新 刻更新 粒子效果 渲染
光源方块 1 否 否 是 否 否 否
灯笼 4 否 是 是 是 否 是
自定义方块 2 否 否 是 否 否 是
蘑菇 3 否 否 是 是 否 是
红石灯 3 是 否 是 否 否 是
荧石 3 是 否 是 是 否 是
海晶灯笼 4 否 是 是 是 否 是
火把 4 否 否 是 是 是 是
红石火把 5 是 否 是 是 是 是

Molang

递归

  • 尽量减少递归使用。
  • 深度嵌套的循环结构会导致性能问题。
  • 适时使用break跳出循环。

结构体

  • 避免结构体过深，每层嵌套都有性能损耗。

变量

  • 尽量使用临时变量减少内存占用。
  • 应根据脚本类型考虑变量计算频率。

纹理

texture_list.json

  • 过多纹理会严重影响性能，应创建texture_list.json文件。

数量

  • 建议不超过3000个纹理。

Render Dragon引擎的限制为4096个纹理，而1.16版本原版已经使用了约800个。

分辨率

  • 最大支持16384x16384。
  • 推荐最大4096x4096，以保证低端设备兼容性。
  • 应注意纹理图集化处理，大尺寸纹理可能影响低端设备的图集生成。
  • 应根据可视距离需求确定必要纹理尺寸。

交易系统

村民交易在达到60项以上时会导致性能问题，甚至可能引发设备崩溃。建议拆分到多个村民或自定义实体/NPC中。测试表明，30项交易是安全阈值。

可能与JSON界面系统有关。

音效

数量

  • 已注册音效总数会影响性能。

压缩

  • 音效压缩可以显著减小包体积。
  • 在Switch等老旧或低功耗设备上效果尤为明显。
  • 基岩版使用的FMod简单API会将所有音效解压为WAV格式后加载到内存中，因此不会带来CPU性能提升。

流式音频不在此列。

流式处理

  • 体积超过500KB或时长超过1分钟的音效，应采用流式处理。

红石

区块边界

  • 应避免红石电路跨越区块边界。

命令方块

  • 构建大型命令链时，应垂直堆叠于单个区块内。
  • 尽可能用函数和附加包替代命令方块。

常加载区域

  • 总区块数比常加载区域更需要关注。
  • 非必要时应避免动态区域。
  • 最佳实践是将常加载区域限制在单个区块。

所有持续运行的红石装置都应置于这个区块中。

  • 应通过/testforblock测试并及时卸载不再需要的常加载区域。

文件管理

  • 过多文件会严重影响性能，应创建contents.json文件。