Android Gradle 依赖配置：implementation & api

背景：
Android Gradle plugin 3.0开始（对应Gradle版本 4.1及以上），原有的依赖配置类型compile已经被废弃，开始使用implementation、api和annotationProcessor类型分别替代。对应的，这三种替代配置类型针对具体的使用场景，具有不同的依赖行为。其中，implementation和api依赖又相对最为常用，对其具体含义也需要理解清，在实际项目中选择依赖配置时，也才能游刃有余。

首先看一下Android官方文档中关于依赖配置的详细介绍：Add build dependencies


为陈述方便且不容易理解歧义，先划分出如下几个术语。

  • 被引入的依赖模块，简称 依赖模块
  • 引入了被依赖模块的当前模块，简称 当前模块
  • 依赖了当前模块的上层模块，简称 其他上层模块

于是，官方文档中的描述翻译后对应的含义为：
1，implementation：
此依赖配置，使Gradle意识到，当前模块引入的依赖模块，在编译期间对其他上层模块不可见，仅在运行时对其他上层模块可见。这将会加快多模块依赖的项目整体编译速度，因为通过implementation引入的依赖模块，如果依赖模块内部有进行过Api的改动，由于其对其他上层模块不可见，因此只需重新编译依赖模块自身以及使用到此改动的Api的当前模块即可。

2, api：
等同于原有的compile，此依赖配置，使Gradle意识到，其引入的依赖模块，无论在编译期还是在运行时，都对其他上层模块可见，即通过api配置引入的依赖模块，在依赖关系上具有传递性。这将会使得其他上层模块可以直接使用依赖模块的Api，但这同时意味着一旦依赖模块发生Api的改动，将导致所有已经使用了此依赖模块改动了的Api的上层模块都需要重新执行编译。因此，一般会加大整个项目的编译时间，如非必要，一般建议优先使用implementation依赖配置。

如此描述一般情况下还不是很容易理解。描述中最关键的几个词有：可见性，依赖传递，编译期，运行时，和 使Gradle意识到。

下面先通过一个具体的例子感性认识下implementation 和 api 两者的区别。
新建一个项目HappyCorn,具体项目结构如下：

Root project ‘HappyCorn‘
+--- Project ‘:app‘
+--- Project ‘:LibA‘
+--- Project ‘:LibB‘
+--- Project ‘:LibC‘
\--- Project ‘:LibD‘
复制代码

其中，app为application类型，LibA、LibB、LibC、LibD分别是四个library类型。
LibA中新建如下类：

package com.happycorn.librarya;

public class LibAClass {
    public static String getName() {
        return "Library A";
    }
}
复制代码

同样的，LibB中：

package com.happycorn.libraryb;

public class LibBClass {
    public static String getName() {
        return "Library B";
    }
}
复制代码

LibC中：

package com.happycorn.libraryc;

public class LibCClass {
    public static String getName() {
        OkHttpClient okHttpClient = new OkHttpClient();
        return "Library C";
    }
}
复制代码

LibD中：

package com.happycorn.libraryd;

public class LibDClass {
    public static String getName() {
        return "Library D";
    }
}
复制代码

进行依赖配置，使得项目整体依赖类似于树形结构：

对应的依赖配置分别如下:

  • :app依赖（implementation或api）:LibA和:LibB
  • :LibA implementation 依赖:LibC
  • :LibB api 依赖:LibD

执行graldew命令，查看:app对那些进行了依赖：

./gradlew :app::dependencies
复制代码

输出结果为(单元测试等不太相干信息先去掉)：

...
debugCompileClasspath - Resolved configuration for compilation for variant: debug
+--- project :LibA
\--- project :LibB
     \--- project :LibD

debugRuntimeClasspath - Resolved configuration for runtime for variant: debug
+--- project :LibA
|    \--- project :LibC
\--- project :LibB
     \--- project :LibD

releaseCompileClasspath - Resolved configuration for compilation for variant: release
+--- project :LibA
\--- project :LibB
     \--- project :LibD

