做定制版app

为什么要通过Build Variants构建

为什么要使用这种方式来打包？ 
要是换做以前，拿到一个这种需求，我很可能的反应是去稳定版本上checkout一个分支出来，然后改改App名称，改改启动图标、启动页面，去除广告逻辑部分。 
这样当然可以解决当前问题。但是这样做有几个弊端

1. 代码维护麻烦 
   checkout出来一份代码，相当于以后需要维护两个App，两份代码。两个版本咱们可能还不觉得有啥，但是这才一个版本定制，要是以后我们的打豆豆App，不止是要定制小米还要定制360、定制魅族、定制三星。还要区分用户群体，推出有广告版本，无广告版本。推出稳定版和功能升级的Pro版本—超级打豆豆。如果每个版本都拿一个分支来做，需要维护多少个分支？要是版本升级一次，是不是每个分支都要升级？哪得需要多大的工作量。

2. 测试负担加重 
   同样，并不是基于一套代码实现的App，测试的时候不可避免的产生很多重复测试。

3. 配合产品运营效率低下 
   因为，这种方式造成开发缓慢、维护麻烦、测试费时造成产品跟不上节拍，效率低下。

正题—怎么创建

生成定制版App名称

1. 首先，如果换作从前，不考虑Gradle我们修改App名称是怎么做的？ 
   找到AndroidManifest.xml文件，application标签里面的android:label标签存储的是App名称 
   
   看到是通过@string/app_name 也就是values文件夹下面的strings.xml文件里面修改 
    
   看到这里，结合上一篇学到的知识，我们大概已经知道该怎么做了。 
   a. productFlavors里面新建一个渠道号xiaomi {} 
   
   b.然后在src目录、也就是main目录的同级目录里面新建一个叫xiaomi的目录，然后把values/strings.xml拷贝到目录下面，然后修改名称为我们希望显示的名称。 
   
   到这里App名称就改好了

生成定制版图标

有了修改App名称的经验，修改图标也就轻车熟路了，只是存储图标的文件夹，会有hdpi、xhdpi、xxhdpi等等好几个目录，需要一起拷贝过去，然后分别替换里面的图标为我们的图标 

修改启动页

和修改图标一样 

这个图片有点抽象 不要多想，毕竟是艺术

生成广告版和免广告版

使用： 

大功告成，我们来试试效果，为了让我们的定制App和原来的App同时安装上手机，我们修改applicationId

  xiaomi { applicationId 'com.xiaomi.makeapp' }
 
 
1

对比着原版，看看效果 

 

productFlavors（渠道），buildTypes（Debug&Release），原版优先级

现在我们已经清楚了，如productFlavors（渠道）里面的文件会覆盖原来App的文件。 
如果我现在新建一个叫debug的文件夹，对应

buildTypes {
        debug {
            minifyEnabled false
            debuggable true
        }
 
 
1
2
3
4
5

，如果对Debug里面也添加一些启动图标、App名称啥的看看会是什么效果 
，还是运行Build Variant的xiaomiDebug 

变成了Debug里面的设置的信息 
根据

productFlavors > main（默认）
buildTypes > productFlavors
 
 
1
2

我们可以得出规律，为了方便阅读就表达为优先级是：

Release&Debug > 渠道版本定制 > 默认设置
 
 
1

也就是说，高的会覆盖低的设置

AB Test

什么是AB Test

有这样的场景：产品经理遇到困惑，对于一个页面有两个方案方案A和方案B，都觉得不错，不知道应该选哪一个。 
解决办法：方案A和方案B都放到线上，统计用户再每个方案的驻留时长，有效点击，订单转换等等有效数据，然后来计算两个方案的效率，最后取效率高的。 
当然，也可以不使用Build Variants，把两个方案都写到一个页面，然后访问服务器，服务器返指定采用那个方案的方式来实现。

Demo代码：https://github.com/zhouruikevin/makeapp