青团社拆包依赖-QDepend

青团社业务发展愈发多样，Android使用模块化设计进行业务的解耦，在代码都解耦上我们已经有一套方案，但在工程的模块化设计上，还缺少一个成熟的方案。

在前期模式过程中，我们在component_task模块上率先进行了尝试，结合当时的需求和场景，我们使用率git submodule和pin工程来实现task工程的管理。

git submodule 将代码都版本管理从主工程中抽离，实现在多个主工程中代码的同步
pin工程细化业务粒度，实现不同flavor下的特定代码实现

改设计上开发一段时间后，git submodule暴露了一些问题：

学习成本，需要学习git submodule的一些命令和思想，尤其是commit id的概念
代码稳定性不可靠，主工程对task的依赖实际是通过commit id进行依赖，多人开发下会出现下拉代码，commit id并不会自动去更新本地的task工程，因此可能会导致未处理的情况下提交代码覆盖了线上的最新commit id

虽然在生产环境下会对commit id进行校验，但独立主工程的版本管理，版本号的缺失，以及维护成本确实对开发不够友好。

为了提高代码稳定性，设计了一套新的依赖管理，在效率上较submodule低一些，但代码稳定性有很大的保障，责任划分也更加明确。

gradle中的依赖

gradle中主要有三种依赖类型

module
project
file

module依赖最简洁，只需要将对应的仓库路径添加进去即可：

    implementation 'com.google.code.gson:gson:2.8.5'

project需要配置setting和build文件

depend1.png

在开发期会倾向于使用project对业务模块进行开发，在打包或者不需要开发的模块使用module依赖方式，手动配置需要改动多个文件，效率低。

QDepend

一键切换依赖模式，确保生产环境aar版本依赖，开发环境动态依赖

对整个切换逻辑进行封装，作为一个plugin添加到maven中，方便实用。

depend2.png

Android Stuido中传统的多module工程结构如下：

├── app
├── component_jobs
├── component_login
├── component_me

QDepend改造后的工程，将原有的module抽离，工程中只含有一个app主module，内部提供maven依赖各个模块

├── app

module作为单独的component库，有独立的git管理，默认的目录结构是与工程平级

├── DrinkWater
│   └──  app
├── component_jobs
├── component_login
├── component_me

在切换maven依赖和本地project依赖时，只需配置module_map.properties中的开关位即可

使用

在一个新的工程中，我们需要手动适配QDepend插件，进行如下操作：

在gradle/depend目录下添加module_map.json
工程目录下添加module_map.properties
setting.gradle添加com.qtshe.setting插件
app/build.gradle添加com.qtshe.depend插件

改造流程

1.添加module_map.json

module_map.json按照特定的数据格式配置，添加需要动态控制的module

{
  "libs": [
    {
      "name": "homepage",
      "group": "com.qtshe.mobile.component",
      "path": "../component_homepage"
    },
    {
      "name": "me",
      "group": "com.qtshe.mobile.component",
      "path": "../component_me"
    }
  ]
}

其中：

name: 对应的module project名
group: 在maven中group字段
path: 本地的module路径

qdepend1.png

比如gson的依赖：

 implementation 'com.google.code.gson:gson:2.8.5'

name:com.google.code.gson

group:gson

2.添加module_map.properties

module_map.properties作为动态依赖的开关，把需要的module name设置为true即可，注意必须在json中存在：

homepage = false
me = true

以上会对me模块替换成本地依赖

qdepend2.png

3.setting.gradle修改

需要引入plugin，注意setting不属于build script，所以要单独添加classpath

include ':QtsCustomer'

buildscript {
    repositories {
        maven { url "http://xxxx/nexus/content/repositories/releases/" }
        maven { url "http://xxxx/nexus/content/repositories/snapshots/" }
        google()
        jcenter()
    }

    dependencies {
        classpath 'com.qtshe.mobile:dependencies:1.1.1-SNAPSHOT'
        classpath 'com.google.code.gson:gson:2.8.5'

    }
}
apply plugin:"com.qtshe.setting"

qdepend3.png

4.build.gradle

因为要使用插件，所以需要在根目录的build.gradle中添加classpath

