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
来源:掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
Android Gradle 依赖配置:implementation & api的更多相关文章
- Android Gradle 依赖方式
Android Gradle 依赖方式有以下6种: Compile compile是对所有的build type以及favlors都会参与编译并且打包到最终的apk文件中. Provided Prov ...
- Gradle系列之Android Gradle高级配置
本篇文章主要在之前学习的基础上,从实际开发的角度学习如何对 Android Gradle 来进行自定义以满足不同的开发需求,下面是 Gradle 系列的几篇文章: Gradle系列之初识Gradle ...
- Gradle系列之Android Gradle基础配置
原文发于微信公众号 jzman-blog,欢迎关注交流. 通过前面几篇文章学习了 Gradle 基础知识以及 Gradle 插件相关的知识,关于 Gradle 及其插件相关知识请先阅读下面几篇文章: ...
- Android gradle provided、implementation等指令注意点
其实这类文章博客网上一搜一大堆,但有些地方可能说的不太清楚(都一样的内容,抄袭太严重),这里只是做个精简的总结和一些其他地方没提到的点. 一.Android Studio 3.0开始使用了新的指令,原 ...
- Android gradle 相关配置
有时候我们需要重命名输出apk文件名,在Android studio 3.0以前我们是这样写的: applicationVariants.all { variant -> variant.out ...
- Android Gradle 常用配置
Gradle:multiDexEnabled之DEX 方法超过64K限制和gradle编译OOM问题解决DEX 方法超过64K限制 UNEXPECTED TOP-LEVEL EXCEPTION: co ...
- Android Gradle基于参数化配置实现差异化构建
一.背景: 项目中有一些特殊的需求,如个别渠道集成腾讯bugly,个别渠道集成易观统计,不同的渠道集成不同的推送策略(如Oppo渠道优先Opush推送),不同的渠道拥有不同的第三方登录集成等等.这些需 ...
- 一文彻底搞清 Gradle 依赖【转】
来源:曾是放牛娃 www.jianshu.com/p/59fd653a54d2 转自:https://mp.weixin.qq.com/s?__biz=MzA3MDMyMjkzNg==&mid ...
- Android Gradle 学习笔记(七):Android Gradle 插件
我们知道Android Gradle其实就是一个Gradle的一个第三方插件,它是由Google的Android团队开发的,基于Gradle构建的,和Android Studio完美搭配.相比于旧的构 ...
随机推荐
- win10装ubuntu双系统
由于在win下进行web开发出现各种问题相当头疼. 所以今天折腾了一天想装个ubuntu,查看了网上好多教程,不得不说,网上的人很多都是不负责任的,教程都是过时根本就不负责任,关键的地方一笔带过,简单 ...
- 回忆一下我的运维时期 关于Impact的架构服务器集群
Impact EDMP平台 Email Direct Marketing Platfrom 电子邮件营销平台 EDM 是 Email Direct Marketing 的缩写,即电子邮件营销,简 ...
- js基础--javaScript数据类型你都弄明白了吗?绝对干货
欢迎访问我的个人博客:http://www.xiaolongwu.cn 数据类型的分类 JavaScript的数据类型分为两大类,基本数据类型和复杂数据类型. 基本数据类型:Null.Undefine ...
- 解决window.showModalDialog在Firefox无法支持
在网页程序中,有时我们会希望使用者按下按钮后开启一个保持在原窗口前方的子窗口,而在IE中,我们可以使用showModalDialog来达成,语法如下 : vReturnValue = window.s ...
- 功能强大的swagger-editor的介绍与使用
一.Swagger Editor简介 Swagger Editor是一个开源的编辑器,并且它也是一个基于Angular的成功案例.在Swagger Editor中,我们可以基于YAML等语法定义我们的 ...
- 关于mui 中popover与下拉刷新冲突问题
最近用mui做app混合式开发时,作为一个后端开发,高前端确实有点吃了,期间遇到的问题肯定也不少.这两天app做更新,为了装逼,将更新的提示搞得好看些,用到了mui中的popover,结果把自己整死了 ...
- 在webpack里使用jquery.mCustomScrollbar插件
malihu-custom-scrollbar-plugin是一个依赖jquery的自定义网页滚动条样式插件 网站:http://manos.malihu.gr/jquery-custom-conte ...
- 开源RPC(gRPC/Thrift)框架性能评测
海量互联网业务系统只能依赖分布式架构来解决,而分布式开发的基石则是RPC:本文主要针对两个开源的RPC框架(gRPC. Apache Thrift),以及配合GoLang.C++两个开发语言进行性能对 ...
- Open-Source Service Discovery
Service discovery is a key component of most distributed systems and service oriented architectures. ...
- Extjs--12种布局方式
按照Extjs的4.1的文档来看,extjs的布局方式大致有12种,下面一一介绍,有些代码就是文档中的. 1.Border 边界布局 border布局,最多可以将页面分割为"东南西北中&qu ...