Android Archive Library (aar) vs jar estándar

He estado leyendo algunos artículos sobre la nueva adopción de Gradle como el sistema de comstackción estándar para las aplicaciones de Android. Bueno, viniendo del desarrollo estándar de Java, generalmente dependo de archivos jar para construir mi proyecto. Sin embargo, parece que Android también tiene paquetes aar , que son el equivalente a los archivos dll en un sistema operativo Windows, como se menciona aquí :

En primer lugar, debe tener en cuenta que la plataforma Android no permite “bibliotecas compartidas” a nivel de aplicación. En las plataformas de lenguaje de progtwigción “tradicional”, C, C ++, Java, lo que sea, tenemos este mecanismo de compartir bibliotecas de tiempo de ejecución. (Por ejemplo, DLL en Windows, DSO en Unix, Jar en JVM, etc.). En Android, sin embargo, no puede hacer eso, a menos que sea Google o un fabricante de dispositivos (consulte la Nota 1 a continuación). Como desarrollador de aplicaciones, esto puede ser una limitación fundamental. Los códigos de “uso compartido” o “reutilización”, tanto en tiempo de comstackción como en tiempo de ejecución, es una parte muy importante de la práctica de ingeniería de software. Esto es bastante difícil (no imposible, simplemente más difícil) en Android debido a la limitación mencionada anteriormente.

Sin embargo, tengo algunas dudas sobre este concepto. Quiero decir, ¿cuándo debería interesar a un desarrollador incluir dependencias aar en su aplicación? ¿Están estas dependencias ajustadas a una versión mínima del SDK?

Por ejemplo, en un proyecto, accedo a un puerto COM, que utilizo NDK precomstackdas .so libraries for. ¿Tengo que crear un aar si quiero compartir esta utilidad?

AAR archivos AAR son más similares a Jar s que a Dll s por la siguiente razón:

Dll se pueden compartir en todas las aplicaciones, ya que los paquetes y los archivos AAR incluyen con su aplicación.

AAR s vs Jar s:

La principal diferencia entre un Jar y un AAR es que los AAR incluyen recursos tales como layouts, drawables etc., lo que facilita mucho la creación de componentes visuales autónomos. Por ejemplo, si tienes varias aplicaciones que usan la misma pantalla de inicio de sesión, con Jar s puedes compartir clases pero no el diseño, los estilos, etc., pero aún así tienes que duplicarlos. Con AAR s todo está incluido en un paquete ordenado.

En conclusión, los AAR son un gran paso en la dirección correcta.

Nota:
Se hicieron bashs similares con apk-lib s pero ahora están obsoletos ya que los AAR son mucho mejores.

La afirmación ” La principal diferencia entre un Jar y un AAR es que los AAR incluyen recursos tales como diseños, etc. ” no se corresponde con la especificación del archivo JAR y, por lo tanto, no es verdad. Según la especificación del archivo JAR :

El archivo JAR es un formato de archivo basado en el popular formato de archivo ZIP y se utiliza para agregar muchos archivos en uno. Un archivo JAR es esencialmente un archivo zip que contiene un directorio META-INF opcional.

Como puede ver, no existe una limitación de contenido que prohíba incluir recursos como diseños, etc. en un archivo JAR. Para obtener más detalles, consulte el artículo 5.3 “Creación y carga” de la especificación de máquina virtual Java®.

Entonces, en la pregunta Android Archive Library (aar) vs jar estándar. La respuesta depende de la herramienta de comstackción que estés usando.

Si está utilizando Android Studio como una herramienta de comstackción (respectivamente como organizador de proyectos), sería mejor utilizar archivos * .aar para compartir recursos encapsulados entre proyectos de Android. El formato de archivo AAR forma parte de la comstackción de Android Studio y, como se comenta en los otros comentarios aquí, su interfaz de usuario admite el formato aar para las bibliotecas de Android.

Pero a excepción de Android Studio, el rest del mundo no sabe qué es ese archivo aar (artefacto). Por ejemplo, si su comstackción de Android se basa en Maven, el archivo preferido para compartir recursos será jar porque ese es el artefacto del proyecto Maven nativo de Java y no hay ninguna limitación acerca de qué poner en el archivo jar estándar. Además, hay una manera de explicar a Maven cualquier formato de archivo, incluido el uso de la mejora del ciclo de vida con un nuevo componente. Un ejemplo simple está disponible aquí ¿Cómo creo un nuevo tipo de empaque para Maven?

La cita en la pregunta no tiene nada en común con la realidad actual. Por supuesto, es posible usar bibliotecas externas en Android y hay muchas bibliotecas disponibles. Tal vez querían decir que cada aplicación debe agrupar todas las bibliotecas que necesita, pero reutilizar la biblioteca en el momento de comstackción (enlace estático) realmente no es un problema.

.aar difiere de .jar no más que .jar difiere de .zip . Tiene ciertos conceptos sobre qué tipo de contenido se debe esperar allí, pero tanto .jar como .aar mayor frecuencia contienen clases comstackdas y recursos. .aar solo especifica que la biblioteca es específica de Android y tiene cierta estructura esperada, razonable para tales bibliotecas (bueno, .jar también tiene cierta estructura esperada).

La vista de que .aar solo es compatible con Android studio también está en desuso. Dichas bibliotecas se pueden implementar en Maven Central, y herramientas como gradle pueden hacer referencia a ellas usando @aar sufijo, por ejemplo:

 dependencies { compile ('io.github.andviane:uncover:2.0.1@aar') .. } 

para hacer referencia a este despliegue central de Maven.