johelrc
25/05/10, 21:11:09
Un artículo muy interesante que me encontré en androidspin, está en inglés, me tomé la libertad de traducirlo (espero que entiendan y me perdonen cualquier falta), abajo está el link original junto al texto traducido.
Saludos
http://androidspin.com/2010/05/25/why-you-dont-need-a-task-killer-app-with-android/
Porqué no necesitas un Task Killer en Android?
Mucha gente nos pregunta que aplicacion es la mejor para matar tareas? Bueno, la respuesta es ninguna. Seguro hay algunas bonitas aplicaciones para matar tareas, pero de hecho usted no necesita ninguna en android. De hecho, la mayoría de los desarrolladores ni siquiera se fijan en el log para ver si hay un task killer en tu telefono android.
Para aclarar el asunto, el blog de los desarrolladores de Android en Google tiene finalmente este debate de porqué un task killer es innecesario, también el porqué hay unos servicios que corren en background todo el tiempo, estoy seguro de que en un momento u otro usted se ha preguntado: "Porqué esos servicios se mantienen arriba aún después de matarlos?", abajo usted puede leer acerca de cuando parar una aplicación. Si desea aprender más al respecto puede leer el post completo de esta url:http://android-developers.blogspot.com/2010/04/multitasking-android-way.html
Cuando parar una aplicación?
Una confusión acerca de la multitarea en android es la diferencia entre una aplicación y un proceso. En android estas no son entidades cercanas: las aplicaciones le pueden aparecer al usuario sin un proceso real ejecuntando la aplicación; multiples aplicaciones pueden compartir procesos, o una aplicación puede hacer uso de multiples procesos dependiendo de sus necesidades; el proceso(os) de una aplicación puede mantenerse en Android aún cuando la aplicación no activamente haciendo algo.
El hecho de que usted pueda ver procesos de aplicaciones "corriendo" no significa que la aplicación esté corriendo o haciendo algo. Eso está allí por que Android lo necesitaria en algún momento, y tomó la decisión de que sería mejor mantenerlo por allí en caso de necesitarlo de nuevo. Del mismo modo, usted puede dejar aplicacion por un momento y retornar a ella desde donde usted la dejó, y durante ese tiempo Android pudo necesitar deshacerse del proceso para otras cosas.
Una clave de como Android maneja las aplicaciones es que los procesos no se paran limpiamente. Cuando un usuario deja un aplicación, el proceso se mantiene en segundo plano, permitiendole que siga trabajando (por ejemplo bajando una página web) si es necesiario, y regresa a primer plano inmediatamente si el usuario retorna a ella. Si un dispositivo nunca se queda sin memoria, entonces Android mantendría todos los procesos, en realidad mantedría la aplicaciones "ejecutandose" todo el tiempo.
Por supuesto que hay un limite para la memoria, y para acomodarse a eso Android debe decidir cuando sacar un proceso que no necesita. Esto conduce a ciclo de vida de un proceso en Android, las reglas que usan para decidir que tan importate es cada proceso y por lo tanto cual es el proximo a detener. Estas reglas se basan tanto en la importancia de proceso para la experiencia del usuario, como en que tanto pasó desde que el proceso fue necesitado por el usuario.
Una vez que Android determina que necesita remover un proceso, lo hace por fuerza bruta, simplemente matando el proceso. El kernel entonces puede reclamar los recursos ocupados por el proceso, sin depender de que la aplicación esté bien escrita o bien responder a una amable petición de salir. Permitiendo al kernel reclamar los recursos de una aplicación hace mucho más sencillo evitar quedarse sin memoria.
Si el usuario retorna a una aplicación que ha sido aniquilada ( :) ), android necesita una manera de relanzar la aplicación en el mismo estado en el que fue vista, para preservar la experiencia de "todas las aplicaciones están corriendo al mismo tiempo". Esto se logra manteniendo un historial de los cambios en la aplicación de que el usuario sabe que cambió (las actividades), y reiniciando entonces con esta información en el ultimo estado que la vió. Este último estado es generado cada vez que el usuario deja una parte de la aplicación, no cuando es "matada", entones el kernel puede libremente matarla sin depender de que la aplicación responda correctamente en ese momento.
En cierto modo, la administración de procesos de android puede ser vistas como una forma de intercambiar espacio: los procesos de la aplicación representan una cierta cantidad de memoria en uso, cuando la memoria baja, algunos procesos se pueden matar(se mueven fuera), cuando esos procesos se necesitan de nuevo, estos procesos se pueden reiniciar en el ultimo estado salvado (se mueven dentro).
Saludos
http://androidspin.com/2010/05/25/why-you-dont-need-a-task-killer-app-with-android/
Porqué no necesitas un Task Killer en Android?
Mucha gente nos pregunta que aplicacion es la mejor para matar tareas? Bueno, la respuesta es ninguna. Seguro hay algunas bonitas aplicaciones para matar tareas, pero de hecho usted no necesita ninguna en android. De hecho, la mayoría de los desarrolladores ni siquiera se fijan en el log para ver si hay un task killer en tu telefono android.
Para aclarar el asunto, el blog de los desarrolladores de Android en Google tiene finalmente este debate de porqué un task killer es innecesario, también el porqué hay unos servicios que corren en background todo el tiempo, estoy seguro de que en un momento u otro usted se ha preguntado: "Porqué esos servicios se mantienen arriba aún después de matarlos?", abajo usted puede leer acerca de cuando parar una aplicación. Si desea aprender más al respecto puede leer el post completo de esta url:http://android-developers.blogspot.com/2010/04/multitasking-android-way.html
Cuando parar una aplicación?
Una confusión acerca de la multitarea en android es la diferencia entre una aplicación y un proceso. En android estas no son entidades cercanas: las aplicaciones le pueden aparecer al usuario sin un proceso real ejecuntando la aplicación; multiples aplicaciones pueden compartir procesos, o una aplicación puede hacer uso de multiples procesos dependiendo de sus necesidades; el proceso(os) de una aplicación puede mantenerse en Android aún cuando la aplicación no activamente haciendo algo.
El hecho de que usted pueda ver procesos de aplicaciones "corriendo" no significa que la aplicación esté corriendo o haciendo algo. Eso está allí por que Android lo necesitaria en algún momento, y tomó la decisión de que sería mejor mantenerlo por allí en caso de necesitarlo de nuevo. Del mismo modo, usted puede dejar aplicacion por un momento y retornar a ella desde donde usted la dejó, y durante ese tiempo Android pudo necesitar deshacerse del proceso para otras cosas.
Una clave de como Android maneja las aplicaciones es que los procesos no se paran limpiamente. Cuando un usuario deja un aplicación, el proceso se mantiene en segundo plano, permitiendole que siga trabajando (por ejemplo bajando una página web) si es necesiario, y regresa a primer plano inmediatamente si el usuario retorna a ella. Si un dispositivo nunca se queda sin memoria, entonces Android mantendría todos los procesos, en realidad mantedría la aplicaciones "ejecutandose" todo el tiempo.
Por supuesto que hay un limite para la memoria, y para acomodarse a eso Android debe decidir cuando sacar un proceso que no necesita. Esto conduce a ciclo de vida de un proceso en Android, las reglas que usan para decidir que tan importate es cada proceso y por lo tanto cual es el proximo a detener. Estas reglas se basan tanto en la importancia de proceso para la experiencia del usuario, como en que tanto pasó desde que el proceso fue necesitado por el usuario.
Una vez que Android determina que necesita remover un proceso, lo hace por fuerza bruta, simplemente matando el proceso. El kernel entonces puede reclamar los recursos ocupados por el proceso, sin depender de que la aplicación esté bien escrita o bien responder a una amable petición de salir. Permitiendo al kernel reclamar los recursos de una aplicación hace mucho más sencillo evitar quedarse sin memoria.
Si el usuario retorna a una aplicación que ha sido aniquilada ( :) ), android necesita una manera de relanzar la aplicación en el mismo estado en el que fue vista, para preservar la experiencia de "todas las aplicaciones están corriendo al mismo tiempo". Esto se logra manteniendo un historial de los cambios en la aplicación de que el usuario sabe que cambió (las actividades), y reiniciando entonces con esta información en el ultimo estado que la vió. Este último estado es generado cada vez que el usuario deja una parte de la aplicación, no cuando es "matada", entones el kernel puede libremente matarla sin depender de que la aplicación responda correctamente en ese momento.
En cierto modo, la administración de procesos de android puede ser vistas como una forma de intercambiar espacio: los procesos de la aplicación representan una cierta cantidad de memoria en uso, cuando la memoria baja, algunos procesos se pueden matar(se mueven fuera), cuando esos procesos se necesitan de nuevo, estos procesos se pueden reiniciar en el ultimo estado salvado (se mueven dentro).