At the #pragma Conference 2015 conference, Marcus Zarra, wrote a book on core data and core animation, and described three ways to use core in a multithreaded environment Data method and try to solve the problem of how to use core data in 2015. In fact, Zarras says that one of the problems you face when working with a 11-year-old technology such as core data is that there is a lot of information available, but it's not easy to find out which information is still accurate and which is imprecise.
According to Zarras, we should use multi-threading when we know we still have spare CPUs, so we can pre-process the data that the user is going to use next. Multithreading Another important use case is to improve the agility of an app, such as network operations, by allowing users to do so without waiting for a lengthy operation. Multithreading is almost never a solution to performance problems and it is a fundamental design decision, not an afterthought.
The initial approach
The initial approach was the only available method before iOS 6 was introduced. This method is still available now, although Zarra suggests not to use it except in some extreme cases. It is based on four main principles:
- A nspersistentstorecoordinator (PSC) handles the interplay of all disks.
- Nsmanagedobjectcontexts (Mocs) dialogues with the PSC and does not know anything about each other.
- One of the Mocs is responsible for updating the UI and working on a single trusted source.
- One of the only ways a MOC begins to realize the change of another MOC is to combine a nsnotification with merging.
This design has some shortcomings, such as the need to write a lot of formulaic code, the thread rules are not clear will cause the unpredictable crash and unexpected thread blocking. With the introduction of iOS 8, these issues have improved some. And thanks to a debug flag, Yosemite can crash the application when it violates the core data concurrency model.
The Hard Way
What Zarras calls the hard way is a method that relies on the multi-process access to SQLite. This means that we can have multiple PSC so that each MOC can have its own PSC. This can be a good way to get rid of any locking problem and enable almost all asynchronous access-unless you write the same table and line up two PSC at the same time.
Even with this design, it is advisable to use only one MOC to feed the data to the UI. This approach makes it difficult to synchronize data with the PSC because they don't know anything about each other. In addition, threading and maintainability can also be compromised. The interesting aspect of this approach is that this is the true portrayal of how icloud works.
The best way
According to Zarra, the best approach is not the fastest, but it is by far the simplest and most sustainable method. It relies on the new apis,new APIs introduced by Apple and iOS 61 to allow the definition of a sub-MOC and to describe in detail the concurrency type of an MOC. The design presented by Zarra is based on how Nsmanageddocument works and uses:
- A separate persistent data coordinator.
- The only one private MOC that can actually access the PSC.
- A primary MOC Federated UI, which is a private MOC sub-device.
- Multiple sub-MOC specific to the worker thread.
The benefit of this design is that all changes in the sub-MoC are automatically routed to their main MOC, eliminating the need for consolidation.
The main drawback of the design is that it is slow, albeit only a few percent slower, Zarra said. One tricky problem is that if you do too many asynchronous operations, it's possible to have a ripple effect on the UI because its associated MOC is subject to multiple variations of the sequence, which may be irrelevant to the other.
A very important detail of this design is that it is best not to reuse the sub-MOC that can be created cheaply. On the other hand, a long-lasting sub-MOC should be kept in sync with the main MOC manually, since the change is only from the sub-MOC to the main MOC and vice versa.
Zarra's final comment is that using nsmanageddocument will lock the UI, so you'd better get ready.
View English Original: Three Ways to Get Core Data multithreading Right
3 ways to properly use core data multi-threading