Android 앱 환경 분리 실현(Gradle 활용)

환경 분리 안내
모든 App 프로젝트 는 적어도 두 가지 환경 이 있 습 니 다.테스트 환경 과 생산 환경 입 니 다.심지어 네 가지 환경 이 있다.개발 환경,테스트 환경,예비 생산 환경 과 생산 환경 이다.개발 자 들 은 환경 간 전환 이 필요 하고 테스트 인원 도 마찬가지다.테스트 인원 들 이 오늘 환경 을 테스트 해 야 하 는 최신 버 전이 자주 나 옵 니 다.앱 개발 자 에 게 포장 해 달라 고 합 니 다.내일 은 생산 버 전 으로 전환 하고 앱 개발 자 에 게 생산 환경 을 포장 해 달라 고 합 니 다.우 리 는 하나의 앱 이 한 대의 휴대 전화 에서 환경 을 테스트 할 수 있 거나 생산 환경 만 테스트 할 수 있다 는 것 을 안다.테스트 인원 이 두 환경 을 테스트 하려 면 서로 다른 환경의 같은 앱 을 계속 바 꿀 수 밖 에 없다.이것 은 정말 번거롭다.이 문 제 를 해결 하기 위해 가장 좋 은 방안 은 환경 분리 이 고 환경 에 따라 앱 이 다르다 는 것 이다.
그러나 안 드 로 이 드 앱 의 경우 같은 패키지 이름 의 apk 는 같은 장치 에 하나만 존재 할 수 있 습 니 다.그래서 우 리 는 같은 설비 에 생산 환경 과 테스트 환경의 설치 패 키 지 를 동시에 설치 할 수 없 기 때문에 일상적인 개발 작업 과 테스트 인원 의 테스트 작업 에 매우 불편 하 다.전체 프로젝트 를 복사 할 수 는 없 으 니 가방 이름 을 수정 하 는 방식 으로 다른 apk 를 포장 하 세 요.그래서 이런 상황 에서 예전 에 흔히 볼 수 있 었 던 방법 은 app 에서 스텔스 입 구 를 제공 하여 내부 자 들 이 서버 주 소 를 전환 시 킨 다음 에 다음 코드 를 통 해 App 을 다시 시작 하 는 것 이다.

private void restartApp(){
 Intent intent = getContext().getPackageManager().getLaunchIntentForPackage(getContext().getPackageName());
 intent.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP);
 startActivity(intent);
}

분명히 이런 방법 도 일종 의 완병책 일 뿐,다소 만 족 스 럽 지 못 하 다.그러나 다행히도 안 드 로 이 드 스튜디오 시대 에 접어 들 면서 구 글 은 Gradle 구축 시스템 을 도입 하기 시 작 했 고 applicationId 의 등장 으로 환경 분리 문제 가 쉽게 해결 되 었 다.
2.package 와 applicationId
Eclipse 를 사용 하여 APK 나 이전 버 전의 Gradle 구축 시스템 을 개발 할 때 사용 할 패키지 이름 은 AndroidManifest.xml 파일 에서 package 속성 에 의 해 결 정 됩 니 다.또한 이 패 키 지 는 인 용 된 자원 류 R 파일 의 이름 을 정의 하 는 데 도 사 용 됩 니 다.
그러나 새로운 Android Gradle 구축 시스템 에서 package 속성의 두 가지 역할 은 연근 을 알 수 있 습 니 다.applicationId 는 응용 프로그램의 유일한 식별 자(패키지 이름)로 서 서로 다른 응용 을 구분 하 는 데 사 용 됩 니 다.package 속성 은 자원 클래스 R 파일 을 정의 합 니 다.참조 에 사용 합 니 다.
applicationId 는 app/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"
 }
 ...

따라서 APK 의 환경 분 리 를 실현 하려 면 같은 장치 에 같은 응용 프로그램의 다른 버 전 을 설치 해 야 한다.본질 적 으로 우 리 는 applicationId 의 값 을 수정 하고 서로 다른 패키지 이름 을 포장 한 apk 설치 파일 을 구축 해 야 한다.Gradle 구축 시스템 은 개발 자 들 이 applicationId 의 값,produtFlavors 와 buildTypes 를 수정 할 수 있 도록 두 가지 방식 을 제공 합 니 다.이 두 가지 방식 을 통 해 우 리 는 apk 의 포장 맞 춤 형 제작 을 쉽게 실현 하거나 Build Variants(변종 구축)를 쉽게 실현 할 수 있 습 니 다.
3.빌 드 변형
프로젝트 의 produtFlavors 와 buildTypes 설정 은 app/build.gradle 코드 파일 이나 Project Structure 에서 수정 할 수 있 습 니 다.역할 은 같 습 니 다.
4.produtFlavors
프로젝트 는 다양한 produtFlavors 를 정의 하여 다양한 맞 춤 형 버 전 을 구현 할 수 있 습 니 다.각각 Flavor 와 buildTypes 가 결합 하여 출력 형식의 apk 파일 을 만 들 수 있 습 니 다.새 프로젝트 초기 화 는 기본 Flavor:default Config 만 있 습 니 다.

