Try to shrink R.java files via inheritance |
||||||
Issue descriptionIf you look at gen/**/*process_resources.srcjar, you can see what our generated R.java files look like. Rather than using aapt, we generate these from our own templates here: https://cs.chromium.org/chromium/src/build/android/gyp/process_resources.py?q=process_resour+ce&sq=package:chromium&l=214 The key insight here is that each android_resources() that depends on another android_resouces() ends up generating an R.java file with the union of all the R.java constants in them. I might have expected Proguard to do a better job at removing / merging / inlining them... but it seems it's not perfect at least. For example, R.styleable.ButtonCompat_buttonColor appears in 4 classes within a release version of Chrome.apk The idea for shrinking is to generate R.java files that look like: class R { class styleable extends org.chromium.base.RootR.styleable {} ... } Then have process_resources.py create RootR.java in the normal way. This should ensure that each R constant is declared at most once. To measure how much smaller this makes the code, we should build monochrome_public_apk with is_java_debug=false, and then list the uncompressed size of classes.dex via "unzip -lv apks/MonochromePublic.apk | grep classes" Related: https://bugs.chromium.org/p/chromium/issues/detail?id=669137
,
Dec 14 2016
Results are unfavorable: Original size 6,323,856 Patched size 6,374,904 Related CL: https://codereview.chromium.org/2572253002/
,
Dec 19 2016
I patched in your change and built system_webview_google_apk, and found that this shrunk classes.dex by 39kb (1632208 -> 1592684) I'll try again later with monochrome, but there's something awry here :P
,
Dec 19 2016
I also find that classes.dex in SystemWebViewGoogle.apk shrinks while the one in monochrome grows. I wonder is SystemWebViewGoogle.apk the right target to build?
,
Dec 20 2016
Hmm, yeah, super weird. Also confirmed that Monochrome and Chrome both get bigger (by 68kb and 42kb respectively), yet SystemWebviewGoogle shrinks by 39kb. hmmmm.....
,
Dec 20 2016
,
Jan 3 2017
Alright, new theory! Diffing the two dex files shows that many obfuscated symbols are removed, and many non-obfuscated symbols are added (mainly from android.support.*). So, I think what's happening is that symbols from non-org.chromium namespace are now being put in the root R's class, and because we have a -keepnames for org.chromium.*, they are no longer being obfuscated! Let's try changing the generated root file to not have a prefix of "org.chromium" and see if these apks shrink.
,
Jan 6 2017
The apk size is related to the package name. Choosing a shorter package name reduces the apk size; however, changing it to non org.chromium.* does not improve the situation. Chrome.apk & MonoChromePublic.apk still grow while SystemWebviewGoogle.apk still shrinks. Upon investigation using apkdiffstats, it turns out that names are not being properly obfuscated by Proguard. Some are obfuscated, some are partially obfuscated, and others are not obfuscated. The plan is to wait until Proguard is updated for clank (crbug.com/674152)
,
Jan 10 2017
Figured out that you can also get some idea of what's happening by looking at proguard's .seeds and .usage files (described here: https://developer.android.com/studio/build/shrink-code.html#shrink-code), and for us, they live at target_gen_dir/chrome_apk.proguard.jar.usage. Looking at these reveals that it's more than just renaming. Proguard is able to remove more with the non-inheritance way at the moment.
,
Jan 13 2017
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by agrieve@chromium.org
, Dec 6 2016