22 votes

Des centaines de accède à "InputModeProperties.plist" sont à la traîne, mon jeu (iPhone)

j'ai un problème bizarre avec une correction de bug pour les petites Ailes. Dans mon jeu, j'ai utiliser quelque chose comme:

NSUserDefaults *userDefaults = [NSUserDefaults standardUserDefaults];      
[userDefaults setFloat:musicVolume forKey:@"musicVolume"];

pour l'enregistrement de certaines préférences et le tableau des meilleurs scores. À la fin de la partie lorsque la gameover écran apparaît le jeu enregistre les meilleurs scores pour la standardUserDefaults. Il fonctionne très bien jusqu'à ce que le jeu affiche un UIAlertView comme ceci:

UIAlertView *alert = [[UIAlertView alloc] init];
[alert setTitle:@"Get ready!"];
[alert setDelegate:self];
[alert addButtonWithTitle:@"Ok"];
[alert show];
[alert release];

Après la AlertView disparu chaque fois que le jeu enregistrer quelque chose pour le standardUserDefaults le jeu lag pendant un certain temps (sur certains appareils pendant plusieurs secondes). Cela se produit également après le jeu utilisé un UITextField pour saisir le nom du joueur. Il n'y a aucun lag dans le jeu avant de l'un des deux UIKit Éléments sont utilisés, mais après l'utilisation de ces le jeu lag jusqu'à ce que je redémarrez l'application. J'ai analysé le problème avec les Outils de Performance et "I/O" l'Activité de l'Instrument montre qu'il y a des centaines de "open - lire - fermer" accède à la

/System/Library/Frameworks/UIKit.framework/InputModeProperties.plist

ce qui provoque le gal.

Je totalement n'ai aucune idée de quoi faire et serait très heureux si anybode peut me donner un indice. Merci à l'avance.

[modifier] il y a un thread dans l'apple developer forum http://devforums.apple.com/message/424374#424374 où quelqu'un a le même problème et il semble qu'il n'apparaît qu'avec l'iOS 4.3. Je l'ai testé et le lag ne se produit que sur mon 4.3 appareils (pas sur de 3,1 iPod Touch et 4.2 de l'iPad).

3voto

Martin Points 589

Ok, en Regardant autour, il semble que InputModeProperties.plist est juste une liste de matériel et de logiciels claviers.

En regardant le fil de discussion du forum que vous avez posté cette question semble n'être qu'après le chargement d'un objet UITextField ou UIAlertView (qui comprend UITextInputTraits.h parmi d'autres) à chaque fois que vous essayez d'enregistrer les paramètres utilisateur par défaut il y a un inexplicable de la boucle de l'un des claviers les définitions de fichier. Cela se produit uniquement dans l'iOS 4.3.

Il semble terriblement comme un bug dans UIKit pour moi et ma conjecture est que, soudain, UIKit est l'enregistrement d'une charge de choses pour aucun but réel. Si c'est le cas, il peut être difficile de faire quoi que ce soit, bien que vous pourriez éviter ces éléments (pas trop mal pour l'alerte, mais le champ est plus délicat) ou vous pouvez passer à la base de données. Alternativement, vous pourriez faire une mutable dictionnaire pour tous vos options et enregistrer l'utilisateur, les valeurs par défaut lorsque l'application se ferme et vous avez moins de soins sur une pause. Ou, juste monter une mise à jour.

