Gradle脚本打包AndroidStudio依赖库的问题

佚名 6年前 (2019-04-11) 随笔 1002人围观抢沙发百度已收录

　　古人云：“以铜为镜，可以正衣冠；以古为镜，可以知兴替；以人为镜，可以明得失；而以法为镜，可以断曲直。”　　

　　目前，国内大多数（99%）渠道在提供给CP渠道SDK时，都会有eclipse的接入方式。但毕竟现在google爸爸已经弃用了eclipse开发方式，AndroidStudio是官方指定使用的开发工具，有一些渠道，特别是刚开始做SDK的一些小渠道，为了方便快捷，使用AndroidStudio进行开发，且提供给CP接入方式也仅仅有一个AndroidStudio接入方式，这个问题对于目前的聚合SDK接入就是一个比较麻烦的问题。比如U8，quick，主要都是eclipse方式的聚合SDK。AndroidStudio对于我们这种eclipse接入方式的最大问题是什么呢。是因为AndroidStuido使用的是gradle自动构建工具，使用的第三方依赖库，直接在项目中gradle中依赖即可，而且依赖库麻烦的是内部依赖，一个依赖库可能内部依赖有其他第三方库。这就使我们获取jar包有一定的难度了。谁知道什么依赖库下依赖着什么呢。

SRE实战互联网时代守护先锋，助力企业售后服务体系运筹帷幄！一键直达领取阿里云限量特价优惠。

　　问题解决，当我遇见这第一个渠道的时候，思考，当前渠道提供给我的有什么，而我需要什么，还缺少什么。在互联网的知识海里遨游，希望寻找到遇到同样困境并已解决的知己伙伴。果真，在随着技术进步的发展下，更多人也喜欢使用AndroidStudio的方式进行开发，那么有人也提出了一些解决办法。如U8解决方案：在AndroidStudio正常接入，该依赖的依赖，该配置的配置，该写的代码写上，然后将整个项目编译成一个apk，反编译，获取里面的资源文件，然后，将项目打包成jar，提供给我们的聚合SDK依赖。没错，这的确是一个好办法，但是对于我的需求来说，算是比较麻烦，首先，我维护更新渠道SDK都得AndroidStudio下，那么就需要Eclipse和AndroidStudio两个开发工具下跑，增加了自己开发维护成本和以后工作交接后，同事在背后的种种谴责；其次，在我们大陆，有幸的隔离了纷纷扰扰的墙外，我们渠道SDK也无需用到google服务等可以通过AndroidStudio特殊打包方式编译的，所以在这个方案的前提下，思考既然可以将项目打包成jar，那我是不是可以将我现在缺少的渠道SDK提供过来的依赖库生成jar给我聚合SDK进行依赖呢。然后就又是一顿遨游。例如gradle打包jar，gradle打包依赖库等等。果真，结合各种答案，在亲测下，找到一个符合我自己目前需求的解决办法。讲了那么多废话，下面开始正题：

　　使用shadow插件进行依赖库打包：

　　首先，还是正常将第三方库依赖，同步跑起来，将第三方库的文件都下载到本地，项目无报错。然后修改自己的gradle，怎样修改呢，如下：

apply plugin: 'java'
apply plugin: 'com.github.johnrengelman.shadow'

buildscript {
    repositories {
        jcenter()
    }
    dependencies {
        classpath 'com.github.jengelman.gradle.plugins:shadow:2.0.1'
    }
}

repositories {
    mavenCentral()
    flatDir {
        dirs'libs'
    }
}

shadowJar {
    baseName = 'library'
    classifier = null
    version = null
    dependencies {
        include(dependency('com.squareup.retrofit2:retrofit:2.2.0'))
        include(dependency('com.squareup.retrofit2:converter-gson:2.2.0'))
        include(dependency('com.jakewharton.retrofit:retrofit2-rxjava2-adapter:1.0.0'))
        include(dependency('com.squareup.okhttp3:okhttp:3.10.0'))
        include(dependency('com.squareup.okhttp3:logging-interceptor:3.8.0'))
        include(dependency('io.reactivex.rxjava2:rxjava:2.0.5'))
        include(dependency('io.reactivex.rxjava2:rxandroid:2.0.1'))
    }
}

