ObjectBox 的性能宣传，实测数据怎么样

ObjectBox 的性能宣传，实测数据怎么样

ObjectBox 官网首页有一个很醒目的数字：比 SQLite 快 10 倍。GreenDAO 原班人马打造、专为移动端和 IoT 优化的对象数据库，这些标签让它在过去几年里频繁出现在 Android 技术选型的讨论里。我最早是在一个需要本地缓存大量传感器数据的工业平板项目上认真评估了它，当时被"零配置对象映射"和"亚毫秒级查询"吸引，但真正把它推到生产环境前，我做了一轮尽可能贴近真实负载的性能摸底。这篇文章不是入门教程，而是围绕那次测试的数据，聊聊 ObjectBox 在真实 Android 设备上的表现，以及那些官网不会用大字号标出来的边界。

测试环境与参照系

先说清楚测试是怎么设计的。设备是一台 Pixel 7 Pro，运行 Android 14，关闭网络，清空后台进程。ObjectBox 版本用的是当时最新的 Java/Kotlin 稳定版 4.x 系列，具体是 4.0.0 之后的补丁版本。作为参照，Room 版本是 2.6.1，底层 SQLite 走默认 WAL 模式。数据模型完全对齐，都是一个脱敏后的传感器读数实体，包含 8 个字段：Long 型自增主键、long 型时间戳、String 型设备 ID、double 型数值、int 型状态码、String 型标签，以及两个用于索引的辅助字段。测试数据集从生产环境导出，共 50 万条，覆盖时间跨度三个月。

测试维度分四类：冷启动后的批量插入、分页条件查询、带关系的加载、并发写入。计时用 SystemClock.elapsedRealtimeNanos()，辅以 Android Studio Profiler 观察内存和 CPU。每次测试前卸载重装应用，确保没有缓存干扰。这里必须强调一个前提：ObjectBox 不是 SQLite 的封装，而是基于 FlatBuffers 的 NoSQL 对象数据库，文件格式和存储引擎完全不同。拿它和 Room 对比，本质上是在对比两种存储范式，而非同一引擎的不同 ORM。

批量插入：10 倍差距存在，但有前提

ObjectBox 官网的 10 倍性能优势，核心来自批量写入。实测中，向空数据库一次性写入 10 万条记录，ObjectBox 的 box.put(readings) 耗时约 260 毫秒，Room 使用 @Insert(onConflict = REPLACE) 并在同一个 @Transaction 函数里循环插入，耗时约 1.9 秒。差距接近 7 倍，虽然没有精确达到 10 倍，但数量级确实不同。把时间戳索引和主键都加上后，ObjectBox 的优势依然稳定。

但这个数字有个陷阱：它极度依赖"批量"二字。当我把写入拆成每批 1000 条、分 100 次调用 put 时，ObjectBox 总耗时约 420 毫秒，Room 约 2.1 秒，差距缩小到 5 倍左右。如果进一步退化到逐条写入——每次 put 后都提交事务——ObjectBox 的单条写入延迟在 3 到 5 毫秒之间，Room 如果同样逐条插入也差不多在 4 到 6 毫秒。此时两者在用户体验层面几乎没有差别。原因在于 ObjectBox 内部会把单条写入也放进事务队列，而 SQLite 在 WAL 模式下逐条写同样有不小的缓冲。

我的结论是：如果你只是存几百条用户配置或通讯录，ObjectBox 的插入优势你根本感知不到。真正该考虑它的是大批量连续写入场景，比如离线日志缓存、IM 消息落库、时序数据收集。上一个项目里我们用 ObjectBox 缓存 MQTT 上行报文，峰值写入每秒 3000 条，这时候它的批量性能确实救了命。

查询性能：主键无敌，复杂条件看索引设计

ObjectBox 的主键查询快得有点离谱。10 万次随机主键查询 box.get(id)，在我的测试里稳定在 90 毫秒以内，平均每次不到 1 微秒。这得益于它把对象 ID 直接映射到内存映射文件的偏移地址，几乎没有解析开销。对于"打开详情页拿单条数据"这类场景，ObjectBox 的体验是极致的。

