feb 3 2011

Migrar de Windows Mobile a Android (3): Multitarea y Estabilidad

Gabolonte Blasfemus

Hoy vamos a revisar un tema que siempre fue controversial en casi toda plataforma móvil: La capacidad de multitasking. Y también volcaré mis impresiones sobre otro apartado prácticamente derivado de la buena o mala implementación del primero: La estabilidad del sistema.

Multitarea o Multitasking

imageMe acuerdo cuando comencé a usar mi primer equipo con Windows Mobile que una de las tantas diferencias que me hacían feliz con respecto a la Palm que usaba antes era que por fin tenía en mis manos una PDA multitasking: Podía abrir, dentro de límites razonables, todas las aplicaciones que quisiera, que todas seguirían ejecutándose de fondo, tal y como en cualquier sistema operativo de escritorio contemporáneo. Era algo impensable en el vetusto Palm OS, donde al abrir una aplicación automáticamente se cerraba la que anteriormente estaba en pantalla, y la única sensación de multitarea que el usuario experimentaba era que la mayoría de las aplicaciones recordaban al cerrarse el estado en que se las dejó, para que cuando volvieran a ser llamadas se mostraran tal y como se las había dejado. Esto parecía una solución de compromiso bastante buena para las limitaciones del hardware de aquel momento y de Palm OS en sí, garantizando una buena velocidad de respuesta al no correr nunca más de una aplicación a la vez, y sin por eso perder, al menos en gran parte de los casos, el trabajo que se venía manteniendo con cada aplicación. De todas maneras sí existía una forma de multitaskear más real, que mediante el uso de ciertas interrupciones o vaya-uno-a-saber-exactamente-qué permitía que aplicaciones especiales, como los reproductores de audio y algunos mensajeros instantáneos, continuaran funcionando de fondo mientras teníamos al frente otra aplicación, algo que no venía sin su precio, ya que generalmente volvía mucho más inestable al sistema. Este infierno en Windows Mobile desaparecía, ya que toda aplicación podía permanecer en memoria y en ejecución todo el tiempo que quiera de fondo, mientras los recursos disponibles lo permitieran. Y lo genial era que dentro del modelo de manejo de recursos de WinMo, ni siquiera hacía falta cerrarlas, ya que el sistema estaba diseñado para que se vayan quedando abiertas y en funcionamiento todas las que se fueran activando, para luego inteligentemente cerrar aquellas con más tiempo sin uso, a medida que fuera necesario liberar recursos en el sistema para otorgárselos a nuevos programas. Tan convencidos estaban de esta filosofía en Microsoft, que la mayoría de las aplicaciones no contaban con ningún diálogo para cerrarse, y el botón con la cruz, herencia del clásico botón para cerrar ventanas y programas en los Windows de escritorio, sólo servía para minimizar, o mejor dicho, mandar al fondo la aplicación que se tenía al frente.

Pero aún así, este excepcional esquema en WinMo tenía un par de costados álgidos. Como todas las aplicaciones de fondo permanecían en ejecución, cualquiera de estas que realizara tareas desatendidas automáticamente y sin necesidad de ser iniciadas por el usuario desde su interfaz, las continuaría realizando en background, en tanto Windows Mobile no la cierre por necesitar liberar memoria. Esto hacía que fuera común embotar un móvil a medida que se iban abriendo muchos programas, y más si alguno de estos presentaba problemas de manejo de memoria o de uso del procesador. Este esquema fue seguramente uno de los responsables de la famosamente conocida lentitud que siempre caracterizó a WinMo, y que llegados a casos extremos podían producir que directamente el teléfono/PDA se cuelgue por minutos, o hasta que se lo tuviera que reiniciar porque se quedó completamente duro. Fue por eso que muchas aplicaciones comenzaron a incluir en WinMo una opción explícita en su menú para efectivamente cerrarse, mientras que por otro lado comenzaron a hacerse populares los administradores de tareas que permitían fácilmente desde la barra de estado consultar las aplicaciones abiertas e ir cerrando las que no se deseaban tener en memoria a voluntad, llegando al punto de que HTC, quien fue el fabricante líder de teléfonos con WinMo durante años, incorporara su propio task manager en cada modelo que fabricaba. De esta forma se podía mantener el control efectivo de las aplicaciones, y podíamos elegir si, por ejemplo, queríamos dejar de fondo un cliente de Twitter consumiendo datos al bajar updates durante toda la tarde o no. En pocas palabras, a pesar de los inconvenientes antes vistos, en Windows Mobile se tenía el control de las aplicaciones que se instalaban.

