javaHispano - Android

Uno de los aspectos de mayor relevancia en Android L es que utilizará una nueva máquina virtual llamada ART (Android RunTime), que utiliza compilación previa (ahead of time) a diferencia de la compilación “justo a tiempo” que utiliza la máquina virtual Dalvik. El resultado será que con ART las apps tomarán más tiempo en instalarse (ya que al instalar en realidad se están compilando binarios con código máquina para la arquitectura de procesador específica del dispositivo) y ocuparán un mayor espacio en disco (alrededor de 20%), pero esto permitirá que tengan un mucho mejor desempeño y brinden una experiencia más fluida ya que el procesador no estará dedicando a compilar pedazos de la app durante la ejecución, tal como sucede en Dalvik.

La buena noticia para los desarrolladores es que ART es compatible con el bytecode DEX de Dalvik, así que en teoría las apps no necesitan ajustes. Es decir que un apk que actualmente funciona para Dalvik también debe funcionar en ART.

Sin embargo, hay algunos casos de excepción, donde código o prácticas de programación que eran aceptadas por Dalvik, no serán aceptadas por ART. Adicionalmente, hay otros casos donde a pesar de que cierto código pueda funcionar en ART, tal vez sea mejor implementarlo de otra forma para optimizar su ejecución.

A continuación listo los principales ajustes que debes hacer al código de tus apps para optimizarlo para ART:

Puedes verificar si tu app se está ejecutando en ART checando el valor de la propiedad de sistema java.vm.version. Si es “2.0.0” entonces estás en ART.
Si utilizas JNI para ejecutar código C/C++, depura tu código usando el modo CheckJNI. Encontrarás que ART es más estricto con JNI, pero también te da mayor información sobre los errores.
Actualiza a la versión más reciente de tus herramientas. ART es más estricto con la validación de bytecode que Dalvik. Si utilizas herramientas de post-procesamiento (por ejemplo para ofuscar código), es posible que ART rechace ese bytecode. Los proveedores de herramientas están trabajando para que actualizar sus productos y que sean compatibles con ART, así que actualizarlos te ayudará.
Elimina las llamadas a System.gc(). Actualmente es una práctica común invocar explícitamente al recolector de basura por medio de System.gc() para evitar que el sistema se quede sin memoria (GC_FOR_ALLOC). Con ART esto ya no debe ser necesario, así que tu código tendrá mejor desempeño si no invocas explícitamente al recolector de basura.
No guardes punteros a los datos de instancias de objetos. El nuevo recolector de basura mueve objetos a su antojo para mejorar el manejo de memoria, así que si haces llamadas tipo Get y Release a ArrayElements() podría resultar en corrupción de memoria.
No intentes ver los campos de Object. Los campos de la clase Object ahora son privados. Si utilizas reflexión para ver campos de tu jerarquía de clases, no llegues hasta el nivel de Object. Por ejemplo, si al serializar y deserializar objetos inspeccionas su jerarquía de clases, detente cuando Class.getSuperclass()==java.lang.Object.class (no continúes hasta que regrese null).
Aprovecha las mejoras en ART para depuración y manejo de errores. ART genera un mensaje de error cuando encuentre código que intente reemplazar métodos privados de un paquete (Dalvik aceptaba esto por error). GetFieldID() y GetStaticFieldID() ya arrojan un NoSuchFieldError (en lugar de null) al no encontrar un campo. De manera similar, GetMethodID() y GetStaticMethodID() ya arrojan un NoSuchMethodError. Otros errores que son detectados por ART incluyen flujo de control inválido, listas de parámetros con longitud 0, inconsistencias en monitorenter/monitorexit.

Referencias: