Seguir todas las llamadas al método ObjC?

A veces, cuando se mira el gran progtwig Objective-C de otra persona, es difícil saber por dónde empezar.

En tales situaciones, creo que sería útil registrar cada llamada a cada método que no sea de Apple.

¿Hay una manera de hacer eso? Básicamente, realice un cambio en algún lugar central y registre cada método que se llame. Preferiblemente limitado a métodos que no sean de Apple.

Puede establecer la variable de entorno NSObjCMessageLoggingEnabled en SÍ. Esto escribirá un registro de todos los envíos de mensajes en la carpeta / tmp / msgSends-xxx.

Puede agregar un punto de interrupción simbólico a objc_msgSend() y hacer que registre el segundo parámetro sin detenerse.

Cómo hacerlo solo para sus propios métodos es una tarea de toucher. ¿Tal vez si pudieras inspeccionar el nombre de la clase que se llama y hacer algo de magia para tener un punto de interrupción condicional solo para las llamadas donde el prefijo de la clase coincida con el tuyo?

No creo que el registro de cada llamada sea lo suficientemente práctico como para ser útil, pero aquí hay una sugerencia en esa dirección.

En una nota lateral, si se trata de un progtwig grande, es mejor tener algún tipo de documentación o un comentario introductorio para que las personas comiencen con el código.

En cualquier caso, cada aplicación Cocoa tiene un método applicationDidFinishLaunching …. Es un buen lugar para comenzar. Algunas aplicaciones también tienen su clase principal (o ‘ventana principal’) definida en el archivo Info.plist. Ambas cosas pueden darle una pista sobre qué clases (específicamente, los controladores de vista) son las más destacadas y qué métodos es probable que tengan largos rastros de stack mientras el progtwig se está ejecutando. Como un bucle de juego en un motor de juego, o algún otro método frecuentemente llamado. Al colocar un punto de interrupción dentro de dicho método y observar el trazado de stack en el depurador, puede obtener una idea general de lo que está sucediendo.

Si se trata de una aplicación de interfaz de usuario de gran tamaño, mirar sus archivos NIB y las clases utilizadas en ellos también puede ayudar a identificar partes de la funcionalidad de la aplicación que podría estar buscando.

Otra opción es iniciar el instrumento Time Profiler y marcar las casillas de verificación Hide missing symbols y Hide system libraries . Esto le dará no solo una vista de pájaro de los métodos que se están llamando dentro del progtwig, sino que también señalará los más comúnmente llamados.

Al interactuar con su progtwig con la grabación de Time Profiler, también puede identificar diferentes partes de la funcionalidad del progtwig y correlacionarlas con sus acciones con bastante facilidad.

Instruments te permite construir tus propios “instrumentos”, que en realidad son solo scripts de DTrace disfrazados. Use la opción de menú Instrumento >> Crear nuevo instrumento y seleccione opciones como qué biblioteca desea rastrear, qué desea registrar cuando toca determinadas funciones, etc. ¡Vuélvase loco!

Esa es una pregunta interesante. La respuesta sería más interesante si la solución admite múltiples subprocesos de ejecución y hay algún tipo de línea de tiempo de llamada que podría informar la actividad a lo largo del tiempo (tal vez especialmente con eventos de usuario trazados de alguna manera).

Suelo iniciar el depurador, establecer un punto de interrupción en el punto de entrada principal (por ejemplo, – applicationDidFinishLaunching: withOptions 🙂 y recorrerlo en el depurador.

En OSX, también hay algunas herramientas de línea de comandos (por ejemplo, muestra y montón) que pueden proporcionar alguna información.

Parece que algún tipo de integración con instrumentos podría ser realmente genial, pero no estoy al tanto de algo que haga exactamente lo que usted desea (y lo quiero ahora también después de pensarlo).

Si tuviéramos que registrar un número de hilo y una dirección de llamada, y algunos detalles del marco, parece que las piezas estarían allí para trazar la línea de tiempo de la llamada. La lógica para descubrir la biblioteca apropiada (proporcionada por Apple o por un tercero) debería existir en el script symbolicatecrash de Apple.