Ios 优化NSManagedObjects的批量删除和创建

当用户下载我的应用程序并“注册”时，我们用用户数据填充核心数据，这些数据可能会运行到数千个对象中

我们还为用户提供了一个“注销”选项，在该选项中，我们将批量删除这些对象。（我们不会删除底层sqlite存储，因为其中的一些数据不是特定于用户的，我们希望保留这些数据）

批量创建和删除的共同点是，这些过程需要花费大量时间

在执行了明显的优化并使用时间剖面仪之后，我得出结论，最大的瓶颈似乎是这种模式：

- (void)awakeFromFetch {
    [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(someSelector:) name:someNotification object:nil];
}

- (void)didTurnIntoFault {
    [[NSNotificationCenter defaultCenter] removeObserver:self];
}

在创建和删除过程中，这似乎占用了所有CPU时间的65-70%。我曾试图尽量减少在创建时未受影响的对象数量，但有一个最小数量我无法进一步降低

但对于删除，似乎必须提取标记为要删除的对象，使其不受影响，然后再次出错，因此对所有已删除的对象调用

didturnintofult

。我在

didTurnIntoFault

中执行了大部分对象清理，但令人惊讶的是，将对象作为观察者从默认的NSNotificationCenter中删除似乎是最繁重的操作（相差很大）

---

你知道为什么removeObserver:会如此沉重吗？有没有关于如何优化此功能以加快注册/注销速度的想法？

NotificationCenter是一个功能强大的工具，需要付出一定的成本。如果使用它时没有接收/生成对象（

object:nil

，则代码中的内容可能会偏离方向，并且开始变得昂贵

所以我的第一个建议是通过添加一个对象来缩小通知的范围。希望有一个对象抛出您正在接收的通知吗？如果是这样的话，你能把它传进来吗

第二个想法是将通知完全移出

NSManagedObject

。这将导致更多的工作，你的一部分，所以这是我的第二个建议，即使我建议它更多。考虑有一个监听通知的控制器，它引用了<代码> NSMARCADION ObjistValue，然后可以做相应的工作。p>

---

如果两者都不合适，则需要更好地了解该通知的用途。

为什么不在用户注销时创建一个新的存储呢。保留一个包含种子数据的新存储，并在用户注销时替换存储，而不是删除对象。或者使用两个存储区，一个存储有可丢弃的用户数据，另一个存储有要保留的数据，只需将其中一个存储区替换为空的用户数据。为什么您甚至需要数千个对象？维护多个存储和延迟加载。我不确定多个存储在这里会有什么帮助，因为在创建和删除过程中，我需要插入/删除所有对象。