AndroidはAPP環境分離を実現する（Graadleを利用する）
一、環境分離の紹介
各アプリプロジェクトには少なくとも二つの環境があります。テスト環境と生産環境。多くは4つの環境があります。開発環境、テスト環境、前生産環境と生産環境です。開発者は常に環境間で切り替える必要があります。テストスタッフも同じです。よくテストスタッフが現れます。今日は環境テストの最新バージョンが必要です。アプリ開発者に彼女に一つ包装させます。明日は生産バージョンに切り替えて、アプリ開発者に生産環境の一つを包装させます。私達は知っています。一つのアプリは携帯電話で環境をテストするか、それとも生産環境しかないです。テストスタッフが二つの環境をテストして、異なる環境の同じアプリを交替するしかないです。これは本当に面倒くさいです。この問題を解決するために一番いい案は環境分離で、環境によって違うアプリがあります。
しかし、Androidアプリにとって、同じパッケージ名のアプリは同じデバイスに一つしか存在しません。ですから、同じ設備に生産環境とテスト環境のインストールパッケージを同時に取り付けることはできません。これは日常の開発作業とテスト人員のテスト作業にとってとても不便です。プロジェクト全体をコピーすることはできません。パッケージ名を修正して別のアプリに包装してください。このような場合には、通常のやり方は、appで隠しエントリを提供し、内部人員にサーバーのアドレスを切り替えるために、次のコードを通じてAppを再起動することです。
二、packageとappication Id
Eclipseを用いたAppや旧バージョンのGrade構築システムでは、アプリケーションのパケット名はAndroid dManifest.xmlファイルでpackageの属性によって決定されます。また、このPackageは、参照されるリソースクラスRファイルという名前を定義するためにも使用される。
しかし、新しいAndroid Grade構築システムにおいて、package属性の2つの大きな役割は、アプリケーションの一意識別子（パケット名）として、異なるアプリケーションを区別するために使用されることを理解する。package属性は、リソースクラスRファイルを定義し、参照に使用する。
apple/build.gradleファイルに存在するdefaultConfigの設定の下で、新規プロジェクトの場合は、デフォルトではpackage属性値を使って初期化しますので、特別な需要がない場合は、この値を気にしないで修正します。
三、Build Varants
プロジェクトのproductFlaavorsとbuildTypesの構成は、ap/build.gradleコードファイルまたはProject Structure上で修正できます。役割は同じです。
四、productFlaavors
プロジェクトは複数の異なるproductFlaavorsを定義することによって、アプリケーションの異なるカスタマイズバージョンを実現できます。各FlavorはbuildTypesと協力して出力タイプのappkファイルを出力します。新規プロジェクト初期化は一つのデフォルトFlavor:defaultConfigだけです。
注意：デフォルトのdefaultConfigは、新規作成されたproductFlaavorsに基本的な構成を提供します。つまり、productFlaavorsの配置はdefaultConfigの同じ属性をカバーし、製品の異なるカスタマイズ版の出力を実現します。環境分離については、ここでは、新しいappication Id属性を定義することにより実現され得る。
五、buildTypes
デフォルトでは、プロジェクトのbuildTypesはdebugとreleaseの2つのビルドバージョンを含んでいますが、releaseバージョンの実行には署名ファイルを手動で設定する必要があります。環境分離については、productFlavoorsとは違って、buildTypesは、aplication IdSuffixを定義することによって実現される。すなわち、拡張子名を追加する。
これらの設定可能な属性以外に、productFlaavorsとbuildTypeはそれぞれのsourceSetを通じてコードとリソースを提供します。デフォルトのパスは、src/flavoorNameとsrc/typeNameです。この特性を利用して、異なるカスタマイズバージョンのappkが異なるアプリケーション名とデスクトップアイコンを表示し、デバイスから区別することができます。
productFlaavorsとbuildTypesはさまざまなフォーマットで「flavoorName＋typeName」のBuild Varantsを生産して、異なるバージョンのappkを包装します。flavoorsをカスタマイズしていない場合は、デフォルトのdefaultConfigもbuildTypesに対応するBuild Veriantsを形成します。名前がないので、debugとreleaseとして表示されます。例えばこの設定:
注意：前に述べたように、buildTypesは、拡張子を追加することにより、aplication Id（パッケージ名）を修正し、言い換えれば、productFlaavorsに基づいてパッケージ名を変更します。したがって、上記の例では、betaRelease構築タイプのパッケージ名は、comp.yifeeng.mdstudysamples.beta.debugである。
五、実現方式
これらの紹介を通して、基本的にはAndroidでappの環境分離がどのように実現されているかを知ることができます。私たちはproductFlavoorsとbuildTypesの2つの方法を使って同じデバイスに同じアプリケーションの異なるバージョンをインストールすることができます。彼らは理屈は同じですが、buildTypesを使ってプロダクトFlaavorsを新しく作らなくてもいいです。もっと便利です。ここではbuildTypesを例にとって環境分離の実現について簡単に説明します。
1.デフォルトのproductFlavoorsとbuildTypesの設定項目については、debug設定のappration IdSuffix属性を修正し、「.debug」（名前は任意に設定できます）に設定して、releaseバージョンは変更しません。
2.srcディレクトリの下でdebugディレクトリを作成し、メインディレクトリのresディレクトリをdebugディレクトリにコピーして、各解像度のデスクトップIconとstrigs.xmlファイルのアプリケーション名を修正し、debugマークを付けます。ディレクトリ構造を図に示します。
パッケージを構築する時、debugディレクトリのresリソースは重ね合わせでメーンに統合され、同じ内容を交換します。この例はデスクトップIconとアプリケーション名だけを修正する必要があります。ここではresディレクトリの関連ファイルだけをコピーしました。他のファイルはコピーされていません。
3.コードの中のサーバーインターフェースのアドレスを修正し、対応するBuild Varantsタイプを選択して、実行すればいいです。実際には、debugとmainディレクトリの下のstring.xmlリソースファイルにサーバアドレスを定義して、プログラムの入り口でコードの中のグローバル静的変数に値を付けてもいいです。
締め括りをつける
以上はこの文章の全部の内容です。皆さんの勉強や仕事に一定の助けを与えてほしいです。もし疑問があれば、メッセージを残して交流してもいいです。
各アプリプロジェクトには少なくとも二つの環境があります。テスト環境と生産環境。多くは4つの環境があります。開発環境、テスト環境、前生産環境と生産環境です。開発者は常に環境間で切り替える必要があります。テストスタッフも同じです。よくテストスタッフが現れます。今日は環境テストの最新バージョンが必要です。アプリ開発者に彼女に一つ包装させます。明日は生産バージョンに切り替えて、アプリ開発者に生産環境の一つを包装させます。私達は知っています。一つのアプリは携帯電話で環境をテストするか、それとも生産環境しかないです。テストスタッフが二つの環境をテストして、異なる環境の同じアプリを交替するしかないです。これは本当に面倒くさいです。この問題を解決するために一番いい案は環境分離で、環境によって違うアプリがあります。
しかし、Androidアプリにとって、同じパッケージ名のアプリは同じデバイスに一つしか存在しません。ですから、同じ設備に生産環境とテスト環境のインストールパッケージを同時に取り付けることはできません。これは日常の開発作業とテスト人員のテスト作業にとってとても不便です。プロジェクト全体をコピーすることはできません。パッケージ名を修正して別のアプリに包装してください。このような場合には、通常のやり方は、appで隠しエントリを提供し、内部人員にサーバーのアドレスを切り替えるために、次のコードを通じてAppを再起動することです。
private void restartApp(){
Intent intent = getContext().getPackageManager().getLaunchIntentForPackage(getContext().getPackageName());
intent.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP);
startActivity(intent);
}二、packageとappication Id
Eclipseを用いたAppや旧バージョンのGrade構築システムでは、アプリケーションのパケット名はAndroid dManifest.xmlファイルでpackageの属性によって決定されます。また、このPackageは、参照されるリソースクラスRファイルという名前を定義するためにも使用される。
しかし、新しいAndroid Grade構築システムにおいて、package属性の2つの大きな役割は、アプリケーションの一意識別子（パケット名）として、異なるアプリケーションを区別するために使用されることを理解する。package属性は、リソースクラスRファイルを定義し、参照に使用する。
apple/build.gradleファイルに存在するdefaultConfigの設定の下で、新規プロジェクトの場合は、デフォルトではpackage属性値を使って初期化しますので、特別な需要がない場合は、この値を気にしないで修正します。
apply plugin: 'com.android.application'
android {
compileSdkVersion 19
buildToolsVersion "19.1"
defaultConfig {
applicationId "com.example.my.app"
minSdkVersion 15
targetSdkVersion 19
versionCode 1
versionName "1.0"
}
...三、Build Varants
プロジェクトのproductFlaavorsとbuildTypesの構成は、ap/build.gradleコードファイルまたはProject Structure上で修正できます。役割は同じです。
四、productFlaavors
プロジェクトは複数の異なるproductFlaavorsを定義することによって、アプリケーションの異なるカスタマイズバージョンを実現できます。各FlavorはbuildTypesと協力して出力タイプのappkファイルを出力します。新規プロジェクト初期化は一つのデフォルトFlavor:defaultConfigだけです。
注意：デフォルトのdefaultConfigは、新規作成されたproductFlaavorsに基本的な構成を提供します。つまり、productFlaavorsの配置はdefaultConfigの同じ属性をカバーし、製品の異なるカスタマイズ版の出力を実現します。環境分離については、ここでは、新しいappication Id属性を定義することにより実現され得る。
五、buildTypes
デフォルトでは、プロジェクトのbuildTypesはdebugとreleaseの2つのビルドバージョンを含んでいますが、releaseバージョンの実行には署名ファイルを手動で設定する必要があります。環境分離については、productFlavoorsとは違って、buildTypesは、aplication IdSuffixを定義することによって実現される。すなわち、拡張子名を追加する。
これらの設定可能な属性以外に、productFlaavorsとbuildTypeはそれぞれのsourceSetを通じてコードとリソースを提供します。デフォルトのパスは、src/flavoorNameとsrc/typeNameです。この特性を利用して、異なるカスタマイズバージョンのappkが異なるアプリケーション名とデスクトップアイコンを表示し、デバイスから区別することができます。
productFlaavorsとbuildTypesはさまざまなフォーマットで「flavoorName＋typeName」のBuild Varantsを生産して、異なるバージョンのappkを包装します。flavoorsをカスタマイズしていない場合は、デフォルトのdefaultConfigもbuildTypesに対応するBuild Veriantsを形成します。名前がないので、debugとreleaseとして表示されます。例えばこの設定:
android {
...
productFlavors{
beta{
applicationId 'com.yifeng.mdstudysamples.beta'
}
production{
applicationId 'com.yifeng.mdstudysamples'
}
}
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
debug {
applicationIdSuffix '.debug'
}
}
}注意：前に述べたように、buildTypesは、拡張子を追加することにより、aplication Id（パッケージ名）を修正し、言い換えれば、productFlaavorsに基づいてパッケージ名を変更します。したがって、上記の例では、betaRelease構築タイプのパッケージ名は、comp.yifeeng.mdstudysamples.beta.debugである。
五、実現方式
これらの紹介を通して、基本的にはAndroidでappの環境分離がどのように実現されているかを知ることができます。私たちはproductFlavoorsとbuildTypesの2つの方法を使って同じデバイスに同じアプリケーションの異なるバージョンをインストールすることができます。彼らは理屈は同じですが、buildTypesを使ってプロダクトFlaavorsを新しく作らなくてもいいです。もっと便利です。ここではbuildTypesを例にとって環境分離の実現について簡単に説明します。
1.デフォルトのproductFlavoorsとbuildTypesの設定項目については、debug設定のappration IdSuffix属性を修正し、「.debug」（名前は任意に設定できます）に設定して、releaseバージョンは変更しません。
android {
...
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
debug {
applicationIdSuffix '.debug'
}
}
}2.srcディレクトリの下でdebugディレクトリを作成し、メインディレクトリのresディレクトリをdebugディレクトリにコピーして、各解像度のデスクトップIconとstrigs.xmlファイルのアプリケーション名を修正し、debugマークを付けます。ディレクトリ構造を図に示します。
パッケージを構築する時、debugディレクトリのresリソースは重ね合わせでメーンに統合され、同じ内容を交換します。この例はデスクトップIconとアプリケーション名だけを修正する必要があります。ここではresディレクトリの関連ファイルだけをコピーしました。他のファイルはコピーされていません。
3.コードの中のサーバーインターフェースのアドレスを修正し、対応するBuild Varantsタイプを選択して、実行すればいいです。実際には、debugとmainディレクトリの下のstring.xmlリソースファイルにサーバアドレスを定義して、プログラムの入り口でコードの中のグローバル静的変数に値を付けてもいいです。
締め括りをつける
以上はこの文章の全部の内容です。皆さんの勉強や仕事に一定の助けを与えてほしいです。もし疑問があれば、メッセージを残して交流してもいいです。