2010-12-09 7 views
10

Estoy a punto de terminar mi primera aplicación de iPhone, y me pregunto si hay un conjunto de pasos que se utilizan para comprobar la pérdida de memoria, el rendimiento, etc. de la aplicación.Al probar una aplicación para iPhone, ¿es suficiente usar el instrumento Leaks?

¿Es suficiente consultar con el instrumento Leaks?

¿Hay alguna serie de pruebas que deba ejecutarse? ¿Hay algún tutorial/documento que ustedes me puedan señalar?

+0

Relacionados con esto son [¿Cuál es su enfoque para probar aplicaciones de iPhone/iPad?] (Http://stackoverflow.com/questions/2670107/whats-your-approach-to-testing-iphone-ipad-apps) y [ ¿Cuál es la estrategia de prueba de tu aplicación de iPhone?] (Http://stackoverflow.com/questions/860889/what-is-your-iphone-app-testing-strategy) –

Respuesta

3

Las pruebas con el instrumento Leaks deben ser parte de su estrategia, pero no todas. Deberá probar su aplicación desde múltiples ángulos.

Mi estrategia hacia las pruebas tiende a centrarse primero en las pruebas funcionales, seguidas de las pruebas de rendimiento y luego en una última ronda de pruebas funcionales. No tiene mucho sentido ajustar el rendimiento si tiene un error que se cuelga en algún lugar de su código, a menos que ese bloqueo se deba a un agotamiento de recursos de algún tipo.

Martille en la aplicación para tratar de romperla al ejecutar cada opción en cualquier condición que se le ocurra. Si eso pasa, suelo emplear mi prueba de "mono loco con crack", donde martillo botones y áreas al azar en la pantalla lo más rápido que puedo para ver si expongo a otros intrusos.

Solo entonces me vuelvo a Instrumentos. Ejecute la aplicación en el dispositivo (no se debe realizar ningún ajuste de rendimiento en el simulador) utilizando los instrumentos Time Profiler y Memory Monitor. Busque zonas activas de rendimiento y picos de memoria, así como acumulaciones de memoria. Repita el mismo tipo de prueba que utilizó para problemas funcionales antes al hacer esto.

Una vez que se ocupe de los puntos críticos y las acumulaciones obvias, puede pasar a un examen de memoria más detallado. De hecho, prefiero usar el instrumento Object Allocations con su nueva capacidad de análisis de fotogramas para el instrumento Leaks para encontrar sutiles acumulaciones de memoria y fugas. El instrumento de Leaks tiende a ser conservador, y puede pasar por alto algunas acumulaciones. Nathaniel señala el excelente post de Bill Bumgarner sobre el tema.

El instrumento Object Allocation y sus diapositivas son particularmente potentes cuando se combinan con el instrumento UI Automation, donde puede realizar cientos o miles de ciclos de pruebas en partes de su aplicación para resaltar incluso la acumulación de memoria más pequeña. Empecé a hacer más de este tipo de pruebas ahora.

Creo que funciona mejor para ver esto en acción en lugar de describirlo en el texto, por lo que recomendaría ver el video de mis clases "Prueba" y "Ajuste del rendimiento" como parte de mi advanced iOS course on iTunes U. Demuestro cada una de estas herramientas y cómo las uso en las pruebas de mis propias aplicaciones antes de la presentación en la App Store. Mi course notes (en formato VoodooPad) también describe esto en detalle.

+0

wow ! eso es muy útil, muchas gracias, voy a ver los enlaces que has mencionado ... Muchas gracias una vez más – Veeru

0

Sólo asegúrese de soltar los objetos siempre que sea necesario para reducir pérdidas de memoria

Comprobar este enlace para saber acerca de los instrumentos.

http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/Introduction/Introduction.html

+0

Gracias BuildSucceeded, revisaré los documentos y veré qué puede encontrar :) – Veeru

+0

Solo asegúrese de que su aplicación salga de los instrumentos sin fugas y no falle. Eso es lo que eres bueno para ir. – iPrabu

0

En primer lugar construir su aplicación, pero no lo hacen, ahora haga clic en la opción "Ejecutar" en la barra de menú superior de la XCode y haga clic en "Ejecutar con herramienta de rendimiento" y seleccionar "fugas" . Verá la nueva ventana donde podrá ver los Bytes en tiempo real utilizados por su aplicación y donde la memoria se está filtrando. Las fugas de memoria se mostrarán con una marca roja. Si encuentra algún problema al hacer esto, siéntase libre de preguntar.

+0

hola, como mencioné en mi publicación, ya lo he hecho con fugas de memoria y todo se ve bien, me pregunto si hay más que necesito hacer – Veeru

4

Correr con "Fugas" es importante. No conozco un tutorial/lista de verificación para las pruebas finales, aunque algo así sería útil. Un par de cosas que me gustaría añadir:

1) Asegúrese de probar con el hardware real y no sólo el simulador para asegurarse de que el rendimiento es razonable en todo el hardware tiene la intención de apoyar. En mi experiencia, el simulador no le da una idea precisa del rendimiento del dispositivo y puede haber diferencias significativas entre el hardware antiguo y el más reciente (el ejemplo extremo es iPhone 4 frente a iPhone Gen1). Por ejemplo, en una de mis aplicaciones, genero un informe en PDF de 1 página. En iPhone 4 e incluso iPad, toma alrededor de 1 segundo. En el iPhone Gen1, el mismo código toma cerca de 8 segundos. No había mucho que pudiera hacer para acelerarlo, pero estaba claro que necesitaba agregar un indicador de progreso para que el usuario supiera que la aplicación no estaba congelada. Esto es algo que no habría notado corriendo solo con el simulador y/o el último hardware.

2) Es posible que desee pasar un poco de tiempo corriendo con NSZombieEnabled. Esto puede encontrar problemas de memoria que pueden estar ocultos detrás de la escena, incluso si actualmente no hay signos visibles de problemas. Más información:

http://www.cocoadev.com/index.pl?NSZombieEnabled

+0

Entiendo lo que quiso decir cbranch, ya he tenido habilitado nszombie en mi proyecto, las cosas se ven bien, pero creo que haré todas y cada una de las pruebas posibles para no intentar ser rechazado por Apple – Veeru

1

Usted debe simular poca memoria para su aplicación para ver cómo reacciona, no es tan divertido a morir por iOS debido a que están consumiendo demasiada memoria. Si se desarrolla solo en un simulador, es fácil pasarlo por alto ya que parece bastante indulgente en lo que respecta a la memoria.

+0

Gracias por el consejo Anders, lo haré de inmediato - espero que no haya sorpresas :) – Veeru

2

El instrumento Leaks detecta muchas fugas posibles, pero no todas. Observe su asignación total de memoria y asegúrese de que disminuya cuando se supone que debe hacerlo. Leer caso de estudio el análisis de heapshot bbum:

http://www.friday.com/bbum/2010/10/17/when-is-a-leak-not-a-leak-using-heapshot-analysis-to-find-undesirable-memory-growth/

y ejecutar el analizador estático Clang, a través de la construir y analizar los comandos, si no lo han venido haciendo desde el getgo.

Cuestiones relacionadas