Picture compression task chain

To find out how image compression is handled, look at what happens to the task chain after Access Booster

Enter the following command:

./gradlew :app:assembleDebug --dry-run
Copy the code

InstallCwebp and comppressCwebp2 are custom tasks that look like image compression

Note that it is inserted between mergeReleaseResources and packageDebugResources

We can also find the output after the task is completed in the build path

Task allocation

Let’s take a look at how these two tasks are inserted between agP tasks in the Config phase

To be clear, the key function in the configuration phase is this one

We can analyze the execution process carefully:

Alpha webP is not supported by phones below 18, but now most phones in China are above 5.0, so we can directly look at the branches in the red box

Focus on the logic in the two red boxes below:

Let’s look at the first red box. What does it do in the Config phase?

Returns a Command object that looks like it’s associated with the command line, but it makes sense, because ultimately the compressed image must call a CwebP executable

We can print out the execution result

This is the location of our specific executable

Go ahead and check out our cwebP plugin, which does have these executables built in

Therefore, the first conclusion is that the configuration phase Booster obtains the location of its own executable file

Look again:

From the above we can see it Here is returned to a SimpleCompressionTaskCreator object, pay attention to the construction of this object involves the two parameters

A this is our own CompressionTool

The other one is a lamda expression, but considering we’re only considering compatibility with android5.0, that’s what it really is

CwebpCompressOpaqueFlatImages

Take a look back:

Essentially calls SimpleCompressionTaskCreator createCompressionTask method, pay attention to this method has six parameters

This function returns a TaskProvider. Taskcollection.getbyname (java.lang.string) ¶ TaskCollection.getByName(java.lang.string) ¶ TaskCollection.getByName(java.lang.string) ¶

Moving on, let’s look at the first part of it

This is to ensure that installCwebp is executed after mergeResources

Continue to look at:

Here we look at the first box, but in fact the front we analyzed CwebpCompressOpaqueFlatImages getCompressionTaskClass is meaning The task to the corresponding task is that it finally.

What else does apply’s lambda stand for? The task that represents the CWebP must follow the install task.

We already know that the install task comes after the mergeRes task, and that the cwebp compression task comes before the processResTask task. Thus the complete construction of the task can be executed sequence

Like:

Finally, the next detail:

If you want to compress an image, you always need to find the original one, right? It’s just some parameter

This is the actual argument that is passed. Note that the code in the lambda will not be executed until the execution time (duh, you will not get the result of the previous compilation at the config stage).

Task execution period

After analyzing the order of tasks, all that remains is analyzing the execution process of tasks, which is actually much simpler than the previous config phase

Let’s start with part one:

Googleplay does not allow your app icon to be in a non-png format, so we should only compress and convert non-icon PNG images when converting png-webp images

So the core idea of the above code is to determine which image files are used for appIcon by parsing the manifest file

Then continue:

We’re going to focus on two things here,

First: the images in the red box are actually the output of the mergeRes task, that is, the Png. flat files compiled by AAPT2

For more information on AppT2, you can take a look at this Google document

aapt2

The second is the aapt2ActionData code

So this is essentially doing two things, encapsulating two commands,

One is to call the CwebP executable to compress our PNG file into a CwebP file

The second step is to compile our CWEBP files into webP. Flat files using AAPT2. This step is very important and should not be omitted

Finally, take a look at the actual command execution:

The first is to actually perform image compression

Then, according to the results of image compression, it is judged whether aapT2 should be compiled into. Flat file again

Here, we need to pay attention to details. In addition, Booster judges whether the compression command is successfully executed. In addition, booster compares the size of the compressed image with that of the original file

This detail is wonderful (I couldn’t have written it myself)