releaseRuntimeClasspath - Resolved configuration for runtime for variant: release
+--- project :LibA
|    \--- project :LibC
\--- project :LibB
     \--- project :LibD
...
复制代码

从输出信息中可以看出，无论是debug还是release变体，在编译时与运行时所依赖的依赖模块是不同的。对于:LibC，在编译时对:app不可见，但在运行时对:app是可见的。

执行./gradlew :LibA:dependencies，确认下:LibA的依赖。 对应输出结果：

debugCompileClasspath - Resolved configuration for compilation for variant: debug
\--- project :LibC

debugRuntimeClasspath - Resolved configuration for runtime for variant: debug
\--- project :LibC

releaseCompileClasspath - Resolved configuration for compilation for variant: release
\--- project :LibC

releaseRuntimeClasspath - Resolved configuration for runtime for variant: release
\--- project :LibC
复制代码

可见，:LibA确实已经依赖了:LibC。

进一步，如果此时在:app中分别调用:LibA、:LibB、:LibC、:LibD模块的Api，发现:app中是无法直接调用:LibC的方法的。

因此，可以证实，通过 implementation引入的依赖模块，在编译期对其他上层模块是不可见的，对应的依赖关系不具有传递性。

接下来继续看依赖关系与模块编译之间的关系。 先执行命令清理掉历史构建结果：

./gradlew clean
复制代码

执行build task assembleDebug 或 :app:compileDebugJavaWithJavac：

./gradlew :app:compileDebugJavaWithJavac  --info
复制代码

编译成功，其中，关键信息输出记录为：

:LibC:compileDebugJavaWithJavac (Thread[Task worker for ‘:‘ Thread 3,5,main]) started.
> Task :LibC:compileDebugJavaWithJavac
...
Compiling with JDK Java compiler API.
Class dependency analysis for incremental compilation took 0.003 secs.
Created jar classpath snapshot for incremental compilation in 0.0 secs.
Written jar classpath snapshot for incremental compilation in 0.0 secs.

:LibC:compileDebugJavaWithJavac (Thread[Task worker for ‘:‘ Thread 3,5,main]) completed. Took 0.023 secs.

...

:LibA:compileDebugJavaWithJavac (Thread[Task worker for ‘:‘ Thread 3,5,main]) started.
> Task :LibA:compileDebugJavaWithJavac
...
Compiling with JDK Java compiler API.
Class dependency analysis for incremental compilation took 0.001 secs.
Created jar classpath snapshot for incremental compilation in 0.001 secs.
Written jar classpath snapshot for incremental compilation in 0.0 secs.

:LibA:compileDebugJavaWithJavac (Thread[Task worker for ‘:‘ Thread 3,5,main]) completed. Took 0.024 secs.

...

:LibD:compileDebugJavaWithJavac (Thread[Task worker for ‘:‘ Thread 3,5,main]) started.
> Task :LibD:compileDebugJavaWithJavac
...
Compiling with JDK Java compiler API.
Class dependency analysis for incremental compilation took 0.0 secs.
Created jar classpath snapshot for incremental compilation in 0.0 secs.
Written jar classpath snapshot for incremental compilation in 0.0 secs.

:LibD:compileDebugJavaWithJavac (Thread[Task worker for ‘:‘ Thread 3,5,main]) completed. Took 0.018 secs.

...

:LibB:compileDebugJavaWithJavac (Thread[Task worker for ‘:‘ Thread 3,5,main]) started.
> Task :LibB:compileDebugJavaWithJavac
...
Compiling with JDK Java compiler API.
Class dependency analysis for incremental compilation took 0.002 secs.
Created jar classpath snapshot for incremental compilation in 0.0 secs.
Written jar classpath snapshot for incremental compilation in 0.0 secs.

:LibB:compileDebugJavaWithJavac (Thread[Task worker for ‘:‘ Thread 3,5,main]) completed. Took 0.033 secs.

...

