前沿：

極光推送是我們在實際生活中使用比較多的一種推送方式，成本低廉，不少公司都是使用的他，換工作之後，當前公司還是使用的極光推送。

問題/需求想要效果:

當前的公司需要測試環境的只能夠推送測試，正式環境的只能夠推送正式，應為IOS方存在可以直接通過配置至之後實現當前需求想要的要求，但是android卻沒有，官方提供的是通過建立兩個app來實現測試對測試，正式對正式

官方提供的解決方式:

下面是具體的實現:

開發環境:AS 2.1.1.應為當前專案中也包含微信分享和高德地圖相關的問題，顧本人也提供瞭如何實現包名修改後，其他的如何實現的分享和地圖檢視相關:

1.給專案匯入相關支援的包

1)極光

   //極光推送
    compile 'cn.jiguang.sdk:jpush:3.0.5'
    // 此處以JPush 3.0.5 版本為例。
    compile 'cn.jiguang.sdk:jcore:1.1.2'
    // 此處以JCore 1.1.2 版本為例。

2)其他依賴包，可以更具自己的實際使用來匯入相關包

2.自己通過程式碼實現相關的功能實現

此處省略1萬字，具體實現請根據實際需求實現

3.通過配置話實現需求想要效果

  buildTypes {
        release {
            minifyEnabled false
 

            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
            manifestPlaceholders = [
                    JPUSH_PKGNAME: "包名",
                    JPUSH_APPKEY : "release環境下的key",
                    GAODE_APPKEY:"release環境下高德key",
                    WEATCH_APPID:"relase環境下微信key"
 
,
                    JPUSH_CHANNEL: "developer-default",
                    ]
        }
        debug {
           minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
           manifestPlaceholders = [
                    JPUSH_PKGNAME: "報名.debug",
                    JPUSH_APPKEY : "測試環境下對應的推送key",
                    GAODE_APPKEY:"測試環境下對應的高德地圖key",
                    WEATCH_APPID:"測試環境下微信對應的appid",
                    JPUSH_CHANNEL: "developer-default",
            ]
            }

只要做了上面的操作就可以了，我們編譯之後就可以看到，我們執行平時走的debug環境，打relase的包都是relase環境。就能夠區分開。

缺點：

這樣做的缺點也很明顯，android很多平臺申請都是通過packageName+keystore作為唯一標識，如上的操作，就相當於我們又兩個app，顧很多情況下都需要申請兩套，尤其是在專案還有支付類的時候，就會特別覺得，申請成本比較大。

優勢：

能夠很好的測試對應debug模式，正式對應relase模式，不會正式推送到測試來，測試的也不會推送到正式來，很好的做到了完全區分開。

推薦使用：

這種方法也是極光官方推廣的比較權威的大家認可的方法，也算是比較perfect的方法 。

方法二:通過標籤和別名進行區分[不推薦]

在很多情況下，不少的需求會覺得這樣做成本比較高，他們希望能夠只申請一個應用就完成測試和正式區分開，哪怕產生一些比較明顯的bug，如果你完全不care 系統推送是否推送到時正式還是測試可以通過現在我們要說的方法。這也是極光官方以及本人並不推薦的方法，程式設計師只是需求的實現方，這樣會很明顯的造成測試不便，也沒有比較好的完成需求的要求效果。

一.App端已進入就區分環境並進行設定標籤或者別名，開始分組

  if(Contens.URL.equal(“正式環境”)){
    //註冊別名/標籤
    .....//此處省略一萬字
  }else if(Contens.URL.equal("測試環境")){
    //註冊別名/標籤
    .....//此處省略一萬字
  }

二.這步也需要後端介面人員進行介面支援，需要通過別名或者標籤進行環境判斷

後端實現標籤/別名區分環境進行程式碼寫入
此處省略一萬字

如上這種也是可以實現測試環境和正式環境的區分，但因確定/不足明顯，顧並不推薦使用，在前期公司的專案中，有使用這種方法[方法二]，而最後導致正式測試系統推送混亂，並且測試的時候也不是很方便，尤其是不敢進行通過平臺推送。

希望本篇文章對你有用