Bienvenidos a Android. Eso no existe más.

imageCuando comencé a jugar con mi Milestone 2 una de las primeras cinco aplicaciones que instalé fue un administrador de tareas, primero porque ya venía con todo el esquema mental heredado de usar Windows Mobile, y segundo porque en varios blogs donde se recomendaba software para el androide siempre sugerían alguno. Adivinen qué, tanto ellos como yo estábamos muy equivocados.

Al principio todo parecía ir bien. De todos los task managers que probé me quedé con Task Manager de Adao Team, por su combinación justa de simpleza, funciones, e interfaz limpia. Podía ver las aplicaciones abiertas y cerrarlas a voluntad. Incluso conseguí un complemento ideal para mi rígida visión de lo que es una aplicación: Startup Cleaner, el que me permitía en teoría eliminar del inicio automático las aplicaciones que no necesitaba que arranquen solas junto con el sistema, otra cosa que conocía muy bien de Windows Mobile, que siempre se comportó como un Mini Windows.

Pero a lo largo de los días empezaron a suceder cosas raras. Casi toda aplicación que instalara, así sea la más pavota, como por ejemplo una de notas, figuraba en la lista que Startup Cleaner me mostraba, por lo que siempre que instalaba nuevas aplicaciones tenía que darme una vuelta por ahí; no me interesaba que el cliente SSH y los 4 clientes de Twitter que puse estuvieran iniciándose cada vez que reseteaba el teléfono. Algo olía mal en todo esto.

El complemento a esta extrañeza lo proporcionó Task Manager, que se la pasaba mostrando aplicaciones abiertas que nunca había iniciado en todo el día o que había matado hacía cinco minutos. Las aplicaciones en Android parecían ser zombis que se levantaban una y otra vez de su tumba, y evidentemente yo no estaba apuntando a la cabeza.

Este sinsentido comenzó a aclararse cuando empecé a leer algunos reveladores artículos sobre el concepto de multitasking tan particular que tiene Android. Ahí entendí unas cuantas cosas:

  1. La filosofía central de Android es que a los ojos del usuario todas las aplicaciones corren todo el tiempo. Esto, cual gato de Schrödinger, es así y no lo es al mismo tiempo, ya que…
  2. Una aplicación en Android no consta de un proceso inequívocamente ligado a la misma, sino que se componen de diversos elementos, cada uno con un set de funciones y propiedades específicas y una jerarquía  bien definida a la hora de ser considerados para su anulación. Dentro de esta filosofía, los diálogos de una aplicación recaen en los elementos llamados actividades, que normalmente se cierran ni bien dejan de estar en pantalla. Pero una actividad puede iniciar un servicio, componente que sí puede ejecutarse de fondo. Es lo que suele pasar cuando nuestro reproductor sigue pasando música o descargamos un archivo mientras estamos haciendo otra cosa. Las actividades al irse de pantalla no sólo se cierran, sino que guardan exactamente el estado en el que estaban al abandonarse, tal y como hacía el viejo Palm OS con sus aplicaciones. De esta forma luego Android puede matar su proceso sin siquiera pedirle amistosamente que se cierre, eliminando toda posibilidad de que procesos mal programados cuelguen o ralenticen el sistema. Luego, si llamamos nuevamente a la aplicación, al cargarse la actividad (pantalla) principal, levantará los datos guardados y se presentará tal y como la habíamos dejado.
  3. Siempre van a haber componentes de una aplicación cargados en memoria en determinados momentos, o que se carguen como respuesta a un evento específico para así realizar una tarea previamente designada. También existirán servicios pertenecientes a aplicaciones que permanecerán en ejecución de fondo, pero que normalmente informarán de tal situación mediante un icono en la barra de notificación, de manera que el usuario sepa que algo está pasando de fondo y tenga el control de ir y detenerlo. Para todos los demás componentes de una aplicación que puedan permanecer en background se puede afirmar que están inactivos, a menos que sean disparados por determinados eventos.
  4. En consecuencia de esto, los task killers o task managers no sirven para nada, y según Google incluso perjudican al sistema, ya que mata procesos antes de que terminen de realizar la operación para la cual fueron llamados, lo que los obliga a despertar una y otra vez (el efecto zombi). También deduzco que deben mostrar muchas aplicaciones abiertas de las que tal vez no hay más que un componente de la misma pausado o detenido.

