疑难杂症记录1：关于Kotlin aar文件不能debug的问题

现在有个这样的场景，需要你编写一个基础库sdk供上层业务调用，同时考虑引入kotlin，于是你花了3分钟很快就把所有的代码写完了，然后assembleRelease输出aar，再引入aar到主工程中。此时你想在主工程中结合业务调试下刚写完的kt代码，发现没法debug，效果如下所示：

由于项目时间关系，在我遇到这个问题时由于代码量不大，立马就将kt编写改成java了。但java语法在某些场景下实在太罗嗦，同时为了引入kt的协程特性，如果我要继续在基础库中使用kt，前提条件是需要解决kt的aar包不能debug的问题。

解决问题的过程总是那么曲折不顺，解决问题后的感受总是那么神清气爽。先说结论，这个问题有两种解决方式：

通过引入子模块的方式，配置一个开关，在你需要调试代码时引入子模块中的源代码，而发布时依赖aar
通过maven库的方式，不管是本地还是远程maven，在发布代码时附带源码

子模块方式

这种方式在操作上依赖一个开关变量，而我根本不想再多维护一个开关值，所以不推荐。下面还是简单说明下怎么操作，原本是aar方式依赖，现在改成子模块方式，如下图所示：

1 2	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/

接着登录进去(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以及源码成功发布到了仓库中

工程配置和发布到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界面，真香

后记

我这套示例程序的环境如干净的贝加尔湖水，而你的工程环境如同你小区的垃圾堆脏乱不堪。这里没有贬低之意，只是环境的简单和复杂会在你引进依赖库后报很多奇怪的问题，比如重复引入的问题、依赖传递的问题等等，而这些就依赖我们自己解决问题的能力了。

上面sonatype的使用也是最简单的，它还有很多复杂的功能，比如权限、分组等，这些如果你要用到再找资料也不迟。多提一嘴，在拉仓库代码时，可能会失败报错：Repository does not allow updating assets，此时你就进入sonatype的配置页允许匿名访问就ok了。

总的来说，想要debug某个aar库，想办法搞到源码，源码在手，debug我有。

参考：