Biblioteka archiwum systemu Android (aar) w porównaniu ze standardowym plikiem jar

Czytałem artykuły o nowym zastosowaniu Gradle jako standardowego systemu kompilacji dla aplikacji na Androida. Cóż, wychodząc ze standardowego programowania w Javie, zwykle polegam na plikach jar , aby zbudować mój projekt. Wygląda jednak na to, że Android ma również pakiety aar , które są odpowiednikiem plików dll w systemie operacyjnym Windows, jak wspomniano tutaj :

Po pierwsze, musisz zdać sobie sprawę, że platforma Android nie zezwala na „biblioteki współdzielone” na poziomie aplikacji. W „tradycyjnych” platformach języków programowania, C, C ++, Java, jak to nazwałeś, mamy ten mechanizm współdzielenia bibliotek wykonawczych. (Np. DLL w systemie Windows, DSO w systemie Unix, Jar w JVM itp.). Jednak na Androidzie nie możesz tego zrobić, chyba że jesteś Google lub producentem telefonu (patrz przypis 1 poniżej). Dla twórców aplikacji może to być fundamentalne ograniczenie. „Udostępnianie” lub „ponowne wykorzystywanie” kodów, zarówno w czasie tworzenia, jak i wykonywania, jest bardzo ważną częścią praktyki inżynierii oprogramowania. Jest to dość trudne (nie niemożliwe, po prostu trudniejsze) na Androidzie ze względu na wspomniane ograniczenie.

Mam jednak wątpliwości co do tej koncepcji. Chodzi mi o to, kiedy programista powinien być zainteresowany włączeniem zależności aar do swojej aplikacji? Czy te zależności są zaostrzone do jakiejś minimalnej wersji zestawu SDK?

Na przykład w jednym projekcie mam dostęp do portu COM, do którego używam prekompilowanych bibliotek .so NDK . Czy muszę tworzyć AAR, jeśli chcę udostępniać to narzędzie?

AARpliki są bardziej podobne do Jars niż do Dlls z następującego powodu:

DllPliki s mogą być współużytkowane w aplikacjach, w których pliki AARs i jars są spakowane z aplikacją.

AARs vs Jars:

Główną różnicą między a Jari a AARjest to, że AARs obejmują zasoby, takie jak layouts, drawablesitp. To znacznie ułatwia tworzenie niezależnych komponentów wizualnych. Na przykład, jeśli masz wiele aplikacji, które używają tego samego ekranu logowania, z Jars możesz udostępniać klasy, ale nie możesz udostępniać układu, stylów itp., Nadal musiałeś je powielić. Ze AARs wszystko jest spakowane w jednym estetycznym opakowaniu.

Podsumowując, AARs to duży krok we właściwym kierunku.

Uwaga:
Podjęto podobne próby z apk-libs, ale są one teraz przestarzałe, ponieważ AARs są znacznie lepsze.

Stwierdzenie „ Główną różnicą między JAR a AAR jest to, że AAR zawierają zasoby, takie jak układy, elementy do rysowania itp. ” Nie odpowiada specyfikacji pliku JAR i dlatego nie jest prawdą. Zgodnie ze specyfikacją pliku JAR :

Plik JAR to format pliku oparty na popularnym formacie pliku ZIP i służy do agregowania wielu plików w jeden. Plik JAR to zasadniczo plik zip, który zawiera opcjonalny katalog META-INF.

Jak widać, nie ma ograniczenia zawartości, które zabrania umieszczania zasobów, takich jak układy, elementy do rysowania itp. W pliku JAR. Więcej informacji można znaleźć w artykule 5.3 „Tworzenie i ładowanie” specyfikacji wirtualnej maszyny Java®.

A więc w kwestii biblioteki archiwum systemu Android (aar) w porównaniu ze standardowym plikiem jar. Odpowiedź zależy od używanego narzędzia do kompilacji.

Jeśli używasz Android Studio jako narzędzia do kompilacji (odpowiednio jako organizatora projektów), zdecydowanie lepiej użyj plików * .aar do udostępniania zamkniętych zasobów między projektami Androida. Format pliku AAR jest częścią kompilacji Android Studio i, jak to zostało skomentowane w innych komentarzach, jego interfejs użytkownika obsługuje format aar dla bibliotek systemu Android.

Ale poza Androidem Studio reszta świata nie wie, co to za plik aar (artefakt). Na przykład, jeśli Twoja kompilacja systemu Android jest oparta na Maven, preferowanym plikiem do udostępniania zasobów będzie jar, ponieważ jest to natywny artefakt projektu Java Maven i nie ma ograniczeń co do tego, co należy umieścić w standardowym pliku jar. Ponadto istnieje sposób na wyjaśnienie Mavena dowolnego formatu pliku, w tym aar, używając ulepszenia cyklu życia za pomocą nowego komponentu. Prosty przykład jest dostępny tutaj. Jak utworzyć nowy typ opakowania dla Maven?

Cytat w pytaniu nie ma nic wspólnego z obecną rzeczywistością. Oczywiście możliwe jest korzystanie z zewnętrznych bibliotek w systemie Android i dostępnych jest wiele bibliotek. Być może chcieli powiedzieć, że każda aplikacja musi zawierać wszystkie potrzebne biblioteki, ale ponowne użycie biblioteki w czasie kompilacji (łączenie statyczne) naprawdę nie stanowi problemu.

.aarróżni się od .jarnie więcej niż .jarróżni się od .zip. Ma pewne koncepcje, na jakich rodzajach treści należy się tam spodziewać, ale oba .jari .aarnajczęściej zawierają skompilowane klasy i zasoby. .aarokreśla tylko, że biblioteka jest specyficzna dla Androida i ma pewną oczekiwaną strukturę, rozsądną dla takich bibliotek (cóż, .jarma również pewną oczekiwaną strukturę).

Pogląd, że .aar jest obsługiwany tylko przez Android Studio, również jest przestarzały. Takie biblioteki można wdrożyć w Maven Central, a narzędzia takie jak gradle mogą odwoływać się do nich za pomocą przyrostka @aar, na przykład:

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

aby odwołać się do tego centralnego wdrożenia Maven.

Główną różnicą jest to, że aar jest podzielony wewnątrz Androida na słoik.

Jeśli Twoja aplikacja będzie używana tylko w aplikacji użytkownika tylko w Android Studio, preferowany jest aar.

Jeśli planujesz komunikację aplikacji ze skompilowanym plikiem jar lib.so w języku c / c ++, jest to preferowane rozwiązanie.

Używanie słoika i aar w oparciu o wymagania aar działa łatwo, słoik zapewnia większą elastyczność.

To jest moja wiedza do Androida 5 Lollipop. Nowa wersja, której nie znam.