Todo este menjunje, que por un lado se lo puede ver como state of the art en términos de versatilidad y experiencia de usuario, desde el punto de vista de la seguridad y el control por parte del usuario lo podemos ver como state of the ort. Todo esto puede sonar muy confuso, por lo que quiero dejarlo bien claro:

  • En Android no hace falta instalar ningún task killer, de hecho dañan al sistema. Android se ocupa de abrir y cerrar los diversos componentes de cada aplicación inteligentemente para proveer en todo momento una experiencia fluida. De hecho las aplicaciones que proveen una opción para salir de las mismas lo hacen sólo a modo de dejar tranquilo al usuario, ya que bajo este modelo generalmente nunca se van por completo. De hecho, y para cortar un poco con esta mala práctica para su modelo, a partir de Froyo ya no es posible para ninguna aplicación de terceros, por ende para ningún task killer tampoco, matar completamente a otra aplicación, con sus servicios incluidos.
  • Cuando apretamos el botón back para salir de una aplicación, esta realmente no se va de memoria, pero a los efectos de como funciona Android bien podemos asumir esto, ya que entra, generalmente, en un estado de inactividad, para quedar a disponibilidad de que el sistema la mate cuando lo considere necesario.
  • La única forma de asegurarse en Android de que una aplicación no se ejecute nunca de fondo es desinstalarla.

Presten atención a eso último. Si tienen dudas de que alguna aplicación pueda estar haciendo algo raro, incluso cuando no la están usando y concienzudamente deshabilitaron desde su configuración todo funcionamiento de fondo, no hay forma de asegurarse que nunca ninguna parte de ella va a estar ejecutándose durante el transcurso del día, y que alguna de esas partes, en algún momento, pueda hacer algo que nosotros no queríamos. Sólo pueden estar completamente seguros quitándola.

Estabilidad

imageWindows Mobile siempre fue lento, tan lento como Lento Rodríguez, el primo de Speedy González. Pero, dejando de lado un teléfono que ya me había venido muy castigado por su anterior dueño, puedo asegurar que mis otros dos dispositivos con WinMo jamás presentaron problemas de cuelgues o reseteos, con excepción de cuando una aplicación era claramente la culpable. Era lento, pero muy estable.

En este droide, tengo que decir con tristeza que vengo sufriendo un reseteo inesperado con una frecuencia de al menos una vez cada tres días. Incluso se me han colgado filmaciones, echando a perder todo el archivo de vídeo al no terminar de grabarlo con los encabezados correspondientes. Pero claro, puede ser porque lo rootié, o que en mi ignorancia venía usando un task killer, o algunas de las 200 aplicaciones que ya lleva instaladas… quién sabe. Lo que sí se es que a mis WinMo’s también les instalé bocha de aplicaciones y modificaciones al sistema, y jamás comenzaron a reiniciarse solitos…

Ahora cuenten: ¿Cómo fueron sus primeras experiencias e impresiones con el multitasking de Android? ¿Y qué tal la estabilidad de sus modelos?