¿Alternativa a DTSendSignalFlag para identificar events key en instrumentos?

Solía ​​haber una buena herramienta, DTSendSignalFlag , que forma parte del marco de trabajo DTPerformanceSession , mediante el cual se podían insert marcadores en instrumentos (ver comparación de trazas de Xcode Instruments ). Esta function dejó de funcionar en iOS 7.

¿Alguien ha conseguido que DTSendSignalFlag funcione en iOS 7? Los indicadores de señal son (¿eran?) Una forma útil de progtwigr posts de banderas en Instrumentos a través del código (realmente útil al diagnosticar aplicaciones complicadas en Instrumentos), pero no veo mis banderas creadas por progtwigción en Instrumentos cuando ejecuto el simulador iOS 7 pero funciona cuando tengo Xcode 5 build para el simulador iOS 6).

En lugar de usar banderas, ahora podemos usar señales insertadas programáticamente que se capturan en los "Puntos de Interés" del Instrumento. En iOS 10 y MacOS 10.12, podemos usar kdebug_signpost . Esto se ilustra en el rastreo del sistema de video WWDC 2016 en profundidad .

Para aquellos processs que kdebug_signpost_start una cantidad de time discreta, podemos usar kdebug_signpost_start y kdebug_signpost_end . Por ejemplo:

 kdebug_signpost_start(SignPostCode.download.rawValue, UInt(index), 0, 0, SignPostColor.orange.rawValue) // perform download kdebug_signpost_end(SignPostCode.download.rawValue, UInt(index), 0, 0, SignPostColor.orange.rawValue) 

Para marcar un solo momento, podemos usar kdebug_signpost :

 kdebug_signpost(SignPostCode.done.rawValue, 0, 0, 0, UInt(SignPostColor.networking.rawValue)) 

El primer parámetro es solo un código numérico único que corresponde a un "nombre de código de poste indicador" que usaremos en Instrumentos. Puede usar los valores que desee (entre 0 y 16383), pero yo uso algo que designa el tipo de tarea:

 enum SignPostCode: UInt32 { // some custom constants that I'll reference in Instruments case download = 0 case parse = 1 case done = 2 } 

El rest de los parameters pueden ser cualesquiera valores de UInt que desee, pero en mi ejemplo, UInt el segundo parámetro como un identificador único para hacer coincidir las llamadas repetidas de start y end , y usaré el último parámetro para codificar en color mis regiones en instrumentos:

 enum SignPostColor: UInt { // standard color scheme for signposts in Instruments case blue = 0 case green = 1 case purple = 2 case orange = 3 case networking = 4 } 

Una vez hecho esto, puede perfilar la aplicación en Instrumentos, hacer clic en el button "+" en el lado derecho de la barra de herramientas de Instrumentos y agregar "Puntos de interés". Al configurar los "nombres de código de poste indicador" para que coincidan con los valores numéricos que pasé como el primer parámetro en mis paneles, Instruments realmente traducirá esos códigos para mí. Una vez que perfile la aplicación y ahora tengo mis puntos de interés claramente resaltados para mí:

introduzca la descripción de la imagen aquí

En esta instantánea, describí siete operaciones de descarga (en naranja) y siete operaciones de análisis (en verde), restringidas a dos a la vez, respectivamente. Y cuando terminaron, publiqué un único cartel "hecho" (pin rojo). Pero los detalles de esta aplicación de demostración no son críticos, sino que simplemente ilustra cómo se muestran los paneles de señal única y los indicadores de inicio / fin en los "Puntos de interés" de los instrumentos.

El problema principal es que ahora tengo una correspondencia clara entre los events en mi código y lo que veo en Instruments. Y puedo controlar -haz clic en una input de la list de ranges de señal y decirle a Instrumentos que establezcan "filter de time", si así lo deseo, para que cuando regrese a mis otros instrumentos (asignaciones o perfilador de time o lo que sea), la inspección El range se filtra a los puntos relevantes de interés en mi aplicación.


Nota: Estoy usando kdebug_signpost introducido en iOS 10 / macOS 10.12. Los encabezados nos dicen que las versiones anteriores del sistema operativo podrían usar syscall :

En versiones anteriores del sistema operativo, las aplicaciones podrían usar:

 syscall(SYS_kdebug_trace, APPSDBG_CODE(DBG_MACH_CHUD, <your event code>) | DBG_FUNC_<type>, arg1, arg2, arg3, arg4); 

para registrar events que mostrarían los instrumentos. syscall(2) ahora está en desuso y esta interfaz reemplaza la llamada anterior.

Nota: Si tiene que usar syscall en una versión anterior del sistema operativo, tendrá que importar <sys/kdebug.h> :

 #import <sys/kdebug.h> 

Además, no pude encontrar una statement de SYS_kdebug_trace en ninguno de los encabezados, pero tropecé con una reference en línea que decía que este valor es 180 , lo que empíricamente verifiqué:

 #ifndef SYS_kdebug_trace #define SYS_kdebug_trace 180 #endif