Dreams comes true
And then we will able to mark this topic as solved =)
UPD: topic updated with Defold 1.2.100 data
UPD_1: topic updated with Defold 1.2.102 data
UPD_2: topic updated with Defold 1.2.112 data
Dreams comes true
And then we will able to mark this topic as solved =)
UPD: topic updated with Defold 1.2.100 data
UPD_1: topic updated with Defold 1.2.102 data
UPD_2: topic updated with Defold 1.2.112 data
Is there an ETA on the auto stripping or similar implementation?
it’s already done! You can remove unused modules using App Manifest
More info here
Or here (rus):
http://agulev.com/defold-umenshaem-razmer-bilda-app-manifest/
Did you see last changes on Google Play?
Looks like Google consider build size one of the most important info about an app.
I’ve made the new release .apk today and noticed that build size rised by a Megabyte from my last .apk. There are no new resources, app manifest, etc, the same project with small texts changing.
See on screenshot:
Hmm ???
It seems that it happened in version 1.2.136
Maybe something of these changes:
Yes, unfortunately, in order to be backwards compatible, we needed to update the java packages. And since google stopped supporting a ready made android-support-v4.jar, we had to create one ourselves.
It’s a tedious process, and we’d very much like to get back to it and perhaps use Proguard (if that helps in this scenario) to remove redundant classes.
I have read this article https://developer.android.com/topic/performance/reduce-apk-size
and what I wanna ask:
As I understand Defold adds to apk the Facebook resources (res
folder) even if we turn off facebook using appmanifest. How to avoid this? (I understand that it’s something about100Kb but I wanna back my solitair in 3Mb :))) )
As you mention, currently there’s no easy way of removing those assets. Even google play assets are there, which might conflict if you’re using newer google play libraries.
What we’d like to do, is to build upon the app manifest, to remove (or rather hide) the cumbersom configuration part, and instead specify what features you’d like to include or exclude. E.g. you should be able to uncheck a box next to the Facebook feature, and our tools would take care of the rest.
We’re not quite there yet though, so in the meantime, I wonder if the easiest way would be to unpack the .apk, remove those assets and then repack it again?
(I’d really like us to support custom scripts in when bundling from the editor, so you could automate those steps)
I have no updates for empty project, but for Solitaire game:
asmjs: 4.1 Mb and gzip 1.3
wasm: 2.6 Mb and gzip 1.1
Did you done some Android Build tests ? Are the build sizes bigger or smaller in comparison to the previous DEFOLD version ?
there is a size comparasion here https://github.com/britzl/dmengine_size that @britzl keeps up to date
It’s hard to compare old versions with new one, because now we have appmanifest and webasm for html5 builds, but let’s try:
Defold 1.2.144 (without appmanifest) :
Looks like new builds even smaller than old one except for Android (why)
In the new update of Google Play Console they pay even more attention to the build size:
- App size metrics and reports — gain insights about your app size in Android vitals, including download size, size on device (at install time), changes compared to peers over time, and tailored optimization recommendations.
.apk size for 32bit only and 32+64bit architecture in the release mode:
And of course it’s still possible to upload two different apk: https://developer.android.com/google/play/publishing/multiple-apks
Does Defold have any plans to use App Bundles?
No, nothing concrete no.
@AGulev, will you update the sheet with data for 1.2.170? I’m curious how it is now with Android App Bundle also what exactly do you measure? Size of the the whole folder? For both Defold and Unity the same approach?