附加包性能优化¶
基岩版的玩家群体横跨多种平台，涵盖高端主机与入门级移动设备。一个技术上出色的附加包，如果在低性能设备上造成明显卡顿，其价值便大打折扣。因此，将性能意识贯穿于附加包开发的各个阶段，是负责任的开发者的应有之义。
注意
本页内容主要来自社区实测与经验总结，部分结论可能因版本、设备或具体配置不同而存在差异。不应将这里的任何建议视为绝对规则，始终应以实际设备测试为准。
生物群系与地物¶
生物群系¶
- 生物群系系统本身的性能开销相对可控。
- 高度图中设置较大数值通常不会造成明显问题。
climate组件可能引发大规模粒子风暴，应谨慎使用。
地物¶
- 地物放置通常比生物群系本身更容易引发延迟。
- 每区块多方块地物执行数百次迭代的性能开销可以接受。
- 每区块多方块地物执行数千次迭代会对游戏体验产生负面影响。
- 每区块单方块地物执行数十万次迭代的性能开销同样可以接受。
方块¶
材质¶
- 始终选用能实现目标效果的最低开销材质：
- 半透明（alpha blend）开销高于透明镂空（alpha test），后者高于不透明（opaque）。
数量与类型¶
- 应尽可能减少流动液体的数量。
更新¶
- 应尽量减少方块更新的频率与范围。
命令¶
数量与类型¶
- 尽量减少每刻运行的命令总数。
- 每刻都执行
/effect或/gamemode对性能影响显著，应当避免。 - 应避免在运行时执行大范围克隆（clone）或填充（fill）操作。
- 如有必要，可将大操作拆分为多个较小的命令，分散到多个刻执行，以避免卡顿尖峰。
目标选择器¶
- 确保函数不会在过多的实体上同时执行，导致命令被重复调用过多次。
- 执行一次记分板命令的开销高于多次解析同一目标选择器；合理权衡。
- 使用
c=1可让选择器在找到第一个目标后停止，有助于提升性能。 - 若需以同一选择器执行多条命令，将其整合为函数可避免反复解析选择器。
标签与记分板¶
- 在大规模状态管理场景下，记分板的性能优于标签。
实体¶
实体在各子系统中往往是性能开销最大的来源，应尽量减少加载实体的总数。
组件¶
- 飞行生物的寻路有显著性能开销。
- 飞行生物总体上容易出现性能问题，如有可能，可考虑用动画模拟飞行效果代替真实寻路飞行。
虚拟实体¶
- 虚拟实体的性能开销与普通实体基本相当，但移除寻路等重量级组件后开销会有所降低。
几何体¶
- 骨骼（Bone）数量目前未观察到对性能有显著影响。
- 元素（Element）数量通常不是问题，但在极端情况下（数千个元素）会产生影响。
材质¶
- 同样地，始终选用能实现效果的最低开销材质。如有疑问，可参考引擎材质定义文件，了解各材质的继承链与开销差异。
数量¶
- 任意时刻已加载的实体总数应尽量控制在30个以内，以获得最佳性能表现。
亮度¶
地图考量¶
- 密封空洞区域会因亮度计算而引起延迟——建议填充无用的封闭区域。
- 将世界时间锁定为白天或夜晚可避免动态亮度重算。
光源¶
基岩版的亮度是动态计算的，不同光源的性能开销不尽相同：
| 光源 | 综合评分 | 红石更新 | 动态纹理 | 亮度更新 | 刻更新 | 粒子 | 渲染 |
|---|---|---|---|---|---|---|---|
| 光源方块 | 1 | 否 | 否 | 是 | 否 | 否 | 否 |
| 自定义方块（无特殊逻辑） | 2 | 否 | 否 | 是 | 否 | 否 | 是 |
| 蘑菇 | 3 | 否 | 否 | 是 | 是 | 否 | 是 |
| 红石灯 | 3 | 是 | 否 | 是 | 否 | 否 | 是 |
| 荧石 | 3 | 是 | 否 | 是 | 是 | 否 | 是 |
| 灯笼 | 4 | 否 | 是 | 是 | 是 | 否 | 是 |
| 海晶灯 | 4 | 否 | 是 | 是 | 是 | 否 | 是 |
| 火把 | 4 | 否 | 否 | 是 | 是 | 是 | 是 |
| 红石火把 | 5 | 是 | 否 | 是 | 是 | 是 | 是 |
评分越低，性能开销越小。光源方块开销最低（无粒子、无渲染、无刻更新）；红石火把开销最高。自定义光源方块（极少组件）是性能与美观的合理折中。
Molang¶
递归¶
- 尽量减少递归的使用，尤其避免深层嵌套循环结构。
- 在循环中尽量使用
break提前退出。
结构体¶
- 避免创建过深的结构体，每增加一层都有相应的性能开销。
变量¶
- 优先使用临时变量（
temp.），以减少常驻内存的变量数量。 - 考虑不同变量的计算频率——明确它们在哪类脚本中被计算，按需决定是否缓存。
纹理¶
数量¶
- 使用的纹理总数不应超过3000张。
- Render Dragon的纹理上限为4096张，而原版本身约占用800张（基于1.16时的数据）。
分辨率¶
- 单张纹理的最大分辨率为16384×16384。
- 建议最大分辨率为4096×4096，以保持与低端设备的兼容性。
- 注意纹理会被打包进图集，过大的纹理可能影响低端设备的图集生成。
- 纹理分辨率应按实际所需的细节程度设置，避免无谓地放大。
声音¶
数量¶
- 已注册声音的总数据量据报道会对性能有影响。
压缩¶
- 声音压缩对包体积有极大益处，在旧设备（如Nintendo Switch）上尤为明显。
- 基岩版使用的FMod简单API会在加载时将所有音频解压为WAV格式再载入内存，因此压缩本身不带来CPU端的性能提升——但若采用流式播放（Streaming），则不会发生此类解压行为。
流式播放¶
- 一般而言，体积超过500 KB或时长超过1分钟的声音应设置为流式播放。
红石¶
跨区块边界¶
- 应避免红石电路跨越区块边界传输信号。
命令方块¶
- 构建大型命令方块链时，应尽量在单个区块内垂直排列。
- 在可以使用函数或行为替代的地方，尽量减少命令方块的数量。
常加载区域¶
- 区块总数比常加载区域的数量更值得关注。
- 除非必要，应避免使用动态常加载区域。
- 最佳实践是将常加载区域缩减至一个区块——将所有需要持续运行的红石逻辑集中于此。
- 在不再需要时及时卸载常加载区域（可通过
/testforblock等命令检测条件后执行卸载）。