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

xcode-instruments dtsignalflag

Question

Solía ​​haber una buena herramienta, DTSendSignalFlag , parte del marco DTPerformanceSession , mediante la cual podría insertar indicadores en los instrumentos mediante programación (consulte la 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? Las marcas de señal son (¿eran?) Una forma útil de publicar marcas de manera programática en Instruments a través del código (realmente útil cuando se diagnostican aplicaciones complicadas en Instruments), pero no veo las banderas creadas de manera programática en Instruments cuando ejecuto el simulador de iOS 7 ( pero funciona cuando tengo Xcode 5 build para el simulador de iOS 6).

Answer 1

En lugar de usar banderas, ahora podemos utilizar carteles que se insertan mediante programación y 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 WWDC 2016 video System Trace in Depth .

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 momento en el tiempo, solo podemos usar kdebug_signpost :

kdebug_signpost(SignPostCode.done.rawValue, 0, 0, 0, SignPostColor.red.rawValue)

El primer parámetro es solo un código numérico único que corresponde a un "nombre de código de señalización" que usaremos en los instrumentos. Puedes usar los valores que quieras (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 resto de los parámetros pueden ser los valores UInt que desee, pero en mi ejemplo, UInt el segundo parámetro como un identificador único para hacer coincidir las llamadas de start y end repetidas y UInt el último parámetro para codificar por colores 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 hacer un perfil de la aplicación en Instrumentos, hacer clic en el botón "+" en el lado derecho de la barra de herramientas de Instrumentos y agregar "Puntos de interés". Al configurar los "Nombres de códigos de poste indicador" para que coincidan con los valores numéricos que pasé como primer parámetro a mis carteles, los instrumentos realmente traducirán esos códigos para mí. Una vez que hago un perfil de la aplicación, ahora tengo mis puntos de interés claramente resaltados para mí:

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 solo poste indicador de "hecho" (pin rojo). Pero los detalles de esta aplicación de demostración no son críticos, sino que solo ilustran cómo se representan las señales individuales y las señales de inicio / finalización 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 Instrumentos. Y puedo controlar - hacer clic en una entrada en la lista de rangos de poste indicador y decirle a Instruments que "Establezca el filtro de tiempo", si así lo deseo, para que cuando vuelva a mis otros instrumentos (asignaciones o perfilador de tiempo o lo que sea), la inspección El rango se filtra hasta los puntos de interés relevantes en mi aplicación.

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

#import <sys/kdebug_signpost.h>

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 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 los eventos que serían mostrados por 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, deberá importar <sys/kdebug.h> :

#import <sys/kdebug.h>

Además, no pude encontrar una declaración 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 , que verifiqué empíricamente:

#ifndef SYS_kdebug_trace
#define SYS_kdebug_trace 180
#endif