Task cache compilation caused by gradle build cache

Catalog

Preface

Basic knowledge of

Cacheable tasks

TaskOutput

Interesting compilation problems

Problem analysis

Last

Preface

A while ago, an article was published in the subsidiary. If you are interested, you can have a look , Introduce the principle of compilation optimization , Of course, there are some technical details that have not been written .

Bili, Bili Android Compile optimization .

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 .

As for the solution, I won't write , I don't think everyone should be interested .

Last

Say the important thing again , A while ago, I rolled up an article in the company. If you are interested, you can have a look , Introduce the principle of compilation optimization , Of course, there are some technical details that have not been written .

https://www.jb51.net/article/252481.htm

That's all Gradle Build Cache It caused Task Details of cache compilation problems , More about Gradle Build Cache compile Task For cached information, please pay attention to other relevant articles on the software development network ！