Bedrock：另一套实现

Java Edition 玩家把红石机器的截图发给 Bedrock 玩家，对方照着做，却发现"灯不亮"。手机上的世界存档，无法在电脑版 Java Edition 打开。两个版本都叫"Minecraft"，但它们真的是同一个游戏吗？

Bedrock Edition 用 C++ 重写，最初是为了在移动设备、主机和 VR 上运行。它确实更快、更省电、启动更快，但同时也带来了：Redstone 时序不同（没有 Quasi-Connectivity）、刷怪机制不同、战斗机制不同（没有 1.9 的攻击冷却）、存档格式不同（LevelDB vs Anvil）、Mod 生态几乎消失（Add-On 和 Script API 能力有限）。

这些差异不是"移植损耗"或"还没对齐完"，而是两套实现的语义分叉。Mojang 和微软确实在追求 Parity（功能对等），但某些核心差异已经难以消除——不是因为技术不可能，而是因为两边的玩家社区已经依赖各自的历史行为。

本章要回答的核心问题是：

为什么 Bedrock 不是"Java 换成 C++ 的优化版"，而是逐渐形成了不同语义与扩展模型的另一套实现？这对理解"什么是 Minecraft"意味着什么？

我们会看到，Bedrock 的架构选择（C++、RenderDragon、LevelDB）确实带来了性能优势，但同时也塑造了不同的扩展模型（Add-On / Script API vs Mod Loader / Mixin）、不同的商业模式（Marketplace 审核 vs 社区自由分发）、以及不同的玩法语义（Redstone、刷怪、战斗）。这不是"哪个更好"的问题，而是"两套实现如何分叉"的现实。

本文主要以 Bedrock 1.21.50 为当前参照，对比 Java Edition 1.21.4。

1为什么需要 Bedrock？

在讨论技术差异之前，先理解 Bedrock 的起源和目标。

1.1Pocket Edition 的商业需求

2011 年，Mojang 与 Aron Nieminen（4J Studios）合作开发 Pocket Edition，最初用 C++ 编写，目标是 iOS 和 Android。¹

为什么不直接移植 Java Edition？

移动设备的约束：

• 内存有限（早期 Android 设备只有 512MB RAM）；
• CPU 性能弱（ARM 架构，功耗优先）；
• 触控输入（不是键盘鼠标）；
• 应用商店审核（Google Play、App Store）。

跨平台需求（后来）：

• Xbox、PlayStation、Nintendo Switch；
• Windows 10（UWP）；
• VR（Oculus、PSVR）。

Java Edition 的架构不适合这些平台：

• JVM 在移动设备上内存占用太大；
• 某些主机（如 Xbox、Switch）不允许运行 JVM；
• 应用商店不接受"可任意加载代码"的应用（Mod Loader 会被拒）。

1.2从 Pocket Edition 到 Bedrock Edition

2017 年，微软将所有非 Java 版本统一为 Bedrock Edition：²

• Pocket Edition（iOS / Android）
• Windows 10 Edition（UWP）
• Xbox One Edition
• Nintendo Switch Edition
• PlayStation（后来加入）

统一的好处：

• 共享代码库（C++ / RenderDragon）；
• 跨平台联机（Xbox 和手机可以一起玩）；
• 统一的 Marketplace（内容商店）。

统一的代价：

• 必须通过所有平台的审核（主机、应用商店）；
• 不能有"任意加载代码"的 Mod Loader；
• 某些玩法需要适配触控和手柄。

1.3Bedrock 的核心目标

Bedrock Edition 的设计目标与 Java Edition 不同：

这不是"Java 的优化版"，而是为了不同用户群和商业模式的重新实现。

2C++ 实现：性能与代价

Bedrock 用 C++ 重写，带来了性能优势，但也改变了架构和可扩展性。

2.1性能优势

更低的内存占用

• 没有 JVM 开销（Java Edition 需要 2-4GB 堆内存）；
• Bedrock 在移动设备上通常只需 1GB 左右。

