web-dev-qa-db-fra.com

L'application se bloque dans la version Release mais pas dans le débogage

Comme je l'ai dit dans le titre, j'écris une application pour iPhone qui fonctionne parfaitement en mode débogage, mais lorsque je la construis en tant que version finale et que je l'installe via TestFlight, elle se bloque. En raison du journal des incidents, il peut être nécessaire de faire quelque chose avec ces lignes:

let path = NSBundle.mainBundle().pathForResource("PrinterList", ofType: "plist")
if path != nil {
    let printerDic = NSDictionary(contentsOfFile: path!)
    let printerList = NSArray(array: printerDic.allKeys)
    printerNames = printerList as [String]
}

J'utilise un framework Brother pour imprimer sans AirPrint, mais je pense que ce n'est pas le problème car l'application se bloque avant de faire quelque chose avec le framework . Elle se bloque uniquement dans ce ViewController où j'exécute ces lignes. J'ai besoin du cadre uniquement dans ce ViewController.

iosobjective-cswiftcrash-reportstestflight
28
Ben

Il existe de nombreuses raisons pour lesquelles une application risque de tomber en panne en mode de publication mais pas en mode débogage (par exemple, les différences d’allocation de mémoire indiquant un bogue existant dans les deux versions). Elles peuvent nécessiter beaucoup de travail, même avec un logiciel non compilateur bêta/langage.

Vous dites que le problème disparaît si vous suivez les instructions que je vous ai données et que vous générez une version avec optimisations désactivées. Étant donné que le compilateur Swift est toujours en version bêta et qu’il a toujours un problème occasionnel (j’ai vu le compilateur planter tout simplement en construisant des versions optimisées), il s’agit peut-être d’un bogue d’optimiseur.

Pour le moment, je différerais donc de regarder. Libérez sans optimisations jusqu'à ce que nous obtenions une version complète du compilateur. Ensuite, réactivez les optimisations et voyez si le problème persiste. Si vous le faites, c'est le temps de commencer à dépenser votre énergie à essayer de déterminer s'il s'agit d'un bogue du compilateur ou de votre propre code.

37
Matt Gibson

J'ai eu le même problème. J'ai finalement résolu le problème en activant whole module optimization. Combiné avec les implémentations correctes de contrôle d'accès .__, cela devrait résoudre votre problème.

Optimisation de tout le module selon Apple:

Utilisez Optimisation du module entier pour déduire le résultat final sur les déclarations internes . Déclarations avec accès interne (valeur par défaut si rien n'est déclaré) ne sont visibles que dans le module où ils sont déclarés. Parce que Swift compile normalement les fichiers qui composent un module séparément, le compilateur ne peut pas déterminer s'il existe ou non une déclaration interne est remplacé dans un autre fichier. Cependant, si Whole Module L'optimisation est activée, tout le module est compilé ensemble à la en même temps. Cela permet au compilateur de faire des inférences sur le ensemble du module et infère final sur les déclarations avec .__ interne. s'il n'y a pas de substitutions visibles.

Vous pouvez l'activer dans les paramètres de votre projet:

Whole Module Optimization

Sachez toutefois que cette option optimise tous les fichiers d'une cible et permet de meilleures performances au prix d'un temps de compilation plus long.

7
Antoine

Pour attraper le crash test avec le niveau d'optimisation défini sur Plus rapide, plus petit [-Os] en mode débogage pour simuler plus précisément le code qui sera généré et exécuté sur le périphérique de l'utilisateur.

Vous pouvez le définir dans les paramètres de construction, sous Swift Compiler/Génération de code

2
Sakshi Singla

Apple décrit également un problème connu problème . Je décris brièvement au cas où quelqu'un chercherait une réponse et que la solution précédente ne fonctionnerait pas. 

Vérifiez votre crashlog pour des erreurs comme 

Dyld Error Message:
  Library not loaded: @rpath/libswiftCore.dylib

ou 

[....] [deny-mmap] mapped file has no team identifier and is not a platform binary:
/private/var/mobile/Containers/Bundle/Application/5D8FB2F7-1083-4564-94B2-0CB7DC75C9D1/YourAppNameHere.app/Frameworks/libswiftCore.dylib

et suivez Apple conseils si vous avez un crash similaire à celui ci-dessus.

PS: Vous pouvez consulter le journal facilement, même sous Fenêtre -> Périphérique XCode. Cliquez sur le périphérique, puis sur Afficher les journaux du périphérique.

0
flatronka