blogElectronica.com

Últimamente me han preguntado bastante en relación a la memoria RAM de los módulos gprs TC65 y XT65 (y sus correspondientes terminales) así que voy a poner un pequeño artículo en relación a este tema.

Como sabéis el módulo TC65 tiene un total de 400KB de memoria RAM y 1.7MB de memoria FLASH. Es evidente que la memoria flash, FFS (File Flash System, el sistema de archivos) estará en parte ocupada por nuestra aplicación java (es decir, por los ficheros .jad y .jar) y por todos aquellos archivos extra que necesitemos para nuestra aplicación así como los propios archivos generados por nuestra aplicación java, es decir, ficheros con logs, históricos, etc etc …
 

Bueno … con 1.7MB puedo hacer un programa inmenso y me sobra ¿para qué me voy a perder el tiempo leyendo esto?
 
Es cierto que puedes hacer programas bastante grandes pero va a depender mucho de cómo los hagas y de las herramientas que estés utilizando. Si no estructuras bien tu programa puedes llegar a tener problemas serios de memoria.
 

Vaya, no lo entiendo, cuando ejecuto mi aplicación java me sale un “out of memory” y antes me funcionaba, lo único que he hecho es añadir un poco más de código. Mi fichero .jar ocupa unos 150KB y veo que cuanto más grande es mi fichero .jar menos memoria RAM libre me queda libre … ¿Cómo es esto posible? ¿Pero el programa no está en la memoria flash y los 400KB de RAM no son exclusivamente para las variables y datos de mi aplicación?
 
 
Evidentemente no. Por supuesto tus ficheros .jar y .jad están tranquilamente en la memoria Flash, sino cuando apagases el módem se borrarían. Pero piensa que el fichero .jar es un fichero comprimido (puedes abrirlo si quieres con el winrar) y dentro están los bytescode, los ficheros .class, los ficheros con código java compilado. El módem va a descomprimir esos archivos y va a cargar los necesarios en memoria RAM. De ahí que cuanto mayor sea tu programa java menos espacio libre te va a quedar en memoria RAM (o no, depende de tu programación).

Si por ejemplo eres de la vieja escuela y pese a permitir el lenguaje java una programación orientada a objetos haces una programación completamente lineal, tipo programación C, es decir, si tu aplicación consiste en un único fichero .java inmenso lleno de métodos (que tú verás como funciones de C) puedes tener serios problemas a medida que tu aplicación crezca. Si trabajas de esa manera, cuando arranques tu aplicación java, todo el código de programa lo vas a tener cargado de forma permanente en memoria RAM y podrás tener problemas serios de memoria a la larga.

La mejor manera de ahorrarse esos problemas consiste en una programación más estructurada, es decir, una programación realmente orientada objetos. Antes de ponerte a escribir código planifica tu aplicación, estructúrala en objetos creando un archivo .java (y por tanto un archivo .class) por cada objeto de tu aplicación. De esta manera cargarás en memoria pequeños archivos .class sólo cuando sean necesarios por tu aplicación, es decir, cuando necesites crear  un determinado objeto para realizar algo y destruyéndolo cuando no lo necesites, o lo que es lo mismo,  liberando memoria cuando ya no lo necesites. Si haces un programa un único fichero .java inmenso (.class inmenso) tendrás en memoria todo el código de todos los métodos te sean necesarios o no en un momento determinado.
 
 
Es demasiado tarde … ya tengo hecha mi aplicación y tengo problemas de memoria. No puedo volver a hacerla toda, tardaría semanas y mi jefe me mataría … ¿Puedo hacer algo?
 
Estás de suerte, sí (de todas maneras cuando hagas otra aplicación estructúrala mejor).  Puedes utilizar un ofuscador java. Un ofuscador, al realizar su misión, es decir, al ofuscar el código compilado, comprime todavía más los archivos .class. De hecho si creas un package mediante un ofuscador verás como el fichero .jar ocupa bastante menos, incluso la mitad. Esto te va a dar cancha para no tener que rehacer la aplicación entera pero te aconsejo una programación más estructurada en un futuro.
 
 
¿Y qué ofuscador utilizas?
 
Personalmente utilizo el de Proguard integrado en el Eclipse. Otro día ya hablaré más de él en otro artículo, por hoy ya está.
 
 
 
Hoy Sábado a ver si acabo un proyecto que tengo pendiente y al que no acabo nunca de darle el remate final, pues últimamente estoy saturado de trabajo. Un pequeño proyecto on-line que he lanzado hace pocos días en el dominio www.PisosDeAlquiler.com, un portal de cruce de ofertas de pisos de alquiler, como su propio nombre indica.

La verdad es que es uno de los mejores nombres de dominio que tengo (y tengo más de un cententar). Un dominio, como digo yo, “gran reserva del 2002″, ya que lo adquirí en aquel año. Realmente durante estos años he estado a punto de venderlo en varias ocasiones, pues he recibido algunas ofertas de compra por él. La última oferta fue de 3.000€ que me hizo dudar bastante, aunque finalmente, y más viendo cómo está el patio de la vivienda en España en el que creo el alquiler va a crecer, me lo quedé. El tiempo dirá si hice bien.
 
 
Que paséis un estupendo fin de semana

Post relacionados:

1. Uso correcto de la Flash de los módems Cinterion TC65 y XT65 En muchas ocasiones podemos tener la necesidad de utilizar el...
2. Ejemplo de FTP Java para módems gprs Cinterion TC65 y XT65 Posiblemente en alguna ocasión tengas que hacer un programita en...
3. Localizando fallos difíciles de reproducir en los módems Cinterion TC65, XT65 Si desarrollas aplicaciones en Java para los módems gprs TC65,...
4. Compresión de archivos con J2ME en módems GPRS Siemens TC65 En muchas aplicaciones con módems GPRS es necesario almacenar datos...
5. Añadir datos a ficheros con módems Siemens-Cinterion desde java  En bastantes ocasiones me ha llegado la pregunta de cómo...

Esta entrada fue escrita el Saturday, 17 de October de 2009 a las 9:54 y archivada en 2.DISPOSITIVOS (práctico), 4.PROGRAMACIÓN, Comunic. GSM/GPRS. Puedes seguir cualquier respuesta a esta entrada a través del feed RSS 2.0. Puedes dejar una respuesta, o trackback desde tu propio sitio web.