为什么我要将gradle依赖包含为`@ aar`

Question

为什么（或不应该）我将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'
}

Answer 1

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

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

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

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

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

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

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

Answer 2

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

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

对于与该情况相关的组ID /工件ID可能存在多个工件的情况， @语法表示您需要此类工件。

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

在Android Studio的情况下，我的理解是，如果您没有另外指定，它将首先查找AAR工件，然后查找JAR。 我的理解是Maven for Android会反过来寻找JAR，然后是AAR。

因此，如果存在默认工件分辨率不符合您自己喜欢的库，则可以添加@后缀并将分辨率强制为您想要的分辨率。 但是，通常情况下，即使没有它，该工具也会做正确的事情。

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