爲什麼構建類型與產品口味不同？

Question

前言：這不是一個關於如何在Android應用程序中使用構建類型和產品風格的問題。我瞭解所涉及的基本概念。這個問題更多的是試圖瞭解哪些配置應該在構建類型中指定，哪些配置應該在產品風格中指定，以及是否有必要進行區分。

本週，我一直在學習更多關於Android應用程序的gradle配置。我最初認爲自己對構建類型和產品風格有很好的把握，但是我越深入瞭解文檔，就越意識到兩者之間的區別對我來說根本不清楚。

由於有一個定義良好的層次結構（從構建類型中指定的屬性優先於產品風格中指定的屬性），我不明白爲什麼需要區分構建類型和產品口味在所有。將所有屬性和方法合併到產品風格DSL對象中，然後將構建類型作爲（默認）風格維度對待會不會更好？

一些具體的例子，導致我的困惑：

• 的signingConfig屬性可以在兩種類型的建設和產品的口味......但minifyEnabled（？而且，我認爲，shrinkResources）設置只能是在構建類型中配置。

• applicationId只能在產品口味中指定......而applicationIdSuffix只能在生成類型中指定！？

的實際問題（S）：

在上述的例子：有構建類型的產品VS口味的角色之間有明顯的區別？

如果是這樣，理解它的最好方法是什麼？

如果不是，計劃是否最終將構建類型和產品風格合併到一個可配置的DSL對象中？

Answer 1

擴展@CommonsWare在評論中所說的內容，其基本思想是，構建類型適用於應用程序的不同構建，這些構建在功能上並不不同 - 如果您有應用程序的調試和發佈版本，重新使用相同的應用程序，但其中一個包含調試代碼，可能還有更多日誌記錄等，另一個應用程序經過簡化和優化，並可能通過ProGuard進行混淆。隨着口味，意圖是應用程序在某種程度上是明顯不同的。最明顯的例子是免費或付費版本的應用程序，但開發人員也可能根據其分發位置（這可能會影響應用內API帳戶使用）進行區分。

有開發人員爲不同的客戶製作了許多類似應用程序的不同版本 - 例如，可能是一個簡單的應用程序，它在Web視圖中打開網頁，併爲每個版本提供不同的URL和品牌信息 - - 這是一種很好用的口味。

重申一下，如果它是「同一個應用程序」，模塊化一些對最終用戶並不重要的差異，尤其是如果除一個之外的所有變體都用於您自己的測試和開發使用，並且只有一個變體將被部署到最終用戶，那麼它是構建類型的一個很好的候選人。如果它是「不同的」應用程序，並且多個變體將被部署給用戶，那麼它可能是產品風格的候選者。

您已經看到，構建類型和風格之間存在一些功能差異，因爲一些選項支持一種，而另一種則不支持。但即使它們相似，概念也是不同的，並且沒有計劃將它們合併在一起。

Answer 2

buildType配置如何打包我們的應用程序

• shrinkResources
• progaurdFile
• 等

味配置不同的類和資源。

• 在Flavor1您的MainActivity可以做一些事情，並在Flavor2不同的實施

• differente應用程序名稱

• 等

每個產品的風味可以有自己的價值觀以下屬性，其中包括基於與defaultConfig相同的屬性：

• applicationId
• minSdkVersion
• targetSdkVersion
• versionCode
• versionName