:app:compileDebugJavaWithJavac (Thread[Task worker for ‘:‘ Thread 3,5,main]) started.
> Task :app:compileDebugJavaWithJavac
...
Compiling with JDK Java compiler API.
Class dependency analysis for incremental compilation took 0.004 secs.
Created jar classpath snapshot for incremental compilation in 0.0 secs.
Written jar classpath snapshot for incremental compilation in 0.0 secs.

:app:compileDebugJavaWithJavac (Thread[Task worker for ‘:‘ Thread 3,5,main]) completed. Took 0.099 secs.

...
复制代码

每个模块都进行了对应的compile过程。且对应的顺序为:LibC >> :LibA >> :LibD >> :LibB >> :app。

再次执行build task compileDebugJavaWithJavac：

./gradlew :app:compileDebugJavaWithJavac  --info
复制代码

编译成功，此时，关键信息输出记录为：

:LibC:compileDebugJavaWithJavac (Thread[Task worker for ‘:‘ Thread 2,5,main]) started.
> Task :LibC:compileDebugJavaWithJavac UP-TO-DATE
Skipping task ‘:LibC:compileDebugJavaWithJavac‘ as it is up-to-date.
:LibC:compileDebugJavaWithJavac (Thread[Task worker for ‘:‘ Thread 2,5,main]) completed. Took 0.003 secs.

...

:LibA:compileDebugJavaWithJavac (Thread[Task worker for ‘:‘ Thread 2,5,main]) started.
> Task :LibA:compileDebugJavaWithJavac UP-TO-DATE
Skipping task ‘:LibA:compileDebugJavaWithJavac‘ as it is up-to-date.
:LibA:compileDebugJavaWithJavac (Thread[Task worker for ‘:‘ Thread 2,5,main]) completed. Took 0.003 secs.

...

:LibD:compileDebugJavaWithJavac (Thread[Task worker for ‘:‘ Thread 2,5,main]) started.
> Task :LibD:compileDebugJavaWithJavac UP-TO-DATE
Skipping task ‘:LibD:compileDebugJavaWithJavac‘ as it is up-to-date.
:LibD:compileDebugJavaWithJavac (Thread[Task worker for ‘:‘ Thread 2,5,main]) completed. Took 0.002 secs.

...

:LibB:compileDebugJavaWithJavac (Thread[Task worker for ‘:‘ Thread 2,5,main]) started.
> Task :LibB:compileDebugJavaWithJavac UP-TO-DATE
Skipping task ‘:LibB:compileDebugJavaWithJavac‘ as it is up-to-date.
:LibB:compileDebugJavaWithJavac (Thread[Task worker for ‘:‘ Thread 2,5,main]) completed. Took 0.003 secs.

...

:app:compileDebugJavaWithJavac (Thread[Task worker for ‘:‘ Thread 2,5,main]) started.
> Task :app:compileDebugJavaWithJavac UP-TO-DATE
Skipping task ‘:app:compileDebugJavaWithJavac‘ as it is up-to-date.
:app:compileDebugJavaWithJavac (Thread[Task worker for ‘:‘ Thread 2,5,main]) completed. Took 0.024 secs.
复制代码

我们发现，对应的compileDebugJavaWithJavac task都直接Skip掉了，因为此时代码没有更新，无需重新编译。

修改:libD中LibDClass类中的代码，先修改方法内的代码：

public class LibDClass {
    public static String getName() {
        return "Library D ... change code";
    }
}
复制代码

再次执行build task compileDebugJavaWithJavac：

 ./gradlew :app:compileDebugJavaWithJavac --info
复制代码

对应关键编译信息为：

Skipping task ‘:LibC:compileDebugJavaWithJavac‘ as it is up-to-date.

...

Skipping task ‘:LibA:compileDebugJavaWithJavac‘ as it is up-to-date.

...

