Cómo encontrar que genera la pérdida de memoria! (Primera parte) by Kamen

30 10 2009

Siguiendo y leyendo al Developer’s Blog en Inside BlackBerry me encuentro con éste post cuya autoría pertenece a Kamen y que nos esforzamos en traducir y traerles a consideración para que aprendamos un poco mas sobre nuestros dispositivos y su entorno, si bien es cierto, algunos no entenderán a cabalidad los conceptos, nuestra esperanza es que poco a poco vayamos familiarizándonos con ellos y levantemos nuestro perfil y lo fortalezcamos en aras del conocimiento, los dejo con lo que Kamen preparara y publicara…

‎​La liberación de una aplicación con una pérdida de memoria puede ser uno de los momentos más embarazoso para un desarrollador en el ciclo de vida de la aplicación. Dado que los dispositivos móviles tienden a tener menos memoria libre que un PC, el impacto de una pérdida de memoria se hace más pronunciada. Tras los pasos a continuación ayudará a garantizar a los desarrolladores a no encontrarse en esta situación al desarrollar sus aplicaciones para los smartphones BlackBerry ®.

Fugas? ¿Qué son las fugas?

‎​Empecemos por aclarar cómo los desarrolladores pueden terminar con una pérdida de memoria en un entorno de desarrollo Java ®. La Java Virtual Machine (JVM) realiza la recolección de basura con la función de liberar la memoria asignada a los objetos y no hace referencia a nada en el sistema, esto pone a las aplicaciones de Java en una mejor posición que las aplicaciones en un entorno de programación como C + +, por ejemplo. Sin embargo, cuando un objeto que no es necesario ya que queda referenciado por otro objeto en su aplicación, el sistema JVM no tiene manera de saber que este objeto debe ser liberado. Esto es especialmente cierto si las instancias de ese objeto se ven acumuladas en el tiempo.

‎​Nuestra experiencia en el desarrollo del BlackBerry muestra que en la práctica uno de los casos más comunes para la creación de una pérdida de memoria es cuando el registro de oyentes para el sistema de actos a nivel – por ejemplo, al registrar tu propia carpeta de correo electrónico utilizando ApplicationMessageFolderListener. Sin embargo, una pérdida de memoria puede ser creada con sólo añadir una instancia de objeto al Global Runtime Store y no eliminarlo. Ésta es una aplicación muy simple que crea una fuga de memoria cada vez que se inicia:

import net.rim.device.api.system.Application;
import net.rim.device.api.system.RuntimeStore;
import java.util.Random;

class TestMemoryLeaks {
public static void main(String[] args) {
//create a memory leak by adding an item to the runtimestore and never removing it
RuntimeStore store = RuntimeStore.getRuntimeStore();
store.put((new Random()).nextLong(), new TestMemoryLeaks());
}
}

‎​Por supuesto, pérdidas de memoria también pueden existir en el ámbito de una solicitud, pero su impacto es limitado ya que se eliminan cuando se termina la aplicación (a menos que la aplicación está diseñada para ejecutarse siempre en el fondo). En esta categoría entran también todas las implementaciones de detectores registrados para la aplicación amplio ámbito de aplicación por ejemplo el AccelerometerListener. Para los listener como tal, el sistema subyacente utiliza WeakReferences, cuando la aplicación termina y no hay otros objetos que tengan referencias “fuertes” al listener, el sistema automáticamente eliminará la WeakReferences como tal y liberará los objetos.

En la segunda y tercera parte de esta serie, veremos la forma de detectar una fuga y la identificación de la causa raíz, respectivamente. Manténgase sintonizado!!

Ufff!
Si te perdiste en la clase es porque aún no te encuentras muy familiarizado con los términos, espero que pronto subas de nivel pero en definitiva, a veces juzgamos a los Sistemas Operativos y declaramos que éstos tienen mucha fuga de memoria pero en realidad lo que sucede es que usamos aplicaciones que generan esa fuga, debemos tener cuidado con eso y probar primero a los Sistemas Operativos sin aplicaciones de terceros a veces nos cuestionamos el porque al resetear el dispositivo se recupera memoria y porque al no hacerlo se va perdiendo, arriba, en lo que Kamen nos explicara está la respuesta, lee de nuevo.

Saludos
@atilauno

Anuncios

Acciones

Information

4 responses

30 10 2009
Daniel0181

Muy interesante!! Gracias

30 10 2009
nando

Hola muy buen post, ese es el problema con las aplicaciones de terceros consumen mucha memoria ya que dejan instalado archivos necesarios para que funcione la aplicacion rapido al volverla abrir por esto es que apple no permite aplicaciones fuera de la app store ya por ese medio ellos controlan como actua la aplicacion con el dispositivo pienso que rim deberia hacer lo mismo o parecido

30 10 2009
atila1

Pendientes para la segunda parte jeje

Saludos
@atilauno

30 10 2009
atila1

Nando, si, eso es verdad, ahora bien, no creo que RIM monopolice el área de desarrollo de aplicaciones, de hecho, prefieren dar soporte como el Blog’s Developer de Inside BlackBerry para que desarrolladores de aplicaciones de terceros interactúen e intercambien opiniones con ingenieros de RIM (como Kamen) para que eleven la calidad, esperamos que dé los resultados deseados en la nueva generación de aplicaciones que pronto salgan a la luz.

Saludos
@atilauno