buildscript {
    repositories {
        maven { url "http://xxxx/nexus/content/repositories/releases/" }
        maven { url "http://xxxx/nexus/content/repositories/snapshots/" }
        google()
        jcenter()
        ……
    }
    dependencies {
        ……
        classpath 'com.qtshe.mobile:dependencies:1.1.1-SNAPSHOT'
        classpath 'com.google.code.gson:gson:2.8.5'

    }
}

同时在build.gradle中应用插件

apply plugin: "com.qtshe.depend"

qdepend4.png

适配好后只需要修改module_map.properties就可以实现切换

依赖库的管理

一个完整的maven依赖包含group，module，version三部分。

模块化开发中规范如下：

所有都component都以com.qtshe.mobile.component作为group。
module命名以flavor-module格式，如趣喝水的login模块：drinkwater-login
开发版：DEV-SNAPSHOT；正式版：verison_name.xx 如趣喝水login：1.0.0.1

开发模式

开发阶段会涉及到频繁的修改代码，本地开发时可以通过QDepend切换本地模式即可，但实际情况往往是多人协助开发，以及提测时jenkins上不断的修复bug更新代码，因此开发模式可以将依赖改为snapshot模式，以下是趣喝水开发阶段的component依赖：

    implementation 'com.qtshe.mobile.component:drinkwater-common:1.0.6'
    implementation ('com.qtshe.mobile.component:drinkwater-login:DEV-SNAPSHOT'){
        exclude group:'com.qtshe.mobile.component', module:'drinkwater-common'
    }
    implementation ('com.qtshe.mobile.component:drinkwater-me:DEV-SNAPSHOT'){
        exclude group:'com.qtshe.mobile.component', module:'drinkwater-common'
    }
    implementation ('com.qtshe.mobile.component:drinkwater-jobs:DEV-SNAPSHOT'){
        exclude group:'com.qtshe.mobile.component', module:'drinkwater-common'
    }

SNAPSHOT会在每次下拉代码时拉取最新的依赖，保证协助开发的同步和打包机出包代码的时效性

如何生成SNAPSHOT?

工程中已经集成了nnaven_publish.gradle，在rootProject下执行如下命令即可更新本地依赖的module到仓库中：

./gradlew qpublish

该脚本需要结合component中的maven.properties文件：

# module的版本
MODULE_VERSION=1.0.6
# module的maven名
MODULE_ID=common
# 标记不生成SNAPSHOT
IS_LIB=true

其中IS_LIB是为了剔除common等lib，IS_LIB标记后不会生成SNAPSHOT，标准的component工程不需要添加。

为了保证snapshot刷新的时效性，工程配置了cacheChangingModulesFor刷新时间：

    configurations.all{
        resolutionStrategy.cacheChangingModulesFor 0, 'seconds'
    }

实时刷新可能会影响编译速度，不需要的话可以在rootProject的properties中修改标志位：

# is refrsh snapshot
REFRESH_SNAPSHOT = false

正式环境

在提测接近结束时，需要将更新过的component进行发版。具体步骤如下：

1.版本需要指定版本号，更新component下的maven.gradle文件：

# module的版本
MODULE_VERSION=1.0.0.1
# module的maven名
MODULE_ID=common

将MODULE_VERSION指定为最新版本，版本号的规则约定如下：

"${version_name}.x"

比如趣喝水初版版本为1.0.0，对应的component版本号为：1.0.0.1到1.0.0.99，期间可能还存在代码修改的情况，因此预留两位用于更新

2.提交代码到远程仓库

将component的代码更新到release/xxx上，xxx为指定的flavor，如release/drinkwater。

在QDepend中 component的release/xxx类似git flow中的master，可以添加权限，以及用于code review

3.ModuleToMaven上执行打包命令

通过jenkins，选择需要更新的component和flavor，然后build

jenkins_module_to_maven.png

4.更新工程的依赖

将项目中对component的依赖更新到固定版本：

implementation 'com.qtshe.mobile.component:drinkwater-login:1.0.0.1'

5.发版文档更新

每个项目都有有自己的wiki文档，开发负责人需要发版前进行更新

q_depend_wiki.png