:LibB:compileDebugJavaWithJavac (Thread[Task worker for ‘:‘,5,main]) started.
> Task :LibB:compileDebugJavaWithJavac UP-TO-DATE
Skipping task ‘:LibB:compileDebugJavaWithJavac‘ as it is up-to-date.
:LibB:compileDebugJavaWithJavac (Thread[Task worker for ‘:‘,5,main]) completed. Took 0.004 secs.

...

Skipping task ‘:LibB:compileDebugJavaWithJavac‘ as it is up-to-date.

...

Skipping task ‘:app:compileDebugJavaWithJavac‘ as it is up-to-date.
复制代码

我们发现，修改:LibD中的方法中的代码，task compileDebugJavaWithJavac只是重新编译了:LibD。其他模块，包括依赖此模块的各上层模块，都没有重新执行编译task。

接下来，修改:LibD中的方法名，对应如下：

public class LibDClass {
    public static String getNewName() {
        return "Library D";
    }
}
复制代码

执行：

./gradlew :app:compileDebugJavaWithJavac  --info
复制代码

关键信息输出为：

Skipping task ‘:LibC:compileDebugJavaWithJavac‘ as it is up-to-date.

...

Skipping task ‘:LibA:compileDebugJavaWithJavac‘ as it is up-to-date.

...

:LibD:compileDebugJavaWithJavac (Thread[Task worker for ‘:‘,5,main]) started.

> Task :LibD:compileDebugJavaWithJavac
Task ‘:LibD:compileDebugJavaWithJavac‘ is not up-to-date because:
  Input property ‘source‘ file /Users/corn/AndroidStudioProjects/HappyCorn/LibD/src/main/java/com/happycorn/libraryd/LibDClass.java has changed.
Compiling with source level 1.7 and target level 1.7.
Created jar classpath snapshot for incremental compilation in 0.0 secs.
Compiling with JDK Java compiler API.
Incremental compilation of 1 classes completed in 0.008 secs.
Class dependency analysis for incremental compilation took 0.001 secs.
Written jar classpath snapshot for incremental compilation in 0.0 secs.

:LibD:compileDebugJavaWithJavac (Thread[Task worker for ‘:‘,5,main]) completed. Took 0.013 secs.

...

> Task :LibB:javaPreCompileDebug
Task ‘:LibB:javaPreCompileDebug‘ is not up-to-date because:
  Input property ‘compileClasspaths‘ file /Users/corn/AndroidStudioProjects/HappyCorn/LibD/build/intermediates/intermediate-jars/debug/classes.jar has changed.

:LibB:javaPreCompileDebug (Thread[Task worker for ‘:‘,5,main]) completed. Took 0.002 secs.
:LibB:compileDebugJavaWithJavac (Thread[Task worker for ‘:‘,5,main]) started.

> Task :LibB:compileDebugJavaWithJavac UP-TO-DATE
Task ‘:LibB:compileDebugJavaWithJavac‘ is not up-to-date because:
  Input property ‘classpath‘ file /Users/corn/AndroidStudioProjects/HappyCorn/LibD/build/intermediates/intermediate-jars/debug/classes.jar has changed.
Compiling with source level 1.7 and target level 1.7.
Created jar classpath snapshot for incremental compilation in 0.0 secs.
None of the classes needs to be compiled! Analysis took 0.001 secs.
Written jar classpath snapshot for incremental compilation in 0.0 secs.

:LibB:compileDebugJavaWithJavac (Thread[Task worker for ‘:‘,5,main]) completed. Took 0.005 secs.

...

> Task :app:javaPreCompileDebug
Task ‘:app:javaPreCompileDebug‘ is not up-to-date because:
  Input property ‘compileClasspaths‘ file /Users/corn/AndroidStudioProjects/HappyCorn/LibD/build/intermediates/intermediate-jars/debug/classes.jar has changed.

:app:javaPreCompileDebug (Thread[Task worker for ‘:‘,5,main]) completed. Took 0.002 secs.
:app:compileDebugJavaWithJavac (Thread[Task worker for ‘:‘,5,main]) started.

