Gradle多渠道打包实例

版权声明：

本公众号发布的全部文章，均属于原创，版权归本公众号全部。

容许有条件转载，转载请附带底部二维码。

1、前言

在实际的工做中，当接手的App项目逐渐作大的时候，总有一些缘由须要根据需求对项目作一些定制化的维护，例如：三方合做定制、海外版本之类的。可是一般这种方式定制，其大致的框架都是同样的，只是根据不一样的需求点，作部分定制，

本文就这种定制的需求，利用Gradle作一个解决方案。

2、上古时代的作法

曾经，通用的作法是为不一样的专版需求，切出一个git branch出来，而后在这个分支上根据需求，对功能进行定制。每次打包的时候，从这个分支切换代码进行打包、测试、发版。

可是这样存在一个根本上的问题，若是这种专版需求比较多的时候，对于开发而言，一个小小的改动，将它们手工同步到全部的专版分支上，将是一个噩梦。尤为是互联网公司，可能需求每天在变，就会从一个技术活变成一个体力活，而且人工修改，次数多了，不免会有错漏的时候，为了保证质量，同时也加剧了测试的难度。

因此，这种方式如今已是不可取的了。那么，有什么新的方式吗？

3、分清需求，再选方案

全部的技术选型，都要依据实际的业务。当框架的复杂度越高，维护起来就越吃力，因此最好的方案就是在现有的需求之上实现，而且保有可扩展的功能，使之在以后的迭代中，也一样能够胜任。其实就是选个平衡。

那么，若是对于专版需求而言，只是修改一些文案，各个页面的图片等等，这样的小改动，彻底能够经过定制不一样的productFlavors，而后根据名称，去新建对应名称的文件夹，而后替换主项目内，同名的资源文件便可。

实际操做起来，网上已经有大量的例子，而且也不是本文的主题，这里再也不细说。有兴趣的能够自行查阅文档。

那么这种方案的缺陷是什么呢？

它只能简单的适应，在不一样的专版之间，只是替换一下各项资源。若是有更复杂的定制功能，它是无法知足的，例如：不一样的版本依赖不一样的SDK。赶上这样的状况，会将全部专版须要的jar包、so等打在一块儿，这样无形中增大的apk安装包的体积。

4、不一样专版，不一样SDK如何解决？

若是赶上不一样专版，须要接入不一样的SDK去实现，这样的状况下，一样能够经过Gradle来处理这样的状况。

简单的思路：

在主项目以外，经过新建Module（Android Library）的方式，把不一样专版间须要改动的地方抽取出来。而后将它们与主项目链接的地方抽象出来，作成接口去作交互。

也就是说，除了主项目Module以外，其余的每一个专版做为一个Module存在在项目中，这样能够分别维护本身的定制逻辑，而且全部资源分开来配置，引用的包也是分开的，同事不会增长Apk安装包的体积。

5、举个例子

首先，须要把现有的项目拆分，那些功能是能够容许专版定制的，那些功能是共有的部分。

举个例子，一个视频播放的App，须要用户登陆，进入以后，能够购买视频进行播放，那么这样一个App，简单的进行功能上的拆分，能够拆出以下的流程。

![Uploading gradle_module_444571.png . . .]
](http://upload-images.jianshu....

从上图能够看出，除了视频播放这个功能是通用的，其余的逻辑都是须要在不一样的专版之间作定制，可能购买就须要使用不一样合做方的SDK等等。

把功能拆分出来以后，就能够开始着手干了，下面以一个简单的例子说明一下。

新建一个项目，而且在项目内再新建多个Module。记在，这里须要选择Android Library。这种类型的Module，能够编译成arr的包，就能够携带布局文件和so等资源。

用Android Library的方式，新建两个Module，分别表示国内版本（inland）和海外版本（overseas）。

构建好以后，在不一样的Module下，分别设定一样一个Activity，完成以后，项目结构以下。

已经到这一步基本上完成了编码的工做，后面就须要配置主Module的build.gradle文件了。

主要须要配置的地方，已经红线标注出来了。

须要制定productFlavors，设定两个版本须要配置的基本信息。而后在dependencies中为不一样的版本，作不一样的引用，格式就是xxxCompile便可。

由于是个demo，在MainActivity只有一个简单的按钮，点击跳转到LoginActivity。而这里用dependencies制定了不一样版本跳转的LoginActivity页面。到这里就能够直接使用了。

在AS的Build Variant窗口，选择须要运行的版本。就能够在手机上运行不一样的版本进行调试。

这里只是简单的提供思路，具体Gradle每一个字段表示什么意思。这个仍是须要查看一下文档，每一个版本的格式可能略有不一样。

技术以外

这里的技术难点在于，如何将现有项目拆分，如何把拆分后的模块，用接口的形式抽象出来。

那么，在技术以外，还有什么难点？

1. 须要和产品协调，共有逻辑尽可能不要对专版进行单独定制。若是必要定制，只是简单替换资源图片。

2. 须要和设计协调，在出设图的时候，对共有部分UI，不要有对专版的定制UI便可。

用多Module的方式重构了项目以后，核心的问题就是在于如何和多方协调不要在共有的部分进行定制，要么都改，要么就保持原样。