简而言之，优化方法仍然适用，但 Forge/NeoForge 不允许模组修改 EventBus。
项目已废弃 简而言之，优化方法仍然适用，但 Forge/NeoForge 不允许模组修改 EventBus。 与来自 Minecraft 或 Forge 本身的类不同，EventBus 不是作为游戏的一部分加载的，而是作为“库”加载的，这使得通过 Mixin 或 Transformer 修改 EventBus 变得“不确定”。 在 1.2.0 版本中，为了进一步提高性能，我使用了一些脏黑客手段（或者如果你愿意的话，称为“非标准方法”）来修改 ASMEventHandler 类，但这不幸地在 1.18.2+ 版本中失效了。这些版本现已存档，可能不会再收到进一步更新。 FastEvent 是一个 Forge/Neoforge 优化模组，它优化了 Forge 中最基础的系统之一：事件系统。 有多快 为每个支持的 Minecraft 版本制作测试用例并不容易，尤其是这些版本的事件系统各不相同。因此，我将提供我为 Cleanroom 项目制作的 PR 中的 JMH 基准测试报告，其中我使用了与 FastEvent 相同的优化方法： 注册 10,000 个事件监听器，发布事件 0 次： Benchmark Mode Cnt Score Error Units BusPerformanceTest.register10000Legacy avgt 5 1126.498 ± 284.633 ms/op BusPerformanceTest.register10000Modern avgt 5 1058.961 ± 173.586 ms/op 快约 6.4%。 注册 1,000 个事件监听器，发布事件 10,000 次： Benchmark Mode Cnt Score Error Units BusPerformanceTest.register1000test10000Legacy avgt 5 4407.963 ± 4250.643 ms/op BusPerformanceTest.register1000test10000Modern avgt 5 3550.578 ± 1991.352 ms/op 快约 24%。 原始 PR https://github.com/CleanroomMC/Cleanroom/pull/328#issuecomment-2801099504 它是如何工作的 （极客技术细节警告） 当开发人员使用 @EventBusSubscriber 和/或 @SubscribeEvent 订阅事件处理器时，EventBus 无法神奇地获取事件处理器，而只能获得一个 Method 对象。因此，最直接的方法是使用该对象直接调用： method.invoke(...) 。此调用最终将由 JVM 重定向回原始方法，从而使事件处理器在订阅后能够接收事件。 但这种（ method.invoke(...) ) 确实很慢。为了加快速度，EventBus 将在运行时为其发现的每个方法生成事件处理器类，从而消除基于反射的昂贵调用。 但是生成类会引入另一种延迟。为了更快，FastEvent 用 lambda 构造取代了类生成，从而加快了事件处理器的构造速度。另一个好处是 lambda 是“隐藏”的，允许 JVM 执行更多优化。 如果你恰好了解一些 Java 知识，下面的代码示例可能会让你更直观地理解： class Listen { public void onEvent(Event event) { } } Listen lis = new Listen(); // EventBus will generate a new class for every event handler class IEventListener$Listen$onEvent implements IEventListener { private Listen instance; public IEventListener$Listen$onEvent(Listen instance) { this.instance = instance; } @Override public void invoke(Event event) { instance.onEvent(event); } } IEventListener handler = new IEventListener$Listen$onEvent(lis); // FastEvent uses lambda to generate event handler IEventListener handler = lis::onEvent;
在鱼乐云资源中心浏览该资源,登录后可一键安装到你的游戏服务器。