> Task :app:compileDebugJavaWithJavac UP-TO-DATE
Task ‘:app:compileDebugJavaWithJavac‘ is not up-to-date because:
  Input property ‘classpath‘ file /Users/corn/AndroidStudioProjects/HappyCorn/LibD/build/intermediates/intermediate-jars/debug/classes.jar has changed.
Compiling with source level 1.7 and target level 1.7.
Created jar classpath snapshot for incremental compilation in 0.0 secs.
None of the classes needs to be compiled! Analysis took 0.0 secs.
Written jar classpath snapshot for incremental compilation in 0.0 secs.

:app:compileDebugJavaWithJavac (Thread[Task worker for ‘:‘,5,main]) completed. Took 0.004 secs.
复制代码

可见，此时，:LiD，:LiB，:app依次都重新进行了编译task。

新增类，新增或修改非private的对外方法名等，在api引入的方式下，都会使得上层模块重新编译，因为上层模块可能会直接用到此类方法，但在上层模块的实际编译过程中，并不会对模块内的类都进行重新编译，而是只会编译确实已经使用了依赖模块的API的类。

这也正是文档中提到的:
if an api dependency changes its external API, Gradle recompiles all modules that have access to that dependency at compile time.

同样的，我们改变:LibC中的getName()方法实现，方便编译信息跟改变:LibD中的getName()方法实现一样，其他上层模块都没有重新执行编译task。

同样的，改变:LibC中的方法名，再次执行：

 ./gradlew :app:compileDebugJavaWithJavac --info
复制代码

关键信息输出为：

:LibC:compileDebugJavaWithJavac (Thread[Task worker for ‘:‘ Thread 3,5,main]) started.

> Task :LibC:compileDebugJavaWithJavac
Task ‘:LibC:compileDebugJavaWithJavac‘ is not up-to-date because:
  Input property ‘source‘ file /Users/corn/AndroidStudioProjects/HappyCorn/LibC/src/main/java/com/happycorn/libraryc/LibCClass.java has changed.
Compiling with source level 1.7 and target level 1.7.
Created jar classpath snapshot for incremental compilation in 0.0 secs.
file or directory ‘/Users/corn/AndroidStudioProjects/HappyCorn/LibC/src/debug/java‘, not found
Compiling with JDK Java compiler API.
Incremental compilation of 1 classes completed in 0.009 secs.
Class dependency analysis for incremental compilation took 0.004 secs.
Written jar classpath snapshot for incremental compilation in 0.0 secs.
:LibC:compileDebugJavaWithJavac (Thread[Task worker for ‘:‘ Thread 3,5,main]) completed. Took 0.02 secs.

...

> Task :LibA:javaPreCompileDebug
Task ‘:LibA:javaPreCompileDebug‘ is not up-to-date because:
  Input property ‘compileClasspaths‘ file /Users/corn/AndroidStudioProjects/HappyCorn/LibC/build/intermediates/intermediate-jars/debug/classes.jar has changed.
:LibA:javaPreCompileDebug (Thread[Task worker for ‘:‘ Thread 3,5,main]) completed. Took 0.018 secs.
:LibA:compileDebugJavaWithJavac (Thread[Task worker for ‘:‘ Thread 3,5,main]) started.

> Task :LibA:compileDebugJavaWithJavac UP-TO-DATE
Task ‘:LibA:compileDebugJavaWithJavac‘ is not up-to-date because:
  Input property ‘classpath‘ file /Users/corn/AndroidStudioProjects/HappyCorn/LibC/build/intermediates/intermediate-jars/debug/classes.jar has changed.
Compiling with source level 1.7 and target level 1.7.
Created jar classpath snapshot for incremental compilation in 0.001 secs.
None of the classes needs to be compiled! Analysis took 0.001 secs.
Written jar classpath snapshot for incremental compilation in 0.0 secs.
:LibA:compileDebugJavaWithJavac (Thread[Task worker for ‘:‘ Thread 3,5,main]) completed. Took 0.009 secs.

