Android Archive Library（aar）と標準jar

Androidアプリの標準ビルドシステムとしてGradleを新たに採用した記事をいくつか読んでいます。まあ、標準的なJava開発から来ているので、プロジェクトをビルドするためにjarファイルに依存しています。ただし、Androidにはaarパッケージもあるようです。これは、ここで説明するように、Windows OSのdllファイルに相当します。

まず、Androidプラットフォームはアプリケーションレベルの「共有ライブラリ」を許可しないことを理解する必要があります。「従来の」プログラミング言語プラットフォームであるC、C ++、Javaに名前を付けると、ランタイムライブラリを共有するこのメカニズムがあります。（たとえば、WindowsのDLL、UnixのDSO、JVMのJARなど）。ただし、Googleまたは携帯電話メーカーでない限り、Androidではこれを行うことはできません（下の脚注1を参照）。アプリケーション開発者にとって、これは基本的な制限となる可能性があります。ビルド時と実行時の両方での「共有」または「再利用」コードは、ソフトウェアエンジニアリング業務の非常に重要な部分です。前述の制限があるため、Androidではこれはかなり困難です（不可能ではなく、さらに困難です）。

しかし、私はこの概念についていくつかの疑問を持っています。つまり、アプリケーションにaar依存関係を含めることに開発者はいつ関心を持つべきですか？この依存関係は、いくつかのSDK最小バージョンに強化されていますか？

たとえば、あるプロジェクトでCOMポートにアクセスします。このポートには、NDKのプリコンパイルされた .soライブラリを使用します。このユーティリティを共有する場合、aarを作成する必要がありますか？

AAR次の理由により、ファイルはJarsよりsに似てDllいます。

Dlls AARとjarがアプリにパッケージ化されているため、sはアプリケーション間で共有できます。

AARs対Jars：

a Jarとa の主な違いAARは、AARsにlayouts, drawablesetcなどのリソースが含まれていることです。これにより、自己完結型のビジュアルコンポーネントの作成がはるかに簡単になります。たとえば、同じログイン画面を使用する複数のアプリがあり、Jars を使用してクラスを共有できても、レイアウトやスタイルなどは共有できない場合でも、それらを複製する必要がありました。AARsのすべてが1つのきちんとしたパッケージにバンドルされています。

結論として、AARsは正しい方向への大きな一歩です。

注：
同様の試みがapk-libsでも行われましたが、sのAAR方がはるかに優れているため、現在は使用されていません。

「JarとAARの主な違いは、AARにはレイアウトやドローアブルなどのリソースが含まれていることです。」という記述は JARファイルの仕様に対応していないため、真実ではありません。JARファイルの仕様によると：

JARファイルは、一般的なZIPファイル形式に基づくファイル形式であり、多数のファイルを1つに集約するために使用されます。JARファイルは基本的に、オプションのMETA-INFディレクトリを含むzipファイルです。

ご覧のとおり、JARファイルにレイアウトやドローアブルなどのリソースを含めることを禁止するコンテンツ制限はありません。詳細については、Java®仮想マシン仕様の記事5.3「作成とロード」を参照してください。

したがって、Androidアーカイブライブラリ（aar）と標準jarの比較について質問します。答えは、使用しているビルドツールによって異なります。

Android Studioをビルドツールとして（それぞれプロジェクトオーガナイザーとして）使用している場合は、*。aarファイルを使用して、カプセル化されたリソースをAndroidプロジェクト間で共有することをお勧めします。AARファイル形式はAndroid Studioビルドの一部であり、他のコメントでコメントされているように、そのユーザーインターフェイスはAndroidライブラリのaar形式をサポートしています。

しかし、Android Studioを除いて、他の国々はそのaarファイル（アーティファクト）が何であるかを知りません。たとえば、AndroidビルドがMavenに基づいている場合、リソース共有の優先ファイルはjarになります。これは、これがネイティブのMaven Javaプロジェクトアーティファクトであり、標準のjarファイルに何を配置するかについての制限がないためです。さらに、Mavenを任意のファイル形式で説明し、新しいコンポーネントでライフサイクル拡張を使用してaarを含める方法があります。簡単な例がこちらにありますMavenの新しいパッケージタイプを作成するにはどうすればよいですか？

問題の引用は、現在の現実と共通するものは何もありません。もちろん、Androidで外部ライブラリを使用することは可能であり、利用可能な多くのライブラリがあります。おそらく、各アプリケーションは必要なすべてのライブラリをバンドルする必要があると言いたかったのですが、ビルド時にライブラリを再利用すること（静的リンク）は本当に問題ではありません。

.aar異なるの.jarを超えない.jarと相違.zip。そこにはどのような種類のコンテンツが期待されるかについて一定の概念がありますが、両方.jarと.aarほとんどの場合、コンパイルされたクラスとそれらのリソースが含まれています。.aarライブラリがAndroid固有であり、予想される構造があり、そのようなライブラリに適していることを指定しているだけです（.jar予想される構造もいくつかあります）。

.aarはAndroidスタジオでのみサポートされているという見方も廃止されました。このようなライブラリはMaven Centralにデプロイでき、gradleなどのツールは@aarサフィックスを使用してそれらを参照できます。たとえば、次のようになります。

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

この Maven中央デプロイメントを参照します。