为什么我应该将 gradle 依赖项包含在“@aar”中

android java gradle dex

2022-09-03 09:23:35

为什么我应该（或不应该）包括一个 gradle 依赖项作为，@aar

如果有的话，有什么好处/缺点？

如您所见，我在下面支持它的库中添加了@aar。但是在这样做之前，一切似乎都有效...

dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])
    compile 'com.android.support:appcompat-v7:22.1.1'
    compile 'com.google.android.gms:play-services-maps:7.3.+'
    compile 'com.google.guava:guava:18.0'
    compile 'com.octo.android.robospice:robospice-spring-android:1.4.14'
    compile 'org.codehaus.jackson:jackson-mapper-asl:1.9.13'
    compile 'com.mcxiaoke.volley:library-aar:1.0.0@aar'
    compile 'de.psdev.licensesdialog:licensesdialog:1.7.0@aar'
}

答案 1

库可以以多种格式上传，大多数情况下您将使用或。.jar.aar

如果未指定后缀，则将以默认格式（如果不是由其作者定义，则由其定义）下载库及其所有依赖项。@.jar

compile 'com.android.support:appcompat-v7:22.1.1'

指定后缀时，强制以指定的格式下载库（可能存在，也可能不存在）。这很有用，例如，当作者忘记指定库是一个并且maven（或gradle，不确定）将其视为默认值时。指定后缀后缀后，将不再下载此库的依赖项，因此您必须手动确保。@.aar.jar@

compile 'com.android.support:appcompat-v7:22.1.1@aar'
compile 'com.android.support:support-v4:22.1.1@jar'

要确保在指定后缀时下载库的完整依赖项树，必须按以下方式编写它：@

compile ('com.android.support:appcompat-v7:22.1.1@aar') {
    transitive = true
}

答案 2

TL;DR：忽略后缀，你大部分时间都会很好，如果不是一直都很好。@

以此作为序幕，以下是我对正在发生的事情的理解......

该语法指示您需要此类型的项目，以防该组 ID/项目 ID 有多个与该情况相关的项目。@

例如，一个Android库项目自然会编译成一个AAR，所以这将是将要分发的典型工件。但是，如果库项目实际上并没有使用资源，它也可以编译为 JAR，因此在 AAR 不使用的情况下可用。库作者可以将 AAR 和 JAR 作为同一组 ID/工件 ID 的单独工件类型进行分发，因此工具可以获取任何合适的工件类型。未提供后缀的工具将选择一个，但如果您提供后缀，则该工具应遵守您的要求。@

就Android Studio而言，我的理解是，如果您不另行指定，它将首先查找AAR工件，然后查找JAR。我的理解是，Android的Maven会反其道而行之，首先寻找一个JAR，然后是一个AAR。

因此，如果某个库的默认工件分辨率不符合您的喜好，则可以添加后缀并将分辨率强制为所需的分辨率。但是，通常，即使没有工具，该工具也会做正确的事情。@

拥有后缀会是一个问题，如果你要求一些不存在的东西。例如，将不起作用，因为该工件仅作为 AAR 提供 - 当它尝试下载依赖项时，这应该会失败。@compile 'com.android.support:appcompat-v7:22.1.1@jar'