Desarrollo y programación

¿Es difícil adaptar una aplicación a ART?

3 noviembre, 2014 09:05

Android 5.0 Lollipop está a la vuelta de la esquina de forma oficial, dejando próximamente atrás su versión Preview. Y una de las mayores novedades, que ya fue introducida en Android KitKat de forma opcional, es que ART (Android RunTime) será la única máquina virtual de Android Lollipop.

Este cambio de máquina virtual se hizo con la idea de optimizar rendimiento, el cual ya se estaba viendo en parte comprometido con su antecesora, Dalvik.

ART vs Dalvik

Esta nueva máquina virtual, ART, utiliza compilación previa en lugar de la compilación justo a tiempo de Dalvik. Al reducir la cantidad global de compilación que necesita ser realizado a través del funcionamiento de una aplicación, el uso del procesador de un dispositivo móvil se reduce y se mejora la duración de la batería.

Esto también se traduce en que, con ART, las apps tardarán más tiempo en instalarse (ya que en ese momento se están compilando binarios con código máquina) y ocuparán más espacio en la memoria, concretamente en torno a un 20%.

Sin embargo, esto nos permitirá un mayor desempeño y una experiencia más fluída, pues estamos ahorrando carga de trabajo al procesador.

Adaptando el código

Si bien es cierto que ART es compatible con el bytecode DEX de Dalvik, nos podemos encontrar algunas excepciones donde algunas prácticas de programación aceptadas por Dalvik ya no serán válidas con ART, o simplemente que puedan ser optimizadas. Para ello, os recomendamos los siguientes ajustes en vuestro código:

  • Verificar si se está ejecutando en ART: Para ello verificaremos si propiedad del sistema java.vm.version tiene un valor 2.0.0
  • ART es más estricto con JNI: Si utilizamos JNI para código C/C++, si depuramos con CheckJNI tendremos mucha más información sobre errores.
  • Actualizar a las últimas versiones de las herramientas, pues aún podemos llegar a tener alguna herramienta que no haya sido actualizada con el soporte para ART
  • Evitar llamas explícitas al recolector de basura: Ahora, con ART, la llamada System.gc() debemos evitarla, pues la propia máquina tendrá mejor desempeño al no invocarlo
  • No guardar punteros a los datos de instancias de objetos
  • Los campos de la clase Object ahora son privados
  • Hacer uso de las mejoras en ART para depuración y manejo de errores, tales como el flujo de control inválido o listas de parámetros con longitud 0.

Preparados para el cambio

A pesar de todo, no debemos preocuparnos por la muerte definitiva de Dalvik, ya que parece que se están preocupando de que el cambio no sea un quebradero de cabeza para los programadores.

Aunque a pesar de ello, es cierto que lo ideal es que tengamos en cuenta este tipo de sugerencias para evitar cualquier tipo de problema y, sobre todo, sepamos aprovechar todas las ventajas de ART. ¿Estáis preparados para el cambio?

Via JavaHispano