Devo disabilitare NSLog prima di rilasciare l'applicazione?

Quando rilasci un'app per iPhone, se la disabilito NSLog();funzionerà meglio?

Un modo per farlo è accedere alle impostazioni di compilazione e nella configurazione di debug aggiungere un valore al valore "Macro del preprocessore" come:

DEBUG_MODE=1

Assicurati di farlo solo per la configurazione di debug e non per le versioni Beta o Release. Quindi in un file di intestazione comune puoi fare qualcosa come:

#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

Ora invece di NSLog usarlo DLogovunque. Durante il test e il debug, riceverai messaggi di debug. Quando sei pronto per rilasciare una versione beta o finale, tutte quelle DLogrighe diventano automaticamente vuote e non viene emesso nulla. In questo modo non è possibile impostare manualmente le variabili o commentare i NSLogsrequisiti. Scegliere il tuo obiettivo di costruzione si prende cura di tutto ciò.

Aggiornamento per Xcode 5 e iOS 7

nota: per una soluzione Xcode 7 / Swift 2.1 per rimuovere le istruzioni print () in una build di rilascio, trova la mia risposta qui .

Sì, dovresti rimuovere qualsiasi istruzione NSLog nel codice di rilascio, poiché rallenta semplicemente il codice e non è di alcuna utilità in una versione di rilascio. Fortunatamente, in Xcode 5 (iOS 7), è incredibilmente semplice rimuovere "automaticamente" tutte le istruzioni NSLog nelle build di rilascio. Allora perché non farlo.

Prima i 3 passaggi da compiere, poi alcune spiegazioni

1) nel tuo progetto Xcode, individua il file 'yourProjectName-prefix.pch' (normalmente lo troverai nel gruppo 'file di supporto', dove si trova il tuo file main.m

2) aggiungi queste 3 righe alla fine del file ".pch":

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

3) prova la differenza tra la tua versione "debug" e "release". Un modo per farlo è tramite "modifica schema" -> "esegui nome app" -> nella scheda "informazioni" selezionare utilizzando la casella a discesa tra debug e rilascio. Nella versione di rilascio non vedrai alcun output NSLog nella console di debug!

Come funziona tutto ciò?

prima di tutto, bisogna sapere che un preprocessore è relativamente "stupido" e agisce semplicemente come un "sostituto di testo" prima che il compilatore venga chiamato. Sostituisce tutto ciò che "#define" con ciò che segue la #definedichiarazione.

#define NSLog(...);

Il (...)sta per "qualsiasi cosa" tra le parentesi (). Attenzione anche ;alla fine. Questo non è strettamente necessario poiché il compilatore lo ottimizzerà, ma mi piace metterlo lì, poiché è più "corretto". Dopo il nostro #definenon c'è "niente", quindi il preprocessore lo sostituirà con "niente", e quindi butterà via la riga completa, a partire da NSLog...fino a quando includerà il file ;.

le dichiarazioni di definizione possono essere condizionate usando #ifdef(se definito) o #ifndef(se non definito)

qui scriviamo #ifndef DEBUG, che significa 'se il simbolo DEBUG non è definito'. Il #ifdefo #ifndefdeve essere "chiuso" con#endif

Xcode 5 definisce di default il simbolo "DEBUG" quando la modalità di de build è "DEBUG". In "release" questo non è definito. puoi verificarlo nelle impostazioni del tuo progetto, scheda "Impostazioni build" -> scorri verso il basso fino alla sezione "Apple LLVM 5.0 - Preprocessing" -> macro del preprocessore. Vedrai che il simbolo "DEBUG" non è definito per le build di rilascio!

infine, il file .pch viene creato automaticamente da Xcode e automaticamente incluso in ogni file sorgente durante il tempo di compilazione. Quindi è come se avessi messo tutto #definein ciascuno dei tuoi file sorgente.

Quasi tutte le risposte precedenti suggeriscono una soluzione ma non spiegano il problema. Ho fatto una ricerca su google e ho trovato il motivo. Ecco la mia risposta:

Sì, se commentate NSLog nella versione di rilascio, le prestazioni miglioreranno. Perché NSLog è piuttosto lento. Perché? NSLog farà due cose: 1) scrive i messaggi di log in Apple System Logging (ASL), 2) se l'app viene eseguita in xcode, scrive anche su stderr.

Il problema principale risiede nel primo. Per ottenere thread safe, ogni volta che viene chiamato NSLog, apre una connessione alla struttura ASL , invia un messaggio e chiude la connessione. L'operazione di connessione è molto costosa. Un altro motivo è che NSLog impiega del tempo per ottenere il timestamp da registrare.

Riferimento da qui .

Il mio preferito è usare una macro variadica.

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

Oltre a tutte le persone che hanno saggiamente commentato che non chiamare NSLog()affatto in produzione è leggermente più veloce, aggiungo che:

Tutte queste NSLog()stringhe di output sono visibili a chiunque scarichi la tua app dallo store e la esegua con il dispositivo collegato a un Mac che esegue Xcode (tramite la finestra Organizer).

A seconda delle informazioni che registri (e soprattutto se la tua app contatta un server, esegue l'autenticazione, ecc.), Questo può essere un serio problema di sicurezza .

All'interno dell'impostazione predefinita corrente del progetto in Xcode, la NS_BLOCK_ASSERTIONSmacro sarà impostata su 1 nella versione di rilascio e DEBUG=1nella versione di debug.

Quindi, preferisco il seguente metodo.

// NS_BLOCK_ASSERTIONS is defined by default, as shown in the screenshot above.
// Or, you can define yourself Flags in the `Other C Flags` -> `Release`.
#ifndef NS_BLOCK_ASSERTIONS
    #define _DEBUG
#endif

#ifdef _DEBUG
// for debug mode 
#define DLog(fmt,...) NSLog(@"%s " fmt, __FUNCTION, ##__VA_ARGS__) 
... /// something extra
#else
// for release mode
#define DLog(fmt,...) /* throw it away */
... /// something extra
#endif

Sì, dovresti disabilitarlo. Soprattutto se stai cercando di massimizzare la velocità del tuo codice. NSLogging di cose a destra ea sinistra inquina il registro di sistema che altri sviluppatori potrebbero cercare di scavare e può avere un grande impatto sul codice critico per la velocità (all'interno di cicli, ecc.) Ho accidentalmente lasciato alcuni messaggi di registro in una funzione ricorsiva una volta e ha rilasciato un aggiornamento con un "aumento della velocità del 30%!" qualche settimana dopo... ;-)

Tutte buone risposte, tuttavia ecco un altro piccolo trucco che puoi considerare di utilizzare, principalmente nelle fasi di sviluppo / test della tua app.

Potrebbe anche essere utile anche per il codice di rilascio dell'app, se desideri disattivare solo il TUO codice di debug e non i messaggi che potrebbero indicare problemi al di fuori del controllo diretto del tuo codice.

Il trucco:

Puoi disattivare NSLog per file .m semplicemente includendo la seguente riga nella parte superiore del file .m :

#define NSLog(...)

( NOTA: NON inserire questo file .h, solo il file .m! )

Questo fa sì che il compilatore valuti NSLog()espandendo invece la macro del preprocessore. La macro non fa altro che eliminare gli argomenti.

se vuoi riaccenderlo puoi sempre usare

#undef NSLog

Ad esempio, potresti semplicemente impedire le chiamate a NSLog attorno a un particolare gruppo di metodi facendo qualcosa di simile

#define NSLog(...)
-(void) myProblematicMethodThatSometimesNeedsDebugging {
    ...
}
#undef NSLog

NSLog è lento e non deve essere utilizzato per le build di rilascio. Una semplice macro come quella qui sotto la disabiliterà insieme a qualsiasi asserzione che potresti avere che dovrebbe essere disabilitata. Nel caso meno comune in cui desideri NSLog in una build di rilascio, chiamalo direttamente. Non dimenticare di aggiungere "-DNDEBUG" alle impostazioni di compilazione degli "altri flag c".

#ifdef NDEBUG
#define MYLog(f, ...) 
#else
#define MYLog(f, ...) NSLog(f, ## __VA_ARGS__)
#endif

nel file pch annotalo prima di #endif

#define NSLog() //

che dire di questo?

#ifndef DEBUG_MODE
        fclose(stderr);     // the simplest way to disable output from NSLog
#endif    

var showDebugLogs = false;

    func DLog(format: String, args: CVarArgType...) {
        if showDebugLogs{
        println(String(format: format, arguments: args))
        }
    }

Questo accetterà anche gli argomenti aggiuntivi .. Solo il valore del parametro showDebugLogs su true o false, secondo le tue necessità