Question

当用户下载我的应用程序并“注册”时，我们会使用用户数据填充核心数据，这可能会导致数千个对象。

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

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

在执行明显优化并使用Time Profiler工具后，我得出的结论是，最大的瓶颈似乎是这种模式：

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

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

在创建和删除期间，这似乎占用了所有CPU时间的65-70％。我试图尽量减少在创建时没有被删除的对象的数量，但是有一个我无法进一步降低的最小数量。

但是对于删除，似乎标记为要删除的对象必须被提取，无故障，然后再次出现故障，因此对于所有被删除的对象都会调用didTurnIntoFault。我在didTurnIntoFault中进行了大部分对象清理，但令人惊讶的是，从默认的NSNotificationCenter中删除作为观察者的对象似乎是最重要的操作（大幅度）。

任何想法为什么removeObserver：变得如此沉重？有关如何优化此功能以加快注册/注销的任何想法吗？

Answer 1

NotificationCenter是一个功能强大的工具，需要一些费用。当你在没有接收/生成对象（代码中为object:nil）的情况下使用它时，事情可能会横向发展，事情开始变得昂贵。

所以我的第一个建议是通过添加对象来探索缩小通知范围。希望是否有一个对象会抛出您收到的通知？如果是这样，你能以某种方式传递它吗？

第二个想法是将通知完全移出NSManagedObject。这会导致你的工作量增加，所以这是我的第二个建议，即使我推荐它更多。考虑让控制器监听通知，引用NSManagedObjectContext然后可以做适当的工作。

如果这些都不合适，则需要更好地了解该通知的内容。

优化批量删除和NSManagedObjects的创建

1 个答案: