crash IOS périodique, mais je ne vois aucune implication de mon application dans le rapport d'accident

Question

Environ une fois par semaine, je reçois un accident comme celui-ci. Peut-être que je me trompe, mais je ne vois aucune implication de mon application ("WayAndSee"). Quelqu'un at-il un indice sur la façon de procéder?

Attaché le rapport de plantage (qui est très généralement pour ce genre de plantage), j'ai juste tronqué la liste finale des bibliothèques.

Un grand merci à l'avance ...

Incident Identifier: 348BDC52-6574-4EED-A6C7-45E79E696875 
CrashReporter Key: f8ac3e1a61b8129920a4ad40aaa56d5536e2ce22 
Hardware Model:  iPhone6,2 
Process:    WayAndSee [8286] 
Path:    /private/var/containers/Bundle/Application/F1542EC3-3708-4B6E-80EA-A2333883359E/WayAndSee.app/WayAndSee 
Identifier:   Hobrink.WayAndSee 
Version:    2487 (0.3.0) 
Code Type:   ARM (Native) 
Role:    Foreground 
Parent Process:  launchd [1] 
Coalition:   Hobrink.WayAndSee [2936] 


Date/Time:   2017-04-04 14:28:15.3459 +0200 
Launch Time:   2017-04-04 13:05:54.5835 +0200 
OS Version:   iPhone OS 10.2.1 (14D27) 
Report Version:  104 

Exception Type: EXC_CRASH (SIGKILL) 
Exception Codes: 0x0000000000000000, 0x0000000000000000 
Exception Note: EXC_CORPSE_NOTIFY 
Termination Reason: Namespace SPRINGBOARD, Code 0x8badf00d 
Triggered by Thread: 0 

Filtered syslog: 
None found 

Thread 0 Crashed: 
0 libsystem_kernel.dylib   0x1cedf84c mach_msg_trap + 20 
1 CoreFoundation     0x1d7082f9 __CFRunLoopServiceMachPort + 137 
2 CoreFoundation     0x1d7065f7 __CFRunLoopRun + 1015 
3 CoreFoundation     0x1d655533 CFRunLoopRunSpecific + 487 
4 CoreFoundation     0x1d655341 CFRunLoopRunInMode + 105 
5 GraphicsServices    0x1ee2cbfd GSEventRunModal + 157 
6 UIKit       0x22863e67 -[UIApplication _run] + 575 
7 UIKit       0x2285e591 UIApplicationMain + 151 
8 WayAndSee      0x000ba890 main (AppDelegateV2a.swift:667) 
9 libdyld.dylib     0x1ce1f50b start + 3 

Thread 1 name: com.apple.uikit.eventfetch-thread 
Thread 1: 
0 libsystem_kernel.dylib   0x1cedf84c mach_msg_trap + 20 
1 CoreFoundation     0x1d7082f9 __CFRunLoopServiceMachPort + 137 
2 CoreFoundation     0x1d7065f7 __CFRunLoopRun + 1015 
3. CoreFoundation     0x1d655533 CFRunLoopRunSpecific + 487 
4 CoreFoundation     0x1d655341 CFRunLoopRunInMode + 105 
5 Foundation      0x1dfaf88b -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 261 
6 Foundation      0x1dfce631 -[NSRunLoop(NSRunLoop) runUntilDate:] + 87 
7 UIKit       0x2316a2b3 -[UIEventFetcher threadMain] + 129 
8 Foundation      0x1e098b11 __NSThread__start__ + 1161 
9 libsystem_pthread.dylib   0x1cfa9a27 _pthread_body + 217 
10 libsystem_pthread.dylib   0x1cfa994d _pthread_start + 235 
11 libsystem_pthread.dylib   0x1cfa749c thread_start + 8 

Thread 2 name: NetworkLoad 
Thread 2: 
0 libsystem_kernel.dylib   0x1cedf84c mach_msg_trap + 20 
1 CoreFoundation     0x1d7082f9 __CFRunLoopServiceMachPort + 137 
2 CoreFoundation     0x1d7065f7 __CFRunLoopRun + 1015 
3 CoreFoundation     0x1d655533 CFRunLoopRunSpecific + 487 
4 CoreFoundation     0x1d655341 CFRunLoopRunInMode + 105 
5 GeoServices      0x244775ff _runNetworkThread + 475 
6 libsystem_pthread.dylib   0x1cfa9a27 _pthread_body + 217 
7 libsystem_pthread.dylib   0x1cfa994d _pthread_start + 235 
8 libsystem_pthread.dylib   0x1cfa749c thread_start + 8 

Thread 3: 
0 libsystem_kernel.dylib   0x1cef5744 __workq_kernreturn + 8 
1 libsystem_pthread.dylib   0x1cfa7490 start_wqthread + 8 

Thread 4: 
0 libsystem_pthread.dylib   0x1cfa7488 start_wqthread + 0 

Thread 5: 
0 libsystem_pthread.dylib   0x1cfa7488 start_wqthread + 0 

Thread 6: 
0 libsystem_pthread.dylib   0x1cfa7488 start_wqthread + 0 

Thread 0 crashed with ARM Thread State (32-bit): 
    r0: 0x10004005 r1: 0x07000806  r2: 0x00000000  r3: 0x00000c00 
    r4: 0x00002403 r5: 0xffffffff  r6: 0x00000000  r7: 0x0042adb4 
    r8: 0x00000c00 r9: 0x00002403  r10: 0x07000806  r11: 0x00000000 
    ip: 0xffffffe1 sp: 0x0042ad78  lr: 0x1cedf63f  pc: 0x1cedf84c 
    cpsr: 0x60000010 

Binary Images: 
0xb0000 - 0x177fff WayAndSee armv7 <7506039ae577329ab9868e3122d84f5f> /var/containers/Bundle/Application/F1542EC3-3708-4B6E-80EA-A2333883359E/WayAndSee.app/WayAndSee 
0x25c000 - 0x267fff libswiftCoreData.dylib armv7s <3022e21a184d3e6c93bac1ad7b18be30> /var/containers/Bundle/Application/F1542EC3-3708-4B6E-80EA-A2333883359E/WayAndSee.app/Frameworks/libswiftCoreData.dylib 
0x27c000 - 0x28bfff libswiftCoreGraphics.dylib armv7s <4415e467b6df386591e646e7a2978da6> /var/containers/Bundle/Application/F1542EC3-3708-4B6E-80EA-A2333883359E/WayAndSee.app/Frameworks/libswiftCoreGraphics.dylib 
0x2a8000 - 0x2affff libswiftCoreImage.dylib armv7s <9bbbe5b77fdd3551921ca7ec1a98ae38> /var/containers/Bundle/Application/F1542EC3-3708-4B6E-80EA-A2333883359E/WayAndSee.app/Frameworks/libswiftCoreImage.dylib 
0x2c0000 - 0x2ebfff dyld armv7s <898b6b42ae3b3ffb8de9a96b7071f49d> /usr/lib/dyld 
0x42c000 - 0x6abfff libswiftCore.dylib armv7s <b760608c5d35390099731eedb8821bc0> /var/containers/Bundle/Application/F1542EC3-3708-4B6E-80EA-A2333883359E/WayAndSee.app/Frameworks/libswiftCore.dylib 

.... 

Answer 1

que je suis arrivé plusieurs questions au sujet de mes progrès sur cette question, j'ai décidé de écrit une réponse par moi-même. Peut-être que cela pourrait être utile pour les autres. Les rapports d'erreur ont une ligne importante: "Motif de terminaison: SPRINGBOARD d'espace de noms, code 0x8badf00d" -> le SPRINGBOARD a essayé de démarrer l'application en arrière-plan ... et "0x8dadf00d" peut être lu comme "mangé de mauvais aliments" (regardez ici sur StackOverflow, de nombreuses explications pour ce code)

La cause première de ce problème est simplement le lancement. Il est trop long pour commencer en arrière-plan. Il y a une limite de temps pour le démarrage de l'arrière-plan d'environ 5 à 7 secondes. Le lancement au premier plan a une fenêtre temporelle autorisée d'environ 20 secondes.

Cette limite de temps inclut le temps BEFORE main() et AFTER main() jusqu'à ce que l'application soit installée et prête à recevoir l'événement de lancement. Chaque lancement d'une application en arrière-plan est causé par un événement de lancement (emplacement, transfert de fichier, etc.)

Pour avoir une idée de la façon d'analyser l'heure avant main(), je suggère de visionner la vidéo "Optimiser le démarrage de l'application" , Session 406, WWDC 2016. Ils expliquent en détail ce qui se passe AVANT et comment l'analyser et le mesurer. Ils décrivent plusieurs variables d'environnement (définies dans la section "arguments" du schéma) qui produisent des journaux utiles.

"main()", oui, je l'ai appris lors de cet examen. Swift lui permet d'avoir un main(). C'est même une possibilité d'exécuter des instructions en dehors d'une fonction, d'une classe, d'une structure ... Il n'y a pas vraiment besoin de ça dans swift. Mais comme je voulais mesurer le temps de lancement après main, j'ai écrit ce simple fichier main.swift pour le faire.

// 
// main.swift 
// ... 
// 
// Created by Hartwig Hopfenzitz on 31.05.17. 
// Copyright © 2017 Hopfenzitz. All rights reserved. 
// 

import Foundation 
import UIKit 

// very first statement after load.. the current time 
let WaysStartTime = CFAbsoluteTimeGetCurrent() 

