coredata的并发处理

2017-01-14 10:22:58来源:http://www.jianshu.com/p/00575a125e1a作者:maruipp人点击

coredata的并发处理

“我想要高可响应性的app,它允许我即使离线时候也能浏览数据”-我们常常听到有人这么说。


讽刺的是,当用coredata处理数据的时候,它会成为你的应用的核心。除了管理你的app内存中持有数据的方式,coredata还处理高级数据查询(NSPredicate),懒加载(faults),undo和redo支持,表迁移,UI整合(NSFetchedResultsController),合并策略以及其他相关事情。


Coredata可以是你的朋友,也可以是你的敌人,这取决于你使用它的方式:如果在主线程处理,coredata会显着的抑制程序性能。但是,如果你想异步的使用coredata,你需要知道几种模式。


Coredata设计

尽管有人说coredata有比较陡的学习曲线,不过一旦你理解了这个技术它就会变得很容易理解。这个技术就是关于如何管理你的模型的对象流。Coredata的结构见下图:



coredata_design-1024x521.png

通常SQLite数据库是用作备份数据存储,但是你也能指定“原子性”或者“仅内存”这两种储存类型。要注意的是尽管在OSX上coredata支持XML数据存储,但是在iOS上XML存储并不可用。


大致上,一个NSManagedObject实例可以被看做数据库里表里的一条记录。这个表的元数据被存储在NSEntityDescriptor对象中。NSManagedObjectContext是NSManagedObject对象们的数据池。它负责NSManagedObject的生命周期,以及从底层数据存储获取数据对象,持久化,object faulting, undo/redo支持。


一个NSManagedObjectContext必须工作在一个队列上。可通过两种方式来达成。第一种方式就是简单的只在创建NSManagedObjectContext的队列中来使用它。这被称作线程约束。


dispatch_async(queue, ^{
NSManagedObjectContext* moc = [[NSManagedObjectContext alloc] init];
// moc usage
});

第二种方式是将NSManagedObjectContext初始化为concurrency类型,然后通过调用performBlock:^ 或者 performBlockAndWait:^来使用它。如下:


NSManagedObjectContext* moc = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSPrivateConcurrencyType];
[moc performBlock:^{
// use moc in this block
}];

一共有三种异步类型可用:


NSConfinementConcurrencyType - 尽管很多人使用,但是这个类型已经被苹果官方淘汰了。这个类型的意思是:你必须手动保证MOC在创建它的队列内使用。这种情况下,你应该使用init方法来做初始化,而不是initWithConcurrencyType方法。
NSPrivateQueueConcurrencyType - 意味着[moc performBlock:]将在后台队列中执行。
NSMainQueueConcurrencyType - 意味着[moc performBlock:]将在主队列中执行。

NSManagedObject不会被记录到持久化存储中,直到NSManagedObjectContext的save方法被调用。


NSPersistentStoreCoordinator的作用是绑定持久化存储和NSManagedObjectContext。通常,NSPersistentStoreCoordinator有一个持久化存储和多个NSManagedObjectContext,不过,它其实也可以同时处理多个持久化存储。你可以认为NSPersistentStoreCoordinator是持久化存储与NSManagedObject之间的中间层。


要清楚的是,UI更新是在主线程中发生,所以在主线程中的coredata操作都会产生影响,并且可能导致视觉问题或者性能问题。原因是所有UI处理,绘制和用户事件(点击,手势)都在主线程中进行。运行任何其他事情在主线程上都会对app性能产生影响。 If you want to know more about why it is a “failed dream” to create multithreaded UI on any platform, read “Multithreaded toolkits: A failed dream?”.


处理coredata有多重不同的方式。下面是几种实践中比较通用的处理方案。


方案 #1

就是把所有东西都放在主线程中处理。


第一种方法是相当简单的一个:把所有事情放在主线程处理。你需要Xcode生成的默认的CoreData堆栈。下图是这个堆栈的样子:


【图片】



stack1-300x131.png

这个唯一的NSManagedObjectContext是被用来UI处理和记录数据到数据库中。使用范例如下:


1.从服务器获取数据


2.只要数据返回,就展现某种等待提示器


3.存储获得的数据到数据库中(插入,更新,删除)


4.隐藏等待提示器并展示新数据。


然而作为一个非常简单的解决方案,负面影响就是在数据库记录数据的时候,由于它使用主线程在数据库记录新数据,似的app不可用。幸运的是,知名的MBProgressHUD库以一种聪明的方式实现,它能在主线程被coredata任务使用的时候在主线程展示动画。


