2011-02-18 11 views
6

Soy nuevo en Objective-C (procedente de Java) y creo que entiendo muy bien la gestión de la memoria. Pero cuando se carga mi aplicación, obtengo una fuga de memoria extremadamente pequeña, que solo ocurre cuando el juego se está cargando (estamos hablando de 32 a alrededor de 512 bytes).¿Se ha aceptado alguna fuga de memoria en iOS?

Es aleatorio cuando se filtra, y no parece que sea el usuario el que desencadena la fuga. Normalmente se detecta después de aproximadamente 20 segundos a 1 minuto.

La información que obtengo del depurador nunca es la misma. En algún momento es UIApplication que es "marco responsable", a veces es [UIWindow makeKeyAndVisible] y, a veces es [UNibDecoder].

¿Este límite es "aceptado", o la aplicación no debe tener fugas en absoluto? Esta es mi primera aplicación "grande". He hecho una aplicación pequeña de vista flipside, y allí donde no hay fugas.

Por otro lado, ¿cuál es la mejor manera de identificar fugas?

+1

posible duplicar: http://stackoverflow.com/questions/1136511/does-apple-reject-leaking-iphone-apps – jakev

Respuesta

10

No es genial, pero no hará que se rechace su aplicación a menos que cause un bloqueo frente a un revisor. El tamaño es menos importante que la frecuencia con que ocurre. Si solo ocurre una vez cada vez que se ejecuta la aplicación, eso no es gran cosa. Si ocurre cada vez que el usuario hace algo, entonces eso es más un problema.

El analizador estático de LLVM puede encontrar algunos de estos problemas para usted. Limpie su construcción, luego seleccione Build and Analyze en el menú Build. También hay una plantilla de Fugas en Instrumentos.

Probablemente sea una buena idea rastrear estos errores y corregirlos, porque la administración de memoria de Objective C es bastante diferente en comparación con Java, y es bueno practicar con cosas más pequeñas antes de estar atrapado intentando depurar un gran problema con una fecha límite que se avecina.

+1

¡Gracias! Construir y analizar es una característica genial :) – hogni89

+1

+1 respuesta muy completa :) – jv42

4

Demasiado uso total de memoria en vivo es lo que hará que su aplicación falle y/o sea rechazada. Si pierde memoria dentro de un bucle o método de repetición, las filtraciones eventualmente se acumularán y su aplicación se bloqueará.

Pero si hay una fuga, pero no en un ciclo o proceso repetitivo, y la cantidad total es menor que el uso de memoria típico de una aplicación, entonces puede ser descortés y poco elegante, pero realmente no hay manera de saberlo. y hay muy poca desventaja operativa.

A menudo hago pruebas de estrés de mis aplicaciones al "filtrar" intencionadamente varios megabytes durante el lanzamiento de la aplicación, y asegurarme de que las aplicaciones todavía se ejecutan correctamente. Algunas de estas aplicaciones han sido aprobadas para la distribución de la tienda de aplicaciones con este código de prueba que todavía se ha dejado habilitado (mia culpa!). Pero eso muestra que incluso unos pocos MB de fugas no son un problema para la aprobación de la aplicación (a menos que eso sea suficiente para hacer que la aplicación se cuelgue durante las pruebas de poca memoria).

+2

+1 para la prueba de estrés. También suele ser una buena idea tener una gran asignación inútil al principio del desarrollo para tener alguna manera fácil de liberar algo de memoria cuando se vuelve problemático. Esto es especialmente útil en el desarrollo de juegos, pero se puede usar en cualquier lugar. – jv42