sauvegarde IOS de base de données asynchrones

Question

Problème Déclaration

J'ai données côté serveur sauver des problèmes de manière asynchrone.

Structure

J'utilise la structure suivante de NSManagedObjectContext afin de parent à l'enfant:

1. writerManagedObjectContext (NSPrivateQueueConcurrencyType)
2. masterManagedObjectContext (NSMainQueueConcurrencyType)
3. backgroundManagedObjectContext (NSPrivateQueueConcurrencyType)

code

J'utilise le code suivant pour enregistrer les données

[backgroundManagedObjectContext performBlock:^{ 
    [backgroundManagedObjectContext save:nil]; 
    [masterManagedObjectContext performBlock:^{ // Starts blocking UI from here 
     [masterManagedObjectContext save:nil]; 
     [writerManagedObjectContext performBlock:^{ 
      [writerManagedObjectContext save:nil]; 
     }] 
    }] 
}] 

Problème

Le code sauve bien. Le backgroundManagedObjectContext enregistre également de manière asynchrone. Toutefois, masterManagedObjectContext et writerManagedObjectContext refusent d'être enregistrés de manière asynchrone et bloquent le thread d'interface utilisateur. (Je sais que ce bloque le thread d'interface utilisateur parce que j'ai essayé d'effectuer des actions qui ont rien à voir avec les données de base et ils ont également été bloqués. Ce n'est pas un cas du coordonnateur persistant ne pas être accessible)

Questions

1. Quelle serait la raison pour laquelle le code ci-dessus bloque le thread principal?
2. Ai-je raison de supposer que je peux appeler le code ci-dessus de n'importe où puisque le save sera appelé dans chaque thread/contexte?

Toute aide serait grandement appréciée.

Modifier

http://floriankugler.com/2013/04/29/concurrent-core-data-stack-performance-shootout/

Apparemment, le gel vient de la tentative de se propager au parent NSManagedObjectContext. L'article semble échapper au fait qu'il est impossible d'avoir une sauvegarde vraiment asynchrone dans le contexte principal.

Les données étaient fortement liées, 5 Mo, et ont pris environ 40 secondes pour enregistrer dans psc. Je ne pense pas que je vais utiliser une structure parallèle comme décrit dans le post puisque la base de code est déjà grande comme elle est. J'apprécierais toutes les stratégies que je peux utiliser pour diminuer ce gel.

Answer 1

Même si backgroundManagedObjectContext est un contexte de file d'attente privée, il continue de propager ses modifications jusqu'à masterManagedObjectContext, en étant le parent. Cela pourrait être là où ça étouffe. La fusion de changements de contextes enfants prend encore du temps CPU, dont les effets deviennent plus prononcés dans une file d'attente occupée comme les interfaces utilisateur.

Vous pouvez toujours utiliser des instruments pour analyser ce qui se passe.

Si votre cas d'utilisation particulier le permet, essayez de définir backgroundManagedObjectContext.persistentStoreCoordinator sur le même psc que writerManagedObjectContext et de ne pas en faire un enfant de masterManagedObjectContext.

Mieux encore, utilisez un cadre génial comme MagicalRecord. Ne vous protège pas des problèmes de ce type, mais moins de code rend les choses (sans doute) un peu plus faciles à déboguer.