...

> Task :LibD:javaPreCompileDebug UP-TO-DATE
Skipping task ‘:LibD:javaPreCompileDebug‘ as it is up-to-date.

...

> Task :LibB:compileDebugJavaWithJavac UP-TO-DATE
Skipping task ‘:LibB:compileDebugJavaWithJavac‘ as it is up-to-date.

...

:app:javaPreCompileDebug (Thread[Task worker for ‘:‘ Thread 3,5,main]) started.

> Task :app:javaPreCompileDebug UP-TO-DATE
Skipping task ‘:app:javaPreCompileDebug‘ as it is up-to-date.

:app:javaPreCompileDebug (Thread[Task worker for ‘:‘ Thread 3,5,main]) completed. Took 0.008 secs.
:app:compileDebugJavaWithJavac (Thread[Task worker for ‘:‘ Thread 3,5,main]) started.

> Task :app:compileDebugJavaWithJavac UP-TO-DATE
Skipping task ‘:app:compileDebugJavaWithJavac‘ as it is up-to-date.
复制代码

可见，此时:LibA重新执行了编译task，但:LibA的上层模块:app并没有重新执行编译task。因为:app的依赖关系在编译期并不包含:LibC相吻合。

至此，相信对implementation和api的含义已经有了一定的理解。也已经对上文中的最关键的几个词有：可见性，依赖传递，编译期，运行时有了一定的认知。

下面继续阐述下使Gradle意识到具体含义。

实际项目开发中，对于第三方的功能模块，或者项目中抽取出去的独立的功能模块，往往形成独立的git库，进行单独的维护和管理，并生成对应的jar包或aar文件，上传到marven库。主工程中的各模块通过依赖配置去引入对应marven库上的构件。其引入的构件有时又往往通过引入了其他的marven库上的构件。此时，通过marven引入的构件内部，不论是通过implementation还是api的依赖配置去依赖了其他的marven构件，效果对于当前模块来说，都是等同的。因为implementation还是api的依赖传递关系也好，可见性也罢，都是针对当前项目的Gradle而言的。引入的marven上的构件，不论是jar包还是aar文件，都已经是通过自身编译之后的构件，其内部的依赖配置对当前项目的Gradle已经失效。

项目中引入的marven库中的构件，其内部的依赖配置对当前项目的Gradle是失效的。

例如：

  • :app api 依赖 :LibB
  • :LiB api依赖 :LibD
  • :LibD api依赖了 marven库中的构件 :LibX
  • :LibX项目内部implementation依赖了marven库中的另一构件 :LibY

此时，LibD依然可以直接使用LibY中的对外Api，也就是说，此时即使:LibX项目通过implementation引入的:LibY，但:LibY对:LibD 依然具有依赖传递，具有可见性。

此即官方文档中提及的 it‘s letting Gradle know that的内在含义。

总结：
implementation和api依赖配置主要是控制依赖模块对上层模块的依赖关系传递及可见性，在实际进行项目构建时，编译期和运行时，又可能具有不同的依赖传递关系。理解不同的依赖配置，对具体的编译期和运行时的依赖关系具有重要意义，也是解决依赖冲突等问题的关键。

作者：HappyCorn
链接：https://juejin.im/post/5c35df566fb9a04a01648512
来源：掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

原文地址：https://www.cnblogs.com/lwbqqyumidi/p/10256690.html

时间： 2024-10-08 21:39:43

Android Gradle 依赖配置：implementation & api的相关文章

android gradle 依赖项配置变更

在gradle-4.0之前的版本,引入依赖包时,都是按下面的做法 compile 'com.facebook.fresco:animated-gif:0.13.0' 但Android Studio 版本更新至3.0 的gradle-4.0版本中,包依赖配置语句做了修改,变成以下用法: implementation 'com.facebook.fresco:animated-gif:0.13.0' 或者 api 'com.facebook.fresco:animated-gif:0.13.0' 以