方案 #2

将后台写任务从主线程中分离。


【图片】



stack2.png

这里,一个工作context被引入,用来存储从服务端收到的数据。一旦数据存储完成,主context可以以下面两种方式与工作context进行合并:


1.一旦工作context完成操作,它将通知主context,这之后工作线程可以通过调用reset方法来进行重置。


2.工作context触发mergeChangesFromContextDidSaveNotification通知后,主context将进行合并。工作context运行save方法后会触发上述通知。


这种方法的负面影响是开发者需要手动进行context间的合并。


方案 #3

利用NSManagedObjectContext间的父子关系。


在iOS5上,Apple在NSManagedObjectContext间引入了父子关系。使用这个可以帮助同步context之间的数据。下面是一个可能的方案:


【图片】



stack4-300x215.png

这个方案拥有在后台队列创建管理对象(NSManagedObject)的好处。但是在调用save方法后,所有数据对象将传给父context(主队列),而且真实的写数据库将依旧在主线程中发生。所以尽管本方案比方案1略强,但是它仍然对主线程有影响。


方案 #4

与方案3反向的管理对象上下文。


【图片】



stack3-1024x354.png

流行库Restkit就是使用的这种结构,这此方案下,一个私有管理对象上下文被用于存储从服务端获取的数据。一旦完成,主context通过NSManagedObjectContextDidSaveNotification消息得到通知,于是主context更新到了它的父context(工作context)的数据。


在主context用于存储数据时候(可以处理较小量的数据),由于在主context与工作context间的父子关系,更改将被自动合并到私有context。


方案 #5

扩展父子关系的使用


【图片】



stack5-300x298.png

这个方案很有趣。作为对于方案4的补充,本方案引入了一个新的并发context,这个context是主context的子context。接下来我们来看看对应的数据流:


1.数据是异步获取的,当coredata在进行处理时候用户依然可以使用app。


2.服务端数据到达后,工作context被用来在数据库中存储数据。既然存储发生在私有队列,所以用户依然可以和之前一样使用app。


3.在工作context调用save方法后,数据就会被合并到主context。现在这个合并是在主队列发生的,但是由于合并是在内存中完成的,所以这是并不会产生严重的性能问题。


4.最终,数据被传递到另一个工作context,由这个工作context来真实的把数据写到存储里。


这种方法的负面影响是,由于有3个context进行合并,所有这些合并工作对app性能有一个可察觉的负面影响。


方案 #6

每个controller里都有一个管理对象context


如果你有很多工作context或者他们存储了大量的数据,主context与这些工作context间的数据合并就发生在主线程,这可能导致app不响应。


另外,主context在持有很多数据时候会变得很重。随着时间继续,对象会不停的加入context中。如果你想清除它,你必须在主context中调用reset方法。但是,如果你有多个视图控制器在屏幕上课件,这种情况在iPad上比较常见,你就需要对这个reset操作小心谨慎了,以免某个视图控制器获得到已经被重置的数据。


【图片】



stack6.png

这个解决方案就是你简单的不合并任何事情到主context中。你不一定只能有一个主context!与所有view controller只有一个主context相反,你可以尝试这种方法:每个view controller都有自己的NSManagedObjectContext。方法如下:


1.当数据从服务器获得后,使用工作context来存储数据。


2.一旦存储完成,就触发一个通知,比如类似MyAppUsersSavedNotification(假设你正在存储user列表数据到数据库中)。


3.显示user列表的控制器MyAppUsersViewController收到消息并执行下述代码:


[self.managedObjectContext reset];
self.fetchedResultsController = nil;
[self.tableView reloadData];

这样,这个view controller的NSFetchedResultsController将会被重新创建(很多例子中,假设你也有懒获取器),它会从coredata获取最新的数据。尽管这个操作是在主队列中进行的,但这应该是相当快速的,只要别忘记设置NSFetchRequest上fetchBatchSize。另外,也要考虑你真实需要的数据,如果你不需要所有字段,那么你应该只使用NSFetchRequest中的propertiesToFetch字段来获取你需要的字段。


哪个更好?

也许你希望找到一种适用所有情况的解决方案。不幸的是,通常来说,最佳方案取决于你的需求。对于简单的使用场景来说你使用方案1即可,但是对于一些更重的使用场景,我们建议你使用RestKit和那些采用了方案4的解决方案。




最新文章

123

最新摄影

微信扫一扫

第七城市微信公众平台