Our Country Sites: Argentina|Brazil|Chile|Mexico|Peru

procesos i365

Printer-friendly versionPrinter-friendly versionSend by emailSend by email

Hola

Tengo una aplicacion para el movil i365, manejo un proceso constante de envio de datos a un servidor y un proceso de lectura de codigo de barras.

¿Hay una forma de monitorear los procesos del movil?
En codigo ¿Como puedo evitar que los procesos afecten al rendimiento
del movil y de la aplicacion?.

lesagradezco su atencion y su apoyo.

Re: procesos i365

Hola Jessica,

Lo que podrias hacer para monitorear tu aplicación seria revisar la memoria que tienes consumida hasta el momento y los hilos (threads) que tienes ejecutando hasta ese momento en la aplicacion. Eso te permitiria ver si una aplicacion se esta cayendo por falta de memoria heap (en el caso del i365 son 4 megas sino me equivoco) o si hay mas hilos de lo que el procesador del equipo puede manejar ( lo recomendable es que no pase mas de 8 hilos) mas hilos hacen inestables la aplicacion peligrando su funcionamiento.

Te paso unas lineas de codigo para que monitorees la aplicacion segun lo descrito arriba.

te permite ver la cantidad de hilos ejecutandose en tu app:
System.out.println("hilos ===>"+Thread.activeCount())

Te permite ver la memoria heap total y libre y memoria de datos total y libre.

stf.append("Mem.Heap.Tot: ").append(MathUtil.scale(Float.toString(Runtime.getRuntime().totalMemory()/1024),0)).append('\n');
stf.append("Mem.Heap.Lib: ").append(MathUtil.scale(Float.toString(Runtime.getRuntime().freeMemory()/1024),0)).append('\n');
stf.append("Mem.Dat.Tot: ").append(MathUtil.scale(Integer.toString(CustomerCare.getSystemInfo(CustomerCare.DATA_SPACE_TOTAL)),0)).append('\n');
stf.append("Mem.Dat.Lib: ").append(MathUtil.scale(Integer.toString(CustomerCare.getSystemInfo(CustomerCare.DATA_SPACE_FREE)),0)).append('\n');

Como estas Jessica. Ojo, que

Como estas Jessica. Ojo, que si necesitas usar la clase CustomerCare, en caso tengas que instalarlo en el equipo, se haria necesario firmar la aplicacion debido a que la clase mencionada necesita permisos para accesar a informacion del equipo.
Otra forma de monitorear los recursos que usa la aplicacion es usando el emulador que nos proporciona motorola. Cuando ejecutas un programa a travez del emulador, hay una opcion dentro del menu 'Tools' llamada 'Monitor'. Esta activa una ventana con un grafico de como se va aumentando el consumo de memoria a travez del tiempo. Puede servir para que revises que funcionalidad que estas implementando puede producir mayor consumo de memoria, y puedas avisorar que cambios realizar para disminuir este impacto. Tambien es bueno implementar de vez en cuando un System.GC() . No es bueno abusar de esta sentencia, pero es util usarlo en lugares estrategicos.

Las depuraciones en emulador

Las depuraciones en emulador sirven mas para errores de programación que para monitoreo, ya me ha pasado mas de una vez que el emulador solo verifica el maximo de consumo de memoria de acuerdo a la especificacion del equipo pero nada mas.

Lo mejor es hacer depuración sobre el mismo equipo con bastantes System.out.println.

Otra cosa, por ejemplo un error que me paso es que al minimizar la aplicación, esta hacia un System.gc() que hacia colgar la aplicación. Cosa que en emulador jamas pasaba. Ya sea por firmware u otra cosa.

Lo que comenta Kryor es

Lo que comenta Kryor es cierto. Lamentablemente el emulador te 'engaña', pues corre simulando las mejores condiciones, pero en la vida real el equipo tiende a fallar, y no se pueden replicar esos fallos con el emulador. El emulador te puede servir inicialmente, con el puedes monitorear referencialente la aplicacion, simular tener baja señal o no tener señal, no tener GPS. Pero cuando es 'estable' lo mejor es probar con un equipo, poniendo Systems.out en lugares criticos y capturandolo con el Hiperterminal o sino con el Putty.

