Чи потрібно відключити NSLog перед випуском програми?

Якщо випустити додаток для iPhone, якщо я відключу, чи NSLog();буде він краще працювати?

Один із способів зробити це - зайти в налаштування Build і під конфігурацією налагодження додати значення до значення "Препроцесорні макроси", наприклад:

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 "автоматично" у версії версій. То чому б цього не зробити.

Спочатку 3 кроки, які потрібно зробити, потім деякі пояснення

1) у вашому проекті Xcode знайдіть файл "yourProjectName-prefix.pch" (зазвичай ви знайдете це у групі "підтримуючі файли", де знаходиться ваш файл main.m

2) додайте ці 3 рядки в кінці файлу '.pch':

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

3) перевірити різницю між вашою версією "налагодження" та "випуском". Один із способів зробити це - "редагувати схему" -> "запустити ім'я програми" -> у вкладці "інформація" вибрати за допомогою випадаючого поля між налагодженням та випуском. У версії випуску ви не побачите жодного виходу NSLog на консолі налагодження!

Як це все працює?

Перш за все, потрібно знати, що препроцесор є відносно «німим», і він просто виконує функцію «заміни тексту» перед тим, як викликати компілятор. Він замінює все, що ви "#define", тим, що слідує за #defineтвердженням.

#define NSLog(...);

(...)Чи означає «нічого» між дужками (). Зверніть увагу і ;на кінець. Це не обов'язково, оскільки компілятор оптимізує це, але мені подобається розміщувати його там, оскільки це "правильніше". Після нашого #defineнемає "нічого", тому препроцесор замінить його на "нічого", і він просто викине повну лінію, починаючи з NSLog...і включаючи ;.

визначити заяви можна зробити умовними, використовуючи #ifdef(якщо визначено) або #ifndef(якщо не визначено)

тут ми пишемо #ifndef DEBUG, що означає "якщо символ DEBUG не визначений". #ifdefАбо #ifndefпотреба бути «закритим» з#endif

Xcode 5 визначає за замовчуванням символ "DEBUG" для нас, коли в режимі de build є "DEBUG". У "релізі" це не визначено. ви можете перевірити це в налаштуваннях свого проекту, на вкладці "Налаштування параметрів" -> прокрутіть униз до розділу "Apple LLVM 5.0 - Попередня обробка" -> макроси препроцесора. Ви побачите, що символ "DEBUG" не визначений для версій версій!

нарешті, .pch файл створюється Xcode автоматично та автоматично включається у кожен вихідний файл під час компіляції. Так що, ніби ви все це помістили #defineу кожен свій вихідний файл.

Майже всі вище відповіді пропонують рішення, але не пояснюють проблему. Я здійснив пошук в Google, і знайшов причину. Ось моя відповідь:

Так, якщо ви прокоментуєте NSLog у своїй версії випуску, продуктивність стане кращою. Тому що NSLog досить повільний. Чому? NSLog зробить дві речі: 1) записувати повідомлення в журнал Apple System Logging (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 per .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 до істинного чи помилкового, відповідно до вашої потреби