메모:기본 default Config 는 새로 만 든 produtFlavors 에 기본 적 인 설정 을 제공 합 니 다.즉,produtFlavors 의 설정 은 default Config 의 같은 속성 을 덮어 제품 의 서로 다른 맞 춤 형 출력 을 실현 합 니 다.환경 분리 에 대해 서 는 새로운 applicationId 속성 을 정의 하여 실현 할 수 있 습 니 다.
5.buildTypes
기본적으로 프로젝트 의 buildTypes 는 debug 와 release 두 개의 구축 버 전 을 포함 하고 있 으 며,release 버 전의 실행 은 서명 파일 을 수 동 으로 설정 해 야 합 니 다.환경 분리 에 있어 서 produtFlavors 와 달리 buildTypes 는 applicationIdSuffix 를 정의 하여 이 루어 집 니 다.즉,접미사 이름 을 추가 하 는 것 입 니 다.

설정 가능 한 속성 을 제외 하고 produtFlavors 와 buildTypes 는 각각 sourceSet 을 통 해 코드 와 자원 을 제공 합 니 다.기본 경 로 는 src/flavorName 과 src/type Name 입 니 다.이 기능 을 사용 하면 서로 다른 맞 춤 형 버 전의 apk 에서 서로 다른 응용 이름과 데스크 톱 아이콘 을 표시 하여 장치 에서 구분 할 수 있 습 니 다.
produtFlavors 와 buildTypes 는 다양한 형식의"flavorName+typeName"을 생산 하 는 Build Variants 와 결합 하여 서로 다른 버 전의 apk 를 포장 합 니 다.사용자 정의 flavors 가 없 으 면 기본 defaultConfig 도 buildTypes 와 대응 하 는 Build Variants 를 형성 합 니 다.이름 만 없 기 때문에 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'
 }
 }
}

베타 와 production 두 가지 produtFlavors,release 와 debug 두 가지 buildTypes 를 설정 하 였 습 니 다.따라서 해당 하 는 Build Variants 는 베타 Debug,베타 Release,production Debug,productRelease 등 네 가지 가 있다.Build Variants 창 에서 해당 하 는 빌 드 형식 을 보고 선택 하여 실행 할 수 있 습 니 다.

메모:앞에서 언급 했 듯 이 buildTypes 는 접 두 사 를 추가 하 는 방식 으로 applicationId(가방 이름)를 수정 합 니 다.다시 말 하면 produtFlavors 를 바탕 으로 가방 이름 을 수정 한 것 입 니 다.따라서 위의 예 에서 betaRelease 구축 형식 으로 포 장 된 apk 파일 의 가방 이름 은 com.yifeng.mdstudysamples.beta.debug 입 니 다.
5.실현 방식
위의 소 개 를 통 해 Android 에서 app 의 환경 분 리 를 어떻게 실현 하 는 지 알 수 있 습 니 다.저 희 는 produtFlavors 와 buildTypes 라 는 두 가지 방식 으로 같은 장치 에 같은 버 전 을 설치 할 수 있 습 니 다.그들 은 이치 상 같 지만,그 에 비해 buildTypes 를 사용 하면 새 produtFlavors 를 사용 하지 않 아 도 더욱 편리 하 다.여기 서 buildTypes 를 예 로 들 어 환경 분리 의 실현 을 간단하게 설명 하 겠 습 니 다.
1.기본 produtFlavors 와 buildTypes 설정 항목 에 대해 debug 설정 의 applicationIdSuffix 속성 을 수정 하고"debug"(이름 은 마음대로 설정 할 수 있 음)로 설정 합 니 다.release 버 전 은 변경 하지 않 아 도 됩 니 다.

android {

 ...

 buildTypes {
 release {
  minifyEnabled false
  proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
 }
 debug {
  applicationIdSuffix '.debug'
 }
 }
}

이 단계 가 있 으 면 debug 버 전과 release 의 apk 를 같은 장치 에 설치 할 수 있 습 니 다.debug 버 전의 데스크 톱 아이콘,응용 이름 등 을 수정 하여 구분 하기 편리 하도록 할 수 있 습 니 다.
2.src 디 렉 터 리 에 debug 디 렉 터 리 를 새로 만 들 고 main 디 렉 터 리 에 있 는 res 디 렉 터 리 를 debug 디 렉 터 리 에 복사 하여 각 해상도 에 있 는 데스크 톱 Icon 과 strings.xml 파일 의 응용 이름 을 수정 하고 debug 표 지 를 추가 합 니 다.디 렉 터 리 구 조 는 그림 과 같다.

패 키 지 를 구축 할 때 debug 디 렉 터 리 에 있 는 res 자원 은 중첩 방식 으로 main 에 통합 되 고 같은 내용 을 교체 합 니 다.이 예 는 데스크 톱 Icon 과 응용 이름 만 수정 해 야 하기 때문에 저 는 res 디 렉 터 리 에 있 는 관련 파일 만 복 사 했 습 니 다.다른 파일 은 복사 되 지 않 았 습 니 다.
3.코드 에 있 는 서버 인터페이스 주 소 를 수정 하고 해당 하 는 Build Variants 형식 을 선택 하여 실행 하면 됩 니 다.사실 debug 와 main 디 렉 터 리 에 있 는 string.xml 자원 파일 에서 서버 주 소 를 정의 한 다음 프로그램의 입구 에서 코드 에 있 는 전역 정적 변 수 를 할당 할 수 있 습 니 다.
총결산
이상 이 이 글 의 전체 내용 입 니 다.여러분 의 학습 이나 업무 에 어느 정도 도움 이 되 었 으 면 좋 겠 습 니 다.궁금 한 점 이 있 으 면 댓 글 을 남 겨 주 십시오.