Нужно ли мне отключать NSLog перед выпуском приложения?

При выпуске приложения для iPhone, если я отключу NSLog();его, оно будет работать лучше?

Один из способов сделать это - зайти в настройки сборки и в разделе «Отладка» добавить значение «Макросы препроцессора», например:

DEBUG_MODE=1

Убедитесь, что вы делаете это только для конфигурации отладки, а не для версий Beta или Release. Затем в общем файле заголовка вы можете сделать что-то вроде:

#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

Теперь вместо NSLog использования DLogвезде. При тестировании и отладке вы получите отладочные сообщения. Когда вы готовы выпустить бета-версию или финальную версию, все эти DLogстроки автоматически становятся пустыми и ничего не выводится. Таким образом, не NSLogsтребуется ручная установка переменных или их комментирование . Выбор цели сборки позаботится об этом.

Обновление для Xcode 5 и iOS 7

примечание: для решения Xcode 7 / Swift 2.1 для удаления операторов print () в сборке выпуска найдите мой ответ здесь .

Да, вам следует удалить любой оператор NSLog в коде выпуска, так как он просто замедляет ваш код и не используется в выпускной версии. К счастью, в Xcode 5 (iOS 7) удивительно просто удалить все ваши операторы NSLog «автоматически» в сборках выпуска. Так почему бы не сделать это.

Сначала три шага, которые нужно предпринять, затем объяснение

1) в вашем проекте Xcode найдите файл yourProjectName-prefix.pch (обычно вы найдете его в группе «вспомогательные файлы», где находится ваш файл main.m

2) добавьте эти 3 строки в конец файла .pch:

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

3) проверьте разницу между вашей «отладочной» и «выпускной» версией. Один из способов сделать это - «изменить схему» -> «запустить имя приложения» -> на вкладке «информация» выбрать в раскрывающемся списке между отладкой и выпуском. В выпускной версии вы не увидите вывода NSLog в консоли отладки!

Как это все работает?

Прежде всего, нужно знать, что препроцессор относительно «тупой» и просто действует как «заменитель текста» перед вызовом компилятора. Он заменяет все, что вы '#define', тем, что следует за #defineоператором.

#define NSLog(...);

(...)Означает «ничего» между скобками (). Помните также ;о конце. Это не является строго необходимым, поскольку компилятор оптимизирует это, но мне нравится помещать это там, поскольку это более «правильно». После нашего #defineидет «ничего», поэтому препроцессор заменит его на «ничего», и поэтому он просто выбросит всю строку, начиная с NSLog...до и включая; .

Операторы define могут быть условными с помощью #ifdef(если определено) или#ifndef (если не определено)

здесь мы пишем #ifndef DEBUG, что означает «если символ DEBUG не определен». #ifdefили#ifndef потребность быть «закрытым» с#endif

Xcode 5 по умолчанию определяет для нас символ «DEBUG», когда режим сборки - «DEBUG». В «выпуске» это не определено. вы можете проверить это в настройках вашего проекта, на вкладке «Параметры сборки» -> прокрутите вниз до раздела «Apple LLVM 5.0 - Предварительная обработка» -> макросы препроцессора. Вы увидите, что символ «DEBUG» не определен для сборок выпуска!

наконец, файл .pch создается Xcode автоматически и автоматически включается в каждый исходный файл во время компиляции. Это как если бы вы поместили все #defineэто в каждый из ваших исходных файлов.

Почти все приведенные выше ответы предлагают решение, но не объясняют проблему. Я поискал в гугле и нашел причину. Вот мой ответ:

Да, если вы закомментируете NSLog в своей релизной версии, производительность станет лучше. Потому что NSLog довольно медленный. Зачем? NSLog будет делать две вещи: 1) записывать сообщения журнала в системный журнал Apple (ASL), 2) если приложение работает в xcode, оно также записывает в stderr.

Основная проблема заключается в первом. Чтобы обеспечить потокобезопасность, каждый раз , когда вызывается NSLog, он открывает соединение с функцией ASL , отправляет сообщение и закрывает соединение. Операция подключения очень дорогая. Другая причина заключается в том, что NSLog тратит некоторое время на получение отметки времени для регистрации.

Ссылка отсюда .

Лично я предпочитаю использовать макрос с переменными числами.

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

В дополнение ко всем людям, которые мудро прокомментировали, что отсутствие звонков NSLog()в продакшн работает немного быстрее, я добавлю следующее:

Все эти NSLog()выходные строки видны всем, кто загружает ваше приложение из магазина и запускает его с устройством, подключенным к Mac, на котором запущен Xcode. (через окно Организатора).

В зависимости от того, какую информацию вы регистрируете (и особенно если ваше приложение связывается с сервером, выполняет аутентификацию и т. Д.), Это может быть серьезной проблемой безопасности .

Внутри текущей настройки проекта по умолчанию в Xcode NS_BLOCK_ASSERTIONSмакрос будет установлен в 1 в версии выпуска и DEBUG=1в версии отладки.

Итак, я предпочитаю следующий метод.

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

Да, вы должны отключить его. Особенно, если вы пытаетесь максимизировать скорость своего кода. NSLogging вещей слева и справа загрязняет системный журнал, который другие разработчики могут пытаться раскопать, и может иметь большое влияние на критичный по скорости код (внутренние циклы и т. Д.) Я случайно оставил некоторые сообщения журнала в рекурсивной функции один раз и должен выпустить обновление с «увеличением скорости на 30%!» несколько недель спустя ... ;-)

Все хорошие ответы, однако вот еще один небольшой трюк, который вы можете использовать, в основном, на этапах разработки / тестирования вашего приложения.

Это также может быть полезно для кода выпуска приложения, если вы хотите отключить только ВАШ код отладки, а не сообщения, которые могут указывать на проблемы, находящиеся вне прямого контроля вашего кода.

Хитрость:

Вы можете отключить NSLog для файла .m, просто включив следующую строку в верхней части файла .m :

#define NSLog(...)

( ПРИМЕЧАНИЕ: НЕ помещайте это файл .h, только файл .m! )

Это просто заставляет компилятор вычислять NSLog(), вместо этого расширяя ваш макрос препроцессора. Макрос ничего не делает, только удаляет аргументы.

если вы хотите снова включить его, вы всегда можете использовать

#undef NSLog

Вы можете, например, просто предотвратить вызовы NSLog вокруг определенной группы методов, выполнив что-то вроде

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

NSLog работает медленно и не должен использоваться для сборок выпуска. Простой макрос, подобный приведенному ниже, отключит его вместе со всеми возможными утверждениями, которые также следует отключить. В менее распространенном случае, когда вам нужен NSLog в сборке выпуска, просто вызовите его напрямую. Не забудьте добавить «-DNDEBUG» в настройки сборки «другие флаги c».

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

в файле pch запишите это перед #endif

#define NSLog() //

как насчет этого?

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

Это также примет дополнительные аргументы. Просто установите для параметра showDebugLogs значение true или false, в зависимости от ваших потребностей.