Android Bibliothèque d'archives (aar) vs bac standard

Question

J'ai lu des articles sur la nouvelle adoption de Gradle en tant que système de construction standard pour les applications Android. Eh bien, en provenance du développement standard Java dont je dépend habituellement sur jar fichiers afin de construire mon projet. Cependant, il semble que Android a aussi aar paquets, qui sont les équivalent aux fichiers dll sous Windows, comme mentionné ici :

Tout d'abord, vous devez comprendre que la plate-forme Android n'autorise pas les "bibliothèques partagées" au niveau de l'application. Dans les plateformes de langage de programmation "traditionnelles", C, C++, Java, vous l'appelez, avoir ce mécanisme de partage des bibliothèques d’exécution (par exemple, DLL sous Windows, DSO sous Unix, Jar sous JVM, etc.). Sous Android, vous ne pouvez toutefois pas le faire, sauf si vous êtes Google ou un fabricant de combinés (voir la note 1 ci-dessous). En tant que développeur d'applications, cela peut constituer une limitation fondamentale. Les codes de "partage" ou de "réutilisation", à la fois lors de la construction et de l'exécution, constituent une partie très importante de la pratique du génie logiciel. Ceci est plutôt difficile (pas impossible, juste plus difficile) sur Android en raison de la limitation susmentionnée.

Cependant, j'ai quelques doutes sur ce concept. Je veux dire, quand un développeur devrait-il être intéressé, y compris les dépendances aar dans son application? Ces dépendances sont-elles réduites à une version minimale du SDK?

Par exemple, dans un projet, j’accède à un port COM, que j’utilise bibliothèques NDK précompilées. So. Dois-je créer un aar si je veux partager cet utilitaire?

Answer 1

Les fichiers AAR ressemblent davantage à Jars qu'à Dlls pour la raison suivante:

Dlls peut être partagé entre plusieurs applications où AARs et les fichiers jar sont fournis avec votre application.

AARs vs Jars:

La principale différence entre Jar et AAR est que AARs inclut des ressources telles que layouts, drawables etc. Cela facilite beaucoup la création de composants visuels autonomes. Par exemple, si vous avez plusieurs applications utilisant le même écran de connexion, avec Jars, vous pouvez partager des classes, mais pas la mise en page, les styles, etc., vous devez néanmoins les dupliquer. Avec AARs, tout est regroupé dans un paquet soigné.

En conclusion, les AARs sont un grand pas dans la bonne direction.

Note:
Des tentatives similaires ont été faites avec apk-libs mais ils sont maintenant obsolètes car AARs sont bien meilleurs.

Answer 2

La déclaration " La principale différence entre un fichier jar et un fichier AAR réside dans le fait que les fichiers AAR incluent des ressources telles que des mises en page, des éléments dessinables, etc." "ne correspond pas au fichier JAR. spécification et n'est donc pas une vérité. Selon le spécification du fichier JAR :

Le fichier JAR est un format de fichier basé sur le format de fichier Zip populaire et est utilisé pour regrouper de nombreux fichiers en un seul. Un fichier JAR est essentiellement un fichier Zip contenant un répertoire facultatif META-INF.

Comme vous pouvez le constater, aucune limitation de contenu n'empêche d'inclure des ressources telles que des mises en page, des éléments dessinables, etc. dans un fichier JAR. Pour plus de détails, voir l'article 5.3 "Création et chargement" de la spécification Java® Virtual Machine.

Donc, sur la question Android Archive Library (aar) vs jar standard. La réponse dépend de l'outil de construction que vous utilisez.

Si vous utilisez Android Studio en tant qu'outil de construction (respectivement en tant qu'organisateur de projet), vous feriez mieux d'utiliser des fichiers * .aar pour partager des ressources encapsulées entre Android Le format de fichier AAR fait partie de Android) et, comme il est commenté dans les autres commentaires, son interface utilisateur prend en charge le format aar pour les bibliothèques Android.

Mais à part Android Studio, le reste du monde ne sait pas quel est ce fichier aar (artefact). Par exemple, si votre version de Android est basée sur Maven le fichier préféré pour le partage de ressources sera jar car il s'agit de l'artefact de projet Maven Java) natif et il n'y a pas de limitation à ce que le fichier jar standard doit être mis en place. En outre, il expliquer tout format de fichier Maven, inclure aar en utilisant l’amélioration du cycle de vie avec un nouveau composant. Un exemple simple est disponible ici Comment créer un nouveau type de package pour Maven?

Answer 3

La citation dans la question n'a rien de commun avec la réalité actuelle. Bien sûr, il est possible d'utiliser des bibliothèques externes dans Android et de nombreuses bibliothèques sont disponibles. Peut-être voulaient-ils dire que chaque application doit regrouper toutes les bibliothèques dont elle a besoin, mais en réutilisant la bibliothèque au moment de la construction (lien statique) n'est vraiment pas un problème.

.aar diffère de .jar pas plus que .jar diffère de .Zip. Il contient certains concepts sur le type de contenu auquel il faut s’y attendre, mais les deux .jar et .aar contiennent le plus souvent des classes compilées et leurs ressources. .aar spécifie simplement que la bibliothèque est Android spécifique et possède la structure attendue, raisonnable pour ces bibliothèques (ainsi, .jar a également une structure attendue).

La vue selon laquelle .aar est uniquement prise en charge par le studio Android est également obsolète. Ces bibliothèques peuvent être déployées sur Maven Central. Des outils tels que gradle peuvent les référencer à l'aide du suffixe @aar, par exemple:

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

faire référence à this déploiement central Maven.