gradle implementation、compileOnly、api

最近在做项目的时候，由于使用了3.x的gradle，在制作完成sdk后使用到宿主工程后发现原本可用的string资源找不到了，原因是对于新版本的依赖还没有完整的看过，只是知道使用implementation代替了compile，api的使用等，这里写一篇做一个备注。

Android Studio3.x 相比 2.x的版本，gradle版本相应的要求升级为了3.x了，升级后，默认的依赖compile变更为implementation，

但是并非仅仅是这个变更，会有提示：

Configuration 'compile' is obsolete and has been replaced with 'implementation'.
It will be removed at the end of 2018

其实除此外还有api和compileOnly，因此需要了解他们的机制，官网上有介绍

也就是现在compile拆分成了api和implementation两个，分工更加细致了，

implementation：让依赖仅仅使用在自己的模块中，在编译的时候依赖项不会被他模块使用，但是在运行时可以被其他模块使用。这样可以显着缩短构建时间，因为它减少了构建系统需要重新编译的模块数量。

api：当模块包含api依赖项时，模块的依赖项传递到其他模块，在运行时和编译时其他模块都可以使用它，如果api依赖的项更改了，Gradle将重新编译在编译时有权访问该依赖项的所有模块，因此，api依赖项会增加构建时间。

compileOnly：如果使用此配置，则库模块必须包含运行时条件以检查依赖项是否可用，然后正常更改其行为，以便在未提供时仍可正常运行。 这有助于通过不添加不重要的瞬态依赖项来减小最终APK的大小。 此配置的行为与provided的一样（现已弃用）。

 

下面时对官网介绍的翻译：

implementation	compile	Gradle将依赖项添加到编译类路径，并将依赖项打包到构建输出。 但是，当您的模块配置一个implementation依赖项时，它让Gradle知道您不希望模块在编译时将依赖项泄漏给其他模块。 也就是说，依赖性仅在运行时可用于其他模块。使用此依赖项配置而不是api或compile（不建议使用）可以显着缩短构建时间，因为它减少了构建系统需要重新编译的模块数量。 例如，如果实现依赖项更改其API，则Gradle仅重新编译该依赖项以及直接依赖于它的模块。 大多数应用和测试模块都应使用此配置。
api	compile	Gradle将依赖项添加到编译类路径并构建输出。 当模块包含api依赖项时，它让Gradle知道模块想要将该依赖项传递到其他模块，以便在运行时和编译时都可以使用它。 此配置的行为与compile（现在已弃用）类似，但您应谨慎使用它，并且只能将您需要的依赖项传递给其他上游使用者。 这是因为，如果api依赖项更改其外部API，Gradle将重新编译在编译时有权访问该依赖项的所有模块。 因此，拥有大量的api依赖项可以显着增加构建时间。 除非您希望将依赖项的API公开给单独的模块，否则库模块应该使用implementation依赖项。
compileOnly	provided	Gradle仅将依赖项添加到编译类路径（即，它不会添加到构建输出中）。 这在创建Android模块时非常有用，并且在编译期间需要依赖项，但在运行时是可选的。 如果使用此配置，则库模块必须包含运行时条件以检查依赖项是否可用，然后正常更改其行为，以便在未提供时仍可正常运行。 这有助于通过不添加不重要的瞬态依赖项来减小最终APK的大小。 此配置的行为与provided的一样（现已弃用）。
runtimeOnly	apk	Gradle仅将依赖项添加到构建输出，以便在运行时使用。 也就是说，它不会添加到编译类路径中。 此配置的行为与apk（现已弃用）相同。
annotationProcessor	compile	要添加对作为注释处理器的库的依赖关系，必须使用annotationProcessor配置将其添加到注释处理器类路径。 这是因为使用此配置可以通过将编译类路径与注释处理器类路径分开来提高构建性能。 如果Gradle在编译类路径上找到注释处理器，它会停用编译避免，这会对构建时间产生负面影响（Gradle 5.0及更高版本忽略在编译类路径中找到的注释处理器）.Android Gradle Plugin假定依赖是一个注释处理器，如果它的JAR文件 包含以下文件：META-INF / services / javax.annotation.processing.Processor。 如果插件检测到编译类路径上的注释处理器，则会产生构建错误。