Верно ли, что не следует использовать NSLog () в производственном коде?

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

#define DEBUG_MODE

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

Мне было проще поместить весь этот оператор в заголовок префикса, а не в отдельный файл. При желании вы могли бы построить более сложную систему ведения журналов, заставив DebugLog взаимодействовать с обычными объектами Objective-C. Например, у вас может быть класс ведения журнала, который записывает в свой собственный файл журнала (или базу данных) и включает аргумент «приоритет», который вы можете установить во время выполнения, поэтому сообщения отладки не отображаются в вашей версии выпуска, а сообщения об ошибках ( если бы вы сделали это, вы могли бы сделать DebugLog (), WarningLog () и т. д.).

Да, и имейте в виду, что #define DEBUG_MODE можно повторно использовать в разных местах вашего приложения. Например, в моем приложении я использую его, чтобы отключить проверку лицензионных ключей и разрешить запуск приложения только до определенной даты. Это позволяет мне распространять ограниченную по времени полнофункциональную бета-версию с минимальными усилиями с моей стороны.

Поместите эти 3 строки в конец файла -prefix.pch:

#ifndef DEBUG
  #define NSLog(...) /* suppress NSLog when in release mode */
#endif

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

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

Приложения, которые засоряют системный журнал, раздражают и производят впечатление непрофессиональных.

Я не могу комментировать Ответ Марка Шарбонно, поэтому я отправлю его в качестве ответа.

Помимо добавления макроса в предварительно скомпилированный заголовок, вы можете использовать конфигурации целевой сборки для управления определением (или отсутствием определения) DEBUG_MODE.

Если вы выберете активную конфигурацию «Отладка», будет определено DEBUG_MODE, а макрос развернется до полного NSLog определения.

При выборе активной конфигурации «Выпуск» не будет определяться DEBUG_MODE, и ваша NSLog привязка не будет включена в сборку выпуска.

Шаги:

• Цель> Получить информацию
• Вкладка "Сборка"
• Найдите "Макросы препроцессора" (или GCC_PREPROCESSOR_DEFINITIONS).
• Выберите Конфигурация: Отладка.
• Изменить определение на этом уровне
• Добавить DEBUG_MODE=1
• Выберите конфигурацию: Выпуск.
• Подтвердите, что DEBUG_MODE не установлен в GCC_PREPROCESSOR_DEFINITIONS

если вы опустите символ '=' в определении, вы получите ошибку от препроцессора

Также вставьте этот комментарий (показанный ниже) над определением макроса, чтобы напомнить вам, откуда взялось определение DEBUG_MACRO;)

// Target > Get Info > Build > GCC_PREPROCESSOR_DEFINITIONS
// Configuration = Release: <empty>
//               = Debug:   DEBUG_MODE=1

ИЗМЕНИТЬ: метод, опубликованный Марком Шарбонно и доведенный до моего сведения sho, намного лучше, чем этот.

Я удалил часть своего ответа, в которой предлагалось использовать пустую функцию для отключения ведения журнала при отключенном режиме отладки. Часть, которая касается установки макроса автоматического препроцессора, по-прежнему актуальна, поэтому остается. Я также отредактировал имя макроса препроцессора, чтобы оно лучше соответствовало ответу Марка Шарбонно.

Чтобы добиться автоматического (и ожидаемого) поведения в Xcode:

В настройках проекта перейдите на вкладку «Сборка» и выберите конфигурацию «Отладка». Найдите раздел «Макросы препроцессора» и добавьте макрос с именем DEBUG_MODE.

...

ИЗМЕНИТЬ: См. Ответ Марка Шарбонно о правильном способе включения и отключения ведения журнала с помощью макроса DEBUG_MODE.

Я согласен с Мэтью. В производственном коде нет ничего плохого в NSLog. На самом деле это может быть полезно пользователю. Тем не менее, если единственная причина, по которой вы используете NSLog, - это помощь в отладке, то да, это следует удалить перед выпуском.

Кроме того, поскольку вы отметили это как вопрос об iPhone, NSLog требует ресурсов, чего у iPhone очень мало. Если вы ведете NSLogging что-нибудь на iPhone, это отнимает процессорное время у вашего приложения. Использовать его с умом.

