Preciso desabilitar o NSLog antes de lançar o aplicativo?

Ao lançar um aplicativo para iPhone, se eu desativar NSLog();, ele terá um desempenho melhor?

Uma maneira de fazer isso é acessar as configurações de Build e, na configuração Debug, adicionar um valor ao valor "Macros de pré-processador" como:

DEBUG_MODE=1

Certifique-se de fazer isso apenas para a configuração de depuração e não para versões Beta ou de lançamento. Então, em um arquivo de cabeçalho comum, você pode fazer algo como:

#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

Agora, em vez de NSLog usar em DLogtodos os lugares. Ao testar e depurar, você receberá mensagens de depuração. Quando você está pronto para lançar um beta ou lançamento final, todas essas DLoglinhas ficam vazias automaticamente e nada é emitido. Desta forma, não há configuração manual de variáveis ​​ou comentários de NSLogsobrigatórios. Escolher seu alvo de construção cuida disso.

Atualização para Xcode 5 e iOS 7

nota: para uma solução Xcode 7 / Swift 2.1 para remover as instruções print () em uma versão de lançamento, encontre minha resposta aqui .

Sim, você deve remover qualquer instrução NSLog em seu código de lançamento, pois isso apenas retarda o seu código e não tem qualquer utilidade em uma versão de lançamento. Felizmente, no Xcode 5 (iOS 7), é incrivelmente simples remover todas as suas instruções NSLog 'automaticamente' em compilações de lançamento. Então, por que não fazer?

Primeiro as 3 etapas a serem seguidas, depois alguma explicação

1) em seu projeto Xcode, localize o arquivo 'yourProjectName-prefix.pch' (normalmente você o encontrará no grupo 'arquivos de suporte', onde seu arquivo main.m está localizado

2) adicione essas 3 linhas no final do arquivo '.pch':

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

3) teste a diferença entre a sua versão de 'depuração' e 'lançamento'. Uma maneira de fazer isso é através do 'esquema de edição' -> 'executar nome do aplicativo' -> na guia 'informações', selecione usando a caixa suspensa entre depuração e lançamento. Na versão de lançamento, você não verá nenhuma saída NSLog no console de depuração!

Como tudo isso funciona?

em primeiro lugar, deve-se saber que um pré-processador é relativamente 'burro' e apenas atua como um 'substituto de texto' antes de o compilador ser chamado. Ele substitui qualquer coisa que você '#define' pelo que segue a #definedeclaração.

#define NSLog(...);

O (...)significa 'qualquer coisa' entre os colchetes (). Lembre-se também ;do final. Isso não é estritamente necessário, pois o compilador irá otimizar isso, mas eu gosto de colocá-lo lá, pois é mais 'correto'. Depois de nosso, #definenão há 'nada', então o pré-processador irá substituí-lo por 'nada', e então jogará fora a linha completa, começando em NSLog...até e incluindo o ;.

as declarações de definição podem ser tornadas condicionais usando #ifdef(se definido) ou #ifndef(se não definido)

aqui escrevemos #ifndef DEBUG, o que significa 'se o símbolo DEBUG não está definido'. O #ifdefou #ifndefprecisa ser 'fechado' com#endif

O Xcode 5 define por padrão o símbolo 'DEBUG' para nós quando o modo de construção é 'DEBUG'. Em 'release' isso não está definido. você pode verificar isso nas configurações do projeto, guia 'Configurações de compilação' -> role para baixo até a seção 'Apple LLVM 5.0 - Pré-processamento' -> macros do pré-processador. Você verá que o símbolo 'DEBUG' não está definido para versões de lançamento!

finalmente, o arquivo .pch é criado pelo Xcode automaticamente e automaticamente incluído em cada arquivo de origem durante o tempo de compilação. Portanto, é como se você tivesse colocado #definetudo em cada um de seus arquivos de origem.

Quase todas as respostas acima sugerem uma solução, mas não explicam o problema. Fiz uma pesquisa no google e descobri o motivo. Aqui está minha resposta:

Sim, se você comentar o NSLog em sua versão de lançamento, o desempenho será melhor. Porque NSLog é muito lento. Por quê? NSLog fará duas coisas 1) escrever mensagens de log no Apple System Logging (ASL), 2) se o aplicativo for executado em xcode, ele gravará em stderr também.

O principal problema está no primeiro. Para obter um thread seguro, cada vez que o NSLog é chamado, ele abre uma conexão com o recurso ASL , envia uma mensagem e fecha a conexão. A operação de conexão é muito cara. Outro motivo é que o NSLog gasta algum tempo para obter o registro de data e hora.

Referência aqui .

Meu favorito pessoal é usar uma macro variável.

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

Além de todas as pessoas que sabiamente comentaram que não ligar NSLog()na produção é um pouco mais rápido, vou acrescentar que:

Todas essas NSLog()strings de saída são visíveis para qualquer pessoa que baixe seu aplicativo da loja e o execute com o dispositivo conectado a um mac executando o Xcode (por meio da janela do Organizer).

Dependendo das informações que você registra (e especialmente se seu aplicativo contata um servidor, faz autenticação, etc.), isso pode ser um sério problema de segurança .

Dentro da configuração padrão atual do projeto no Xcode, a NS_BLOCK_ASSERTIONSmacro será definida como 1 na versão de lançamento e DEBUG=1na versão de depuração.

Portanto, prefiro o método a seguir.

// 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

Sim, você deve desativá-lo. Especialmente se você estiver tentando maximizar a velocidade do seu código. O NSLogging da esquerda e da direita polui o log do sistema que outros desenvolvedores podem estar tentando vasculhar e pode ter um grande impacto no código crítico de velocidade (dentro de loops, etc.) Eu deixei acidentalmente algumas mensagens de log em uma função recursiva uma vez e conseguiu lançar uma atualização com um "aumento de velocidade de 30%!" algumas semanas depois ... ;-)

Todas boas respostas, mas aqui está outro pequeno truque que você pode considerar usar, principalmente nas fases de desenvolvimento / teste do seu aplicativo.

Também pode ser útil para o código de lançamento do aplicativo, se você quiser apenas desligar SEU código de depuração, e não mensagens que podem indicar problemas fora do controle direto do seu código.

O truque:

Você pode desativar o NSLog por arquivo .m simplesmente incluindo a linha a seguir na parte superior do arquivo .m :

#define NSLog(...)

( NOTA: NÃO coloque este arquivo .h, apenas o arquivo .m! )

Isso apenas faz com que o compilador avalie NSLog()expandindo a macro do pré-processador. A macro não faz nada além de remover os argumentos.

se quiser ligá-lo novamente, você sempre pode usar

#undef NSLog

Você poderia, por exemplo, apenas evitar chamadas para NSLog em torno de um determinado grupo de métodos fazendo algo como

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

NSLog é lento e não deve ser usado para compilações de lançamento. Uma macro simples como a abaixo irá desativá-la junto com quaisquer declarações que você possa ter que também devem ser desativadas. No caso menos comum em que você deseja NSLog em uma versão de lançamento, basta chamá-lo diretamente. Não se esqueça de adicionar "-DNDEBUG" às configurações de compilação de "outras sinalizações c".

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

no arquivo pch anote isso antes de #endif

#define NSLog() //

que tal isso?

#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))
        }
    }

Isso aceitará os argumentos adicionais também .. Apenas o valor do parâmetro showDebugLogs para true ou false, conforme sua necessidade