빌드 유형이 제품 맛과 다른 이유는 무엇입니까?

서문 : Android 앱에서 빌드 유형 및 제품 버전을 사용하는 방법에 대한 질문은 아닙니다. 관련된 기본 개념을 이해합니다. 이 질문은 빌드 유형으로 지정해야 할 구성, 제품 플레이버에서 지정해야하는 구성 및 실제로 구별이 필요한지 여부를 이해하려고합니다.

이번 주에는 Android 앱의 gradle 구성에 대해 자세히 배웠습니다. 처음에는 빌드 유형과 제품의 맛에 대해 잘 알고 있다고 생각했지만 문서에 더 깊이 들어가면 둘 사이의 구별이 전혀 명확하지 않다는 것을 깨달았습니다.

잘 정의 된 계층 구조가 있기 때문에 (빌드 유형에 지정된 속성이 제품 버전에 지정된 속성보다 우선한다는 의미에서) 빌드 유형과 제품 버전을 전혀 구분할 필요가없는 이유를 이해하지 못합니다. 모든 특성과 메소드를 제품 플레이버 DSL 오브젝트에 병합 한 다음 빌드 유형을 (기본) 플레이버 차원으로 처리하는 것이 더 좋지 않습니까?

혼란을 초래 한 몇 가지 구체적인 예 :

• signingConfig속성은 빌드 유형 및 제품의 맛을 모두 설정할 수 있습니다 ...하지만 minifyEnabled(그리고, 내가 가정 shrinkResources?) 만 빌드 유형에서 구성 할 수 있습니다.

• applicationId제품 플레이버 applicationIdSuffix에서만 지정할 수 있으며 빌드 유형에서만 지정할 수 있습니다!?

실제 질문 :

위의 예를 감안할 때 : 빌드 유형의 역할과 제품의 맛 사이에 명확한 차이점이 있습니까?

그렇다면 그것을 이해하는 가장 좋은 방법은 무엇입니까?

그렇지 않다면 결국 빌드 유형과 제품 특징을 구성 가능한 단일 DSL 객체로 병합 할 계획입니까?

의견에서 @CommonsWare가 말한 것을 확장하면 기본 유형은 빌드 유형이 기능이 다르지 않은 응용 프로그램의 다른 빌드에 대한 것입니다. 앱의 디버그 및 릴리스 버전이있는 경우 동일한 앱입니다 하나는 디버깅 코드, 더 많은 로깅 등을 포함하고 다른 하나는 간소화되고 최적화되어 있으며 ProGuard를 통해 난독 처리 될 수 있습니다. 풍미로, 의도는 앱이 어떤면에서 현저히 다르다는 것입니다. 가장 명확한 예는 무료 버전과 유료 버전의 앱이지만, 개발자는 배포되는 위치 (인앱 결제 API 사용에 영향을 줄 수 있음)에 따라 차별화 할 수도 있습니다.

서로 다른 고객을 위해 유사한 앱을 여러 가지 다양한 버전으로 만드는 개발자가 있습니다. 예를 들어 웹 뷰에서 웹 페이지를 열고 각 버전마다 다른 URL과 브랜딩을 사용하는 간단한 앱일 수 있습니다. 풍미의 좋은 사용.

다시 말해, "동일한 응용 프로그램"인 경우 최종 사용자에게 중요하지 않은 일부 차이점, 특히 하나를 제외한 모든 변형이 자체 테스트 및 개발 용이며 하나의 변형 만 배포되는 경우 최종 사용자라면 빌드 유형에 적합한 후보입니다. "다른"응용 프로그램이고 여러 변형이 사용자에게 배포되는 경우 아마도 제품 맛의 후보 일 수 있습니다.

이미 빌드 유형과 특징에 약간의 기능 차이가 있음을 보았습니다. 일부 옵션은 지원되지만 다른 옵션은 지원하지 않습니다. 그러나 개념은 비슷하지만 개념이 다르므로 서로 병합 할 계획이 없습니다.

buildType 우리가 앱을 패키징하는 방법을 설정합니다

• shrinkResources
• progaurdFile
• 기타

플레이버는 다양한 클래스와 리소스를 구성합니다.

• Flavor1에서 MainActivity가 무언가를 할 수 있고 Flavor2에서 다른 구현

• 다른 앱 이름

• 기타

각 제품의 풍미는 다음과 같은 속성을 기반으로 다음과 같은 속성 값을 가질 수 있습니다 defaultConfig.

• applicationId
• minSdkVersion
• targetSdkVersion
• versionCode
• versionName

다음은 본질과의 차이를 증류시키는 방법입니다.

• buildType는 IS 어떻게 빌드.
• flavor빌드 의 내용 입니다.

을 build types표시하는 데 사용되는 debug/release다른 인증서 및 활성화와 모드 Proguard또는 debuggable플래그.

는 flavors사용자 정의 기능을 가지고하는 데 사용됩니다 (예를 무료 또는 유료 버전) minimum and target API등 수준, 장치 및 API 요구 사항은 layout, drawable그래서 당신은 다른 다른 코드와 자원을 가지고 있습니다 flavors.