Si consiglia di fare qualsiasi NSLog ging in un'app di spedizione? So che non dovrei farlo nei loop pesantemente usati. O non registrare troppo verbalmente. Ma non sono sicuro che sia una buona pratica farlo.Devo rimuovere NSLogs durante il rilascio della mia app
Rimuovere tutti gli NSLog s prima di un rilascio non sembra una buona pratica.
Penso che sia una buona pratica per non spam il registro del dispositivo dell'utente.
Per questo, ho una macro, DebugLog, che è attivo solo per il debug build:
#ifdef DEBUG
#define DebugLog(fmt, ...) NSLog(fmt, __VA_ARGS__)
#else
#define DebugLog(fmt, ...)
#endif
Per tutti i messaggi di log che sono interessanti per me per lo sviluppo, io uso DebugLog. Per tutti i messaggi di errore che devono essere registrati, utilizzo incondizionatamente NSLog. In questo modo le build di distribuzione non ingombrano il log della console dell'utente. Vengono registrati solo i messaggi importanti.
Questa è una di quelle domande sulla filosofia di codifica, ma nelle app di produzione utilizzo asl e la configuro per impostazione predefinita, ma lascia l'opzione (tramite una voce in Info.plist) per abilitare vari livelli di registrazione. Tendo ad essere d'accordo con te sul fatto che troppi NSLog s in un'app per le spedizioni appaiano cattivi.
Ancora NSLog should't essere un modo per guasti di un'applicazione in prodotti ionico. Esistono diversi strumenti per segnalare errori e arresti anomali come NewRelic e alcuni altri che sono addirittura gratuiti. – user2387149
La registrazione è sempre importante quando è presente un particolare team di supporto per supportare l'applicazione live, in tal caso è possibile controllare cosa succede e possono risolvere il problema se alcune cose non sono correlate al codice e se si tratta di un codice principale problema quindi possono passare alla squadra Dev.
Ma se l'applicazione è qualcosa come Gioco, il registro non ha importanza. È possibile rimuovere quelli prima di rilasciare l'app.
Dipende. Se non si utilizza una funzione di segnalazione degli arresti anomali nella propria applicazione, è generalmente consigliabile mantenere alcune istruzioni NSLog che registrano errori critici, in modo che un utente esperto possa segnalarle e aiutarvi a risolvere i problemi con l'app dopo pubblicazione. Non è sicuramente una buona idea avere troppe esoteriche chiamate di debug NSLog nella tua versione.
Se volete che il vostro NSLog a lavorare solo quando il debug e non si vuole fare qualsiasi modifiche al codice l'approccio migliore è quello di fare questo sul vostro file PCH:
#ifndef DEBUG
#define NSLog(x...)
#endif
SPIEGAZIONE E RISOLUZIONE DEI PROBLEMI:
questo significa che se DEBUG non è definito sarà "override" tutte NSLogs a non fare nulla, questa stringa sostituire avviene prima di compilare in modo che nessun NSLog in tutto il codice escape, NSLog non verrà lasciato in produzione per errore, questo elimina l'errore umano di dimenticare di rimuovere NSLogs nelle app di produzione.
DEBUG viene normalmente definito in modalità debug per impostazione predefinita in tutti i progetti Xcode.si può scoprire se si è definito a:
Build Settings ->
Apple LLV #.# - Preprocessing ->
Preprocessor Macros -> Debug
se non è lì aggiungere
DEBUG=1
anche se non si dispone di un file PCH o non è stata cablata fino ecco quello che devi farlo (perché è stato automaticamente aggiunto in Xcode 5, ma non è più viene aggiunto in Xcode e 6 per impostazione predefinita sui nuovi modelli di progetto)
Why isn't ProjectName-Prefix.pch created automatically in Xcode 6?
Questo è perfetto quando si lavora con altri sviluppatori perché normalmente tutti usano NSLog e se si desidera definire un'altra macro come "DebugLog()" gli sviluppatori possono dimenticare di usarlo e quindi spedire un'app con la stampa del registro. Questo elimina l'errore umano. – user2387149
Esattamente. Inoltre, il log di sistema sui dispositivi iOS è ridicolmente di breve durata, quindi nella vita reale è solo inutile. 'NSLog()' in iOS è solo uno strumento debug _local_. – Costique