关于重叠包技术在jenkins打包时报错的解决方案

最新推荐文章于 2024-07-17 11:01:02 发布

BruceHurrican

最新推荐文章于 2024-07-17 11:01:02 发布

阅读量2k

点赞数 1

CC 4.0 BY-SA版权

分类专栏： android学习笔记文章标签：解决方案 as

本文链接：https://blog.youkuaiyun.com/BruceHurrican/article/details/51778319

android学习笔记专栏收录该内容

29 篇文章

订阅专栏

本文介绍了一种利用重叠包技术实现Android应用模块化的方案，通过配置Gradle脚本，实现不同业务模块之间的灵活切换及打包。文章详细解释了如何避免因同名文件导致的编译错误，并提供了具体的工程结构示例。

转载请注明出处：
http://blog.youkuaiyun.com/brucehurrican/article/details/51778319

最近公司项目需要进行部分业务模块的抽离，目前我在项目中采用的是重叠包技术，这样我和同事用AS开发时可以通过切换buildtype来进行不同业务模块的切换，编码，打包。

坑点：

打包时，应根据需要的业务模块（即buildtype对应的文件夹）来选择相应的assembleXXX来build,直接build会报错，原因是直接build 会将所有业务模块的包进行build，而这些包对外肯定有一个统一入口(即有一个共同的文件,如 LibActivity.java)。LibActivity.java 在 A 模块中是显示XX地图信息的, 在B 模块中可能就是用来显示XX商城的。同名文件 LibActivity.java在默认build时会全部build 这样会报同名文件错误。
项目组用的是jenkins打包,配置的是用gradle来打包，通过gradle build来编包就会报上述错误。

为了兼顾服务器打包的方便，同时不能增大后期代码维护的成本，在对原有重叠包分业务模块的代码结构不做大改的前提下，通过增加gradle脚本，人为设定在每次build时指定要build的业务type来解决上述问题。

核心代码如下：
工程结构：
demos/src/blue // 业务模块
demos/src/red // 业务模块
demos/src/main // 公共模块
demos/src/test
demos/src/androidTest

demos/buildtypes/red/build.gradle

...
buildTypes{
    red{
        versionNameSuffix 'red'
    }
}
sourceSets{
    main{
        java.srcDirs=['src/main','src/red']
        res.srcDirs=['src/main/res','src/red/res']
    }
}
...

asstudydemo/bruceutils/buildtypes/blue/build.gradle

...
buildTypes{
    blue{
        versionNameSuffix 'blue'
    }
}
sourceSets{
    main{
        java.srcDirs=['src/main','src/blue']
        res.srcDirs=['src/main/res','src/blue/res']
    }
}
...

此两个文件用于替换demos/app/build.gradle,上面两个文件主要是用来在服务器上打包用的。开发人员开发时模块间的切换不用这么麻烦,在demos/app/build.gradle完成如下配置即可

 ...
 buildTypes{
    red{
        versionNameSuffix 'red'
    }
    blue{
        versionNameSuffix 'blue'
    }
}
sourceSets{
    main{
        //java.srcDirs=['src/main','src/blue']
        //res.srcDirs=['src/main/res','src/blue/res']
    }
}
 ...

此时可以通过AS上的 Build Variants功能在相应的业务模块间切换。

那么对于 …/red/build.gradle 和 …/blue/build.gradle这两个文件，jenkins是怎样在打包时分别使用的呢，这里还需要一个复制文件的task。task代码如下:

task typered(type: Copy){
    from 'demos/buildtypes/red/build.gradle'
    into 'demos'
}
task typeblue(type: Copy){
    from 'demos/buildtypes/blue/build.gradle'
    into 'demos'
}

这个复制文件的 task 可以放在 demos/build.gradle 此处记为方法1, 也可以存在于单独的脚本文件中demos/copyfiles.gradle 此处记为方法2.

对于方法1 服务器打包时执行如下命令：

gradle typered
gradle build
生成业务red的apk
gradle typeblue
gradle build
生成业务blue的apk

对于方法2 因为demos/build.gradle 为工程根目录下的gradle脚本,服务器打包时会优先执行该脚本，并顺次招行app/build.gradle脚本，方法2的脚本不在build命令中，如按方法1中命令编译的话，会报 Task typered not found in roo project ‘demos’的错误,此时服务器打包命令就按如下进行：

gradle typered -b ‘demos/copyfiles.gradle’
gradle build
生成业务red的apk
gradle typeblue -b ‘demos/copyfiles.gradle’
gradle build
生成业务blue的apk

坑点1：
各业务模块的build.gradle的名称应和应用build.gradle一致，否则报错。即在本例中，应保证

demos/buildtypes/red/build.gradle
demos/buildtypes/blue/build.gradle
demos/app/build.gardle

三文件名称一致。

坑点2：

如果重叠包应用在app工程下，则blue、red业务模块中可以使用 applicationIdSuffix 属性

blue {
            applicationIdSuffix 'blue'
            versionNameSuffix 'blue'
        }
        red {
            applicationIdSuffix 'red'
            versionNameSuffix 'red'
        }

如果在lib工程下，则 applicationIdSuffix 属性不可用，否则报错。

坑点3：
gradle复制文件脚本时，会有BUG，copyfiles.gradle运行后要替换的文件是 build.gradle，虽然提示运行成功，但是文件并没有替换。对此，我的解决办法是用shell脚本来复制文件不用gradle脚本。

如果你有更好的方法，欢迎不吝赐教^_^

demo下载

参考资料