技术控

    今日:60| 主题:49312
收藏本版 (1)
最新软件应用技术尽在掌握

[其他] Android Gradle configurations

[复制链接]
离落染纤尘一抹绕指柔 发表于 2016-10-4 15:40:01
130 5

立即注册CoLaBug.com会员,免费获得投稿人的专业资料,享用更多功能,玩转个人品牌!

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
The basics of Gradle configurations

  Almost all Gradle projects (including all Gradle-based Android projects) uses some configurations. What does configuration mean in Gradle? First take a look at the example:
  [code]dependencies {
annotationProcessor 'com.jakewharton:butterknife-compiler:8.4.0'
compile 'com.jakewharton:butterknife:8.4.0'
compileproject(':api')
debugCompile 'com.squareup.leakcanary:leakcanary-android:1.4'
releaseCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.4'
androidTestCompile 'com.android.support.test:runner:0.5'
testCompile 'org.robolectric:robolectric:3.1.2'
testAnnotationProcessor 'org.robolectric:robolectric-processor:3.1.2'
}
[/code]   Configurations are used here to group dependencies, they are defined using pattern configurationName dependencyNotation . In the example above compile , testCompile and so on are all configuration names and 'com.jakewharton:butterknife:8.4.0' , project(':api') are dependency notations. All configurations here are created by Android Gradle plugin .
   After project evaluation, each dependency is resolved (with the help of repositories stanza and other rules) to file URI and configuration becomes FileCollection . The latter can be used by various Gradle tasks to achieve their objectives. For example elements of debugCompile configuration are added to debug variant compile classpath.
  Configurations in Android projects

  Configuration names added by Android Gradle plugin consist of two main parts:
  
       
  • optional prefix denoting build variant, product flavor or build type   
  • required suffix denoting scope  
   Eg. in debugCompile : debug is a build type (equal to build variant when there are no product flavors) and compile . If there is no prefix configuration is common to all build variants, eg. compile is applicable to both debug and release build types. Each regular configuration has also corresponding unit test one, so by default for compile there is also testCompile , testDebugCompile and testReleaseCompile . Unit test configuration inherits from regular ones (inheritance is described later in this article).
   Finally there is an androidTest configuration group used for instrumentation tests (running on device/emulator). From configurations point of view androidTest is treated as a build type. Note that currently (up to Gradle plugin 2.2.0) only one build type can be instrumentation-tested, so there are no corresponding debug and release configurations. There are also wearApp configurations related to Android Wear, they are not covered by this article.
  Scopes

  Scope is related to phase when configuration is used. What phase means here? Let’s take a look a the Figure 1.
     
