Android Archive Library (aar) vs jar standard

Ho letto alcuni articoli sulla nuova adozione di Gradle come sistema di generazione standard per le app Android. Bene, provenendo dallo sviluppo Java standard di solito dipendo dai file jar per costruire il mio progetto. Tuttavia sembra che Android abbia anche pacchetti aar , che sono l'equivalente dei file dll in un sistema operativo Windows, come menzionato qui :

Innanzitutto, devi capire che la piattaforma Android non consente "librerie condivise" a livello di applicazione. Nelle piattaforme di linguaggio di programmazione "tradizionali", C, C ++, Java, lo chiami, abbiamo questo meccanismo di condivisione delle librerie di runtime. (Ad esempio, DLL su Windows, DSO su Unix, Jar su JVM, ecc.). Su Android, tuttavia, non puoi farlo, a meno che tu non sia Google o un produttore di telefoni (vedi la nota 1 di seguito). Come sviluppatore di applicazioni, questo può essere un limite fondamentale. La "condivisione" o il "riutilizzo" dei codici, sia in fase di costruzione che in fase di esecuzione, è una parte molto importante della pratica di ingegneria del software. Questo è piuttosto difficile (non impossibile, solo più difficile) su Android a causa della limitazione di cui sopra.

Tuttavia, ho alcuni dubbi su questo concetto. Voglio dire, quando uno sviluppatore dovrebbe essere interessato a includere le dipendenze aar nella sua applicazione? Queste dipendenze sono ridotte a una versione minima dell'SDK?

Ad esempio, in un progetto accedo a una porta COM, per la quale utilizzo librerie .so NDK precompilate . Devo creare un aar se voglio condividere questa utility?

AARi file sono più simili a Jars che a Dlls per il seguente motivo:

Dlli messaggi di posta elettronica possono essere condivisi tra le applicazioni in cui AARi pacchetti sono inseriti nella tua app.

AARs vs Jars:

La differenza principale tra a Jare a AARè che AARincludono risorse come layouts, drawablesecc. Ciò rende molto più semplice la creazione di componenti visivi autonomi. Ad esempio, se disponi di più app che utilizzano la stessa schermata di accesso, con Jars potresti condividere le classi ma non il layout, gli stili, ecc., Devi comunque duplicarle. Con AARs tutto è raggruppato in un unico pacchetto.

In conclusione, AARs è un grande passo nella giusta direzione.

Nota:
tentativi simili sono stati fatti con apk-libs ma ora sono obsoleti in quanto AARs sono molto meglio.

L'affermazione " La differenza principale tra un Jar e un AAR è che gli AAR includono risorse come layout, disegni estraibili ecc. " Non corrisponde alla specifica del file JAR e quindi non è una verità. Secondo le specifiche del file JAR :

Il file JAR è un formato di file basato sul popolare formato di file ZIP e viene utilizzato per aggregare molti file in uno. Un file JAR è essenzialmente un file zip che contiene una directory META-INF opzionale.

Come puoi vedere, non vi è alcuna limitazione del contenuto che proibisce di includere risorse come layout, disegnabili ecc. In un file JAR. Per maggiori dettagli vedere l'articolo 5.3 "Creazione e caricamento" di The Java® Virtual Machine Specification.

Quindi sulla domanda Android Archive Library (aar) vs jar standard. La risposta dipende dallo strumento di compilazione che stai utilizzando.

Se stai usando Android Studio come strumento di compilazione (rispettivamente come organizzatore di progetti), faresti sicuramente meglio a utilizzare i file * .aar per condividere risorse incapsulate tra progetti Android. Il formato di file AAR fa parte della build di Android Studio e come è commentato negli altri commenti qui la sua interfaccia utente supporta il formato aar per le librerie Android.

Ma tranne Android Studio il resto del mondo non sa che cosa è quel file aar (artefatto). Ad esempio, se la tua build Android è basata su Maven, il file preferito per la condivisione delle risorse sarà jar perché è l'artefatto nativo del progetto jav Maven e non ci sono limiti su cosa inserire nel file jar standard. Inoltre, c'è un modo per spiegare a Maven qualsiasi formato di file, includendo aar usando il miglioramento del ciclo di vita con un nuovo componente. Un semplice esempio è disponibile qui Come posso creare un nuovo tipo di imballaggio per Maven?

La citazione nella domanda non ha nulla in comune con la realtà attuale. Naturalmente è possibile utilizzare librerie esterne in Android e ci sono molte librerie disponibili. Forse hanno voluto dire che ogni applicazione deve raggruppare tutte le librerie di cui ha bisogno, ma riutilizzare la libreria al momento della compilazione (collegamento statico) non è davvero un problema.

.aardifferisce da .jarnon più di .jardiverso da .zip. Ha alcuni concetti su quale tipo di contenuto dovrebbe essere previsto lì, ma entrambi .jare .aarmolto spesso contengono classi compilate e risorse. .aarspecifica solo che la libreria è specifica per Android e ha una struttura prevista, ragionevole per tali librerie (beh, .jarha anche una struttura prevista).

Anche la vista secondo cui .aar è supportato solo da Android Studio. Tali librerie possono essere distribuite su Maven Central e strumenti come Gradle possono fare riferimento ad esse utilizzando il suffisso @aar, ad esempio:

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

per fare riferimento a questa distribuzione centrale di Maven.