2013-04-15 4 views
0

J'optimise ma première application iOS avant qu'elle n'atteigne le magasin et je remarque les méthodes qui prennent apparemment beaucoup de temps. J'ai une application maître-détail assez simple où les entités du Core Data SQLite sont affichées dans un UITableView, puis en tapant sur un ouvre une vue détaillée où l'utilisateur peut marquer comme favori (en plaçant un drapeau BOOL dans cet objet à YES. dès qu'ils ont atteint leur bouton favori, je l'appelle [NSManagedObjectContext save] pour assurer leurs changements sont immédiatement, et en cas d'imprévu résilier, etc.Performance de la méthode Save de NSManagedObjectContext

Cette opération save prend actuellement environ 205ms lors du test sur mon iPhone 4S. Il sont environ 4 500 entrées dans la base de données, chacune avec quelques chaînes, et quelques valeurs booléennes (enveloppé dans NSNumber s)

Première question: devrait-il prendre 200ms pour faire ce changement? Je ne fais que définir une valeur booléenne, puis enregistrer le contexte, mais je n'ai jamais utilisé de données de base avant, donc je ne sais pas si c'est à peu près normal.

Deuxième question: le code que j'utilise est ci-dessous - est-ce que je fais quelque chose de mal dans le code pour que la méthode prenne autant de temps à s'exécuter?

- (IBAction) makeFavorite: (id) sender 
{ 
    [self.delegate detailViewControllerDidMakeFavorite]; 
    [_selectedLine setIsLiked: [NSNumber numberWithBool: YES]]; 
    [_selectedLine setIsDisliked: [NSNumber numberWithBool: NO]]; 
    NSError *error; 
    if (![[[CDManager sharedManager] managedObjectContext] save:&error]) NSLog(@"Saving changes failed: %@, %@", error, [error userInfo]); 
} 

Peut-être que je me inquiète pour rien (je suis encore relativement nouveau programmeur), mais sur une note plus large, 200ms me suffit pour au moins essayer de résoudre ce problème, non? :)

Répondre

1

Envisager UIManagedDocument. Il gère automatiquement l'enregistrement dans un contexte d'arrière-plan. Je le recommande particulièrement si vous êtes sur iOS 6. Si vous ne transmettez pas d'ID objet ou si vous ne fusionnez pas avec d'autres contextes, vous devriez pouvoir l'utiliser assez facilement et de manière fiable.

Votre cas d'utilisation simple semble fait sur mesure.

+0

J'ai regardé autour de tutoriels sur le sujet, mais n'a trouvé essentiellement rien, il semble qu'il est principalement conçu pour iCloud, que je n'utilise pas. Il semble que ce soit pour créer un document, mais je tire juste une seule entité d'une base de données Core Data SQLite, je n'ai aucun document en soi. Je ne suis pas sûr de savoir comment cela se rattache à ce que je fais du tout, j'en ai peur. – Luke

+0

UIManagedDocument n'est pas seulement pour iCloud. Il fournit une pile de données de base «préconstruite»: MOC principal avec un parent MOC privé s'exécutant sur un thread d'arrière-plan. –

+0

Je n'ai aucune idée de ce qu'est un MOC, ce commentaire était bien au-dessus de ma tête. Je n'ai pas réussi à trouver de documentation ou de tutoriels qui ne soient pas déroutants - faudrait-il réécrire tout mon code Core Data pour l'implémenter? – Luke

0

1) Si la sauvegarde d'un changement de valeur booléenne prendre 200 ms?

Oui, cela pourrait prendre longtemps. Vous effectuez une opération IO et selon la documentation:

Lorsque Core Data enregistre un magasin de SQLite, mises à jour SQLite seulement une partie du fichier magasin. La perte de cette mise à jour partielle serait catastrophique. Vous pouvez donc vous assurer que le fichier est correctement écrit avant que votre application ne continue. Malheureusement, cela signifie que, dans certaines situations, sauvegarder même un petit nombre de modifications dans un magasin SQLite peut prendre beaucoup plus de temps que d'enregistrer, disons, un magasin XML.

-

2) je fais quelque chose de mal dans le code pour la méthode prendre ce temps pour exécuter?

Non, vous faites la sauvegarde au magasin (en supposant que vous avez pas de contexte parent).

-

3) Est-ce 200ms assez pour moi au moins essayer de résoudre ce problème?

Oui. 200ms sont un temps perceptible pour un humain, et seront ressentis. vous pouvez essayer d'effectuer l'enregistrement en arrière-plan, mais cela est dangereux selon le documentation. ou, déplacez-le à la fin de l'édition entière de l'objet. Mon conseil serait de lire et de voir si vous pourriez faire des compromis dans votre architecture de contexte (votre structure de pile CoreData). D'après mon expérience, économiser en arrière-plan n'est pas si mal.

Questions connexes