--- title: 附加包性能优化 mentions: - SirLich - Joelant05 - MedicalJewel105 - TheItsNameless - SmokeyStack --- # 附加包性能优化 ::: warning 本页内容主要基于多方社区反馈整理。因此部分信息可能存在概括性、主观性或矛盾性。优化附加包时请始终自行判断。本页面不能替代在多种设备上实际测试附加包性能。 ::: 附加包性能至关重要，因为即使技术上最出色的附加包，如果大多数玩家设备无法流畅运行也将失去意义。开发附加包时需时刻谨记，许多基岩版玩家使用性能远低于开发设备的终端进行游戏，移动端用户尤为明显。因此应从性能角度设计附加包，并尽可能在低端设备上进行测试。 本指南按基岩版各子系统分类，列出非详尽性能考量事项。各条目不应视为铁律，而应作为识别潜在优化领域的参考。 ## 生物群系与特征生成 ### 生物群系 - 生物群系系统整体效率较高 - 通常能妥善处理高度图的大数值 - `climate`组件会产生大量粒子风暴 ### 特征生成 - 生物群系生成通常比特征生成更少卡顿 - 单个区块内执行数百次多方块特征迭代性能损耗较低 - 单个区块内数千次多方块特征迭代将显著影响游戏体验 - 单个区块内执行数十万次单方块特征迭代性能损耗较低 - 单个区块内数千个特征实例性能成本较低 - 单个区块内数万个特征实例会显著影响区块加载 - 单个区块内数十万特征实例将导致区块加载极度缓慢 ## 方块 ### 材质 - 应始终使用渲染需求最低的材质类型 > `alpha_blend`性能差于`alpha_test`，后者又差于`opaque` ### 数量与类型 - 应尽量避免并减少流动液体 ### 更新 - 应尽量减少方块更新 ## 命令 ### 数量与类型 - 最小化每tick执行的命令数量 > 每个tick执行`/effect`和`/gamemode`等命令应避免，这些操作对性能影响显著 - 应避免在运行时进行大规模clone、fill和结构加载 > 将大型操作拆分为多tick执行的多个命令可避免卡顿，建议使用结构加载动画 ### 选择器 - 需注意避免对过多实体执行函数导致执行次数过多 - 执行记分板命令的成本高于多次运行实体选择器 - 使用c=1确保选择器在找到第一个实体后停止可提升性能 - 使用相同选择器执行多个命令时，应改用函数避免重复解析 ### 标签与记分板 - 记分板在大规模使用时性能优于标签 ## 实体 - 实体通常是各子系统中性能影响最大的要素，应尽可能减少 ### 组件 - 飞行生物寻路计算性能消耗显著 - 飞行生物通常存在性能问题 > 如有可能，建议通过动画模拟飞行生物 ### 虚拟实体 - 虚拟实体与常规实体性能影响相当（不含寻路等重型组件时） ### 几何结构 #### 骨骼 - 骨骼数量未观测到明显性能影响 #### 元素 - 除极端情况（数千元素）外，元素数量通常不成问题 ### 材质 - 应始终使用实现预期效果所需的最低材质 - 不确定时可参考材质定义文件，同时考虑材质继承系统 ### 数量 - 应尽量减少任意时刻加载的实体数量 > 保持30个以下为最佳 ## 光照 ### 地图设计 - 空心区域即使不可见仍会导致光照计算卡顿 > 填充未使用的封闭空间可避免此问题 - 保持昼夜恒定可避免光照重新计算 ### 光源 - 基岩版动态计算光照，不同光源性能成本不同 > 光源方块性能最佳（无粒子、渲染和特殊状态逻辑） > 火把因产生粒子、渲染和连接状态逻辑存在较小性能问题 > 含最少组件的自定义光源方块是性能与美观的合理折中 #### 对比表格 | 光源类型 | 评分 | 红石更新 | 动画纹理 | 光照更新 | Tick更新 | 粒子效果 | 渲染 | | ---------------: | :--: | :------: | :------: | :------: | :------: | :------: | :--: | | 光源方块 | 1 | 否 | 否 | 是 | 否 | 否 | 否 | | 灯笼 | 4 | 否 | 是 | 是 | 是 | 否 | 是 | | 自定义方块 | 2 | 否 | 否 | 是 | 否 | 否 | 是 | | 蘑菇 | 3 | 否 | 否 | 是 | 是 | 否 | 是 | | 红石灯 | 3 | 是 | 否 | 是 | 否 | 否 | 是 | | 荧石 | 3 | 是 | 否 | 是 | 是 | 否 | 是 | | 海晶灯笼 | 4 | 否 | 是 | 是 | 是 | 否 | 是 | | 火把 | 4 | 否 | 否 | 是 | 是 | 是 | 是 | | 红石火把 | 5 | 是 | 否 | 是 | 是 | 是 | 是 | ## Molang ### 递归 - 尽量减少递归使用 - 深度嵌套循环结构会导致性能问题 - 适时使用break跳出循环 ### 结构体 - 避免结构体过深，每层嵌套均有性能损耗 ### 变量 - 尽量使用临时变量减少内存占用 - 根据脚本类型考虑变量计算频率 ## 纹理 ### texture_list.json - 过多纹理严重影响性能，请创建[`texture_list.json`](/wiki/concepts/textures-list)文件 ### 数量 - 建议不超过3000个纹理 > Render Dragon引擎限制为4096个纹理，1.16版本原版已有800个 ### 分辨率 - 最大支持16384x16384 - 推荐最大4096x4096以保证低端设备兼容性 - 注意纹理图集化处理，大尺寸纹理可能影响低端设备图集生成 - 根据可视距离需求确定必要纹理尺寸 ## 交易系统 村民交易在达到60项以上时会导致性能问题甚至全设备崩溃。建议拆分交易至多个村民或自定义实体/NPC，测试表明30项交易是安全阈值。 *可能与JSON界面系统有关* ## 音效 ### 数量 - 已注册音效总数会影响性能 ### 压缩 - 音效压缩显著减小包体积 - 在Switch等老旧/低功耗设备上效果明显 - 基岩版使用的FMod简单API会将所有音效解压为WAV格式后加载至内存，CPU性能无提升 > 流式音频不在此列 ### 流式处理 - 体积超过500KB或时长超过1分钟的音效应采用流式处理 ## 红石 ### 区块边界 - 应避免红石电路跨越区块边界 ### 命令方块 - 构建大型命令链时应垂直堆叠于单个区块内 - 尽可能用函数和行为包替代命令方块 ## 常加载区域 - 总区块数比常加载区域更需关注 - 非必要时应避免动态区域 - 最佳实践是将常加载区域限制在单个区块 > 所有持续运行的红石装置应置于此区块 - 通过/testforblock测试并及时卸载不再需要的常加载区域 ## 文件管理 - 过多文件严重影响性能，请创建[`contents.json`](/wiki/concepts/contents)文件