一文彻底搞清 Gradle 依赖【转】

来源:曾是放牛娃 www.jianshu.com/p/59fd653a54d2 转自:https://mp.weixin.qq.com/s?__biz=MzA3MDMyMjkzNg==&mid=2652262838&idx=1&sn=e160fb15de0518fd207fedf5835b3814&chksm=84dc6e21b3abe73735a917ee8c79b3b422f460bb198c3dbc23e0ab776c846ca4fdc22a94e57d&mp

Android Gradle Pluin指南（三）——依赖关系、android库和多项目配置

原文地址:http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Dependencies-Android-Libraries-and-Multi-project-setup 4.Dependencies,Android Libraries and Multi-project setup(依赖关系,Android库和多项目设置) Gradle项目可以依赖于其它组件.这些组件可以是外部二进制包,或者是其它的Gradle项

Android Gradle Plugin指南（三）——依赖关系、android库和多项目配置

原文地址:http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Dependencies-Android-Libraries-and-Multi-project-setup 4.Dependencies.Android Libraries and Multi-project setup(依赖关系,Android库和多项目设置) Gradle项目能够依赖于其他组件.这些组件能够是外部二进制包,或者是其他的Gradle项

Android使用Gradle统一配置依赖版本

前言 目前的Android开发为了减少编译时间,开发效率,大多都采用模块化,组件化的开发方式. 采用这种方式不可避免的将会用到多个Library. 那么当我们协同开发时,如何处理每个人的版本统一呢? 我想大部分人应该都在使用Gradle来依赖管理,还没有使用的去面壁思过,Gradle使用起来简直太好用了,举个例子,我们想依赖个support-v4包,直接一句话: compile 'com.android.support:support-v4:25.1.0' 但是不知道你们发现一些问题没有?比如以

Android Gradle 配置 [转]

转载自:http://pybeta.com/2016/06/about-gradle/ Android Gradle配置 编译加速 在gradle.properties中配置 1 org.gradle.configureondemand=true #demand 2 org.gradle.daemon=true #单独的守护进程 3 org.gradle.parallel=true #串行编译 4 org.gradle.jvmargs=-Xmx2048m -XX:MaxPermSize=512m

【转】Android Studio安装配置学习教程指南 Gradle基础--不错

原文网址:http://www.linuxidc.com/Linux/2015-02/113890p4.htm 其实很早之前也写了一篇Gradle的基础博客,但是时间很久了,现在Gradle已经更新了很多,所以暂且结合Stduio 1.0正式版与最新的Gradle语法来详细讲解下,小伙伴们直接跟我一步步来学习吧. 什么是Gradle? Gradle是一种依赖管理工具,基于Groovy语言,面向Java应用为主,它抛弃了基于XML的各种繁琐配置,取而代之的是一种基于Groovy的内部领域特定(DS

Android Gradle编译学习日记之二（使用 Gradle 编译 Eclipse，引入依赖资源以及迁移 Android Studio)

大家如果喜欢我的博客,请关注一下我的微博,请点击这里(http://weibo.com/kifile),谢谢 转载请标明出处(http://blog.csdn.net/kifile),再次感谢 Android Gradle编译学习日记(基于 Android Studio 1.0): Android Gradle编译学习日记之一(搭建 Gradle 环境以及编译 Android 应用) 在上一篇文章中,我简单介绍了一个 Gradle 环境变量的搭建,以及如何使用 Gradle 编译 Android

Android Studio之gradle的配置与介绍

1.gradle的简单介绍 Gradle是可以用于Android开发的新一代的Build System,也是Android Studio默认的build工具.其实Gradle脚本是基于一种JVM语言- Groovy,再加上DSL组成的.由于Groovy是JVM语言,所以可以使用大部分的Java语言库.所谓DSL就是专门针对Android开发的插件,比如标准Gradle之外的一些新的方法(Method).闭包(Closure)等等.通过我们简单的了解知道Gradle的语法足够简洁和简单,而且可以使