Multidex support appears to increase file size significantly. Possible to disable?

Solar2D Android
#21

Thanks for the thorough testing Rob - guess I’ll just have to get used to the fact that ~10.8M is now my minimal build.

Aside:  The reason I felt it reasonable to pollute the two topics together was because if you don’t have any add-ins at all, then you’re unlikely to push multi-dex.  (plus I happen to know that the OP also uses AdMob in his builds, so wondered if it may have been one of his contributing factors too)  The minimal size of ~7M with or without multidex is an interesting “baseline” for a minimal build, but it isn’t a practical test of how things have changed (your first column).  AdMob, on the other hand, is big enough to measure differences with. (your second column)

I don’t necessarily see the problem as being with multi-dex support *in and of itself*, but rather a side effect of all the reasons that we need multi-dex to begin with (everything just seems to keep getting bigger and bigger).

Maybe a 2+M increase doesn’t seem like much, but for me I experienced ~21% growth from 12.1M to 14.7M by doing nothing other than implementing the new admob plugin on an existing project.  (first one compiled circa 4/27/2016, second one compiled 2/2/2017)  Of course, included in that are whatever other internal changes in subsequent Corona builds, but admob was clearly a big contributor.  Maybe Δ2.6M doesn’t seem like all that much, but if you’re aiming for small apps, it’s the percentage gain that’s more telling.

#22

I wanted to bump this topic again.

Now that we’ve got the new admob plugin, gpgs and android dependency system, (and whatever else similarly related), and all of them fighting for multidex support, a formerly “simple little game” now spans 3 dex files, totalling 4.1M (in compressed .dex form, ~38M as extracted classes).

Given the more-or-less static binary lib size (which has been sitting at or around ~4.5M for a while now), and the app’s own more-or-less static assets (which also just happen to be right around 4.5M), I used to be able to build a ~12M apk (4.5M lib + 4.5M assets + 1.5M dex + 1.2M res + trivial misc).  Present-day builds are about 14.7M.

The bulk of this appears to be gms (google mobile services) which is apparently sooo big in and of itself  that it’s gotta be spread across two of those dex’s.  (presumably hits the 64k limit)   The android support library is another big contributor at ~7.1M extracted.

I realize that by including admob, com.google.android.gms.ads will be coming along for the ride too.  And I realize that the never-ending clamour of your developer community for new features must lead to some bloat over time too.

But is all of this _ really _ necessary?

#23

just for reference, using build 3025,

a “do nothing” (no code, no assets) resulting apk ~= 6.8M

add ONLY the plugin.admob to build.settings, resulting apk ~= 10.3M

difference ~=  3.5M

#24

This really isn’t a practical option for us. Many plugins are going to push the app over 65K symbols. As Dave pointed out, AdMob alone needs two DEX files.

For simulator builds it’s going to be very hard to make it optional. However Enterprise builds would have much greater control over that process.

Rob

#25

Sorry, I’m not following you here … is all what really necessary?  It’s true to say that if you add several third party libraries to your project the resulting APK grows bigger over time as said third party libraries grow.  What’s the expected behavior?

Multi-dex is necessary to support the number of symbols in Google’s libraries which increases over time (as does the raw size of the libraries).  It’s a complication we’d love to not be needed but that’s how APKs are built today.

For the record, a trivial app (no plugins, 476KB of assets) built with CoronaSDK 2830 (non-multi-dex) is 7.7MB while the same app built with CoronaSDK 3030 (multi-dex) is 7.5MB (the size difference is due to changes unrelated to multi-dex).

#26

Hi Perry, thanks for replying.

My own testing found that an empty/do-nothing project produced a 6.8M apk.

By adding only a single plugin, admob, that same project produced a 10.3M apk.

A difference of roughly 3.5M

The majority of that 3.5M increase is attributable to all the various parts of gms, including large portions of it that don’t seem to have any obvious relevance to ad support.  (it’s easy enough to unpack the dex’s and see what’s inside, and diff them between the two builds)

So the question really is:  Is it truly necessary to include all of that 3.5M of gms just to get admob support?

IOW, is there a chance that more-than-is-necessary is being linked in?

The prior version of AdMob certainly did not add anywhere near this much overhead to a build.

#27

re-checked again with build 3033, in case maybe I just had a ‘flawed’ daily.  complete source:

main.lua:

--

config.lua:

application = {}

build.settings:

settings = { plugins = { ["plugin.admob"] = { publisherId = "com.coronalabs" } }, android = { usesPermissions = { "android.permission.INTERNET", "android.permission.ACCESS\_NETWORK\_STATE" } } }

nothing else.

resuling apk:  10,739,489 bytes, which seems excessive.

Is that just the way it’s gonna be, or is there perhaps something amiss?  thx

#28

This thread is now talking about two different things: 1. The increase in size for multi-dex  and 2. The increase in size for the AdMob plugin. These probably should be separate threads, but it’s not, so I’m going to have two answers :slight_smile:

Multi-Dex.

I took Dave’s code above and built it with the legacy plugin and without the plugin using 2992, the latest public build and with 2851, the last daily build before we added Multi-dex support as well as a recent daily build (and the new AdMob plugin). Here are the results:

Build      w/o AdMob     w/ AdMob

2851       7.2mb         9.1mb

2992       7.1mb         8.7mb

3032       7.1mb         10.8mb

It’s clear that multi-dex did not add any overhead, if any we trimmed a touch.

Now for AdMob

It has grown 2.1mb from the legacy plugin and even less (1.7mb) pre-multi-dex. Google has added a lot of features to AdMob. It supports SDK-less mediation and video ads as well as a host of other new features. And they probably have added quite a few features to their support libraries as well. I don’t feel that a 2mb increase going from v4 of Google Play Services to v9 is that much given all of the additions/updates.

I don’t know if Google is providing us source (I doubt it) or compiled binary libraries (most likely). If we are using their binary libraries, our hands are tied. But even if we had source, if we started hacking out parts we didn’t think was needed, we would likely break things for a future update and who knows how much space we would really get back. It might be a minimal gain.

Rob

#29

Thanks for the thorough testing Rob - guess I’ll just have to get used to the fact that ~10.8M is now my minimal build.

Aside:  The reason I felt it reasonable to pollute the two topics together was because if you don’t have any add-ins at all, then you’re unlikely to push multi-dex.  (plus I happen to know that the OP also uses AdMob in his builds, so wondered if it may have been one of his contributing factors too)  The minimal size of ~7M with or without multidex is an interesting “baseline” for a minimal build, but it isn’t a practical test of how things have changed (your first column).  AdMob, on the other hand, is big enough to measure differences with. (your second column)

I don’t necessarily see the problem as being with multi-dex support *in and of itself*, but rather a side effect of all the reasons that we need multi-dex to begin with (everything just seems to keep getting bigger and bigger).

Maybe a 2+M increase doesn’t seem like much, but for me I experienced ~21% growth from 12.1M to 14.7M by doing nothing other than implementing the new admob plugin on an existing project.  (first one compiled circa 4/27/2016, second one compiled 2/2/2017)  Of course, included in that are whatever other internal changes in subsequent Corona builds, but admob was clearly a big contributor.  Maybe Δ2.6M doesn’t seem like all that much, but if you’re aiming for small apps, it’s the percentage gain that’s more telling.