刷新一个领域的成本是多少？

Question

我已阅读文档并了解在许多情况下您不需要在 Realm 实例上手动调用 refresh。然而，在这个非常常见的场景中，它被证明是必要的，因为完成块可能会在下一个运行循环开始之前查询 Realm。

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
    [[RLMRealm defaultRealm] transactionWithBlock:^{
        // Add some RLMObjects
    }];

    if (completion) {
        dispatch_async(dispatch_get_main_queue(), ^{
            [[RLMRealm defaultRealm] refresh]; // necessary if it queries realm
            completion();
        });
    }
});

我认为通过在后台线程上执行写操作我是一个好公民，但现在我必须调用refresh，我想知道这个调用所涉及的开销是否会破坏进行后台处理的意义.

所以我的问题是：

1) 在Realm 上调用refresh 的性能成本是多少？

2) 在这种模式下只向领域添加一个对象可能是 无意义。在此模式中添加多少对象后，我会发现与仅在主线程上同步执行写入事务相比有优势吗？

Answer 1

非常棒的问题！

1) 在Realm 上调用refresh 的性能成本是多少？

tl;博士;提神并没有那么贵

成本将与在该线程上推进的Realm 实例支持的实时“访问器”数量成正比。 Realm Objective-C 中的访问器是RLMObjects、RLMArrays 和RLMResults。

由于 Realm 在底层使用 MVCC versioning system，类似于 git 的内部工作，调用 -[RLMRealm refresh] 是将 Realm 的“当前事务指针”推进到最新的稳定状态，就像 git pull 操作一样。

值得注意的是，对于具有 runloop 且 autorefresh 设置为 YES 的线程上的 Realms（主线程上的 Realms 通常是这种情况），-[RLMRealm refresh] 将在每次迭代时自动调用运行循环。

因此，在绝大多数情况下，刷新 Realm 对性能的影响可以忽略不计，除非您在该线程上有非常大量实时“访问器”。

2) 在这种模式下只向领域添加一个对象可能是没有意义的。在此模式中添加多少对象后，我会发现与仅在主线程上同步执行写入事务相比有优势吗？

tl;博士;在后台执行写入更安全

在绝大多数没有争用的情况下，在主线程上执行写入事务的开销将低于流畅 UI 所需的 1/60 秒阈值。 然而 Realm 中的写入是阻塞，这意味着如果在后台同时发生大型写入事务，这将在从主线程并发写入时阻塞主线程，这不太理想，因为它会导致 UI 卡顿或阻塞。

因此，我们建议所有写入事务，无论多小多快，都在后台线程上执行，除非您确定不会发生任何争用。

我意识到，Realm 对访问器的严格线程限制强制执行使在后台线程上执行写入变得复杂，这就是为什么我们正在跟踪为异步写入添加 API，从而允许在 #3136 中跨线程安全地切换访问器。

由于 Realm 中的读取操作不会被其他读取或写入阻塞（感谢上面提到的 MVCC！），因此在任何线程上执行这些操作是完全可以接受的。