instalación para dispositivos móviles de Bazel

Informar un problema Ver fuente

Desarrollo iterativo rápido para Android

En esta página, se describe cómo bazel mobile-install hace que el desarrollo iterativo para Android sea mucho más rápido. Se describen los beneficios de este enfoque frente a los desafíos del método tradicional de instalación de apps.

Resumen

Para instalar cambios pequeños en una app para Android muy rápido, haz lo siguiente:

  1. Busca la regla android_binary de la app que quieras instalar.
  2. Inhabilita ProGuard quitando el atributo proguard_specs.
  3. Establece el atributo multidex en native.
  4. Establece el atributo dex_shards en 10.
  5. Conecta tu dispositivo que ejecute ART (no Dalvik) a través de USB y habilita la depuración por USB en él.
  6. Ejecuta bazel mobile-install :your_target. El inicio de la app será un poco más lento de lo habitual.
  7. Edita el código o los recursos de Android.
  8. Ejecuta bazel mobile-install --incremental :your_target.
  9. Disfruta de no tener que esperar mucho.

Estas son algunas opciones de línea de comandos para Bazel que pueden ser útiles:

  • --adb le indica a Bazel qué objeto binario de adb debe usar.
  • Se puede usar --adb_arg para agregar argumentos adicionales a la línea de comandos de adb. Una aplicación útil de esto es seleccionar en qué dispositivo deseas realizar la instalación si tienes varios dispositivos conectados a tu estación de trabajo: bazel mobile-install --adb_arg=-s --adb_arg=<SERIAL> :your_target
  • --start_app inicia la app automáticamente.

Si tienes dudas, consulta el ejemplo o comunícate con nosotros.

Introducción

Uno de los atributos más importantes de la cadena de herramientas de un desarrollador es la velocidad: hay muchas diferencias entre cambiar el código y ver que se ejecuta en un segundo, y tener que esperar minutos, a veces horas, antes de recibir comentarios sobre si los cambios hacen lo que esperas.

Lamentablemente, la cadena de herramientas tradicional de Android para compilar un .apk implica muchos pasos monolíticos y secuenciales, y todos estos deben realizarse para compilar una app para Android. En Google, esperar cinco minutos para compilar un cambio de una sola línea no era inusual en proyectos más grandes, como Google Maps.

bazel mobile-install hace que el desarrollo iterativo para Android sea mucho más rápido mediante una combinación de reducción de cambios, fragmentación de trabajos y manipulación inteligente de los componentes internos de Android, todo sin cambiar el código de tu app.

Problemas con la instalación de apps tradicionales

La compilación de una app para Android tiene algunos problemas, como los siguientes:

  • Conversión a DEX. De forma predeterminada, "dx" se invoca exactamente una vez en la compilación y no sabe cómo volver a usar el trabajo de compilaciones anteriores: vuelve a convertir a DEX todos los métodos, aunque solo se haya cambiado un método.

  • Carga de datos al dispositivo. adb no usa todo el ancho de banda de una conexión USB 2.0. Además, las apps de mayor tamaño pueden tardar mucho tiempo en cargarse. Se sube toda la app, incluso si solo cambiaron partes pequeñas, como un recurso o un solo método, por lo que esto puede ser un gran cuello de botella.

  • Compilación en código nativo. En Android L, se presentó ART, un nuevo tiempo de ejecución de Android, que compila apps con anticipación en lugar de compilarlas justo a tiempo como lo hace Dalvik. Esto hace que las apps sean mucho más rápidas, a costa de un mayor tiempo de instalación. Esta es una buena compensación para los usuarios, ya que, por lo general, instalan una app una vez y la usan muchas veces, pero hace que el desarrollo sea más lento, ya que la app se instala muchas veces y cada versión se ejecuta, como máximo, varias veces.

El enfoque de bazel mobile-install

bazel mobile-install implementa las siguientes mejoras:

  • Conversión a DEX fragmentada. Después de compilar el código Java de la app, Bazel fragmenta los archivos de clase en partes aproximadamente de igual tamaño y, luego, invoca a dx por separado en ellos. dx no se invoca en los fragmentos que no cambiaron desde la última compilación.

  • Transferencia incremental de archivos. Los recursos, los archivos .dex y las bibliotecas nativas de Android se quitan del .apk principal y se almacenan en un directorio independiente de instalación para dispositivos móviles. Esto permite actualizar el código y los recursos de Android de forma independiente sin reinstalar toda la app. Por lo tanto, la transferencia de archivos lleva menos tiempo y solo los archivos .dex que se modificaron se vuelven a compilar en el dispositivo.

  • Carga de partes de la app desde fuera del .apk. Se inserta una pequeña aplicación de stub en el .apk que carga recursos de Android, código Java y código nativo desde el directorio de instalación para dispositivos móviles del dispositivo y, luego, transfiere el control a la app en sí. Todo esto es transparente para la app, excepto en los casos límite que se describen a continuación.

Dex fragmentado

La dex fragmentada es bastante sencilla: una vez que se compilan los archivos .jar, una herramienta los fragmenta en archivos .jar separados que tienen aproximadamente el mismo tamaño y, luego, invoca a dx en los que se modificaron desde la compilación anterior. La lógica que determina qué fragmentos a DEX no es específica de Android: solo usa el algoritmo general de reducción de cambios de Bazel.

