R8 3.1.X cause the dex files size increased 17.3% [233779072]

WAI

Bug

adexe s nau

Status Update

No update yet.

Description

mi...@gmail.com

created issue #1

May 25, 2022 02:21AM

Dear R8 team,

After the update to AGP 7.1.2, our App Size increased by 5% (caused by the dex files size increase of 17.3%).

Checked out your code, compile and try on the project. I figured out the dex file size spike caused by this commit https://r8-review.googlesource.com/c/r8/+/61680

In an early investigation of the dex files:

The number of Classes increased from 126812 to 129056

The number of Methods increased from 644636 to 644981

References Methods reduced from 730370 to 729775

There are a lot more lambda classes is keeping in the dex files after applying the commit to R8. For example:

.class public final synthetic Lcom/google/android/datatransport/runtime/scheduling/DefaultScheduler$$ExternalSyntheticLambda1;
.super Ljava/lang/Object;
.source "SourceFile"

# interfaces
.implements Lcom/google/android/datatransport/runtime/synchronization/SynchronizationGuard$CriticalSection;


# instance fields
.field public final synthetic com.google.android.datatransport.runtime.scheduling.DefaultScheduler$$InternalSyntheticLambda$2$7876631007fc8fb6b785707224cd9cac60856136e5c63650222501c2e428acf4$0.f$0:Lcom/google/android/datatransport/runtime/scheduling/DefaultScheduler;

.field public final synthetic com.google.android.datatransport.runtime.scheduling.DefaultScheduler$$InternalSyntheticLambda$2$7876631007fc8fb6b785707224cd9cac60856136e5c63650222501c2e428acf4$0.f$1:Lcom/google/android/datatransport/runtime/TransportContext;

.field public final synthetic com.google.android.datatransport.runtime.scheduling.DefaultScheduler$$InternalSyntheticLambda$2$7876631007fc8fb6b785707224cd9cac60856136e5c63650222501c2e428acf4$0.f$2:Lcom/google/android/datatransport/runtime/EventInternal;


# direct methods
.method public synthetic constructor com.google.android.datatransport.runtime.scheduling.DefaultScheduler$$InternalSyntheticLambda$2$7876631007fc8fb6b785707224cd9cac60856136e5c63650222501c2e428acf4$0.<init>(Lcom/google/android/datatransport/runtime/scheduling/DefaultScheduler;Lcom/google/android/datatransport/runtime/TransportContext;Lcom/google/android/datatransport/runtime/EventInternal;)V
    .registers 4

    invoke-direct {p0}, Ljava/lang/Object;-><init>()V

    iput-object p1, p0, Lcom/google/android/datatransport/runtime/scheduling/DefaultScheduler$$ExternalSyntheticLambda1;->com.google.android.datatransport.runtime.scheduling.DefaultScheduler$$InternalSyntheticLambda$2$7876631007fc8fb6b785707224cd9cac60856136e5c63650222501c2e428acf4$0.f$0:Lcom/google/android/datatransport/runtime/scheduling/DefaultScheduler;

    iput-object p2, p0, Lcom/google/android/datatransport/runtime/scheduling/DefaultScheduler$$ExternalSyntheticLambda1;->com.google.android.datatransport.runtime.scheduling.DefaultScheduler$$InternalSyntheticLambda$2$7876631007fc8fb6b785707224cd9cac60856136e5c63650222501c2e428acf4$0.f$1:Lcom/google/android/datatransport/runtime/TransportContext;

    iput-object p3, p0, Lcom/google/android/datatransport/runtime/scheduling/DefaultScheduler$$ExternalSyntheticLambda1;->com.google.android.datatransport.runtime.scheduling.DefaultScheduler$$InternalSyntheticLambda$2$7876631007fc8fb6b785707224cd9cac60856136e5c63650222501c2e428acf4$0.f$2:Lcom/google/android/datatransport/runtime/EventInternal;

    return-void
.end method


# virtual methods
.method public final com.google.android.datatransport.runtime.scheduling.DefaultScheduler$$InternalSyntheticLambda$2$7876631007fc8fb6b785707224cd9cac60856136e5c63650222501c2e428acf4$0.execute()Ljava/lang/Object;
    .registers 4

    iget-object v0, p0, Lcom/google/android/datatransport/runtime/scheduling/DefaultScheduler$$ExternalSyntheticLambda1;->com.google.android.datatransport.runtime.scheduling.DefaultScheduler$$InternalSyntheticLambda$2$7876631007fc8fb6b785707224cd9cac60856136e5c63650222501c2e428acf4$0.f$0:Lcom/google/android/datatransport/runtime/scheduling/DefaultScheduler;

    iget-object v1, p0, Lcom/google/android/datatransport/runtime/scheduling/DefaultScheduler$$ExternalSyntheticLambda1;->com.google.android.datatransport.runtime.scheduling.DefaultScheduler$$InternalSyntheticLambda$2$7876631007fc8fb6b785707224cd9cac60856136e5c63650222501c2e428acf4$0.f$1:Lcom/google/android/datatransport/runtime/TransportContext;

    iget-object v2, p0, Lcom/google/android/datatransport/runtime/scheduling/DefaultScheduler$$ExternalSyntheticLambda1;->com.google.android.datatransport.runtime.scheduling.DefaultScheduler$$InternalSyntheticLambda$2$7876631007fc8fb6b785707224cd9cac60856136e5c63650222501c2e428acf4$0.f$2:Lcom/google/android/datatransport/runtime/EventInternal;

    invoke-static {v0, v1, v2}, Lcom/google/android/datatransport/runtime/scheduling/DefaultScheduler;->$r8$lambda$gan_DuQtUIPPXez98St01P-VZPQ(Lcom/google/android/datatransport/runtime/scheduling/DefaultScheduler;Lcom/google/android/datatransport/runtime/TransportContext;Lcom/google/android/datatransport/runtime/EventInternal;)Ljava/lang/Object;

    move-result-object v0

    return-object v0
