背景某些客户因为工作环境的特殊性，无法正常地去通过远程依赖的方式来对sdk包进行依赖，只能通过本地依赖的方式进行依赖，这个时候我们就需要将我们的sdk进行aar打包处理。在这里将会着重对aar包化时的踩坑和排查进行介绍。aar包的注意点通常我们编写了一个项目时是需要引入多个第三方库，可以大量节省我们的时间。我们可以通过下面的makeModule‘xxx'的方式进行aar包打包。但是当我们将这个aar包直接提供其他项目进行依赖时就会发现出现一个问题，xxxclassnotfound，这个时候就会发现有很多类都没有找到，仔细进行排查时发现这些类都是第三方库的类。没错，这个就是aar包打包的一个缺陷，他不能将第三方库的包一并打入进去，需要你收到将这些第三方包的jar包、aar包逐个添加进去才行。其实我们通过远程依赖方式也是很容易产生冲突，例如版本冲突、类名相同冲突，A包依赖库与B包依赖库相同等冲突，这些冲突都是交给了Gradle来替我们解决的，当然某些情况还是需要我们人为介入将通过Gradle来决定如何解决冲突。在早期没有Gradle、Maven等这些构建工具的时候，只能人为手动一个一个去处理冲突问题。回到正题，我们这里也是一样，只能人为将这些依赖库的jar包和aar包挑选出来，然后放入到依赖的项目里面去。当然这样人为手动去进行打包是比较苦逼的，可以去使用Gradle插件：fat-aar-androidhttps://github.com/kezong/fat-aar-android但是很可惜这个插件是有很多问题的例如不支持注解处理，aar包找不到R资源等，这些都需要根据你自己的项目进行调整。所以这里只能人为地去筛选aar包导入到项目中，并没有去使用这个插件第三方aar包导入普通依赖库导入这里我先抛出一个概念，导入的依赖库我这里是分为两种，一种就是普通的依赖库，一种是注解处理器的依赖库（这个让我吃尽苦头，下面也是着重介绍这种依赖库怎么处理）。对于这种普通的依赖库其实处理起来很容易，通过gradlewdemo:dependencies来进行打印即可知道我们的项目依赖了什么第三方库，然后去.gradle\caches\modules-2或是.gradle\caches\transforms-2中去找对应的jar包即可了，缺少什么就去导入什么就好了。注解处理依赖库导入源起按照我们上面的处理后，能够编译成功并安装apk了，但是当我们运行程序的时候就闪退崩溃了，然后看log提示redpack\model\datasource\database\dao\RedpackCacheDAO_Implclassnotfou这个是什么鬼？我们的项目根本就没有用到这个类，这个是什么东西？从这个类的命名方式、包名来看，貌似是注解处理器生成出来的东西。看了一下我们的项目，我们的是使用了room这个第三方库，用于去管理数据库的，这么一看貌似是这个第三方库没有导进去，但是奇怪的是我们在dependencies中是没有看到这个库打印出来，并且在ExternalLibraries中是没有看到这个库的，奇怪了。。。（这个会在下面进行解释）那么我们直接将这个库的jar包扔进libs吧，既然他提示没有生成这个库中。但是他提示出了这一个错误大概提示就是说该库存在注解处理器，需要特别声明。在该log中提示你可以配置android.defaultConfig.javaCompileOptions.annotationProcessorOptions.includeCompileClasspath=true。但是按照上述配置发现是不成功的，提示没有includeCompileClasspath属性，这个属性在高版本的Gradle中移除了。上外网找了一圈后发现我们可以通过这种方式进行依赖annotationProcessorfiles('/libs/room-compiler-2.0.0.jar')破局尝试一下，发现的确没有了上面的那一个错误了，但是报了一个这样的错误出来，然后没有其他信息了。只有这个错误信息让我百思不得其解，google了一圈也没有什么头绪，这个类是什么鬼？后面经过一番查找发现该类是在一个com.google.auto:auto-common这个包中发现有这么一个类。然后就猜想是否是这个注解处理器需要依赖到这个类呢？然后我就把这个包扔进libs中看一下。然后我就使用这种方式来进行依赖implementationfiles('/libs/auto-common-0.6.jar')发现还是上面的报错信息，这个时候陷入困局了，然后也是一顿google还是没有什么头绪，后面突然想到了注解处理器声明需要使用annotationProcessor声明，那么这个依赖是否也需要使用这个依赖呢？尝试一下annotationProcessorfiles('/libs/auto-common-0.6.jar')发现这个错误没有了，换成另外一个类的错误提示了。在这里发现我们可以通过annotationProcessorfiles(libs/xxx）的方式为注解处理器的依赖进行声明。那么好了，我们可以通过这种方式逐个将注解处理器需要的类依赖进去就行了，但是这里就出现一个问题了，这里报的错误信息只有包名，但是并没有指明是那一个第三方库持有了这个类，这里只能到**.gradle\caches\modules-2**中逐个依赖包去查找，幸运的是大部分库的包名是与这个类相识的，所以还是能找到大部分的依赖库，仅剩下的小部分是没有的，所以只能一个一个去找了，这个就很痛苦了。思考：按理来讲我们是可以通过Gradledependencies来将库的依赖打印出来的，但是通过该命令是没有打印出来了，后面经过查找发现这里涉及到了编译时和运行时的问题。在网上找的都是打印运行时的依赖，并没有编译时的依赖，按理来讲是可以通过自定义task来讲编译时的依赖进行打印，但是没有找到类似的案例，也许某些第三方GradlePlugin可以做到，但是也没有找到，这里只能用笨方法一个一个去找了，幸运的的是我们这里只有room这个第三方库有这个问题，其他的没有，所以并不算多。在这里涉及到了编译时和运行时的概念，如果有使用过ARouter的和使用过注解处理器的朋友一定不陌生，这里简单介绍一下这两个的不同编译时是不会将jar包打进去apk的，只是在编译时期使用到，在这里room注解处理器中就是用于生成java文件，然后一同编译。运行时时会将jar包打进apk的，在运行时就会使用到的，例如retrofit2的注解，他是通过反射的方式获取到注解的信息，这个过程是在应用运行时才会使用到，所以这里会将需要包打进来的。在我们的项目中也使用到的了Retrofit2的，Retrofit2也是用到了注解，但我们并不需要像上面导入room.jar包那样为他的依赖进行多个声明，Retrofit2也能正常运行，就是因为Retrofit2是运行时使用的，通过反射来获取到API接口的参数，所以只需要将Retrofit使用到的依赖库直接放入libs中即可。回到正题，为什么room这个库要这么复杂，需要为他的依赖类逐个进行声明？这个就是因为这个room库的注解处理器是在编译时处理，在上面提到了编译时使用的jar包是不会编译，而我们的依赖第三方库是使用下面的这种方式进行依赖apifileTree(dir:'libs',include:['*.aar','*.jar'])这种api依赖方式貌似是运行时进行的依赖，而编译时需要的依赖是导不进去的，所以就需要使用到了annotationProcessor这个关键字进行声明，通过annotationProcessor声明后在编译时就能依赖到了。这个也正好回应到了上面为什么执行gradledemo:dependencies命令不能打印出注解处理器的依赖出来，因为这个命令只能将运行时的依赖打印出来，并不能将编译时的依赖打印出来。而room的这个库并不是独立依靠自己就完成所有的注解处理，他还依赖了很多第三方库来进行注解处理，例如javaPoet这个库，所以我们就需要同时将这个javaPoet依赖进去。这个也是痛点问题，A库依赖B库，B库依赖C库，就需要将ABC都找出来，逐个进行annotationProcessor声明才可以疑点：如果按照我上面的猜测，按道理来说使用compileOnly关键字去声明应该是可以的，但是却依然依赖不成功，只有使用annotationProcessor才成功，这就非常奇怪了风云再起按照上面的配置其实基本就能完成本地库处理了，但是在这里还遇到了另外一个问题，编译时通过了，但是到了最后打包的时候出现了一个冲突问题依赖的androidx.annotation:annotation:1.0.0和我们room中需要的依赖库annotation-1.3.0.jar产生了冲突了。而room中一定是需要annotation-1.3.0.jar。所以这里我们的解决方式是新开一个module，这个module专门用于注解处理的，而Gradle有对project进行隔离的特性，所以这个module中去进行注解处理器声明，这样就不会影响到其他module，从而引起类冲突的问题。源灭这里总结一下，就是aar包的打包并不能将其需要用到的子包一并打进aar包里面，这个其实是合理的，如果都能打进aar包的话，很容易产生依赖冲突，而且很不好解决。面对上面的情况我们就需要手动将用到的子包一并添加进去才行。而如果依赖到了注解处理器的话，我们要分清楚这个注解处理器是否是编译时，如果是的话就需要使用annotationProcessor进行声明，并且这个注解处理器所依赖的子库都要用annotationProcessor进行声明。为了项目的更好管理，最好是新开一个module用于管理注解处理，而我们只需要通过annotationProcessorproject(':anootationproject')声明这个anootationprojectmodule用于注解处理即可了这里我贴一下room这个库中用到的jar包,方便后续管理自此我们的所有依赖问题都解决了，项目也能够正常跑起来了奇淫巧技其实如果遇到了上面的问题，我们还有一些比较特殊的技巧，可以快速进行接入。巧技一：上面最主要的问题是，无法在编译时生成出RedpackCacheDAO_Impl这个类，那么简单我们在能正常使用远程依赖的项目中运行起来，那么肯定能正常生成出这个类，然后我们就根据这个类所在的包，直接将该类复制到aar包依赖项目对应的位置即可，缺少那一个类就生成出来，复制过去就行了。但这里是有一个问题就是，如果我们的sdk对于使用到这一部分功能有所变动，那么生成出来的类就会发生变动，需要将发生变动的类一同移交给客户，这个就不太利于后续的维护，不过如果是为了快速接入，使用这个方法也是可以的巧技二：使用远程依赖时，一般会将下载下来的库放入到.gradle\caches\modules-2\files-2.1或.gradle\caches\transforms-2\files-2.1这两个地方，当需要依赖的时候就会优先从缓存库中取出来，所以可以直接将这两个地方的文件拷贝处来，直接交给客户，然后使用远程依赖的方式进行依赖，不过使用这个方式弊端巨大，所以就没有尝试过这种方式了，不过按理来讲应该是可行的