2010-11-30 28 views
5

Nous recevons un journal de plantage d'iTunes connect qui est un peu étrange.Crash de l'application iPhone au lancement

Nous avions des problèmes avec notre application qui prenait beaucoup de temps à revenir de ApplicationDidFinishLaunching. Cela a été causé par un trop grand travail dans applicationDidFinishLaunching et nous avons dépassé le délai de 20 secondes sur les périphériques plus lents. Pour résoudre ce problème, nous avons déplacé tout notre code d'installation de ApplicationDidFinishLaunching et l'avons déplacé dans un secondaryLoadingController spécial. En plus de cela, nous avons déplacé le code d'installation à l'intérieur de ce contrôleur vers un thread séparé. Toutefois, nous observons toujours des journaux de plantage qui indiquent que l'application n'a pas pu être lancée à temps, même si le journal de plantage affiche un appel à [UIApplication _reportAppLaunchFinished]. Pour moi, cela indique que l'application a terminé le lancement et nous devrions être libres de prendre aussi longtemps que nous voulons exécuter notre code d'installation. Voici le journal des accidents.

Merci pour toute aide que vous pouvez offrir.

Incident Identifier: 429360D5-6B02-49BE-9A0F-164DC521BE36 
Hardware Model:  iPod2,1 
Process:   XYZ [357] 
Path:   /var/mobile/Applications/D5038F26-CC5B-48E5-824E-090163B5C0C4/XYZ.app/XYZ 
Identifier:  XYZ 
Version:   ??? (???) 
Code Type:  ARM (Native) 
Parent Process: launchd [1] 



Date/Time:  2010-09-28 13:35:25.138 -0700 
OS Version:  iPhone OS 4.0 (8A293) 
Report Version: 104 



Exception Type: 00000020 
Exception Codes: 0x8badf00d 
Highlighted Thread: 0 



Application Specific Information: 
com.xyz.xyz failed to launch in time 
elapsed total CPU time (seconds): 20.180 (user 15.910, system 4.270), 100% CPU 
elapsed application CPU time (seconds): 10.960, 54% CPU 



Thread 0: 
0 libobjc.A.dylib     0x3523a50c objc_msgSend + 44 
1 CoreFoundation     0x363bf568 -[__NSArrayM addObject:] 
2 XYZ      0x0000a152 -[Database fetchDrinks:] + 290 
3 XYZ      0x0000677c -[Database getAllDrinks] + 136 
4 XYZ      0x0003a164 -[SecondaryLoadingViewController viewDidLoad] + 208 
5 UIKit        0x323e582c -[UIViewController view] 
6 UIKit        0x323f9628 -[UIViewController viewControllerForRotation] 
7 UIKit        0x323f9574 -[UIViewController _visibleView] 
8 UIKit        0x323f94fc -[UIViewController rotatingContentViewForWindow:] 
9 UIKit        0x3249a514 -[UIClientRotationContext initWithClient:toOrientation:duration:andWindow:] 
10 UIKit        0x32499314 -[UIWindow _setRotatableClient:toOrientation:duration:force:] 
11 UIKit        0x32497d78 -[UIWindowController transition:fromViewController:toViewController:target:didEndSelector:] 
12 UIKit        0x32497534 -[UIViewController presentModalViewController:withTransition:] 
13 UIKit        0x324977fc -[UIViewController _tryRecursivelyPresentModalViewController:withTransition:] 
14 UIKit        0x324977c0 -[UIViewController _tryRecursivelyPresentModalViewController:withTransition:] 
15 UIKit        0x32496e00 -[UIViewController presentModalViewController:withTransition:] 
16 UIKit        0x3249699c -[UIViewController presentModalViewController:animated:] 
17 XYZ      0x000044a2 -[HomeViewController viewDidLoad] + 82 
18 UIKit        0x323e582c -[UIViewController view] 
19 UIKit        0x323fd68c -[UIViewController contentScrollView] 
20 UIKit        0x323fd4ac -[UINavigationController _computeAndApplyScrollContentInsetDeltaForViewController:] 
21 UIKit        0x323fd358 -[UINavigationController _layoutViewController:] 
22 UIKit        0x323fccb8 -[UINavigationController _startTransition:fromViewController:toViewController:] 
23 UIKit        0x323fca1c -[UINavigationController _startDeferredTransitionIfNeeded] 
24 UIKit        0x323fc90c -[UINavigationController viewWillLayoutSubviews] 
25 UIKit        0x323fc43c -[UILayoutContainerView layoutSubviews] 
26 UIKit        0x32370ab0 -[UIView(CALayerDelegate) _layoutSublayersOfLayer:] 
27 CoreFoundation     0x363c85ba -[NSObject(NSObject) performSelector:withObject:] 
28 QuartzCore      0x30c8c61c 0x30c82000 + 42524 
29 QuartzCore      0x30c8c2a4 0x30c82000 + 41636 
30 QuartzCore      0x30c8bbb0 0x30c82000 + 39856 
31 QuartzCore      0x30c8b7d8 0x30c82000 + 38872 
32 QuartzCore      0x30c8b684 0x30c82000 + 38532 
33 UIKit        0x323d99d4 -[UIApplication _reportAppLaunchFinished] 
34 UIKit        0x3251d77c -[UIApplication _runWithURL:payload:launchOrientation:statusBarStyle:statusBarHidden:] 
35 UIKit        0x323d87b8 -[UIApplication handleEvent:withNewEvent:] 
36 UIKit        0x323d7eb4 -[UIApplication sendEvent:] 
37 UIKit        0x323d77e8 _UIApplicationHandleEvent 
38 GraphicsServices     0x33c4dedc PurpleEventCallback 
39 CoreFoundation     0x364142ac __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ 
40 CoreFoundation     0x364161d6 __CFRunLoopDoSource1 
41 CoreFoundation     0x3641718e __CFRunLoopRun 
42 CoreFoundation     0x363be0bc CFRunLoopRunSpecific 
43 CoreFoundation     0x363bdfca CFRunLoopRunInMode 
44 UIKit        0x32363b18 -[UIApplication _run] 
45 UIKit        0x32361fb8 UIApplicationMain 
46 XYZ      0x00002b20 main + 36 
47 XYZ      0x00002af0 start + 32 

