We've learned how to use build types
to customize Gradle's behavior.
So now let's look at how build variants
allow you to control the behavior of
your app itself.
And depending on which
app we're building,
the Android Gradle plugin creates
a whole slew of source sets.
And depending on which variant you're
building, it will merge the sources and
resources from those source
sets into the final APK.
At the most broad level,
there's the main source set
which is located in source main.
This is where we've been
putting all of our code so far.
Additionally, there's a source set for
each product flavor.
Assuming our example from before,
let's say we have a free and
a paid product flavor.
There's also a source set for each build
type, in this case debug and release.
Finally there's also a source for
each final variant.
So that's source free debug, free
release, paid debug, and paid release.
If we have sources and resources
that we need in a paid flavor but
not in the free flavor,
we can put them in source paid.
Similarly, if there are resources
we need for debug build but not for
the release build,
we can put them in source debug.
Finally, if we have resources
that are needed only for
the paid debug variant, then we can
put them in the source paid debug.
When we build a particular variant,
Gradle will take care of all
the emerging sources and
resources we need for that variant.
It will also take care of a variety of
resources that are defined in more than
one configuration.
The rule is that the more
specific configurations
override the less
specific configurations.
Java's source files
cannot be overwritten, so
you need to be careful that you don't
try to define the same class definition,
and it ends up in multiple variants.
Gradle can do a bit better for
resource files like strings.xml, or
even Android Manifests.
For resources of that type,
the files will be merged, and
the entries will be overridden by ID.
To determine what sources and resources
are included when we build a particular
variant, we can draw a diagram
that looks like this.
We start in the middle.
If we want to build the paid debug
variant, Gradle will include everything
in main, then merge everything in paid,
overriding any conflicts.
Next Gradle will merge in everything
from debug overriding again.
Then, finally,
Gradle will merge in the resources and
source that are in paid debug.
لقد تعلمنا كيفية استخدام أنواع البنية
.لتخصيص سلوك Gradle
لذا لنطَّلع الآن على كيفية إتاحة متغيرات البنية
إمكانية التحكم في سلوك
.التطبيق نفسه
ووفقًا للتطبيق
،الذي نقوم ببنائه
ينشئ مكون Gradle الإضافي لـ Android
.مجموعة كبيرة كاملة من المجموعات المصدر
واستنادًا إلى المتغير الذي تقومون
ببنائه، يدمج المكون المصادر
والموارد من المجموعات
.المصدر هذه إلى مجموعة أدوات APK النهائية
،وعلى أوسع مستوى
توجد المجموعة المصدر الرئيسية
.والتي تقع في القائمة الرئيسية المصدر
وهذا هو مكان
.وضع كافة التعليمات البرمجية حتى الآن
بالإضافة إلى ذلك، هناك مجموعة مصدر لكل
.صفة منتج
،افترضوا المثال الذي تناولناه من قبل
لنقُل أن لدينا صفة منتج مجانية
.وأخرى مدفوعة
وهناك أيضًا مجموعة مصدر لكل نوع
.بنية، في هذه الحالة تصحيح الأخطاء والإصدار
في النهاية، هناك أيضًا مصدر لكل
.متغير نهائي
إذًا لدينا مجموعة مصدر مجانية لتصحيح الأخطاء ومجموعة مصدر
.مجانية للإصدار ومجموعة مصدر مدفوعة لتصحيح الأخطاء ومجموعة مصدر مدفوعة للإصدار
إذا كان لدينا المصادر والموارد
اللازمة في الصفة المدفوعة
،وليس في الصفة المجانية
.فيمكننا وضعها في المجموعة المصدر المدفوعة
وبالمثل، إذا كان لديكم الموارد
اللازمة في بنية تصحيح الأخطاء
،وليس في بنية الإصدار
.فيمكننا وضعها في المجموعة المصدر لتصحيح الأخطاء
وأخيرًا، إذا كان لديكم الموارد
اللازمة فقط
لمتغير بنية تصحيح الأخطاء المدفوعة، فيمكننا
.وضعها في المجموعة المصدر المدفوعة لتصحيح الأخطاء
،عند قيامكم ببناء متغير محدد
يحرص Gradle على كافة
المصادر والموارد الناشئة
.اللازمة لذلك المتغير
وسيحرص أيضًا على مجموعة متنوعة من
الموارد التي تم تعريفها في أكثر من
.تكوين واحد
القاعدة هي أن
التكوينات المحددة الأكثر
تتجاوز التكوينات المحددة
.الأقل
،لا يمكن الكتابة فوق ملفات Java المصدر
لذلك
يجب ألا
،تحاولوا تعيين نفس تعريف الفئة
.فينتهي الأمر بمتغيرات متعددة
يمكن أن يقوم Gradle بأداء أفضل
لملفات الموارد مثل strings.xml، أو
.حتى بيانات Android
،فيما يتعلق بالموارد من ذلك النوع
يتم دمج الملفات
.وتجاوز الإدخالات بواسطة المعرِّف
لتحديد المصادر والموارد
المضمنة عند بناء
متغير محدد، يمكننا رسم مخطط
.يبدو كهذا
.نبدأ في الوسط
،إذا أردنا بناء متغير المجموعة المصدر المدفوعة لتصحيح الأخطاء
يُضمن Gradle كل شيء
،في القائمة الرئيسية ثم يدمج كل شيء في المجموعة المصدر المدفوعة
.متجاوزًا أي تعارض
بعد ذلك، يتم دمج Gradle في كل شيء
.من تجاوز تصحيح الأخطاء مرة أخرى
،وأخيرًا
يتم دمج Gradle في الموارد
.والمصادر الموجودة في المجموعة المصدر المدفوعة لتصحيح الأخطاء
Aprendemos a usar tipos de compilações
para personalizar o comportamento do Gradle.
Agora vamos ver como as variantes de compilação
permitem que você controle o comportamento do
próprio aplicativo.
E de acordo com o aplicativo
que estiver sendo compilado,
o plugin Gradle do Android cria
uma enorme quantidade de conjuntos de origem.
E dependendo da variante que você está
compilando, ela unirá as origens e os
recursos desses conjuntos de origem
em um APK final.
No nível mais amplo,
existe um conjunto principal de origens
localizado na fonte principal.
Aqui colocamos
todos os códigos até agora.
Além disso, há uma origem definida para
cada sabor do produto.
Citando o exemplo de antes,
digamos que temos um sabor do produto gratuito
e um sabor pago.
Há também um conjunto de origens para cada tipo de
compilação, neste caso, depuração e versão.
Além disso, há também uma origem para
cada variante final.
Assim, essa é uma depuração de origem gratuita, versão
gratuita, depuração paga e versão paga.
Se tivermos origens e recursos
que precisamos em um sabor pago, mas
não em um sabor gratuito,
podemos colocá-los em uma origem paga.
Da mesma forma, se tivermos recursos
necessários para a compilação de depuração, mas não para
a compilação de lançamento,
podemos colocá-los na depuração de origem.
Finalmente, se tivermos recursos
necessários só para
a variante de depuração paga, então podemos
colocá-los na depuração de origem paga.
Quando compilamos determinada variante,
o Gradle cuida de todos os
recursos e origens emergentes
necessários para a variante.
Ele também cuidará de uma variedade de
recursos definidos em mais de
uma configuração.
A regra é que
configurações mais específicas
substituem configurações
menos específicas.
Arquivos de origem do Java
não podem ser sobrescritos, por isso
tenha cuidado para não
tentar definir a mesma definição de classe,
e terminar com várias variantes.
O Gradle pode fazer melhor com
arquivos de recursos, como strings.xml, ou até mesmo
com Manifestos Android.
Para recursos desse tipo,
os arquivos serão mesclados e
as entradas serão substituídas por ID.
Para determinar quais origens e recursos
são incluídos quando compilamos determinada
variante, podemos desenhar um diagrama
com esta aparência.
Começamos pelo meio.
Se quisermos compilar a variante de
depuração paga, o Gradle incluirá tudo
no principal, depois mesclará tudo em pago,
substituindo os conflitos.
Depois, o Gradle mesclará tudo
da depuração, substituindo novamente.
Finalmente,
o Gradle mesclará os recursos e
a origem que estão na depuração paga.
我们已经学会如何使用构建类型自定义 Gradle 行为
现在看看构建变种如何允许你控制应用
本身的行为
基于我们正在构建的应用
Android Gradle 插件可创建各来源组的整体转换
根据构建的变种 它会合并来源和资源
这些来自嵌入最终 APK 的来源组
在最广泛的层面上
有位于来源主要部分的主要来源组
这是目前为止我们一直存放所有代码的地方
此外 每个产品风格都有一个来源组
在前面例子中 假设我们有
一个免费的和一个付费的产品风格
每个构建类型还有一个来源组 在这种情况下调试和发布
最后 每个最终变种还有一个来源
这就是来源免费调试、免费发布、付费调试和付费发布
如果我们有在付费风格而非免费风格中需要的来源和资源
可以将其放入付费来源中
同样 如果有需要用于调试构建而非用于发布构建的资源
则可将其放入来源调试中
最后 如果有仅付费调试变种需要的资源
可以将其放入来源付费调试中
在构建特定变种时
Gradle 将照顾所有新出现的来源和需用于该变种的资源
它还将照顾多个配置中
定义的各种资源
规则是 覆盖的具体配置越多
具体配置就越少
Java 的源文件不能被覆盖
因此需要小心以免定义同一类定义
否则将产生多个变种
对于资源文件 如 strings.xml 甚至 Android 清单
Gradle 可以做得好一些
对于该类型的资源 这些文件将被合并
条目将被 ID 覆盖
为确定当构建特定变种时将哪些来源和资源包括在内
我们可以画一个像这样的图表
我们从中间开始
如果我们想构建付费调试变种 Gradle 将在主要部分包括每个项目
然后将每个项目合并到付费部分 覆盖任何冲突
下一步 Gradle 将从调试合并到每个项目 再次覆盖
最后 Gradle 将合并到付费调试中的
资源和来源