dependencies {
    implementation fileTree(dir: 'libs', include: ['*.jar'])
    // 添加Retrofit
    implementation 'com.squareup.retrofit2:retrofit:2.2.0'
    implementation 'com.squareup.retrofit2:converter-gson:2.2.0'
    implementation 'com.jakewharton.retrofit:retrofit2-rxjava2-adapter:1.0.0'
    // 添加okhttp
    implementation 'com.squareup.okhttp3:okhttp:3.10.0'
    implementation 'com.squareup.okhttp3:logging-interceptor:3.8.0'
    // RxJava
    implementation 'io.reactivex.rxjava2:rxjava:2.0.5'
    implementation 'io.reactivex.rxjava2:rxandroid:2.0.1'
}

　　如上，这就是我当前遇到的一个只提供AndroidStudio方式提供过来的，dependencies就是渠道SDK需要依赖的第三库，然后在shadowJar方法中dependencies加入我们需要打包的第三方依赖库，如上。OK，通过这个脚本，我们在AndroidStudio Terminal窗口下执行”gradlew shadowJar“，我们可以看到BUILD SUCCESSFUL，欢呼吧，雀跃吧。我觉得我解决了天大的问题，是能比肩中国四大发明的创举。然后拿到build/libs下的我通过脚本生成的这个library.jar，使用压缩软件打开看下，嗯嗯，确实是每个依赖库的代码也在，但是rxandroid这个依赖库是以aar形式进行依赖的，这需要我们手动拷贝出来，然后将对应的依赖库classes.jar获取。行，我想现在所要用到的第三方库就齐全了吧，正常接入，跑起来。What the fuck。Ru'ntimeException，未找到okio的什么类。咦，确实是，okhttp似乎是依赖okio使用的，但是gradle依赖无需再次引用该依赖，这就使我们打包的时候缺失了该第三方库了。寻找解决办法，我现在需要知道所有依赖库的依赖关系，我不可能一个个依赖去查对应的资料，是否有进行依赖吧。怎样可以知道整个依赖树关系呢，gradle通过命令可以查找，但是这个命令实在繁琐，AndroidStudio有个插件叫gradle view，可以看到当前项目的依赖树关系。如图：

　　原来，我刚刚打包的jar确实是有依赖其他第三方库的，得到答案，那我们就查缺补漏，将依赖关系树中未依赖的第三方库进行在gradlr脚本中进行依赖，然后再次执行脚本文件，同样，build成功，拿到jar替换刚刚生成的不全面的jar包，打包，运行，运行无误。

　　以上，就是我对一些需求不复杂且未使用特殊第三方库的渠道SDK的依赖库打包获取，从而得到一个完整的SDK依赖。在这里有那么几个缺点：

　　1、例如v7这些依赖，使用很多android资源的，见仁见智吧，可以不依赖，单独去sdk里面拿v7这个jar和资源，也可以依赖打包，但资源文件还是需要去sdk里拿到的；

　　2、例如rxandroid依赖的aar，我们通过脚本打包进去的也是rxandroid的aar文件，我们还需要将他单独拿出来，并确认aar中res下有没有资源文件，有则也需要获取。这个问题，我们可以写个脚本，解压aar，拷贝jar，如果有资源则复制合并资源，在我印象中，依赖库除了android本身的带有资源，其他还没见到过带有res资源文件的，所以这不是一个很大的问题，自己有sdk，有脚本，需要的都是能拿到的，这个脚本后面有空再更新上来。

　　3、例如海外渠道，用到google服务的等一些特殊需求时，比如google-service.json文件，在gradle下会打包自动编译的，这些问题就相对比较麻烦，虽然是有方法集成到eclipse下，还是建议U8的解决方案。

　　虽然这个方案不是一个最棒的方案，小小的特殊需求寻求小小的特殊方法解决，对于国内渠道来说解决了公司聚合SDK接入方式困境，最主要的是方便，能统一在eclipse下维护更新SDK。