更快的启动

• 不需要加载 JVM、预热 JIT；
• Bedrock 启动通常只需几秒（Java Edition 可能需要 30 秒以上，尤其是装了 Mod）。

更好的帧率

• C++ 可以直接控制内存布局；
• 更好的 CPU Cache 利用率；
• 没有 GC 停顿。

更适合移动设备

• ARM 架构优化；
• 低功耗（省电）；
• 触控友好的 UI。

2.2代价：Mod 生态几乎消失

Java Edition 的 Mod 生态依赖：

• 字节码可反编译（第 16 章讨论过）；
• Mixin 在运行时注入代码；
• Mod Loader 动态加载 .jar 文件。

Bedrock 用 C++ 后，这些都不可能了：

二进制难以修改

• C++ 编译成机器码，难以反编译；
• 没有"字节码"这一层可修改的中间表示；
• Modding 需要逆向工程和内存补丁（风险高、门槛高）。

应用商店不允许任意代码加载

• iOS App Store 禁止运行时下载和执行代码；
• 主机（Xbox、Switch）同样禁止；
• 即使 Windows 10 版本，也要通过 Microsoft Store 审核。

官方没有提供 Mod API

• Java Edition 虽然没有官方 Mod API，但社区可以通过 Mixin 扩展；
• Bedrock 的二进制不提供扩展点，官方也不鼓励第三方 Mod。

结果：

Bedrock 的第三方 Mod 生态几乎不存在。社区只能通过官方提供的 Add-On 和 Script API 扩展游戏。

第 16 章《Java 版运行时与发布环境》讨论了 Java 的字节码为什么能支持 Mod 生态。

2.3C++ 的架构差异

Bedrock 的 C++ 实现不是"Java 代码逐行翻译成 C++"，而是重新设计的架构。

实体组件系统（ECS）

• Bedrock 使用类似 ECS 的架构（Entity-Component）；
• 实体由组件组成（HealthComponent、TransformComponent 等）；
• 对比：Java Edition 是传统的继承层次（Entity → LivingEntity → Mob）。

RenderDragon 渲染引擎

• Bedrock 的自研渲染引擎，支持延迟渲染（Deferred Rendering）；
• 对比：Java Edition 用 LWJGL + OpenGL（第 16 章讨论过）。

多线程架构

• Bedrock 的某些系统（渲染、网络）可以多线程并行；
• 对比：Java Edition 的主循环仍然是单线程（第 04 章讨论过）。

LevelDB 存储

• Bedrock 使用 Google 的 LevelDB 存储世界数据；
• 对比：Java Edition 使用 Anvil 格式（Region 文件）（第 02 章讨论过）。

这些架构差异不是"优化"，而是不同的设计选择，各有优劣。

3扩展模型：Add-On vs Mod

Bedrock 的扩展模型与 Java Edition 完全不同。

3.1Add-On：官方支持的扩展

Bedrock 提供两种官方扩展方式：

Resource Pack（资源包）

• 改变视觉和音频（纹理、模型、音效）；
• 与 Java Edition 的资源包类似，但格式不兼容。

Behavior Pack（行为包）

• 修改游戏逻辑（实体行为、战利品表、配方）；
• 通过 JSON 文件定义；
• 类似 Java Edition 的 Data Pack，但能力更强（可以修改实体 AI）。

示例：自定义实体

{
  "format_version": "1.16.0",
  "minecraft:entity": {
    "description": {
      "identifier": "custom:my_mob",
      "is_spawnable": true,
      "is_summonable": true
    },
    "components": {
      "minecraft:health": {
        "value": 20,
        "max": 20
      },
      "minecraft:movement": {
        "value": 0.25
      }
    }
  }
}

能做什么：

• 修改现有实体的属性；
• 创建新的实体（但模型和行为受限于现有组件）；
• 修改战利品表、配方、世界生成。

不能做什么：

