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

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


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

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

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

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

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

下面先通过一个具体的例子感性认识下implementationapi 两者的区别。
新建一个项目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依赖(implementationapi):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相吻合。

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

下面继续阐述下使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的内在含义。

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

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

Android Gradle 依赖配置:implementation & api的更多相关文章

  1. Android Gradle 依赖方式

    Android Gradle 依赖方式有以下6种: Compile compile是对所有的build type以及favlors都会参与编译并且打包到最终的apk文件中. Provided Prov ...

  2. Gradle系列之Android Gradle高级配置

    本篇文章主要在之前学习的基础上,从实际开发的角度学习如何对 Android Gradle 来进行自定义以满足不同的开发需求,下面是 Gradle 系列的几篇文章: Gradle系列之初识Gradle ...

  3. Gradle系列之Android Gradle基础配置

    原文发于微信公众号 jzman-blog,欢迎关注交流. 通过前面几篇文章学习了 Gradle 基础知识以及 Gradle 插件相关的知识,关于 Gradle 及其插件相关知识请先阅读下面几篇文章: ...

  4. Android gradle provided、implementation等指令注意点

    其实这类文章博客网上一搜一大堆,但有些地方可能说的不太清楚(都一样的内容,抄袭太严重),这里只是做个精简的总结和一些其他地方没提到的点. 一.Android Studio 3.0开始使用了新的指令,原 ...

  5. Android gradle 相关配置

    有时候我们需要重命名输出apk文件名,在Android studio 3.0以前我们是这样写的: applicationVariants.all { variant -> variant.out ...

  6. Android Gradle 常用配置

    Gradle:multiDexEnabled之DEX 方法超过64K限制和gradle编译OOM问题解决DEX 方法超过64K限制 UNEXPECTED TOP-LEVEL EXCEPTION: co ...

  7. Android Gradle基于参数化配置实现差异化构建

    一.背景: 项目中有一些特殊的需求,如个别渠道集成腾讯bugly,个别渠道集成易观统计,不同的渠道集成不同的推送策略(如Oppo渠道优先Opush推送),不同的渠道拥有不同的第三方登录集成等等.这些需 ...

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

    来源:曾是放牛娃 www.jianshu.com/p/59fd653a54d2 转自:https://mp.weixin.qq.com/s?__biz=MzA3MDMyMjkzNg==&mid ...

  9. Android Gradle 学习笔记(七):Android Gradle 插件

    我们知道Android Gradle其实就是一个Gradle的一个第三方插件,它是由Google的Android团队开发的,基于Gradle构建的,和Android Studio完美搭配.相比于旧的构 ...

随机推荐

  1. GitHub学习笔记:本地操作

    安装过程略,假设你已经注册好了Github, 已经有了一个准备好的程序.我们的一切工作都是基于Git Shell,与GUI客户端无关. 在使用前你先要配置好config中的几个内容,主要是你自己的个人 ...

  2. 使用on-my-zsh时,php 输出内容后面多个%号

    今天用php写个命令行的小工具时,突然发现在echo输出后,总是会多个%号,开始以为是代码的问题,然后新建了一个代码文件: <?php echo 'hello world'; 输出结果: hel ...

  3. 【多线程】-ThreadPool线程池

    ThreadPool介绍: Thread类是一个静态类,所有不存在实例化构造函数操作,直接可以调用其内所存在的方法. 微软官网给出的解释: 提供一个线程池,该线程池可用于执行任务.发送工作项.处理异步 ...

  4. python3+requests:使用类封装接口测试脚本

    前言:接口测试用例较多,我们不可能每个用例都写一次requests,get或者requests,post等,所以对共用方法要进行封装处理 第一次修改:将get请求和post请求单独定义出来,使用过程中 ...

  5. bootstrap datepicker 属性设置 以及方法和事件

    DatePicker支持鼠标点选日期,同时还可以通过键盘控制选择: page up/down - 上一月.下一月 ctrl+page up/down - 上一年.下一年 ctrl+home - 当前月 ...

  6. java里的堆内存于栈内存的区别

    这个区别对于我们来说并不大,这是内存分配的两种方法.一般代码逻辑,简单变量,结构体都是放入栈中,而对象,以及被装箱的数据是放入堆中的.简单来说,栈就是一个很长的栈(数据结构中的栈,如果不理解可以当做是 ...

  7. System.nanoTime理解

    JDK1.5之后java中的计时给出了更精确的方法:System.nanoTime(),输出的精度是纳秒级别,这个给一些性能测试提供了更准确的参考. 但是这个方法有个需要注意的地方,不能用来计算今天是 ...

  8. 【手记】小心在where中使用NEWID()的大坑

    这个表达式: --把GUID弄成正整数,然后取模 是随机返回0.1.2这三个数,不可能返回其它东西,但是如果把它用在where里面,就会发生很神奇的事情,比如这个查询: --创建一个只有1列3行的表, ...

  9. Bitmap对图像的处理

    p { margin-bottom: 0.1in; line-height: 120% } a:link { } Bitmap对图像的处理 一.引言: 在开发中涉及到图片包括.png,.gif,.9. ...

  10. 关于Java泛型"擦除"的一点思考

    头次写博客,想说的东西不难,关于泛型的疑问,是前一阵在学习jackson中遇到的. 下面就把我所想到的.遇到的,分享出来. 泛型是JDK1.5后的一个特性,是一个参数类型的应用,可以将这个参数声明在类 ...