.end method

.class public final synthetic Lcom/google/android/exoplayer2/audio/AudioListener$-CC;
.super Ljava/lang/Object;
.source "SourceFile"


# direct methods
.method public static a(Lcom/google/android/exoplayer2/audio/AudioListener;Lcom/google/android/exoplayer2/audio/AudioAttributes;)V
    .registers 2

    return-void
.end method

.method public static b(Lcom/google/android/exoplayer2/audio/AudioListener;I)V
    .registers 2

    return-void
.end method

.class public final synthetic Lcom/company/di/DaggerAccountComponent$Builder-IA;
.super Ljava/lang/Object;
.source "SourceFile"

It's challenging to create a demo project with the same issue. From the commit I provided, would you please help to advise:

Any things that could help us mitigate the situation
If it's a project-specific issue. What should be the best approach to investigate this kind of problem?

ps: Currently, we force the project to use R8 3.0.x to avoid the case, but for some reason, we soon have to use the new R8 version.

Comments

ch...@google.com <ch...@google.com> #2May 25, 2022 04:16AM

Reassigned to ch...@google.com.

Thanks for the detailed bug report and for taking the time to identify the change causing this.

From a first look this seems to be working as intended. In R8 3.0, the behavior of R8 in presence of -dontoptimize was changed to be more aggressive (Do not interpret -dontoptimize as a global keep rule, Fix interpretation of -dontoptimize with -dontobfuscate). We backtracked on this in R8 3.1 with the above commit you correctly identified.

Could you try building with R8 3.0.46, which should not have the more aggressive behavior, to validate that it is indeed the above two CLs that significantly reduce the dex size?

In order to fix this, you would need to remove -dontoptimize from your Proguard configuration. To start with, you could maybe replace -dontoptimize by the following rule, which should effectively mark the matched items as not subject to optimization, due to the absence of ,allowoptimization.

-keep,allowaccessmodification,allowobfuscation,allowshrinking class * { <fields>; <methods>; }

You could then try to narrow down the set of items matched by this rule to reduce the dex size of your app.

mi...@gmail.com <mi...@gmail.com> #3May 25, 2022 04:57AM

Hi team, Thank you a lot for your reply. Let me try your suggestion and come back on this

mi...@gmail.com <mi...@gmail.com> #4Jun 1, 2022 10:58AM

Comment has been deleted.

Message last modified on Jun 1, 2022 01:58PM

mi...@gmail.com <mi...@gmail.com> #5Jun 3, 2022 03:46AM

Hi Team, Sorry for the delay. There is some update from my side:

We do not have the size issue with Android Gradle Plugin 4.2.2 which use the R8 version 2.2.71.

We do see a 1.6MB (2%) reduction in the binary size when enforcing to use of the R8 version 3.0.64 with AGP 7.1.2 (Update from R8 2.2.71 and AGP 4.2.2) As you asked, I tried multiple versions of R8, and here is the result:

R8 version	Note on rule	Dex size
3.0.46		32.4MB
3.0.47		31.8MB
3.0.64 (Enforce to use in the project now with AGP 7.1.2)		27.3MB
3.1.66 (default R8 version from AGP 7.1.2)		36.8MB
3.1.66	Use proguard-android-optimize.txt	27.3MB
3.1.66	Use proguard-android-optimize.txt Apply "-keep,allowaccessmodification,allowobfuscation,allowshrinking class * { <fields>; <methods>; }"	36.3MB

Conclusion:

Look like the dex size spike is not only caused by the two commits you mentioned. Applying "proguard-android-optimize.txt" seems to fix the issue. As Google recommends using "proguard-android-optimize.txt"(https://developer.android.com/studio/build/shrink-code#configuration-files), we will work on migrating to use "proguard-android-optimize.txt".

Message last modified on Jun 3, 2022 03:48AM

ch...@google.com <ch...@google.com> #6Mar 28, 2023 10:01AM

Status: Won't Fix (Intended Behavior)

Marking this as working as intended as the regression was caused by -dontoptimize. Moving to proguard-android-optimize.txt should avoid this problem as these rules do not include -dontoptimize.

Issue 233779072