• 不能添加新的方块类型（只能修改现有方块的行为）；
• 不能添加新的游戏机制（如红石组件）；
• 不能修改核心游戏循环（Tick、Chunk Loading）。

3.2Script API：JavaScript 脚本

2021 年起，Bedrock 引入 Script API（基于 JavaScript / TypeScript）。³

运行环境：

• JavaScript 引擎（QuickJS）；
• 沙盒执行（不能访问文件系统、网络）；
• 通过事件系统与游戏交互。

示例：监听方块破坏

import { world } from '@minecraft/server';

world.afterEvents.playerBreakBlock.subscribe((event) => {
  const { player, block } = event;
  player.sendMessage(`You broke a ${block.typeId}!`);
});

能做什么：

• 监听游戏事件（玩家行为、方块更新、实体生成）；
• 修改实体属性、生成实体；
• 创建自定义游戏规则和小游戏。

不能做什么：

• 不能修改方块或实体的底层行为（如 Piston 的推动逻辑）；
• 不能像 Mixin 那样"注入"到游戏代码中；
• 性能受限（JavaScript 比原生代码慢）。

3.3对比：Java Mod vs Bedrock Add-On

核心差异：

Java Mod 可以修改游戏的任何部分（通过 Mixin 和反射），而 Bedrock Add-On 只能在官方提供的扩展点内工作。

这不是"Bedrock 的 Add-On 不够好"，而是：

• Java Edition：社区可以自由扩展，但需要逆向工程和适配每个版本；
• Bedrock Edition：官方提供稳定的 API，但能力受限，且需要通过审核。

第 14 章《Mod、Mixin 与加载器》详细讨论了 Java Mod 的工作原理。

4Marketplace：审核与商业模式

Bedrock 的 Marketplace 是官方内容商店，创作者可以出售皮肤、地图、纹理包和 Add-On。

4.1Marketplace 的运作方式

创作者提交内容：

• 通过 Minecraft Partner Program 申请；
• 内容需要通过审核（质量、兼容性、适龄）；
• 定价以 Minecoins（虚拟货币）计算。

玩家购买内容：

• 内容绑定到 Microsoft 账户；
• 可以在所有登录该账户的设备上使用；
• 无法导出或分享给其他账户。

分成：

• 微软和创作者分成（具体比例未公开）；
• 创作者可以获得稳定收入。

4.2Marketplace 的约束

Marketplace 的审核机制会反过来限制创作者能做什么：

技术限制：

• 不能使用任意代码（只能用 Add-On / Script API）；
• 不能访问文件系统或网络；
• 不能修改核心游戏机制。

内容限制：

• 需要适合所有年龄段（主机分级要求）；
• 不能包含暴力、色情、版权侵权内容；
• 需要在所有平台上运行（移动、主机、PC）。

商业限制：

• 内容绑定账户，不能自由分享；
• 玩家需要购买 Minecoins；
• 创作者需要通过审核才能上架。

4.3对比：Java 社区 vs Bedrock Marketplace

核心差异：

Java Edition 的 Mod 生态是社区自治的，Bedrock 的 Marketplace 是官方管理的。

这不是"哪个更好"，而是两种不同的生态模型：

• Java：创作自由、法律风险自负、难以盈利；
• Bedrock：审核保护、稳定收入、创作受限。

卷一第 11 章《模组、服务器与灰色经济》讨论了 Java Mod 的商业模式。

5语义分叉：为什么"灯不亮"

Bedrock 最致命的问题不是性能或 Mod 生态，而是玩法语义的分叉。

5.1Redstone：Quasi-Connectivity 的缺失

Java Edition：

• 活塞和其他红石组件有 Quasi-Connectivity（准连接）；
• 活塞会检查上方一格是否有信号，即使没有直接连接；
• 这是一个历史 Bug，但已经成为玩家依赖的"特性"。⁴

Bedrock Edition：

• 没有 Quasi-Connectivity；
• 活塞只检查直接相邻的方块；
• 红石逻辑更"正确"，但与 Java 不兼容。