Android Gradle configurations-1 (android,gradle,android,gradle下载)
      Fig. 1. – configurations by phase.      annotationProcessor/kapt/apt

   This scope is dedicated to annotation processors like dagger-compiler from Dagger 2 . Using this configuration is not strictly required for annotation processing itself to work ( provided or even compile in some cases also do the job). However additional scope guarantees that transitive dependencies (like guava or javapoet commonly used by annotation processors) won’t be available for use from application code. If provided is used instead they are available and used by a mistake will cause crash at runtime due to missing classes. In case of compile all the classes from transitive dependencies will be available but method number (which is limited to 65K for dex file) will often increase drastically.
   AnnotationProcessor has been introduced in Android Gradle Plugin 2.2.0. Formerly this functionality was provided by android-apt Gradle plugin. In kotlin this scope is called kapt .
  provided/compileOnly

   In maven and Android Gradle Plugin it is called provided however name compileOnly is self-explanatory this is how kotlin and Java Gradle plugins call this scope. As the second name suggests dependencies declared in this configuration are available only at the compile time but not at runtime. They are not packaged into APK or AAR so attempt to access classes from those dependencies will cause runtime error. There are 2 important limitations of this scope:
  
       
  • dependencies are not transitive so they are not included in dependent projects   
  • dependencies can only be JARs, not AARs meaning they cannot include Android resources, assets, manifests etc.  
   When should it be used? Typically dependencies containing source-only annotations go here. Some widely used examples for Android applications projects are: Android Support Annotations (however large number of samples use compile scope for it) or lombok (needs to be also in annotationProcessor ).
  compile

   This is the most common scope. Dependencies will be available in both compile and execution time, which is desired in most cases. Eg. butterknife is needed during compilation and also in runtime.
  apk

   This is rarely used scope, even not mentioned in official documentation. Dependencies are available at runtime but not during compilation, this may be useful eg. when using @SneakyThrows annotation from lombok .
  Inheritance

   Configuration can extend another one which means that it contains also items from parents. Eg. testCompile extends compile so all production dependencies can also be used in unit tests but not vice versa. Robolectric classes can be used in unit test sources but not in production code. Analogously debugCompile extends debug and so on. Particular configuration can inherit from more than one parent. Note that inheritance must be explicitly declared and naming scheme does not imply it eg. testAnnotationProcessor does not extend annotationProcessor .
  Custom configurations

   Existing configurations can also be extended manually which can be used to achieve useful results. Let’s say that junit and assertj-android are needed in both unit ( src/test ) and instrumentation ( src/androidTest ) tests. The most straightforward way to achieve that is to declare each dependency separately in appropriate configuration:
  [code]testCompile 'com.squareup.assertj:assertj-android:1.1.1'
testCompile 'junit:junit:4.12'
androidTestCompile 'com.squareup.assertj:assertj-android:1.1.1'
androidTestCompile 'junit:junit:4.12'
[/code]   As you can see there are repetitions. To avoid them we can introduce additional configuration, let’s call it commonTestCompile . First we need to create it inside configurations stanza. Along with creation we can configure inheritance telling that appropriate configurations from Android plugin extends from newly created one:
  [code]configurations {
[androidTestCompile, testCompile].each { it.extendsFromcommonTestCompile }
}
[/code]   Now all dependencies added to commonTestCompile will be also available in androidTestCompile and testCompile so each common dependency can be declared only once:
  [code]commonTestCompile 'com.squareup.assertj:assertj-android:1.1.1'
commonTestCompile 'junit:junit:4.12'
[/code]
友荐云推荐




上一篇:10月4日-每日安全知识热点
下一篇:7 Different Star Pattern Programs in C#
酷辣虫提示酷辣虫禁止发表任何与中华人民共和国法律有抵触的内容!所有内容由用户发布,并不代表酷辣虫的观点,酷辣虫无法对用户发布内容真实性提供任何的保证,请自行验证并承担风险与后果。如您有版权、违规等问题,请通过"联系我们"或"违规举报"告知我们处理。

难瘦 发表于 2016-10-4 18:38:55
在乎的人不明白,明白的人不在乎。
回复 支持 反对

使用道具 举报

tmddl 发表于 2016-11-2 19:44:44
tmddl等着楼主
回复 支持 反对

使用道具 举报

那一年丶时光 发表于 2016-11-15 08:04:34
楼上的心情不错啊!
回复 支持 反对

使用道具 举报

qcwvw 发表于 2016-11-15 14:00:47
我是个凑数的。。。
回复 支持 反对

使用道具 举报

7Q8Q9Q 发表于 2016-11-19 11:07:56
离落染纤尘一抹绕指柔,此事必有蹊跷!
回复 支持 反对

使用道具 举报

*滑动验证:
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

我要投稿

推荐阅读

扫码访问 @iTTTTT瑞翔 的微博
回页顶回复上一篇下一篇回列表手机版
手机版/CoLaBug.com ( 粤ICP备05003221号 | 文网文[2010]257号 )|网站地图 酷辣虫

© 2001-2016 Comsenz Inc. Design: Dean. DiscuzFans.

返回顶部 返回列表