前言：
aar包中包含了类似APP的res下的一切资源，实际上相当于一个module直接依赖了一个工程module库，只是我们将这个工程module库打包成为了一个aar文件方便直接引用，而不是提供真正的源代码，而我们在进行开发aar的目的是为了将其作为一个库提供给真正的application使用，所以aar自身工程在开发过程中不会也不可能引用需要自身被引用的工程中，说的有点绕。但是在实际开发中可能存在就是aar作为开发的某个模块的功能，比如直接属于启动的主界面的某个Fragment，并且该Fragment包含了很多功能，该功能里面点击某个view则进入到一个WebView网页界面，进入网页界面需要判断该APP是否登录，那么我们作为一个aar工程实际上是拿取不到该APP登录的逻辑的，所以就存在了一个环境模拟的思路。这个时候就涉及到运行时和编译时。我们在aar中调用APP中的某个方法时不需要去具体实现，只需要模拟该环境也即：包、类、方法/属性并调用，实际上只需要编译时通过即可，而真正的运行时则实际上调用的是APP中的真正方法进行判断。
再者当我们的aar包需要依赖比如百度地图时，也采用只参与编译而非运行时依赖，因为百度的ak之类的只能一个值，而我们自行开发时需要测试，所以实际上我们该相应的key该配置还得配置，便于开发，实际上提供aar时属于运行时给APP作为第三方库使用，是不会影响APP真正的使用的。
如果APP中，比如下拉刷新，是属于自定义的下拉刷新的 方式，而我们的aar中也用到了该下拉刷新那么也需要模拟相同环境进行调用。那么我们开发库中可以新建相应的一个依赖库模拟相同的环境的下拉刷新路径，如想要保持相同风格，则可以暂时先由第三方提供测试，最终实际上运行时的程序调用的还是APP中的库.
如何打包AAR:
方式一：IDE工具界面直接打包
方式二：使用命令行
在Terminal下使用gradlew assembleRelease 命令
AAR 包下的所有资源文件命名问题
application中的res下的资源名称很有可能会和依赖的aar库中的res资源名称相同，引发资源重复引用。
处理方式为在打包aar库文件时，将资源名称以自己独有的格式命名，避免常规命名冲突，比如所有的资源文件添加以公司省略英文字母作为命名前缀。
AAR中的依赖方式
所以我们所有的这一系列的依赖方式都为：compileOnly
- 在编译时所需的依赖关系，但在运行时不需要例如仅源代码注解或注释处理器;
- 在编译时所需的依赖关系，但在运行时仅在使用某些功能时才需要，也称为可选依赖项;
- 在编译时需要其API，但其实现由消费库，应用程序或运行时环境提供的依赖关系。
- 仅编译依赖关系与常规
compile、implementation依赖关系明显不同。它们不包含在运行时类路径中，它们是非传递性的，意味着它们不包括在依赖项目中。当使用Gradle项目依赖关系以及发布到Maven或Ivy存储库时，这一点是正确的。在后一种情况下，只有从已发布的元数据中省略编译依赖关系。
android3.0+依赖方式：
在
Android studio3.0+中，compile依赖关系已被弃用，被implementation和api替代，provided被compile only替代，apk被runtime only替代，剩下的看名字就知道了。下面我们来看看2.x和3.x区别
implementation：只能在内部使用此模块，比如我在一个libiary中使用implementation依赖了gson库，然后我的主项目依赖了libiary，那么，我的主项目就无法访问gson库中的方法。这样的好处是编译速度会加快，推荐使用implementation的方式去依赖，如果你需要提供给外部访问，那么就使用api依赖即可api（compile）
这种是我们最常用的方式，使用该方式依赖的库将会参与编译和打包。
当我们依赖一些第三方的库时，可能会遇到com.android.support冲突的问题，就是因为开发者使用的compile依赖的com.android.support包，而他所依赖的包与我们本地所依赖的com.android.support包版本不一样，所以就会报All com.android.support libraries must use the exact same version specification (mixing versions can lead to runtime crashes这个错误。
解决办法可以看这篇博客：com.android.support冲突的解决办法
解决方法（同样的适用于其他的依赖冲突。）
1）修改自己项目中的com.android.support的版本号，与所依赖的库版本号一致，但是当我们依赖的库中的com.android.support版本号有好几个版本就不行了。（不推荐）
2）推荐这种方法，如果发生冲突了，依赖第三方库时候排除掉对com.android.support包的依赖，这样自己的项目随便依赖什么版本都可以。
exclude group:表示只要包含com.android.support的都排除
api("com.afollestad.material-dialogs:core:0.9.5.0") {
exclude group: 'com.android.support'
}
module：删排除group中的指定module
api("com.afollestad.material-dialogs:core:0.9.5.0") {
exclude group: 'com.android.support', module: 'support-v13'
exclude group: 'com.android.support', module: 'support-vector-drawable'
}
compileOnly（provided）
只在编译时有效，不会参与打包
可以在自己的moudle中使用该方式依赖一些比如com.android.support，gson这些使用者常用的库，避免冲突。runtimeOnly（apk）
只在生成apk的时候参与打包，编译时不会参与，很少用。testImplementation（testCompile）testImplementation只在单元测试代码的编译以及最终打包测试apk时有效。debugImplementation（debugCompile）debugImplementation只在debug模式的编译和最终的debug apk打包时有效releaseImplementation（releaseCompile）releaseImplementation仅仅针对Release模式的编译和最终的Release apk打包。
在我们自己创建library给别人使用时，如果需要依赖的话，建议用compileOnly的方式依赖（android studio3.0中更改为compileOnly老版本为provided），这样只会在编译时有效，不会参与打包。实际上调用的是APP中的功能。
如何使用AAR
implementation project(':youaarlibrary')//既可以直接依赖开发
//compile(name: 'youaarlibrary-release', ext: 'aar')//也可以添加aar方式开发
https://blog.csdn.net/yuzhiqiang_1993/article/details/78214812