// build the parameters for the call to UIApplicationMain() 
let argc = CommandLine.argc 
let argv = UnsafeMutableRawPointer(CommandLine.unsafeArgv).bindMemory(to: UnsafeMutablePointer<Int8>.self, capacity: Int(CommandLine.argc)) 

// start the main loop 
UIApplicationMain(argc, argv, nil, NSStringFromClass(AppDelegate.self)) 

Comme vous pouvez le voir: Dans la toute première déclaration, je prends le temps. Avec cela, je peux mesurer la différence de temps au moment où l'application est opérationnelle.

Cependant: Si vous voulez utiliser un main() dans votre projet swift, vous devez commenter ou supprimer l'instruction "@UIApplicationMain" dans AppDelegate.swift. Cette instruction "simule" la fonction main(), donc elle serait redondante.

Et oui, il vaut mieux commencer à mesurer sur main(). J'ai aussi testé avec la mesure du temps en commençant par "willFinishLaunchingWithOptions:". Sur mon appareil de test habituel, un iPhone 5s (appareil de test réel, pas un simulateur), la différence est d'environ 0,4 sec. Je suis sûr que le temps dépend de l'application et comment elle est structurée, donc je suggère de le mesurer à partir de main(). OK, et comme toujours: "si vous mesurez, vous êtes capable de gérer".

La cause principale habituelle des temps de lancement lents est un thread principal surchargé. Ce fil principal est le cheval de travail le plus important de chaque application. Il encombre la boucle d'événement et l'interface utilisateur. Donc, ma première étape a été de déplacer le plus de travail possible loin de la menace principale en utilisant GCD (Grand Central Dispatch).GCD est assez facile à utiliser et vous donne beaucoup d'options pour affiner la charge de travail de plusieurs threads. Il y a plusieurs vidéos sur la GDC sur la WWDC, mon préféré est le "Construire des applications réactives et efficaces avec GCD", Session 718, WWDC 2015.

Cependant, par ceci j'ai réduit le nombre d'accidents de manière drastique, MAIS .. .. il y avait encore des accidents ...

Mon écran initial est si complexe, en utilisant beaucoup de autolayout et autosizing etc .. Il a simplement fallu parfois longtemps pour terminer le rendu avant la limite de temps se bloque l'application. Si je comprends bien, IOS veut que le premier écran fonctionne, pour un lancement réussi.

Eh bien, les mots magiques sont "le premier écran". J'aime mon Main.storyboard, très joli et très adaptatif. Donc je ne voulais pas le réduire. Heureusement, j'ai trouvé ce blog http://timdietrich.me/blog/swift-multiple-storyboards/. Il décrit les étapes nécessaires pour travailler avec plusieurs storyboards dans un projet swift/xcode. Il y en a plusieurs autres à trouver sur internet, mais celui-ci est assez facile à lire et à comprendre. J'ai donc créé un storyboard appelé "Start.storyboard". Ce storyboard est très simple, juste une copie de Launchscreen.storyboard. Et j'ai utilisé cela comme "le premier écran".

J'ai créé cette classe pour le ViewController de cet écran de démarrage, qui ne fait rien d'autre que de lancer mon Main.Storyboard.

// 
// StartViewController.swift 
// ... 
// 
// Created by Hartwig Hopfenzitz on 02.06.17. 
// Copyright © 2017 Hopfenzitz. All rights reserved. 
// 

import UIKit 

class StartViewController: UIViewController { 

    override func viewDidLoad() { 
     super.viewDidLoad() 

     // Do any additional setup after loading the view. 

     // Create instance of our main storyboard 
     let mainStoryboard = UIStoryboard(name: "Main", bundle: nil) 

     // Create the instance of main's initial view controller. 
     let mainController = mainStoryboard.instantiateViewController(withIdentifier: "WaysViewController") as UIViewController 

     // Make sure it will start on the main thread 
     DispatchQueue.main.async(execute: { 

      // present it .. and never come back 
      mainController.modalTransitionStyle = UIModalTransitionStyle.crossDissolve 
      mainController.modalPresentationStyle = .fullScreen // Display on top of current UIView 

      self.present(mainController, animated: true, completion: nil) 
     }) 
    } 
} 

Dans Info.plist, vous trouverez la clé "Nom de base du fichier de storyboard principal". Cette clé indique quel storyboard est celui avec l'écran initial. Donc, dans mon exemple, vous devez changer la valeur de "Main" à "Start", car le nouveau storyboard initial est appelé "Start.storyboard". Voila: le premier écran démarre presque immédiatement et IOS est très heureux de l'heure de lancement. L'utilisateur ne le reconnaît pas.

OK Voilà comment je me suis débarrassé de cette plante ... peut-être il aider les autres ...

Bonne programmation ;-)