后果：

大量 Java Edition 的红石机器在 Bedrock 上无法工作。

玩家会发现：

• BUD（Block Update Detector）不工作；
• 某些门、电梯、飞行器失效；
• 需要重新设计红石电路。

第 08 章《红石与更新顺序》详细讨论了 QC 的技术原理。

5.2刷怪机制：不同的生成规则

Java Edition：

• 敌对生物在光照等级 0 生成；
• Despawn 距离：24-128 方块；
• 刷怪上限：70 个敌对生物。

Bedrock Edition：

• 敌对生物在光照等级 7 及以下生成（不同！）；
• Despawn 规则不同（距离和条件）；
• 刷怪上限更复杂（分类型计算）。

后果：

Java Edition 的刷怪塔在 Bedrock 上效率完全不同，甚至可能不工作。

5.3战斗机制：攻击冷却的缺失

Java Edition：

• 1.9 引入攻击冷却（Attack Cooldown）；
• 需要等待冷却条恢复才能打出满伤害；
• 盾牌可以格挡。

Bedrock Edition：

• 没有攻击冷却；
• 可以连续点击快速攻击（像 1.8 及以前）；
• 盾牌机制不同。

后果：

Java 和 Bedrock 的 PvP 玩法完全不同。

Java 玩家习惯等待冷却、使用盾牌和斧头，Bedrock 玩家习惯连点和快速移动。

5.4方块实体：活塞的差异

Java Edition：

• 活塞通常不能推动方块实体（如箱子、熔炉）；
• 例外：部分方块实体在某些版本可以被推动（历史行为）。

Bedrock Edition：

• 活塞可以推动某些方块实体（如箱子）；
• 这让某些机器（如可移动存储）更容易制作。

后果：

Bedrock 的某些机器在 Java 上不可能实现，反之亦然。

5.5存档格式：不能互转

Java Edition：

• Anvil 格式（Region 文件，.mca）；
• NBT 序列化。

Bedrock Edition：

• LevelDB（键值数据库）；
• 不同的序列化格式。

后果：

Java 和 Bedrock 的存档不能直接互转。

虽然有第三方工具（如 Amulet Editor、MCC Toolchest）可以转换，但：

• 红石机器会失效（QC 差异）；
• 某些方块实体可能丢失；
• Mod 内容无法转换。

5.6语义分叉表

这不是"还没对齐完"：

某些差异（如 QC、攻击冷却）已经成为各自玩家社区依赖的核心玩法，难以统一。

6Parity：追求功能对等的努力

Mojang 和微软确实在追求 Parity（Java 和 Bedrock 的功能对等）。⁵

6.1已经对齐的

内容 Parity：

• 大部分方块、物品、生物在两个版本都有；
• 新版本更新（如 1.19 The Wild Update）同时发布到 Java 和 Bedrock；
• 世界生成（生物群系、结构）基本一致。

UI / UX Parity：

• 两个版本的界面越来越接近；
• 都支持触控、手柄、键鼠（Bedrock 优势更大）。

6.2难以对齐的

底层机制：

• Redstone（QC、更新顺序）；
• 刷怪机制；
• 战斗机制（攻击冷却）。

扩展模型：

• Java 的 Mod 生态无法"移植"到 Bedrock；
• Bedrock 的 Marketplace 审核模式也不会出现在 Java。

平台限制：

• Bedrock 需要通过主机和应用商店审核，Java 不需要；
• Java 可以随意安装 Mod，Bedrock 不能。

6.3为什么 Parity 困难？

技术债：

• Java 的 QC 是历史 Bug，但已经成为"特性"；
• 修改会破坏现有玩家的红石机器。

玩家社区：

• Java 玩家依赖 QC、攻击冷却、Mod；
• Bedrock 玩家依赖触控、跨平台联机、Marketplace。

商业约束：

• Bedrock 需要通过审核，不能有"任意加载代码"；
• Java 的开放 Mod 生态是核心卖点，不能放弃。

