Fugas de memoria inherentes en iOS o MonoTouch?

memory-leaks xamarin.ios

Question

Estamos luchando con fugas de memoria en una aplicación de iPad que tiene que ser lo suficientemente estable como para poder seguir funcionando las 24 horas del día, los 7 días de la semana, por lo que las pérdidas de memoria son intolerables.

Como una prueba simple, creamos un nuevo proyecto iPad MonoTouch, usando la plantilla "Vista única", y lo ejecutamos usando instrumentos en el iPad (iPad tercera generación, no hay otras aplicaciones ejecutándose / en la memoria).

En Instrumentos, si seguimos presionando el botón "Marcar memoria" de vez en cuando, sigue comiendo memoria. No mucho, pero un poco cada cierto tiempo:

La aplicación literalmente no hace nada por nuestra parte, pero claramente se está ejecutando algo que asigna memoria.

¿Es esto un problema de iOS, un problema de MonoTouch o algo más?

¿El plan para crear una aplicación iPad 24/7 es realista? Tememos que cuando comencemos a agregar código, la cantidad de pérdidas de memoria también aumentará. La aplicación podría funcionar claramente durante bastante tiempo con las fugas en la imagen de arriba, pero si aumenta, la fecha límite para la memoria completa será mucho más rápida.

Answer 1

Las capturas de pantalla muestran asignaciones, no pérdidas de memoria. Puede pedirle a Instruments que rastree fugas, es decir, donde no se encuentre ninguna referencia a la memoria asignada.

Sin embargo, no es posible, sin más datos, decir si esos son normales o no. Necesitamos, al menos, saber de dónde vienen las asignaciones? Los instrumentos pueden darle más detalles sobre cada asignación. Intente taladrar el árbol debajo de cada uno de los planos para ver de dónde proviene la asignación.

Situaciones similares a menudo se deben al almacenamiento en caché, y eso se hace en todos los niveles. Fuera del código de la aplicación, observará que iOS y sus marcos están almacenando en caché (por ejemplo, imágenes, webkit ...).

Mono en sí mismo almacena en caché y también utiliza grupos de memoria que crecerán cuando sea necesario. Se mostrará una asignación (incluso si se liberó) pero no es una fuga: cuando se libere la memoria, si es posible (por ejemplo, tamaño) reutilizada.

Por supuesto, también podría ser un error (en la aplicación, en cualquier framework, mono touch, iOS). Con el tiempo, una sola y pequeña fuga es suficiente para bloquear una aplicación si ocurre en el lugar equivocado (por ejemplo, parte de un ciclo de ejecución, notificación de procesamiento ...). Solo encontrar de dónde provienen las asignaciones y si son asignaciones repetidas (de la misma fuente) le indicará cuán críticas son.

EDITAR (más)

Así que hice un experimento con mi propia aplicación anoche. La siguiente captura de pantalla muestra el crecimiento del montón durante 13 horas y 45 minutos.

Durante las primeras 4 horas (1-13) la aplicación estaba en primer plano. La última parte (14) de la aplicación estaba en el fondo (pantalla apagada por la noche). La grabación también se detuvo después del # 14, por lo que ese número no pudo reducirse con el tiempo.

Mi aplicación es más grande (línea base inicial a 5 MB) y no la utilicé después de su inicio. Mi primer "Mark Heap" se realizó una vez que supe que la inicialización estaba completa (está cargando una base de datos de 80MB bastante grande ). OTOH también escucha eventos de red , usando NSNetServiceBrowser , que NSNetServiceBrowser la devolución al código administrado (sin ninguna pista visual).

Expanding Heapshot # 1 muestra un solo objeto, 48 bytes, con un stacktrace que termina con _ZL13_cache_mallocm , cache_fill , lookupMethod , _class_lookupMethodAndLoadCache3 ... no hay nada de mi aplicación o mono mostrado más arriba en las personas que llaman.

Expanding Heapshot # 2 muestra cuatro objetos, los primeros dos con CA::Render::Encoder::ObjectCacche::invalidate(...) y CGNotificationCenterPostNotification en su seguimiento de pila. El tercero con _cache_addForwardEntry , el cuarto parece Heapshot # 1 pero, al igual que el tercero, proviene de _XReceivedStatusBarDataAndAction (no es algo que mi aplicación o monotouch hagan directamente).

Expanding Heapshot # 3 muestra 10 objetos ... un poco largos para _XReceivedStatusBarDataAndAction , sin embargo, todos están bajo la misma llamada _XReceivedStatusBarDataAndAction .

Mismo patrón al expandir la imagen # 4.

Heapshot # 5 tiene una diferencia (de 11) donde la asignación proviene de una cola de envío (_xpc_connection_init) pero no hay ningún marco de pila administrado (aplicación) o mono [táctil] visible.

Mismo patrón (como el n. ° 3) al expandir el plano n. ° 6, n. ° 7, n. ° 8.

La imagen # 9 está vacía (sin asignación).

Heapshot # 10, # 11 como # 3.

La imagen # 12 también está vacía.

Heapshot # 13 es mayormente como # 3 pero también almacena en caché las mismas imágenes, CA::Render::Image::caches_encoding() y otra _cache_fill + lookUpMethod ocurrió cuando se recibió una notificación _significantTimeChange (no gestionada o marco de pila MT debajo de UIApplicationMain ). Algunas otras asignaciones están relacionadas con la notificación.

Heapshot # 14 es principalmente sobre notificación (probablemente se le diga que va a un segundo plano). Nuevamente hay algunas asignaciones _cache_fill .

¿Es esto un problema de iOS, un problema de MonoTouch o algo más?

No hay nada más que apunta a MonoTouch o incluso a mi aplicación. OTOH No he comparado esto con una aplicación ObjC (y es posible que no tenga tiempo para hacerlo), pero creo que verás algo bastante cercano, dependiendo de qué API / servicios se usen (y la aplicación que haga lo mismo debería mostrar lo mismo asignaciones).

Como dije antes de YMMV, las fugas (o la retención involuntaria de memoria) suelen ser específicas de la API. Si encuentra trazas raras en sus sesiones de instrumentos, complete un informe de errores (a Xamarin o Apple, según el seguimiento de la pila) sobre ellos para que puedan analizarse y corregirse (si tiene errores).

¿El plan para crear una aplicación iPad 24/7 es realista?

En cuanto a la ejecución de una aplicación 24/7, creo que se puede hacer, pero requiere la cooperación del usuario (lo que podría no ser realista). Cambiar a otra aplicación (botón de inicio, gestos) significa que su aplicación no estará en primer plano y Apple puede eliminar cualquier aplicación de fondo para reclamar memoria. Por ejemplo, App X se queda sin memoria y iOS comienza a preguntar, y luego a matar, las aplicaciones de fondo para satisfacer la aplicación de primer plano.