Adaptive Optimization (Reborn)
一款根据系统负载和游戏内状况动态优化Minecraft性能的模组。
查看大图🧠 Adaptive Optimization — 为 Minecraft 打造的真实自适应性能优化
✅ Adaptive Optimization 现已正式进入稳定版阶段
Adaptive Optimization 已正式进入其稳定开发阶段。
在对其观测、性能分析、持久化、负载归因及性能测量系统进行了一次重大内部重构之后，该模组如今拥有了比以往预览版更强大、更可靠的基础。
Adaptive Optimization 不再仅仅是一个围绕预定义优化行为构建的实验性概念。
它正在成为一个真正的自适应优化平台，其设计目标是：
观察 → 识别 → 诊断 → 实验 → 测量 → 学习 → 改进
当前的稳定版本已能在 Minecraft 中提供真实的性能提升，而未来的预览版将继续扩展其自主优化能力。
⚠️ 重要开发说明
我的模组是在 AI 的大量帮助下开发的。
我仍在学习 Java 和 Minecraft 模组开发，因此即使 Adaptive Optimization 现在被视为稳定版本，这并不意味着不存在 bug 或异常兼容性问题。
稳定意味着当前的基础已达到一个足够可靠的阶段，可以正常使用并持续开发，而无需不断重建核心架构。
我仍然建议在重要存档中使用前，先在自己的整合包中测试新版本，尤其是在非常大或非常规的整合包中。
如果你遇到以下情况：
- 性能回退
- 兼容性问题
- 意外行为
- 卡顿
- 崩溃
- 或 Adaptive Optimization 似乎使某些情况变得更糟
请报告这些问题。
来自真实环境的报告对于改进系统极为有用。
⚙️ 当前版本
目前支持：
Forge 1.20.1
未来计划支持更多 Minecraft 版本和模组加载器。
🚀 Adaptive Optimization 实际上做了什么
🧠 自适应运行时优化
Adaptive Optimization 会在你游玩时持续观察 Minecraft 的行为。
AO 并非完全依赖静态的调整列表，而是构建关于当前工作负载的运行时信息，并利用这些信息来确定可能存在优化机会的位置。
不同的整合包可能表现出截然不同的行为。
AO 正是基于这一现实而设计的。
🔍 真实工作负载检测
Adaptive Optimization 现在可以区分多种不同类型的工作负载，包括：
- 原版 Minecraft
- 模组化工作负载
- 单个模组
- 类和方法
- 客户端工作负载
- 服务端工作负载
- 实体
- 寻路
- 计划刻
- 区块相关工作
- 网络
- I/O
- 渲染
- 命令
- 文件系统活动
- 锁竞争
- CPU 压力
- 内存压力
- 垃圾回收
- 未知或未分类的工作负载
当证据不足时，该模组不需要假装理解某些内容。
必要时，工作负载可以保持为UNKNOWN 状态，直到 AO 收集到更好的信息。
🎯 原版 / 模组归因
AO 可以判断观察到的负载属于：
- Minecraft 原版
- 某个特定模组
- 某个特定子系统
- 某个语义工作负载组
- 或未知来源
这使得优化器能够更好地理解实际消耗资源的是什么，而不是简单地响应全局 FPS 或 TPS 数值。
📊 高级运行时性能分析
性能分析系统已被大幅重建。
Adaptive Optimization 可以跨多个时间窗口分析工作负载行为，并判断某事物是：
- 正在出现
- 持续存在
- 正在消失
- 偶发出现
它还执行基于调用栈的归因，使相关工作负载能够被分组，而不是分散在数十个独立方法中。
这使得 AO 能够更准确地识别真实的性能模式。
⏱️ 真实服务端 Tick 测量
Adaptive Optimization 现在包含了正确的服务端 tick 持续时间测量。
AO 会观察 Forge 服务端 tick 边界，同时使用 Minecraft 自身的内部 tick 计时器作为独立参考。
这些测量保持独立，以便 AO 可以检测以下两者之间的差异：
- Minecraft 的核心 tick 工作负载
- 围绕其周围的额外 Forge/模组工作负载
这为 Adaptive Optimization 提供了更好的可见性，涵盖：
- MSPT
- Tick 不稳定性
- 服务端工作负载峰值
- 模组服务端压力
- 模拟速度下降
监控系统经过特别设计，具有极低的开销。
🧪 因果性能测量
最大的架构变化之一是新的实验性测量系统。
Adaptive Optimization 现在具有独立的测量阶段：
PRE
优化之前的性能。
EXPERIMENT
候选优化生效时的性能。
RECOVERY
优化被还原之后的性能。
该架构正在构建中，以便 AO 最终能够确定一个优化是否真正导致了改进，而不是看到性能变化就假定是优化造成的。
🛡️ 工作负载可比性
Minecraft 的性能是不断变化的。
移动到另一个维度、生成地形、垃圾回收、另一个模组开始活跃，或性能分析器丢失样本，都可能使两次性能测量无法公平比较。
Adaptive Optimization 现在可以检测许多此类情况。
示例包括：
- 工作负载变化
- 目标消失
- 世界变化
- 维度变化
- 资源重载
- 生命周期变化
- CPU 压力变化
- 垃圾回收
- 堆内存变化
- 锁竞争
- 网络突发
- 采样退化
- 缺失观测
如果实验不能被信任，AO 可以将其标记为：
INCONCLUSIVE
而不是学习错误的信息。
🧬 自适应与基于进化的优化
Adaptive Optimization 包含旨在随时间生成、评估、记忆和改进优化策略的系统。
长期目标不仅仅是：
启用优化 X。
而是，AO 正朝着以下方向开发：
确定当前游戏需要什么，测试可能的解决方案，测量它们，拒绝糟糕的方案，保留优秀的方案，并改进未来的决策。
现有的自适应系统正在逐步连接到更新、更可靠的观测和因果评估架构上。
💾 持久学习
Adaptive Optimization 可以在会话之间保存有用的信息。
其持久化系统也已重建和修正，以提供更安全的长期状态处理。
目标是让 AO 最终能够记住诸如：
- 有效的策略
- 失败的策略
- 它们影响的工作负载
- 涉及的模组
- 产生良好结果的环境
- 不应再次尝试的候选方案
这使得优化知识能够随着时间推移变得更加有用，而不是每次会话都从零开始。
🎮 关注真实游戏稳定性
Adaptive Optimization 的设计目标不仅仅是追求最高的 FPS 数字。
其更大的目标是改善 Minecraft 的整体稳定性。
这包括：
- 帧时间一致性
- Tick 稳定性
- 减少工作负载峰值
- 减少卡顿
- 更好的响应性
- 大型整合包下的更好表现
- 长时间游戏会话中的一致性
一个平均 200 FPS 但持续冻结的 Minecraft 实例并不是真正优化的。
AO 关注的是完整的性能体验。
🧩 为模组化 Minecraft 设计
Adaptive Optimization 是专门针对复杂的模组环境开发的。
AO 不会假设每个工作负载都是原版的，而是可以观察模组归属并识别模组行为。
随着整合包不断变大以及多个系统开始相互交互，这一点变得越来越重要。
🤝 Adaptive Optimization 与我的其他优化模组
Adaptive Optimization 并不打算让我的其他优化项目过时。
相反，长期目标是创建一个优化生态系统。
例如以下项目：
Sync Fix
针对 tick/同步相关系统及其领域内其他工作负载的专业化优化。
Chunks Optimization
对区块加载、生成、一致性及大规模区块工作负载的深度优化。
Logs Fixer
减少不必要的日志开销，防止过量的日志刷屏影响性能。
Mods Fixer
检测并修正根因位于第三方模组内部的问题，包括兼容性问题以及低效或损坏的模组行为。
Future Render Optimization
渲染工作负载的专业化优化。
Adaptive Optimization 在发现互补的优化机会时，仍然可以优化这些相同领域中的额外部分。
其理念不是人为限制 AO。
相反：
专业化模组深度优化其子系统，而 Adaptive Optimization 则提供额外的自适应的跨系统层。
这些系统应该协同工作，而不是盲目地执行两次相同的优化。
🔬 安全优化理念
Adaptive Optimization 并非通过简单地禁用功能或激进地跳过游戏逻辑来获得性能提升。
该项目围绕更安全的优化技术进行开发，例如：
- 缓存
- 记忆化
- 去重
- 批处理
- 合并
- 对象复用
- 更好的调度
- 延迟适当的工作
- 正确的失效处理
- 快速路径
- 安全拦截
- 受控重写
任何未来的自主优化系统也必须能够在候选方案不安全或无效时拒绝它们。
🛡️ 不破坏游戏性的性能提升
如果优化破坏了游戏，那它就是无用的。
新架构分离了几个问题：
性能是否提升了？
优化是否安全？
游戏是否继续正确运行？
未来的自主实验将在允许优化被信任之前独立评估这些方面。
可能的实验结果包括：
ACCEPTREJECTINCONCLUSIVEABORTED
这使得 AO 在证据不确定时能够更加保守。
🔮 接下来是什么？
稳定并不意味着开发已经完成。
Adaptive Optimization 仍有更宏大的路线图。
即将推出的预览版将专注于连接已经构建的系统。
🧪 即将推出 — 自主实验协调器
下一主要阶段是核心实验协调器。
其职责将是安全管理：
观察 ↓ 基线测量 ↓ 候选应用 ↓ 稳定化 ↓ 实验测量 ↓ 回滚 ↓ 恢复测量 ↓ 评估
它还将保护实验免受崩溃和重启的影响，确保未完成的实验不能悄然成为永久的优化状态。
🧠 即将推出 — 真实因果学习
一旦实验协调器被证明可靠，自适应学习系统将开始接收可信的因果结果。
不再学习：
我做了某事之后性能发生了变化。
AO 将转向学习：
这个确切的候选方案在这些条件下改进了这个可比的工作负载，并通过了所需的安全检查。
这是项目最重要的目标之一。
🧬 即将推出 — 自主候选生成
后续预览版将继续推动 AO 超越预定义的优化列表。
目标是让 Adaptive Optimization 最终能够自动发现工作负载并生成安全的优化候选方案。
它应当能够发现那些并未针对某个特定模组或某个特定整合包显式编程的优化机会。
🌐 未来 — 共享自适应技术
为 AO 开发的自适应架构最终可能会引入到我的其他几个优化模组中。
这将使每个专业化优化器能够在其自身领域内学习和适应，而 Adaptive Optimization 则处理更广泛的跨系统决策。
长期愿景是一个能够协作而非独立工作的优化系统生态系统。
⚠️ 重要说明
Adaptive Optimization 不是即时的 FPS 提升器。
结果会因以下因素而异：
- 硬件
- Minecraft 设置
- 整合包
- 当前工作负载
- 世界
- 光影
- 其他优化模组
某些情况可能会显示大幅改进，而其他情况可能只显示较小的变化。
目标不是伪造性能提升。
而是每当存在安全且可测量的优化机会时，让 Minecraft 真正表现更好。
❤️ 致谢
感谢 TishinaCentral 测试和展示了 Adaptive Optimization：
💬 Discord
你可以在此加入 Discord 服务器：
Bug 报告、测试结果、兼容性报告和反馈对于改进项目非常有用。
☕ 支持项目
在以下地址支持开发：
buymeacoffee.com/col9kam
⚙️ 关于开发环境
从版本 8.3.7 开始，Adaptive Optimization 正式迁移到 IntelliJ IDEA。
早期版本的项目是使用 MCreator 进行原型设计的，但当前系统是独立编写代码的，并已成长为一个更大的 Java 项目，拥有专门用于以下方面的系统：
- 观察
- 性能分析
- 归因
- 持久化
- 自适应参数
- 优化策略
- 运行时测量
- 实验评估
- 安全
- 学习
这次迁移为项目在架构、性能、兼容性和测试方面提供了显著更多的控制力。
📖 这个项目是如何开始的
早在 2024 年，我开始这个项目时，并不知道如何将这个想法变为现实。
我最初的目标是创建一个能够适应 Minecraft 的优化模组，而不是仅仅包含另一份预定义调整的列表。
当时，我的开发知识极其有限，而且 AI 开发工具的能力也远不如现在。
该项目曾被拒绝，并被告知我需要更多的开发经验。
我没有放弃这个想法，而是持续学习。
2025 年 10 月 11 日，我决定使用更新的 AI 工具和我已获得的 Java 知识再次尝试。
这最终帮助我摆脱了 MCreator，将项目迁移到 IntelliJ IDEA，理解了真实 Forge 项目的结构，并持续将 Adaptive Optimization 重建为今天的样子。
我仍然认为自己是个初学者。
AI 在开发方面帮助巨大，但我也在不断测试、审查、重新设计，并从出错中学习。
Adaptive Optimization 的存在是因为我坚持一个最初看起来远超我能力范围的构想。
🧠 总结
Adaptive Optimization 不再只是一个试图动态优化 Minecraft 的原型。
它现在正式进入稳定阶段，其核心优化、观察、性能分析和测量系统正在真实的 Minecraft 环境中运行。
开发现在正朝着下一个目标迈进：
使这些系统日益自主化。
Adaptive Optimization 的构建目标：
观察 Minecraft，理解其工作负载，发现优化机会，验证它们是否真的有效，拒绝不安全或无用的更改，记住成功的策略，并随着时间推移变得更好。
这不是 Adaptive Optimization 的终点。
稳定是为下一步奠定基础。
正在加载版本记录…
正在加载评论…
评论在新手盒子客户端中发表，这里同步展示。