How to solve the task cache compilation problem caused by gradle build cache

Gradle Build Cache It caused Task How to solve the cache compilation problem

Today I'd like to share with you Gradle Build Cache It caused Task How to solve the cache compilation problem , Detailed content , Clear logic , I believe most people still know too much about this knowledge , So share this article for your reference , I hope you will gain something after reading this article , Now let's take a look .

Basic knowledge of

Gradle Building a cache is a caching mechanism , Designed to save time by reusing output from other builds . Build cache by storing （ Local or remote ） Build the output and allow the build to get the output from the cache when it determines that the input has not changed , Thus avoiding the expensive work of regenerating them .

The first function of using build cache is task output cache . Essentially , The task output cache utilizes the same intelligence as the latest check , When a previous local build has produced a set of task outputs ,Gradle Use it to avoid work . however , The task output cache is not limited to previous builds in the same workspace , But to allow Gradle Reuse any early built task output anywhere on the local machine . When using shared build cache for task output caching , This can even work across developer machines and build agents .

In addition to the task , Artifact transformation can also take advantage of the build cache and reuse its output , Similar to task output cache .

Excerpt from above gradle Official documents , Links are as follows

I'll simply translate it to you guys , Exist locally build cache Under the circumstances ,gradle task Will be cached based on the current input key value , If the input has not changed , It means Ben Task Can be skipped , In addition, this is different from incremental compilation .

You can steal official pictures again . Take a chestnut ,JavaCompiler task Of input java The file is the same as the one compiled last time , This means that the task can use the original compilation output as the compilation product .

Cacheable tasks

Task type needs to be used @CacheableTask Note: select to add the task output cache . Please note that ,@CacheableTask Not inherited by subclasses . By default , Custom task types cannot be cached .

There are official instructions on how to use compilation cache , First of all, our Task To be defined as @CacheableTask.

In addition to Task Internal input and output also need to be marked @TaskInputs and @TaskOutputs annotation . Only in this way can we ensure the current Task With the ability of compiling and caching .

So you want to have the ability to write a cache Task It's also complicated . That's why Android It will start to push Artifacts Used , Let developers care less about the logic related to input and output .

We have upgraded the adapter AGP 7.0 | gossip

So relative , No definition @CacheableTask , it is considered to be a task with a compilation cache .

TaskOutput

In the above skipped tasks , Usually there will be in Task After compiling, bring some special identifiers .

• (no label) or EXECUTED The task was carried out normally .

• UP-TO-DATE The task output has not changed .

• The input and output have not changed .

• The task was carried out , But the mission tells gradle The output has not changed .

• The task is not executed and some dependencies , But all dependencies are up to date 、 Skipped or from cache .

• The task is not performed or relied on .

• FROM-CACHE The output of the task can be found in the previous execution . Task has recovered output from build cache .

• SKIPPED The task was not performed . The task has been explicitly excluded from the command line .

• NO-SOURCE This task is not currently required . Input content has no source file , such as .java

In a nutshell , Except for the first case , The rest is that the task is skipped .

Interesting compilation problems

Okay , With the pre knowledge reserve , Let's talk about a strange problem we have encountered recently .

We have a protobuf Compiled warehouse , Be in charge of pb File to java perhaps kotlin. Then the generated files will be moved to the other two modules for packaging , Finally, delete all generated class files . Then go ahead and do it javacompiler task.

There is a secondary compilation problem in this module . Packing for the first time protobuf Module compilation is normal , Then when the module is compiled twice , The module will have the problem of class loss .

Problem analysis

This problem is relatively simple to analyze . In the case of secondary compilation , Because the input has not changed , So it triggers Gradle Task Related cache , And then all of the pb File to java kt The process is skipped . But the follow-up copy task Because it doesn't have caching capacity , So he'll do it again cv The task of . But the original generation java and kt It has been deleted . At this time, he will overwrite the empty folder . Then it leads to the original java and kt The problem of losing all the files .

This is a very interesting build cache Resulting in strange problems , Because the last task has a compilation cache , After that, I skipped the compilation and directly used the original output Output . But the next task is not cached , Therefore, the copy task must still be performed .

That's all “Gradle Build Cache It caused Task How to solve the cache compilation problem ” All the content of this article , Thank you for reading ！ I believe you will gain a lot after reading this article , Xiaobian will update different knowledge for you every day , If you want to learn more , Please pay attention to the Yisu cloud industry information channel .