Dois-je désactiver NSLog avant de lancer l'application ?

Question

Lors de la sortie d'une application pour iPhone, si je désactive la fonction NSLog(); sera-t-il plus performant ?

Answer 1

Une façon de le faire est d'aller dans vos paramètres de construction et sous la configuration de débogage ajouter une valeur à la valeur "Macros du préprocesseur" comme :

DEBUG_MODE=1

Assurez-vous que vous ne faites cela que pour la configuration Debug et non pour les versions Beta ou Release. Ensuite, dans un fichier d'en-tête commun, vous pouvez faire quelque chose comme :

#ifdef DEBUG_MODE
#define DLog( s, ... ) NSLog( @"<%p %@:(%d)> %@", self, [[NSString stringWithUTF8String:__FILE__] lastPathComponent], __LINE__, [NSString stringWithFormat:(s), ##__VA_ARGS__] )
#else
#define DLog( s, ... ) 
#endif

Maintenant, au lieu de NSLog utiliser DLog partout. Lors des tests et du débogage, vous obtiendrez des messages de débogage. Lorsque vous serez prêt à publier une version bêta ou finale, tous ces messages de débogage seront affichés. DLog deviennent automatiquement vides et rien n'est émis. De cette manière, il n'y a pas de paramétrage manuel des variables ou de commentaire de NSLogs nécessaire. Le choix de votre cible de construction s'en charge.

Answer 2

Mise à jour pour Xcode 5 et iOS 7

note : pour un Xcode 7 / Swift 2.1 solution pour éliminer print() dans un build de version, trouver ma réponse aquí .

Oui, vous devez supprimer toute déclaration NSLog dans votre code de version, car elle ne fait que ralentir votre code, et n'est d'aucune utilité dans une version de version. Heureusement, dans Xcode 5 (iOS 7), il est étonnamment simple de supprimer toutes les déclarations NSLog "automatiquement" dans les versions release. Alors pourquoi ne pas le faire.

D'abord les 3 étapes à suivre, puis quelques explications

1) Dans votre projet Xcode, localisez le fichier 'yourProjectName-prefix.pch' (normalement, vous le trouverez dans le groupe 'supporting files', où se trouve votre fichier main.m).

2) ajouter ces 3 lignes à la fin du fichier '.pch' :

#ifndef DEBUG
   #define NSLog(...);
#endif

3) testez la différence entre votre version 'debug' et 'release'. Une façon de le faire est de passer par 'edit scheme' -> 'run app name' -> sous l'onglet 'info' sélectionnez en utilisant la boîte déroulante entre debug et release. Dans la version release, vous ne verrez pas de sortie NSLog dans la console de débogage !

Comment tout cela fonctionne-t-il ?

Tout d'abord, il faut savoir qu'un préprocesseur est relativement "bête", et agit simplement comme un "substitut de texte" avant que le compilateur ne soit appelé. Il remplace tout ce que vous "#definez" par ce qui suit la balise #define déclaration.

#define NSLog(...);

El (...) signifie "tout" entre les crochets (). Pensez aussi au ; à la fin. Ce n'est pas strictement nécessaire car le compilateur l'optimisera, mais j'aime bien le mettre là, car c'est plus "correct". Après notre #define il n'y a rien, donc le préprocesseur le remplacera par "rien", et donc il jettera la ligne complète, en commençant par NSLog... jusqu'à et y compris le ; .

Les déclarations de définition peuvent être rendues conditionnelles en utilisant #ifdef (si elle est définie) ou #ifndef (si non défini)

ici nous écrivons #ifndef DEBUG ce qui signifie "si le symbole DEBUG n'est pas défini". Le site #ifdef o #ifndef doivent être "fermés" avec #endif

Xcode 5 définit par défaut le symbole 'DEBUG' pour nous lorsque le mode de construction est 'DEBUG'. En 'release', il n'est pas défini. Vous pouvez le vérifier dans les paramètres de votre projet, onglet 'Build settings' -> descendez jusqu'à la section 'Apple LLVM 5.0 - Preprocessing' -> macros du préprocesseur. Vous verrez que le symbole 'DEBUG' n'est pas défini pour les builds release !

enfin, le fichier .pch est créé automatiquement par Xcode, et automatiquement inclus dans chaque fichier source lors de la compilation. Ainsi, c'est comme si vous aviez mis tout le fichier .pch dans le fichier source. #define dans chacun de vos fichiers sources.

Answer 3

Presque toutes les réponses ci-dessus suggèrent une solution mais n'expliquent pas le problème. J'ai fait une recherche dans google, et j'ai trouvé la raison. Voici ma réponse :

Oui, si vous commentez NSLog dans votre version, les performances s'amélioreront. Parce que NSLog est assez lent. Pourquoi ? NSLog va faire deux choses : 1) écrire les messages de log dans Apple System Logging (ASL), 2) si l'application s'exécute en xcode, elle écrit aussi sur stderr.

Le principal problème réside dans le premier. Afin d'obtenir une sécurité thread, à chaque fois que NSLog est appelé, il ouvre une connexion à l'installation ASL envoie le message, et ferme la connexion. L'opération de connexion est très coûteuse. Une autre raison est que NSLog prend un certain temps pour obtenir l'horodatage à enregistrer.

Référence de aquí .

Answer 4

Mon préféré est d'utiliser une macro variadique.

#ifdef NDEBUG
    #define NSLog(...) /* suppress NSLog when in release mode */
#endif

Answer 5

En plus de toutes les personnes qui ont judicieusement fait remarquer que ne pas appeler NSLog() du tout dans la production est légèrement plus rapide, je vais ajouter ça :

Tous ceux NSLog() les chaînes de sortie sont visibles pour toute personne qui télécharge votre application depuis le magasin et l'exécute avec l'appareil branché sur un Mac exécutant Xcode. (par la fenêtre de l'Organisateur).

En fonction des informations que vous enregistrez (et surtout si votre application contacte un serveur, procède à une authentification, etc,) cela peut être un sérieux problème de sécurité .