MISE À JOUR Je tente d'exécuter le temps code d'importation (ne se passe sur une mise à jour de l'application) sur un thread séparé. Je suis même en train de mettre à jour le GUI en utilisant un AlertView avec une barre de progression intégrée pour que l'utilisateur sache que quelque chose se passe encore. Au cours de notre processus de test, cela fonctionne très bien. Voici le code du thread qui semble ne pas fonctionner. Le journal des pannes semble indiquer que tout le travail est effectué sur le thread principal.

if ([database appDidUpdate] == YES) { 
    NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init]; 
    dbImportThread = [[NSThread alloc] initWithTarget:self selector:@selector(import) object:nil]; 
    [dbImportThread start]; 
    [pool release]; 

- (void)import { 
//do importing work and update the gui with the progress 
} 
+1

Est-ce que toutes ces informations que vous chargez sont requises immédiatement par l'application?chargement paresseux devrait être votre ami dans les appareils mobiles. –

+0

+1 pour @Jesse Naugher. Vous avez des problèmes plus importants que le plantage si votre conception pour une application mobile nécessite que vos utilisateurs restent debout pendant plus de 20 secondes pendant le démarrage de l'application. C'est juste un mauvais design. Vous pouvez résoudre tous vos problèmes et améliorer l'application en général en ne chargeant que les données dont vous avez besoin pour un affichage immédiat. – TechZen

+0

Ce chargement ne se fait réellement que sur une mise à jour. Nous avons beaucoup de données saisies par l'utilisateur que nous sauvegardons aux valeurs par défaut de l'utilisateur. Si la mise à jour est fournie avec une nouvelle base de données, nous devons importer les données utilisateur dans la nouvelle base de données. Donc, ce cas ne se produit pas trop souvent, mais lors d'une mise à jour, les personnes ayant des appareils plus lents rencontrent toujours des problèmes. – jmurphy

Répondre

4

Vous bloquez toujours le thread principal trop longtemps - que ce soit pendant le lancement ou plus tard. Seul l'interface graphique légère fonctionne sur le thread principal. Le thread principal est également bloqué si vous effectuez un travail sur un deuxième thread mais attendez dans votre thread principal pour les résultats.

Instruments est votre ami ici.

+1

+1 Le système d'exploitation recherche tout ce qui ressemble à un gel d'interface utilisateur de plus de 20 secondes, quel que soit le moment où il se produit. – TechZen

+0

Donc, si je cours le code sur un fil séparé, ça devrait aller? Je viens de trouver du code supplémentaire qui pourrait bloquer l'interface graphique. J'espère que je peux mettre cela sur un fil séparé et être ok. – jmurphy

+0

Oui, mais le temps CPU n'est pas votre problème - l'heure du mur est. Ne bloquez pas, et ça devrait aller. Et planifiez les mises à jour (courtes) de l'interface graphique sur le thread principal avec performSelectorOnMainThread. – Eiko

0

Bien que je n'ai pas l'expérience directe avec cela, après avoir lu votre journal de l'accident, il semble que l'appareil a remarqué votre application en prenant le temps de CPU à 100% pour un peu plus de 20 secondes après le lancement. Il semblerait que même si cette utilisation du processeur ne se trouve pas dans la méthode applicationDidFinishLaunching:, le système d'exploitation n'est pas dupe et met fin à votre application.

1

sa mise en veille d'un chien de garde. son blocage du thread principal pendant plus de 20 secondes. comme cela a été dit, vous avez besoin de charge paresseuse. seulement charger quelque chose qui sera visible sur le premier écran. Utilisez des instruments, essayez de corriger tout ce qui est particulièrement inefficace et essayez de vous débarrasser de tout ce que vous pouvez faire avec un thread d'arrière-plan. (IE tout ce qui ne va pas mettre à jour le UI) vous pouvez charger beaucoup de données sur un thread d'arrière-plan, et une fois que les objets de données ont été configurés, les renvoyer au thread principal, et exécuter un sélecteur de mise à jour à partir de là.

2

semble que tout fonctionne sur le thread principal ... (ai-je raison?) Si c'est le cas, il peut bloquer votre interface utilisateur. Avez-vous envisagé de charger vos informations de base de données sur un autre thread et de mettre à jour votre interface graphique lorsque vous récupérez les données? En second lieu, vous pouvez mesurer la performance de chaque morceau de code dans la relation de temps-cosuming et voir ce qui prend exactement autant de temps à charger.