无框玻璃板从入门到入土，从出土到废弃

Cat_A***

无框玻璃板做完了，从设计到算法，从开发到优化。这是自 1.21.20 更新以来，我做过最复杂的方块。它有些成功，但其实相当失败，最后的结果可能是废弃这个附加包。不过我已经把附加包发出来了，版本是 1.21.40+（截至本文编写时，这个版本有 .20 和 .21 这两个测试版），欢迎下载附加包 v1.2，告诉我它的崩溃过程。

我们来简化一下整件事。无框玻璃附加包的 v1.2 有完整的无框玻璃板功能，但是完整功能在大多数设备应该都跑不起来，所以我做了子包，结果它崩溃了。具体表现是进入带这个附加包的存档时瞬间出错，提示“加载此世界时出错。”（本地化键名：disconnectionScreen.internalError.cantFindLocal。）

排查了原因，我发现是 manifest.json 文件中 subpacks 字段的问题，将这个字段设为空数组就不会崩溃了。

所以现在无框玻璃附加包处于一个尴尬的位置，现在我只能等，看看他们会不会修那个 bug。

---

回到上一篇帖子。当时我把速度提到了 28.9 b/s（b/s 就是方块每秒的意思），代码已经优化过了，似乎没法再提升了。要继续提高速度，只能从原理入手。

无框玻璃板为什么这么慢？因为每个无框玻璃板都需要获取上下两个方块的状态，根据它们设置自身状态。简单来说，放置无框玻璃板后，系统处理它们的过程分三步：

• 首先获取周围方块，如果是固体方块或玻璃类方块就连接（状态设为1，伸出部分玻璃板），其中如果是相同的玻璃板，进一步连接（状态设为2，去掉边框）；
• 获取上下方块的状态，决定这个方块的顶部和底部框是否渲染以及渲染多少；
• 对相邻的六个方块重复第二步操作。

优化代码前，这么做还可以；优化代码后，第二步必须放在第三步后面执行了，而且要加上延迟。就这么一加，速度提高到了约 42 b/s。

检查了一下，我发现其实不用每次都更新上下两个方块的连接状态。于是我在列表中去除了那两个字符串，现在速度提高到了 54 b/s。

---

现在有个问题，与无框玻璃几百的处理速度相比，无框玻璃板的速度简直捉襟见肘——太慢了，还是太慢了，根本不是一个量级的。

我发现每次用命令放置大量无框玻璃板时其实不用更新周围方块的上下状态，因为对于每一个方块，它都刚被放下，会触发相关逻辑。只有手动放置时需要更新周围的无框玻璃板，因为另一个无框玻璃板是旧有的。找了找，我果然看到了想要的东西——beforeOnPlayerPlace 触发器，在玩家放置这个方块前触发。注意是“玩家”，而不是命令或其他的，所以可以利用这个把玩家逻辑和命令逻辑区分开。虽然是 before 触发器，我们仍然可以用 system.run 让它变成 after 触发器。

就因为这个想法，无框玻璃板的速度飙升到了 236 b/s。以上都是中秋节之前那天晚上的工作，“速度提上来了，那大概可以发布了吧，中秋节可以好好休息一会儿了，”我这么想着。殊不知，这才是噩梦的开始……

---

9 月 15 日，中秋假期第一天早上 8 点，我开始了十六色无框玻璃板的测试。

“刚才测试了一下添加16色染色玻璃板会怎么样，不出意外，卡崩了。”

从1.21.40的首个测试版开始，无论有没有附加包，进入存档时总会莫名其妙卡一下，然后才开始加载。起初我只知道服务端一直未响应，今天又看了看旁边的参数，才知道其中还有奥秘。

测试版顶部文字第二行中，ServerTime 是服务端响应时间，单位是毫秒；旁边的 Mem 是目前使用的内存，HighestMem 是这次会话（从启动 MC 到大退称为一次会话）中使用的最高内存，而 FreeMem 是目前可用的内存，它们的单位都是 MiB。

一开始进入游戏，内存只用了约 200MiB，在可接受范围内，但服务端一直不响应。之后内存使用量激增，从 500MiB 到 2GiB，4GiB，最后到达了恐怖的 6GiB（对于我这渣机而言），此时 FreeMem 只剩 500MiB 了。之后调度了最后一些内存过去，使用量到达了顶峰——7GiB，FreeMem 仅剩 32MiB。之后，由于不合理的内存请求，游戏进程被系统结束，崩溃。而且最后那段时间里想截屏都几乎不可能，从顶部划下通知栏也不太可能，回到桌面都需要时间加载。

“所以无框玻璃板的发布严重受阻，很可能不会发布了。”当时我这么说。

之后，我花了近两个小时寻找原因。一开始我认为是附加包有什么未知的语法错误或模式错误，还没有相关的内容日志，所以崩溃了。但似乎不是，明明一个黄绿色无框玻璃板都运行得好好的，加上其他 15 种颜色的就不行了吗？这种情况发生的概率很小，不过还是要排查一下的。确定了不是这个原因，我就认为是 16 种无框玻璃板超出了某种限制，却没有提示，导致计算量指数级上升。继续测试，我发现我的手机能带动两种无框玻璃板，再加两种就崩溃了。此时，我在现实生活中有点要应付的事，于是暂时停止了研究。下午外出旅行，照样没时间。

---

假期第二天，我继续测试手机的极限，结果就是最多能带动三种无框玻璃板，而且这还是我等了好几分钟的结果。（这是当时的图片，可以看到内存占用量真的很多。）（运行结果。）

之后我测出了慢速的原因——方块状态太多。一个无框玻璃板就要那么多状态，17 种无框玻璃板（算上没染色的那个）当然要卡爆手机。于是我提出了解决办法——子包。

我花了几个小时做好了简化版的渲染，通过去除顶部渲染提高效率。结果确实很好，大多数玩家都不怎么关心那里，因为玻璃板通常是窗户，窗户的顶边和底边总是固体方块。（在性能和美观之间找平衡，性能当然重要，不然都没人用我这附加包。美观也要考虑，总不能太简陋了，那样照样没人用。）

“这样……总该可以发布了吧……”我活动了下手指，站起来伸懒腰。没想到，噩梦的进度条甚至没有过半……

---

今天是假期最后一天，也是中秋节。我打开 MC，准备看看无框玻璃板，结果突然提示“加载此世界时出错”！没错，这就是帖子刚开始时我说的那件事。于是本该美好的假期变成了灾难，我花了一个上午都没解决这个问题，倒是有了点新结论——不仅是 1.21.40，在以前的版本中，方块状态太多照样会崩溃，现象大体一致。contents.json 也加了，各种方法也试过了，我甚至怀疑是不是换行符（\n）的问题，结果当然不是。

开发了几年的附加包，这肯定是有史以来我遇到的最奇怪的事，一个好好的附加包到了第二天就不能用了？太荒谬了，就像勾股定理是 a^2.013 + b^2.013 = c^2.013 一样。

下午把作业写完了，现在我正在打字，把这个中秋节开发附加包的历程记录下来。放假时，大家有一天都不刷视频（哪怕一眼也算）的经历吗？反正今天我是做到了，无框玻璃板的糟心事太让我难受了。

襄方块***

/storage/emulated/0/Androⅰd/data/co.pamobile.minecraft.addonsmakr/AddonsMaker/测试没什么好说的 从来凑字数的.mcaddon