结果：

Parity 只能在内容层面（方块、生物、生物群系）对齐，机制层面（Redstone、战斗、Mod）难以统一。

第 18 章《兼容、重构与技术债》会详细讨论为什么"修复历史行为"如此困难。

7跨平台联机：Bedrock 的优势

Bedrock 最大的优势之一是跨平台联机。

7.1实现方式

统一的网络协议：

• 所有 Bedrock 平台使用相同的协议；
• Xbox、手机、PC、Switch 可以一起玩。

Realms：

• 官方托管的多人服务器；
• 自动备份、跨平台访问；
• 订阅制（付费）。

Xbox Live 集成：

• 好友列表、邀请、成就；
• 主机玩家更熟悉这套系统。

7.2对比：Java Edition 的局限

Java Edition 的多人：

• 需要手动设置服务器（Dedicated Server）；
• 或使用 Realms（付费）；
• 不能与 Bedrock 联机。

第三方桥接：

• Geyser：允许 Bedrock 客户端连接到 Java 服务器；⁶
• 协议转换，但某些功能（如 QC、Mod）无法完美兼容。

核心差异：

Bedrock 的跨平台联机是一等公民（官方支持），Java 的多人是社区驱动（自建服务器）。

第 10 章《网络架构与状态同步》讨论了 Java Edition 的网络架构。

8这一章留下什么

从 C++ 实现、跨平台架构到 Add-On、Marketplace 与语义分叉，Bedrock Edition 证明了：换语言不仅改变性能，也会改变生态和玩法。

Bedrock 用 C++ 重写，最初是为了在移动设备、主机和 VR 上运行。它确实获得了更好的性能（更低内存、更快启动、更高帧率）、跨平台能力（移动、主机、PC、VR 统一联机）、以及官方内容商店（Marketplace，创作者可以盈利）。但同时付出了代价：Mod 生态几乎消失（C++ 二进制难以修改，应用商店不允许任意代码加载）、扩展能力受限（Add-On 和 Script API 只能在官方扩展点内工作，不能像 Java Mod 那样修改任何部分）、语义分叉（Redstone 没有 QC、战斗没有攻击冷却、刷怪机制不同、存档格式不兼容）。

Mojang 和微软确实在追求 Parity（功能对等），但某些核心差异已经难以消除——不是因为技术不可能，而是因为两边的玩家社区已经依赖各自的历史行为。Java 玩家依赖 QC、攻击冷却、Mod 生态；Bedrock 玩家依赖触控、跨平台联机、Marketplace。两个版本在内容层面（方块、生物、生物群系）可以对齐，但机制层面（Redstone、战斗、扩展模型）已经分叉成两个不同的游戏。

对爱好者来说，"Bedrock 是优化版"这句话不准确。Bedrock 确实更快、更省电，但它不是"Java Edition 加速"，而是另一套实现。如果你依赖 QC、Mod、或 Java 的红石教程，Bedrock 不是"升级选项"。如果你需要在手机和主机上玩、需要触控友好、需要跨平台联机，Bedrock 是更好的选择。两个版本共享品牌和内容，但玩法和生态已经分叉。

对开发者来说，能抄走的是：C++ 可以带来性能优势（尤其是内存和启动速度），跨平台架构需要从头设计（不是"移植"），官方审核的内容商店可以让创作者盈利（但会限制创作自由），ECS 架构在某些场景比继承层次更灵活。不能照抄的是：Bedrock 的具体 C++ 架构、RenderDragon 渲染引擎、LevelDB 存储、Marketplace 的审核流程。真正值得继承的是：换语言会导致语义分叉，除非有统一的语义测试集；性能和生态是权衡，不是免费的（Bedrock 快但 Mod 少，Java 慢但 Mod 多）；扩展模型塑造社区文化（Java 的自由 Mod 生态 vs Bedrock 的审核 Marketplace）；跨平台需求会反过来约束设计（主机审核、应用商店限制、触控输入）。