Вместо использования флагов теперь мы можем использовать программно вставленные указатели, которые фиксируются в «Точках интереса» инструмента.
В iOS 13 и macOS 10.15 мы можем использовать os_signpost. Это показано в видео WWDC 2019 Начало работы с инструментами.
Например, в Свифте:
Импортируйте единую структуру ведения журналов:
import os.log
Создайте OSLog для точек интереса:
private let pointsOfInterest = OSLog(subsystem: Bundle.main.bundleIdentifier!, category: .pointsOfInterest)
Если вы хотите начать диапазон точек интереса, вы можете .begin указать точку интереса:
let id = OSSignpostID(log: pointsOfInterest)
os_signpost(.begin, log: pointsOfInterest, name: "Download", signpostID: id, "Download %d", index)
Если вы хотите закончить диапазон точек интереса, вы можете .end сделать это:
os_signpost(.end, log: pointsOfInterest, name: "Download", signpostID: id, "Download %d", index)
Если вас интересует не диапазон времени, а отдельный указатель, вы можете просто опубликовать .event:
os_signpost(.event, log: pointsOfInterest, name: "Done", "All done")
Или в Objective-C:
Импортируйте унифицированную структуру указателей ведения журналов:
@import os.signpost;
Создайте OSLog для точек интереса:
os_log_t log = os_log_create("ViewController", OS_LOG_CATEGORY_POINTS_OF_INTEREST);
Если вы хотите начать диапазон точек интереса, вы можете .begin точку интереса:
os_signpost_id_t identifier = os_signpost_id_generate(log);
os_signpost_interval_begin(log, identifier, "Download", "Started %d", index);
Если вы хотите закончить диапазон точек интереса, вы можете .end сделать это:
os_signpost_interval_end(log, identifier, "Download", "Finished %d", index);
Если вас интересует не диапазон времени, а отдельный указатель, вы можете просто опубликовать .event:
os_signpost_event_emit(log, OS_SIGNPOST_ID_EXCLUSIVE, "Done");
В любом случае, инструмент «Точки интереса» теперь может графически представлять ряд операций загрузки и разбора (каждая очередь ограничена двумя одновременными операциями на очередь) в инструментах:
Обратите внимание, что значения name (в одном наборе я использовал имя Download, а в другом — Parse) хорошо разделены на разные плавательные дорожки в инструменте Points of Interest. И поскольку я использовал необязательные строки формата, я действительно могу видеть сообщения, в которых я могу четко соотнести каждую операцию загрузки и синтаксического анализа с конкретной задачей в моем приложении.
Выше я использовал необязательные параметры OSSignpostID, потому что у меня было несколько перекрывающихся диапазонов, и я хотел избежать путаницы при связывании конкретного .end с соответствующим .begin. Если вы либо не используете диапазоны точек интереса, либо у вас нет перекрывающихся диапазонов, вам технически не нужно использовать этот необязательный параметр, если невозможна двусмысленность. (Даже если вы используете эти идентификаторы указателей, убедитесь, что name связанных указателей .begin и .end также совпадают, иначе инструменты не будут идентифицировать их как начало и конец одного и того же диапазона точек интереса, даже с одним и тем же указателем. я бы.)
В любом случае, теперь, когда у вас есть инструмент «Точки интереса», заполненный информацией, вы можете дважды щелкнуть по диапазону, чтобы выбрать его, или трижды щелкнуть по нему, чтобы также установить диапазон проверки.
В iOS 10 и macOS 10.12 мы использовали kdebug_signpost. Это показано в видео WWDC 2016 Подробная трассировка системы.
Для тех процессов, которые занимают дискретное количество времени, мы можем использовать kdebug_signpost_start и kdebug_signpost_end. Например:
kdebug_signpost_start(SignPostCode.download.rawValue, UInt(index), 0, 0, SignPostColor.orange.rawValue)
performDownload {
kdebug_signpost_end(SignPostCode.download.rawValue, UInt(index), 0, 0, SignPostColor.orange.rawValue)
}
Чтобы отметить один момент времени, мы можем просто использовать kdebug_signpost:
kdebug_signpost(SignPostCode.done.rawValue, 0, 0, 0, SignPostColor.red.rawValue)
Первый параметр — это просто какой-то уникальный числовой код, соответствующий «кодовому имени указателя», который мы будем использовать в инструментах. Вы можете использовать любые значения (от 0 до 16383), но я использую то, что обозначает тип задачи:
enum SignPostCode: UInt32 { // some custom constants that I'll reference in Instruments
case download = 0
case parse = 1
case done = 2
}
Остальные параметры могут быть любыми значениями UInt, которые вы хотите, но в моем примере я буду использовать второй параметр в качестве уникального идентификатора для сопоставления повторяющихся вызовов start и end, а последний параметр я буду использовать для цветового кодирования своих регионов. в Инструменты:
enum SignPostColor: UInt { // standard color scheme for signposts in Instruments
case blue = 0
case green = 1
case purple = 2
case orange = 3
case red = 4
}
Сделав это, вы можете затем профилировать приложение в «Инструментах», нажать кнопку «+» в правой части панели инструментов «Инструменты» и добавить «Точки интереса». Настроив «Имена кодов указателей» так, чтобы они соответствовали числовым значениям, которые я передал в качестве первого параметра своим указателям, Instruments фактически переведет эти коды для меня. После того, как я профилирую приложение, мои интересы четко выделены:
На этом снимке я профилировал семь операций загрузки (оранжевым цветом) и семь операций синтаксического анализа (зеленым цветом), ограниченных двумя за раз соответственно. И когда они были готовы, я разместил единственный указатель «Готово» (красная булавка). Но детали этого демонстрационного приложения не имеют решающего значения, а скорее просто иллюстрируют, как отдельные указатели и указатели начала/конца отображаются в «Точках интереса» от Instruments.
Основная проблема в том, что теперь у меня есть четкое соответствие между событиями в моем коде и тем, что я вижу в Инструментах. И я могу управление-щелкнуть запись в списке диапазонов указателей и сказать инструментам "Установить фильтр времени", если я хочу, чтобы, когда я вернусь к другим моим инструментам (распределениям или времени профилировщик или что-то еще), диапазон проверки фильтруется до соответствующих точек интереса в моем приложении.
Обратите внимание, что это Swift. В Objective-C kdebug_signpost API похож, но вы должны включить:
#import <sys/kdebug_signpost.h>
Очевидно, то, как вы определяете свои перечисления для своих кодов, также изменится.
Обратите внимание, что этот kdebug_signpost API был представлен в iOS 10/macOS 10.12. Заголовки сообщают нам, что более ранние версии ОС могли использовать syscall:
В предыдущих версиях операционной системы приложения могли использовать:
syscall(SYS_kdebug_trace, APPSDBG_CODE(DBG_MACH_CHUD, <your event code>) | DBG_FUNC_<type>, arg1, arg2, arg3, arg4);
для записи событий, которые будут отображаться с помощью инструментов. syscall(2) теперь устарел, и этот интерфейс заменяет вышеуказанный вызов.
Примечание. Если вам придется использовать syscall в более ранней версии ОС, вам придется импортировать <sys/kdebug.h>:
#import <sys/kdebug.h>
Кроме того, я не смог найти объявление SYS_kdebug_trace ни в одном из заголовков, но наткнулся на ссылку в Интернете, в которой говорилось, что это значение равно 180, что я эмпирически проверил:
#ifndef SYS_kdebug_trace
#define SYS_kdebug_trace 180
#endif
person
Rob
schedule
09.09.2016