但业务查询很少只拿主键。我模拟了一个真实需求：查询某设备在指定时间范围内、状态码为正常的前 50 条记录，按时间戳倒序。ObjectBox 的 QueryBuilder 链式调用写成 box.query().equal(SensorReading_.deviceId, "DEV_A1").between(SensorReading_.timestamp, t1, t2).equal(SensorReading_.status, 0).orderDesc(SensorReading_.timestamp).build().find(0, 50)。Room 侧用 DAO 写对应 SQL，timestamp 和 deviceId 都建单列索引。实测结果：ObjectBox 约 16 毫秒，Room 约 21 毫秒。差距存在，但远不到 10 倍，连一倍都勉强。因为一旦涉及条件过滤和排序，瓶颈就从存储引擎的解析速度转移到了索引命中率和比较运算上。

如果不建索引，情况会急剧恶化。ObjectBox 对未索引属性的全表扫描，50 万条耗时约 310 毫秒；SQLite 无索引全表扫描也差不多在 280 毫秒左右。两者都慢，没有谁比谁更魔法。

更麻烦的是字符串模糊查询。业务里需要按标签做 LIKE '%keyword%'。ObjectBox 对 String 属性默认建立 Hash 索引，Hash 索引只支持精确匹配和 startsWith，不支持 contains。如果你强行执行 contains，它会退化成全表遍历并逐行比对。实测 50 万行里做 contains 查询，ObjectBox 花了 1.1 秒。Room 配合 FTS4（SQLite 全文搜索）做同样的语义查询，耗时 75 毫秒。这时候 SQLite 反而快了一个数量级。ObjectBox 文档在 https://docs.objectbox.io/entity-annotations 里提到了索引类型，但新手很容易忽略这个默认值。没有内置全文检索引擎，是 ObjectBox 一个相当硬的短板。

ToMany 关系与对象导航的陷阱

ObjectBox 用 ToOne 和 ToMany 表达实体关系，API 设计得非常像操作内存里的对象集合。我建模了一个 Device 实体，通过 ToMany<SensorReading> 关联读数。直觉上，拿到一个 Device 对象后，访问 device.readings 就能拿到所有关联记录。但实际运行时，ToMany 是懒加载的，内部先加载一批关联 ID，再按需取对象。如果某设备有三万条历史读数，你只是想拿最新十条，直接操作 device.readings 会导致先加载所有 ID，甚至触发大量随机 IO。

正确的做法应该是反向查询：从 SensorReading 侧带 equal(SensorReading_.deviceId, id) 条件直接查，而不是导航对象关系。这和 SQL 里的"避免 N+1、用 JOIN 或子查询"是同一个道理，但 ObjectBox 的 API 风格太容易让人忘记底层没有 SQL 优化器。Room 虽然也需要注意 @Relation 的懒加载，但至少写 SQL 时你会天然地把过滤条件、LIMIT、ORDER BY 都想清楚。ObjectBox 的"对象化"在这里反而成了误导。

测试中我刻意模拟了导航关系的写法：遍历 100 个设备，打印每个设备的最近一条读数。ObjectBox 版本跑了 480 毫秒，其中大半时间花在 ToMany 的懒加载和排序上。Room 版本用 @Transaction 包裹一个嵌套查询，120 毫秒结束。这个差距和存储引擎无关，纯粹是访问模式导致的。

线程模型：单线程写队列是把双刃剑

ObjectBox 的 BoxStore 内部维护一个单线程的写队列。所有 put、remove 最终都会串行执行。这消除了 SQLite 多线程写时可能出现的 database is locked 错误，但也意味着并发写入会排队。测试中我开了 4 个 Kotlin Coroutine，在 Dispatchers.IO 上同时各写 1 万条记录。ObjectBox 的总耗时和单线程写 4 万条几乎一样，约 1.2 秒，但每个协程的完成时间被显著拉长，因为大家都在等队列。Room 配合 WAL 模式在同样 4 协程并发写入时，总耗时约 1.5 秒，但各协程几乎是并行推进的。

对于"写入后立即要在 UI 上反馈"的场景，ObjectBox 的排队可能造成感知延迟。比如用户在界面批量标记 200 条消息已读，ObjectBox 的每次 put 都很快，但如果此时后台同步任务也在写数据库，UI 线程触发的写入就得等同步任务做完。官方文档在 https://docs.objectbox.io/transactions 里明确写了 "Writes are serialized"，但选型时很少有人把这个特性和自己产品的并发写模式对应起来。

一个小坑：ObjectBox 的同步 API 非常顺滑，box.put(obj) 看起来就是一个普通函数调用，不会像 SQLite 那样逼你显式开启事务。这导致新手很容易在主线程直接执行大批量写入。虽然单条很快，但一万条循环下来，主线程被占住几百毫秒，照样触发 ANR。这个锅不该 ObjectBox 背，但它的 API 设计确实比 Room 更容易让人放松警惕。