Correcto, aparte el

Correcto, aparte el procesador de los equipos de gama baja es de cerca de 45 mhz y lo comparte para el S.o y aplicaciones Java, si tienes una APP que demande demasiado al equipo lo mas probable es que se aciga o demore una eternidad.

Tambien es recomendable

Tambien es recomendable revises que el equipo cuente con el ultimo firmware, pues estos se publican para corregir bugs reportados del equipo. Servicio tecnico puede apoyarte para revisar que el firmware del equipo sea el apropiado.

jessicaMGR, Cuando mencionas

jessicaMGR,
Cuando mencionas procesos del móvil, a que te refieres? Yo cuando monitoreo la aplicación, hago los conocidos System.out.println(""); y hago debug con la cadena de conexión del móvil...

Slds!
Juan Carlos

Procesos

Gracias a todos por sus respuestas me ayudan mucho.

Hola jcarlos.

A los procesos que me refiero son los hilos y el envio de datos.
Una pregunta entonces como puedo hacer ese debug conectandome desde el movil fisico?

Es bueno mencionar que vía

Es bueno mencionar que vía Bluetooth (scanner) puedes hacer el debug con lo que han dicho los chicos... Si fuera vía cable no puedes hacer debug porque usas el puerto.

Slds!
Juan Carlos

Respuesta

Hola JessicaMGR, si deseas hacer un debug cuando ya estas probando la aplicacion en el equipo, te recomiendo lo siguiente:

1) Abrir el Hiperterminal
2) Elegir el COM con el que esta conectado el nextel hacia la computadora(para saber el COM, digitas en la pantalla de comandos "mode")
3) Insertas esta linea "AT+WS46=252;+WS45=0;+IAPPL=2;D" y le das enter.
4) Empiezas a utilizar la aplicacion y segun tantos "System.Out.Print" hayas puesto en tu aplicacion, en el Hiperterminal se reflejara como esta caminando tu aplicacion en tiempo real y sabras por donde puede ser el error.

Saludos,
EP

El hiperterminal es el mas

El hiperterminal es el mas usado por que viene por default con el windows, pero tambien puedes usar el Putty.
La cadena para conectarte al equipo que usarmos es la que comenta Enrique :
AT+WS46=252;+WS45=0;+IAPPL=2;D
Pero los ultimos modelos no trabajan con esta cadena, y en estos casos debes usar la cadena Athens:
AT+IAPPL=2;D

Como estas Jessica. El debug

Como estas Jessica. El debug al cual se refiere JuanCa no es un debug interactivo del equipo con puntos de pausa. Cuando queremos hacer debug en el movil nos limitamos a poner mayor nivel de detalle en el System.out para saber como se esta comportando el aplicativo en los puntos que sospechamos que puede estar fallando.

Lo bonito de todo es que en

Lo bonito de todo es que en bluetooth (scanner) puedes hacer el debug respectivo como los chicos lo han indicado, lamentablemente un debug cuando usas el puerto del equipo vía cable no se puede hacer.

Slds!
Juan Carlos

Lo que Juan Carlos quiere

Lo que Juan Carlos quiere decir (corrigeme si me equivoco), es que si el puerto esta ocupado enviando y recibiendo informacion por bluetooth, no va a poder ser usado por el cable para enviar y recibir informacion del System.out , por lo que no se podra revisar a menos que se desconecte el scanner.

oaulestia que tal, No es así,

oaulestia que tal,
No es así, uno puede abrir un socket Bluetooth y por el puerto físico o virtual (cable) si podrás ver los 'sout' en ese mismo momento.

Slds!
Juan Carlos

Ah, entendi mal entonces.

Ah, entendi mal entonces. Interesante, voy a probar tu alcance. Muchas gracias.