memory ne libère pas avec ARC et storyboard dans iOS 5.1

Je me casse la tête sur des problèmes de memory avec mon application, l'application fonctionne bien, sauf qu'elle va planter une fois qu'il a frappé avertissement de memory faible et sont très très très laggy lors de l'utilisation pendant 10 à 20 minutes.

EDIT: comment poptoviewcontroller?

introvideo-> welcomeview & tutorialview-> mainviewcontroller-> scannerviewcontoller-> questionview -> (si réponse correcte -> correctView) else -> wrongView

Comment puis-je revenir au controller MainView?

le code ci-dessous doit résoudre l'ajout du controller de vue à la stack navigationcontroller.viewcontroller. Comme j'utilise storyboard poussant de viewcontroller à un autre controller de vue avec pop-out. le code apparaîtra dans le viewcontroller qui se trouve déjà dans la stack viewcontroller.

le stream de mon storyboard en pièce jointe:

https://dl.dropbox.com/u/418769/storyboard%20flow.png

video d'introduction -> vue de bienvenue et vue tutoriel (si nom d'user! existe) -> controller de vue principale

C'est le file principal que l'user va toujours aller.

http://dl.dropbox.com/u/418769/scannerViewController.h

http://dl.dropbox.com/u/418769/scannerViewController.m

J'utilise une séquence personnalisée pour afficher les controllers de vue, ce qui a résolu une partie du problème.

-(void)perform { UIViewController *sourceVC = (UIViewController *) self.sourceViewController; NSInteger index = -1; NSArray* arr = [[NSArray alloc] initWithArray:sourceVC.navigationController.viewControllers]; for(int i=0 ; i<[arr count] ; i++) { if([[arr objectAtIndex:i] isKindOfClass:NSClassFromSsortingng(@"mainViewController")]) { index = i; } } [UIView transitionWithView:sourceVC.navigationController.view duration:0.5 options:UIViewAnimationOptionTransitionCrossDissolve animations:^{ [sourceVC.navigationController popToViewController:[arr objectAtIndex:index] animated:NO]; } completion:^(BOOL completed) { } ]; } 

Cependant, l'application continue à manger la RAM et la VRAM.

J'apprécie vraiment tous les amis ici pour aider à résoudre ma question, la valeur forte a causé ce problème?

Quand vous dites que vous utilisez une "séquence personnalisée pour afficher le controller de vue principal", je ne suis pas sûr si je comprends bien cela. Utilisez-vous performSegueWithIdentifier ? Si oui, alors vous n'éclatez pas; vous appuyez sur une autre copy du controller de la vue principale!

Dans la plupart des scénarimages, vous ne voyez pas une vue enfant du côté droit en boucle à gauche de la vue parente (et votre capture d'écran montre un nombre vertigineux de saisies dans le controller de la vue principale, ce qui est un peu d'un drapeau rouge). C'est un storyboard beaucoup plus habituel (tiré de Beginning Storyboards dans iOS 5 ) chez Ray Wenderlich):

Exemple de storyboard du tutoriel de Ray Wenderlich Habituellement, vous rejetez une vue enfant avec quelque chose comme le suivant, ne pas utiliser une section.

 [self.navigationController popViewControllerAnimated:YES]; 

De, si vous vouliez revenir à plusieurs niveaux, vous utiliseriez popToViewController ou popToRootViewControllerAnimated . Ou si vous utilisez des segments modaux, vous rejetteriez le modal avec dismissViewControllerAnimated .

Si j'ai mal compris ce que vous entendez par "custom segue to pop", pouvez-vous fournir le code que vous utilisez pour cela?

L'parsing assistée par ordinateur est le moyen de résoudre ce problème. Construisez et parsingz et résolvez tous les problèmes. Exécutez votre application sous les instruments Fuites et allocations. Utilisez l'parsing de tas-shot.

  1. L'parsing de @ ken-thomases est sur place. Voir aussi Recherche de fuites .

  2. Je présume que vous utilisez ARC?

  3. Pouvez-vous expliquer quel est le but de l'exemple de code ci-dessus et que fait votre application pour exiger quelque chose comme ça? C'est comme si vous abordiez un symptôme plutôt que de résoudre un problème.

  4. En réponse à votre question, il est peu probable que l'utilisation de strong soit la source de problèmes, à less que vous n'ayez de forts cycles de reference (voir Transitioning to ARC ). Si vous suivez les suggestions de Ken, vous identifierez la fuite de memory de votre application (si tel est le cas), et si oui, où elle se trouve. À ce stade, si vous ne comprenez toujours pas la source de la fuite, vous pouvez afficher le code incriminé ici et je suis sûr qu'il y aura beaucoup de gens prêts à aider. De plus, si vous avez du code, vous vous requestz si la reference strong est inappropriée, publiez ce code pertinent et, encore une fois, je suis sûr que nous serons heureux de vous aider si nous le pouvons.