Простая правда в том, что NSLog просто медленный.

Но почему? Чтобы ответить на этот вопрос, давайте выясним, что делает NSLog, а затем как он это делает.

Что именно делает NSLog?

NSLog делает 2 вещи:

Он записывает сообщения журнала в средство ведения системного журнала Apple (asl). Это позволяет отображать сообщения журнала в Console.app. Он также проверяет, идет ли поток stderr приложения на терминал (например, когда приложение запускается через Xcode). Если это так, он записывает сообщение журнала в stderr (чтобы оно отображалось в консоли Xcode).

Запись в STDERR не кажется сложной. Это можно сделать с помощью fprintf и ссылки на дескриптор файла stderr. А как насчет asl?

Лучшая документация, которую я нашел об ASL, - это сообщение из 10 частей в блоге Питера Хози: ссылка

Не вдаваясь в подробности, главное (что касается производительности) таково:

Чтобы отправить сообщение журнала в средство ASL, вы в основном открываете клиентское соединение с демоном ASL и отправляете сообщение. НО - каждый поток должен использовать отдельное клиентское соединение. Итак, чтобы быть потокобезопасным, каждый раз, когда вызывается NSLog, он открывает новое клиентское соединение asl, отправляет сообщение, а затем закрывает соединение.

Ресурсы можно найти здесь и здесь.

Как отмечено в других ответах, вы можете использовать #define, чтобы изменить, используется ли NSLog во время компиляции.

Однако более гибким способом является использование библиотеки журналов, например Cocoa Lumberjack, который позволяет вам также изменить, будет ли что-то регистрироваться во время выполнения.

В вашем коде замените NSLog на DDLogVerbose или DDLogError и т. Д., Добавьте #import для определений макросов и т. Д. И настройте логгеры, часто в методе applicationDidFinishLaunching.

Чтобы иметь тот же эффект, что и NSLog, код конфигурации

[DDLog addLogger:[DDASLLogger sharedInstance]];
[DDLog addLogger:[DDTTYLogger sharedInstance]];

С точки зрения безопасности это зависит от того, что регистрируется. Если NSLog (или другие регистраторы) записывают конфиденциальную информацию, вам следует удалить регистратор в производственном коде.

С точки зрения аудита, аудитор не хочет проверять каждое использование NSLog, чтобы убедиться, что конфиденциальная информация не регистрируется. Он просто скажет вам удалить регистратор.

Я работаю с обеими группами. Мы проверяем код, пишем руководства по кодированию и т. Д. Наше руководство требует, чтобы в производственном коде было отключено ведение журнала. Так что внутренние команды знают, что не стоит пробовать это;)

Мы также отклоним внешнее приложение, которое входит в производственную среду, потому что мы не хотим принимать на себя риск, связанный с случайной утечкой конфиденциальной информации. Нам все равно, что нам говорит разработчик. Просто не стоит тратить время на расследование.

И помните, мы определяем «чувствительный», а не разработчик;)

Я также воспринимаю приложение, которое выполняет много журналов, как приложение, готовое к взрыву. Есть причина, по которой выполняется / требуется так много журналов, и обычно это не стабильность. Это прямо там со «сторожевыми» потоками, которые перезапускают зависшие службы.

Если вы никогда не проходили обзор архитектуры безопасности (SecArch), мы рассмотрим такие вещи.

Вы не должны излишне подробно рассказывать о printf или NSLog в коде выпуска. Попробуйте выполнить printf или NSLog только в том случае, если с приложением что-то случилось, т. Е. неисправимая ошибка.

Имейте в виду, что NSLogs может замедлить работу пользовательского интерфейса / основного потока. Лучше всего удалить их из сборок выпуска, если в этом нет крайней необходимости.

Я настоятельно рекомендую использовать TestFlight для ведения журнала (бесплатно). Их метод переопределит NSLog (с помощью макроса) и позволит вам включить / выключить ведение журнала на их сервер, системный журнал Apple и журнал STDERR для всех ваших существующих вызовов NSLog. Приятно то, что вы по-прежнему можете просматривать сообщения журнала для приложений, развернутых для тестировщиков, и приложений, развернутых в App Store, без появления журналов в системном журнале пользователя. Лучшее из обоих миров.