La primera versión del algoritmo de fragmentación simplemente ordenó alfabéticamente los archivos .class y, luego, cortó la lista en partes de igual tamaño, pero esto resultó ser poco óptimo: si se agregaba o quitaba una clase (incluso una anidada o anónima), todas las clases cambiarían alfabéticamente después de ella, lo que generaría dex esos fragmentos nuevamente. Por eso, se decidió fragmentar paquetes de Java, en lugar de clases individuales. Por supuesto, esto aún genera un proceso de DEX de muchos fragmentos si se agrega o quita un paquete nuevo, pero eso es mucho menos frecuente que agregar o quitar una sola clase.

El archivo BUILD controla la cantidad de fragmentos (con el atributo android_binary.dex_shards). En un mundo ideal, Bazel determinaría automáticamente cuántos fragmentos son los mejores, pero en la actualidad debe conocer el conjunto de acciones (por ejemplo, comandos que se ejecutarán durante la compilación) antes de ejecutar cualquiera de ellos, por lo que no puede determinar la cantidad óptima de fragmentos porque no sabe cuántas clases de Java habrá en la app. Por lo general, más lento será el inicio y la instalación será más lenta, ya que, en general, el inicio de la app será más lento, pero la instalación será más lenta. Por lo general, el punto ideal es entre 10 y 50 gemas.

Transferencia de archivos incremental

Después de compilar la app, el siguiente paso es instalarla, preferentemente con el menor esfuerzo posible. La instalación consiste en los siguientes pasos:

  1. Cómo instalar el .apk (generalmente con adb install)
  2. Cómo subir los archivos .dex, los recursos de Android y las bibliotecas nativas en el directorio mobile-install

No hay mucha incrementalidad en el primer paso: la app está instalada o no. Actualmente, Bazel depende del usuario para indicar si debe realizar este paso con la opción de línea de comandos --incremental, ya que no puede determinar en todos los casos si es necesario.

En el segundo paso, se comparan los archivos de la app de la compilación con un archivo de manifiesto en el dispositivo que enumera qué archivos de la app están en el dispositivo y sus sumas de verificación. Se subirán archivos nuevos al dispositivo, se actualizarán los archivos que hayan cambiado y se borrarán del dispositivo los archivos que se hayan quitado. Si el manifiesto no está presente, se considerará que todos los archivos deben subirse.

Ten en cuenta que es posible engañar al algoritmo de instalación incremental cambiando un archivo en el dispositivo, pero no su suma de verificación en el manifiesto. Esto podría haberse protegido contra el cálculo de la suma de verificación de los archivos en el dispositivo, pero se consideró que no valía la pena el aumento en el tiempo de instalación.

La aplicación Stub

En la aplicación de stub, se produce la magia de cargar los dex, el código nativo y los recursos de Android desde el directorio mobile-install integrado en el dispositivo.

La carga real se implementa mediante la subclasificación de BaseDexClassLoader y es una técnica razonablemente bien documentada. Esto sucede antes de que se carguen las clases de la app, de modo que cualquier clase de aplicación que se encuentre en el APK se pueda colocar en el directorio mobile-install del dispositivo para que se puedan actualizar sin adb install.

Esto debe suceder antes de que se carguen las clases de la app, por lo que no es necesario que haya ninguna clase de aplicación en el .apk, lo que implicaría que los cambios en esas clases requerirían una reinstalación completa.

Esto se logra reemplazando la clase Application especificada en AndroidManifest.xml por la aplicación de stub. Esta toma el control del inicio de la app y ajusta el cargador de clases y el administrador de recursos de manera apropiada en el primer momento (su constructor) utilizando el reflejo de Java sobre los componentes internos del framework de Android.

Otra cosa que hace la aplicación de stub es copiar las bibliotecas nativas instaladas por la instalación para dispositivos móviles en otra ubicación. Esto es necesario porque el vinculador dinámico necesita que se configure el bit X en los archivos, lo cual no es posible para cualquier ubicación a la que pueda acceder un adb que no sea raíz.

Una vez hecho todo esto, la aplicación de stub crea una instancia de la clase Application real y cambia todas las referencias a sí misma por la aplicación real dentro del framework de Android.

Resultados

Rendimiento

En general, bazel mobile-install acelera de 4 a 10 veces la compilación y la instalación de apps grandes después de un pequeño cambio.

Se calcularon las siguientes cifras para algunos productos de Google:

Esto, por supuesto, depende de la naturaleza del cambio: la recompilación después de cambiar una biblioteca base lleva más tiempo.

Limitaciones

Los trucos que reproduce la aplicación auxiliar no funcionan en todos los casos. Los siguientes casos destacan los casos en los que no funciona según lo esperado:

  • Cuando se transmite Context a la clase Application en ContentProvider#onCreate(). Se llama a este método durante el inicio de la aplicación antes de que podamos reemplazar la instancia de la clase Application. Por lo tanto, ContentProvider igualmente hará referencia a la aplicación de stub en lugar de a la real. Podría decirse que este no es un error, ya que no se supone que reduzcas Context de esta forma, pero parece que esto sucede en algunas apps de Google.

  • Los recursos que instala bazel mobile-install solo están disponibles desde la app. Si otras apps acceden a los recursos a través de PackageManager#getApplicationResources(), estos recursos serán de la última instalación no incremental.

  • Dispositivos que no ejecutan ART. Si bien la aplicación stub funciona bien en Froyo y versiones posteriores, Dalvik tiene un error que hace pensar que la app es incorrecta si su código se distribuye en varios archivos .dex en ciertos casos, por ejemplo, cuando las anotaciones de Java se usan de manera específica. Siempre que tu app no genere señales de estos errores, también debería funcionar con Dalvik (no obstante, ten en cuenta que la compatibilidad con versiones anteriores de Android no es nuestro enfoque preciso).