现在有个这样的场景，需要你编写一个基础库sdk供上层业务调用，同时考虑引入kotlin，于是你花了3分钟很快就把所有的代码写完了，然后assembleRelease输出aar，再引入aar到主工程中。此时你想在主工程中结合业务调试下刚写完的kt代码，发现没法debug，效果如下所示：
testktaar-kt源码被编译成class文件.png
由于项目时间关系，在我遇到这个问题时由于代码量不大，立马就将kt编写改成java了。但java语法在某些场景下实在太罗嗦，同时为了引入kt的协程特性，如果我要继续在基础库中使用kt，前提条件是需要解决kt的aar包不能debug的问题。
解决问题的过程总是那么曲折不顺，解决问题后的感受总是那么神清气爽。先说结论，这个问题有两种解决方式：
- 通过引入子模块的方式，配置一个开关，在你需要调试代码时引入子模块中的源代码，而发布时依赖aar
- 通过maven库的方式，不管是本地还是远程maven，在发布代码时附带源码
子模块方式
这种方式在操作上依赖一个开关变量，而我根本不想再多维护一个开关值，所以不推荐。下面还是简单说明下怎么操作，原本是aar方式依赖，现在改成子模块方式，如下图所示：
testktaar-basic-net-aar转子模块依赖方式.png
include 'basic-net'
project(':basic-net').projectDir = new File(settingsDir, '../TestKtAarLib/basic-net')
这种方式明目张胆把源码依赖进来了，实在找不到借口不能debug了。说了这么多不好，其实还是有优点的，你可以及时修改源码来佐证自己的想法，但仅仅是佐证而已，如果这套基础库代码不是你维护的，或者你们有明确分工，不建议你修改后commit。
maven库方式
推荐采用这种方式，原因很简单，发布完后不用管事了，上层业务使用的同学权限也仅仅是debug级别，不会由于一些莫名其妙的原因修改了你的代码而不自知。
下面我以线上maven库的方式为例，首先要弄个maven服务，去 这里下载，提取码：hcxu ，完事之后解压，cmd 进入到这个目录：nexus-3.22.0-02-win64\nexus-3.22.0-02\bin>，windows系统下运行命令 nexus.exe /run，别着急等待一下，看到 Started Sonatype Nexus OSS 3.22.0-02 这句话就代表服务起好了，然后你就打开 http://localhost:8081/
testktaar-启动maven服务.png
testktaar-启动maven服务成功.png
testktaar-启动maven服务成功-打开浏览器.png
接着登录进去(admin/admin123)，然后拷贝maven-releases和maven-snapshots这两个仓库的地址：
maven服务这部分算是完事了，下面来看工程中怎么配置，在gradle.properties中配置maven的pom属性以及maven仓库地址和账密。maven的pom属性配置你也可以不写到gradle.properties中，而是放到每个module下分类管理更好。
#MAVEN需要的配置
PROJ_GROUP_ID = com.leeeyou.testktaar.basic.net
PROJ_ARTIFACTID = basic-net
PROJ_VERSION = 1.1.0
PROJ_DESCRIPTION =test kt aar debug
PROJ_TYPE = aar
#这里是maven地址和账密
MAVEN_REPO_RELEASE_URL=http://localhost:8081/repository/maven-releases/
MAVEN_REPO_SNAPSHOT_URL=http://localhost:8081/repository/maven-snapshots/
NEXUS_USERNAME=admin
NEXUS_PASSWORD=oooo9999
现在准备一个maven_push.gradle用于发布aar和源码到maven仓库中，同时在build.gradle中引入该文件：apply from: 'maven_push.gradle'
apply plugin: 'maven'
apply plugin: 'signing'
configurations {
deployerJars
}
repositories {
mavenCentral()
}
// 判断版本是Release or Snapshots
def isReleaseBuild() {
return !PROJ_VERSION.contains("SNAPSHOT");
}
// 获取仓库url
def getRepositoryUrl() {
return isReleaseBuild() ? MAVEN_REPO_RELEASE_URL : MAVEN_REPO_SNAPSHOT_URL;
}
uploadArchives {
repositories {
mavenDeployer {
beforeDeployment {
MavenDeployment deployment -> signing.signPom(deployment)
}
pom.version = PROJ_VERSION
pom.artifactId = PROJ_ARTIFACTID
pom.groupId = PROJ_GROUP_ID
repository(url: getRepositoryUrl()) {
authentication(userName: NEXUS_USERNAME, password: NEXUS_PASSWORD) // maven授权信息
}
}
}
}
// 进行数字签名
signing {
// 当 发布版本 & 存在"uploadArchives"任务时，才执行
required { isReleaseBuild() && gradle.taskGraph.hasTask("uploadArchives") }
sign configurations.archives
}
//上传源码
task androidSourcesJar(type: Jar) {
classifier = 'sources'
from android.sourceSets.main.java.srcDirs
}
artifacts {
archives androidSourcesJar
}
最后执行uploadArchives任务后，发现aar以及源码成功发布到了仓库中
testktaar-发布aar到maven仓库.png
testktaar-sonatype-发布成功.png
工程配置和发布到maven仓库这部分算是完事了，接下来就是使用刚发布的aar。首先在根build.gradle中配置仓库地址，然后在具体的module中引入basic-net依赖库，同步一下，正常情况下能成功拉下代码。
//根build.gradle
maven {
url 'http://localhost:8081/repository/maven-releases/'
}
//module的build.gradle
implementation 'com.leeeyou.testktaar.basic.net:basic-net:1.1.0'
此时我已成功拉下了1.1.0版本的代码，测试是包含源码的，所以我可以随意debug NetRequest的post和get函数。久违的debug界面，真香
testktaar-debug-maven库.png
后记
我这套示例程序的环境如干净的贝加尔湖水，而你的工程环境如同你小区的垃圾堆脏乱不堪。这里没有贬低之意，只是环境的简单和复杂会在你引进依赖库后报很多奇怪的问题，比如重复引入的问题、依赖传递的问题等等，而这些就依赖我们自己解决问题的能力了。
上面sonatype的使用也是最简单的，它还有很多复杂的功能，比如权限、分组等，这些如果你要用到再找资料也不迟。多提一嘴，在拉仓库代码时，可能会失败报错：Repository does not allow updating assets，此时你就进入sonatype的配置页允许匿名访问就ok了。
总的来说，想要debug某个aar库，想办法搞到源码，源码在手，debug我有。
参考：
网友评论