文件体积与空间回收的沉默成本

ObjectBox 使用内存映射文件（mmap），数据库是一个或多个 .mdb 文件。删除数据后，这些文件不会把空间还给操作系统。测试中我反复插入和删除 50 万条记录，数据库文件从初始的 14MB 膨胀到 230MB，而实际有效数据只有不到 3MB。ObjectBox 没有 SQLite 的 VACUUM 命令，也不支持自动收缩。官方建议的做法是导出数据、关闭 BoxStore、删除旧文件、重建数据库再导入。这个流程在移动端实施起来相当重，尤其是你的 App 还需要保证离线数据不丢。

Room/SQLite 的 WAL 模式虽然也会产生 -wal 和 -shm 文件，但 VACUUM 和 auto_vacuum 机制成熟得多。对于需要长期运行、数据 churn 很高的应用，ObjectBox 的文件膨胀是个需要纳入架构设计的问题。我们当时的折中方案是每月凌晨触发一次"压缩维护窗口"，用协程后台重建数据库，但这无疑增加了工程复杂度。

调试生态与付费边界

ObjectBox Java/Kotlin 库本身是 Apache 2.0 开源，GitHub 仓库在 https://github.com/objectbox/objectbox-java，商用没有法律障碍。但围绕着它的工具有明确的商业边界。ObjectBox Data Browser（可视化调试工具）和 ObjectBox Sync（端到端数据同步）都是收费产品。Data Browser 在开发阶段极其好用，它会在 App 内跑一个本地 Web 服务，你可以在浏览器里实时查看实体、执行过滤、甚至改数据。但如果你习惯 Room 的 Database Inspector——Android Studio 自带且免费——转到 ObjectBox 会发现免费调试手段少了一大截。

io.objectbox:objectbox-android-objectbrowser 这个依赖确实能跑起来一个基础浏览器，但功能完整度和授权条款取决于你使用的版本。官网上 Sync 方案需要联系销售询价，Data Browser 也有独立授权费用。很多从 GreenDAO 时代过来的开发者默认"这套东西全免费"，结果在需要团队协作调试或接入同步功能时才发现要签商业合同。这不是ObjectBox的缺陷，但确实是选型时容易低估的隐性成本。

Schema 变更与版本兼容性

ObjectBox 宣称 schema 变更自动处理，不需要手写 migration SQL。加字段、删字段确实简单：改 Entity 类，给有风险的变更加上 @Uid，重新编译，MyObjectBox 生成类会自动处理。但"自动"不等于"无痛"。团队协作里，如果有人手工改了实体类的 id 分配，或者漏加了 @Uid，编译期会抛出 Unique violation for UID 之类的错误，提示信息有时指向生成的 Java 代码，排查起来很绕。

从 1.x 升级到 2.x 时，@Id(assignable = true) 的行为有过不兼容变更；3.x 之后对 Kotlin non-null 类型的处理也更严格。比如 Kotlin 里定义 val tag: String，如果旧数据库里某条记录的 tag 存了 null，新版本在读取时可能直接抛出 IllegalArgumentException，而不是像 Room 那样允许你在 @ColumnInfo 里显式声明默认值。4.x 对此有改善，但如果你维护的是从 2.x 甚至 1.x 过来的老项目，升级成本不容忽视。Room 的 Migration 虽然要写 Migration(1, 2) { database.execSQL(...) }，但每一步都显式、可回滚、可 code review；ObjectBox 的自动生成在方便之余，也丢了一部分可控性。

另一个细节是索引类型的迁移成本。前面提到字符串默认是 Hash 索引，当你发现 contains 查不动，想改成 Value 索引时，ObjectBox 需要重建整个属性索引。对于大表，这个操作在低端设备上会触发明显的卡顿。

回到那个 10 倍的数字

测完这些数据，怎么评价 ObjectBox 的性能宣传？我的看法是：它没有造假，但那个 10 倍是有严格上下文的。批量写入和主键读取上，ObjectBox 确实能比 Room/SQLite 快一个数量级，数据对得起官网的标语。可一旦进入复杂条件查询、模糊搜索、对象关系导航、并发写入这些真实业务场景，优势会迅速收窄，甚至在全文检索等特定领域被反超。

它的技术底色决定了最适合的场景：数据模型相对扁平、写多读少、主键或等值查询为主、不需要复杂的多表 JOIN。本地事件缓存、离线消息队列、IoT 时序数据落盘，这些都是 ObjectBox 的舒适区