有這樣一個場景：一個專案正在開發，後來領導說有另外一個專案跟當前專案很像，只要在上面改些東西就可以了，然後你一聽立刻把程式碼複製一份在上面改，改完以後領導又說要加一些功能，兩個專案都要加，累死累活做完以後領導又說，後面可能還會有第三個專案，只需要在上面改點東西就可以了， 並且後面加功能這三個專案都要，是不是很崩潰？這該怎麼辦？有沒有一種簡單的方法只需要配置一下就可以了？ 答案是當然有，上節介紹了gradle的基礎配置知識，如果沒有看的話建議先看上面的基礎知識，有個整體瞭解以後本章理解起來會更容易，貼上上一節的連結：   http://www.360doc.com/showweb/0/0/793594973.aspx

一、productFlavors

在android{}下面新增如下程式碼：

productFlavors {
    own {
        
    }

    vores {

    }
}

wangcang和vores是隨便起的名字，意思是工程中目前有兩種配置， 一種配置是wangcang，一種配置是vores，同時會在工程變數中生成四個變數：voresDebug、voresRelease、ownDebug、ownRelease

 它們到底能做什麼呢？ 用處可大了，往下看。

productFlavors {
    own {
        buildConfigField("String"
 
, "AppName", "\"appwangcang3\"")
        applicationId "com.idcs.mobilewc"
        signingConfig signingConfigs.config
        manifestPlaceholders = [
                JPUSH_PKGNAME: applicationId,
                JPUSH_APPKEY : "7eaed6ccd1a84f5620fbae06",  //JPush上註冊的包名對應的appkey.
                JPUSH_CHANNEL
 
: "developer-default", //使用者渠道統計的渠道名稱
                APP_SCHEME: "warehouseno3"
        ]
    }
    vores {
        buildConfigField("String", "AppName", "\"appvores\"")
        applicationId "com.vores.mobile"
	signingConfig signingConfigs.vores
        manifestPlaceholders = [
                JPUSH_PKGNAME: applicationId,
                JPUSH_APPKEY : "fd4711da71114fdfa392ad2d",  //JPush上註冊的包名對應的appkey.
                JPUSH_CHANNEL: "developer-default", //使用者渠道統計的渠道名稱
                APP_SCHEME: "whvoresapp"
        ]
    }
}

首先大家會說buildConfigField是什麼東西， 它其實是給BuildConfig生成一些變數：

buildConfigField("String", "AppName", "\"appwangcang3\"")和buildConfigField("String", "AppName", "\"appvores\"")

String型別一定要用斜槓把字串轉義，不然在BuildConfig.java裡面生成的字串沒有雙引號，就會報錯。

生成這些變數有什麼用呢？

 首先我們想到了工程中生成了四個變數：voresDebug、voresRelease、ownDebug、ownRelease， 當我選ownRelease時候AppName的值就是“appwangcang3”，如果我選擇了voresRelease則值就會變成“appvores”，每次選的時候工程都會重新build，因為他會使用對應own或者vores下面的配置。own和vores下面的配置大家可以仔細看看，裡面有applicationId、signingConfig，manifestPlaceholders。   applicationId改變的是應用程式的包名， signingConfig改變的是app的簽名， manifestPlaceholders改變的是一些變數配置， 每次選擇左下角的四個配置重新編譯後其實就是另一個應用了。

因此當我們在需要動態的初始化一些變數的時候就可以用到BuildConfig裡的變數，根據app來初始化極光推送的key， 就可以這樣寫：

// 初始化到不同app的變數
if (BuildConfig.AppName.equals("appwangcang3")) {
    APP_ID = "";
    bdAppId = "";
    bdApiKey = "";
    bdSecret = "";
} else if (BuildConfig.AppName.equals("appvores")) {
    // vores 重新申請的app key
    APP_ID = "";
    bdAppId = "";
    bdApiKey = "";
    bdSecret = "";
}

看到這裡大家應該明白了， 一套程式碼裡面可以編譯多個工程，在這一套程式碼中可以根據BuildConfig.java裡面的變數來動態初始化第三方庫的key和appId等，根據productFlavors生成的四個變數來配置當前是哪個應用。

二、manifestPlaceholders的使用

manifestPlaceholders可以替換我們在AndroidManifest.xml中提前設定好的變數， 例如：

1. <meta-data

2. android:name="UMENG_APPKEY"

3. android:value="${umeng_app_key}"/>

同一套程式碼如果根據不同的應用來設定不同的值應該怎麼做呢？ 

productFlavors {
    own {
        applicationId "com.proj.config.projectconfig"
        manifestPlaceholders = [

		umeng_app_key: "這是own工程使用的key",
		jpush_app_key:"aaaaaaaaaaaaaaa"
        ]
    }
    vores {
        applicationId "com.proj.vores.projectconfig"
        manifestPlaceholders = [
                umeng_app_key: "這是vores工程使用的key",
		jpush_app_key:"bbbbbbbbbbbbbbbb"
        ]
    }

}

這樣就可以根據上面四個變數的配置直接把值替換到AndroidManifest.xml中