¿Alternativa a DTSendSignalFlag para identificar eventos clave en los instrumentos?

Solía ​​haber una buena herramienta, DTSendSignalFlag , parte de la estructura DTPerformanceSession , mediante la cual se podían insertar indicadores de manera programática en los instrumentos (ver comparación de rastreo de Xcode Instruments ). Esta característica dejó de funcionar en iOS 7.

¿Alguien ha logrado que DTSendSignalFlag funcione en iOS 7? Los indicadores de señal son (¿fueron?) Una forma útil de publicar indicadores en Instrumentos mediante código (realmente útil al diagnosticar aplicaciones complicadas en Instruments), pero no veo mis banderas creadas mediante progtwigción en Instruments 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 utilizar señales insertadas mediante progtwigción 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 video Sistema de seguimiento de WWDC 2016 en profundidad .

    Para aquellos procesos que toman una cantidad de tiempo 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 en el tiempo, simplemente podemos usar kdebug_signpost :

     kdebug_signpost(SignPostCode.done.rawValue, 0, 0, 0, UInt(SignPostColor.red.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 utilizo 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 parámetros pueden ser los valores UInt que desee, pero en mi ejemplo, UInt el segundo parámetro como identificador único para hacer coincidir las llamadas repetidas de start y end y usaré el último parámetro para codificar el color de 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 red = 4 } 

    Una vez hecho esto, puede perfilar la aplicación en Instrumentos, hacer clic en el botón “+” en el lado derecho de la barra de herramientas Instrumentos, y agregar “Puntos de interés”. Al configurar los “Nombres del código del poste indicador” para que coincidan con los valores numéricos que pasé como el primer parámetro de mis señales, en realidad, los instrumentos traducirán esos códigos para mí. Una vez que perfilé la aplicación y ahora tengo mis puntos de interés claramente resaltados para mí:

    enter image description here

    En esta instantánea, perfilé 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 solo cartel de “hecho” (pin rojo). Pero los detalles de esta aplicación de demostración no son críticos, sino que esto solo ilustra cómo los indicadores únicos y los indicadores de inicio / final se representan en los “Puntos de interés” de Instruments.

    El problema principal es que ahora tengo una correspondencia clara entre los eventos en mi código y lo que veo en los instrumentos. Y puedo controlar -hacer clic en una entrada en la lista de rangos de señalización y decirle a Instruments que “Establezca el filtro de tiempo”, si quiero, de modo que cuando regrese a mis otros instrumentos (asignaciones o perfilador de tiempo o lo que sea), la inspección el rango se filtra a los puntos de interés relevantes en mi aplicación.


    Tenga en cuenta que lo anterior es Swift. En Objective-C, la API kdebug_signpost es similar, pero debe incluir:

     #import  

    Obviamente, la forma en que defina sus enumeraciones para sus códigos también cambiará.

    Tenga en cuenta que esta API kdebug_signpost se introdujo en iOS 10 / macOS 10.12. Los encabezados nos dicen que 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, ) | DBG_FUNC_, arg1, arg2, arg3, arg4); 

    para registrar eventos que se mostrarían por 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 :

     #import  

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

     #ifndef SYS_kdebug_trace #define SYS_kdebug_trace 180 #endif