Bonne chance (le jeu de l'amour btw)

3voto

Vincent Guerci Points 8619

MODIFIER

Un décent bug solution de contournement :

Version courte: Seulement retarder le bug de déclenchement des appels jusqu'à ce que l'utilisateur n'est pas gêné.

Version longue:

Car je pense que le problème vient de [NSUserDefaults standardUserDefaults] d'appel, qui déclenche cette sale plist-chargement en boucle APRÈS certains d'action de la requérante, les dispositions de Clavier (par exemple, une UIAlert)...

Je suggère d'appeler [NSUserDefaults standardUserDefaults] une seule fois à l'application de chargement (AVANT tout bug causant d'appel), et de garder le retourné de référence dans une classe singleton pendant tout cycle de vie des applications. Je ne pense pas que l'empreinte mémoire serait énorme... (je fais cela dans plusieurs applications w/o toutes les questions). Au pire la plist charge*100 serait fait en une seule fois au chargement des applications, et non en cours de jeu.

Si le problème vient de l' [userDefaults setXxxx:...] des appels, même solution de contournement, vous pouvez simplement conserver les valeurs à enregistrer dans la mémoire et les mettre plus tard en userDefaults, comme juste avant de se synchroniser entre eux... Mais au risque de perdre des informations si quelque chose va mal, comme un crash. Personnellement, je préfère sync après chaque set afin d'assurer l'intégrité des données...

ENDOFEDIT


La réponse courte : iOS4.3 bug, très peu de chances de trouver une solution de contournement... rapport de bogue et d'attendre la prochaine mise à jour d'iOS... de la WWDC en 2 semaines... 1~2 mois.

La longue:

Après avoir regardé UIKit l'assemblée, ici sont mes suppositions:

  • InputModeProperties.plist contient une liste de tous les claviers par les paramètres régionaux.
  • UIKit l'utiliser pour plusieurs choses, comme lors de l'affichage d'un clavier, d'établir les claviers. (Les paramètres régionaux...)
  • Une chose est intéressante, on peut trouver certaines de ses informations en NSUserDefaults :

    NSLog(@"%@", [[NSUserDefaults standardUserDefaults] dictionaryRepresentation]);
    ==> {
    AppleKeyboards =     (          // I have two keyboard in preferences
       "fr_FR@hw=French;sw=AZERTY", // french  first
       "en_US@hw=US;sw=QWERTY"      // english second
    );
    ...
    
  • Mais ces informations ne sont pas stockées dans les applications préférences, contrairement à votre score. (NSGlobalDomain, ou plus probablement des domaines Distincts pour chacune de ses langues préférées)
  • Donc je ne serais pas surpris de voir un conflit (bug) existe dans UIKit + NSUserDefaults à l'origine de ce sale plist chargement de la boucle.
  • Autour de 100 appelez, dites-vous? C'est quelque chose comme le nombre de paramètres régionaux/layouts dans le plist!

Lorsque aucun clavier n'est disponible en NSUserDefaults... (Comme après la synchronisation, imaginons un bug faisant cela)... UIKit pourrait essayer tous les claviers disponibles pour déterminer un utilisateur, salement cette analyse 4.4 K plist des centaines de fois... Comme lors de la démonstration de l' UIAlertView... après un NSUSerDefault sync/modifier.

Qui sait? La Pomme de gens qui a le code source :)

Je ne serais pas surpris d'aller dans les préférences pour définir un clavier autre que celui par défaut, etats-unis, puis de revenir à NOUS permettrait de résoudre le problème. Inutile dans votre cas, mais de confirmer le problème. Vu que pour un autre 4.3 bug...

Comme d'autres ont dit, ne pas utiliser NSUserDefaults mais une simple coutume plist dans /Documents pourrait être une (en)décent solution de contournement.

Excellent travail sur de Minuscules Ailes! :)

2voto

Moshe Points 23825

À l'aide de UIKit et OpenGL n'est pas recommandée. Je ne pense pas que ce point de vue est le problème tant que le concept de mélanger les deux. Je recommande fortement nixing qui alerte et plutôt, de montrer une coutume de superposition, de sorte que vous pouvez accomplir deux choses:

  1. Faire le "Get Ready" alerte match les graphismes du jeu.
  2. D'éviter ce problème.

J'ai vu ralentir les performances avec la version actuellement sur l'App Store, lors de la reprise le jeu sur une deuxième génération de l'iPod touch.

Si vous voulez garder ces éléments est, ce qu'Apple Developer Forum post suggère l'exécution de la synchroniser sur un thread séparé. Va avec ça, je voudrais suggérer que ces étapes:

  1. D'autres ont suggéré, de conserver une référence à NSUserDefaults quelque part. (J'ai l'habitude de tout simplement faire quelque chose comme ceci: #define kSettings [NSUserDefaults standardUserDefaults]. Bien sûr, vous avez besoin d'invoquer une fois pour instancier le singleton.)

  2. Exécutez l' synchronize appel à un deuxième thread (comme par Apple Developer Forum).

  3. Voir si on peut appeler synchronize à un autre moment qu' willResignActive. La question semble un peu pire lorsque vous appelez une synchronisation à partir de cette méthode.

Félicitations pour le jeu.

1voto

kball Points 2499

Juste un coup de feu dans l'obscurité de la recherche sur la 4.3 diff -

Peut-être une combinaison de la nouvelle

- (BOOL)disablesAutomaticKeyboardDismissal

sur UIViewController et UIModalPresentationFormSheet (où il est réglé par défaut sur OUI) est à l'origine une sorte de boucle dans votre code.

1voto

gotnull Points 4918

En supposant que vous exécutez une méthode pour afficher l'alerte de vue, avez-vous essayé le suivant?

[self performSelector:@selector(displayAlert) withObject:nil afterDelay:0.5];

- (void)displayAlert {
  UIAlertView *alert = [[UIAlertView alloc] init];
  [alert setTitle:@"Get ready!"];
  [alert setDelegate:self];
  [alert addButtonWithTitle:@"Ok"];
  [alert show];
  [alert release];
}

La raison pour laquelle je demande, c'est que j'ai souvent ressenti une étrange comportement lorsque vous tentez d'exécuter une méthode tout de suite après la synchronisation NSUserDefaults. Sinon, nous aurions vraiment besoin de voir un peu plus de code afin de déterminer ce qui se passe.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X