Created attachment 17098 [details]
Android binary size issue repro
Large applications, with lots of methods and particularly lots of async methods, lambdas, iterators and generic types makes AOTed binaries very large. All the full unmangled method names are included in the resulting *.so files.
C# features that generate display classes are particularly bad in this regard, as the names length is generally not a concern when part of the original .NET assembly.
In the attached sample, LargeAssembly is 974KB and SmallAssembly is 808KB, and while the only differences are classes names, the resulting AOTed binaries are respectively 4.4MB and 3.4MB. That's a lot of strings...
I recall iOS does not embed any symbol names in the generated binaries, so is there a reason these symbol names are stored in the resulting binary ?
Is there anything that could be done about this with the current interaction of AOT on Android?
Passing the 'no-write-symbols' aot option will turn this off. We might also be emitting dwarf debug info, that could be turned off with the 'nodebug' option, but that will also turn off more than that.
Thanks Zoltan !
For now, there seem to be no way to pass additional arguments to the Aot msbuild task, unless I'm mistaken.
Looks like we got a feature request here.
Could we extend the msbuild aot task to allow passing extra args to it?
Ho well, this very significant! Ildasm/ilasm being my friends, I'm now able to get AOTed binaries down to LargeAssembly at 801KB and SmallAssembly is 802KB.
I tried using both `nodebug` and `no-write-symbols`.
On more real scenario assemblies, I'm observing decreases from 21MB to 13MB, or another one from 11.9MB down to 6.2MB for Arm-v7a.
This impacts the on-disk size of installed apps, particularly for low end devices, as well as install time.
I have not measured it yet, but the AOT generation times seems a bit faster as well.
Correction, my non-modified-task real-scenario files where having linker enabled, making them smaller.
Without the linker, it gives a good idea of the strings impact, where sizes are 39MB down to 13MB and 14MB down to 6MB.
The first assembly contains a lot of small methods, async methods, iterators, lambdas, etc...
Adding extra args to the AoT task should be fairly trivial. It probably won't make it for cycle8 though (the current Alpha).
That's unfortunate. The modifications makes a blank android app zip APK (with x86 and armv7a) go down from 15MB to 12MB, and on disk from 49MB to 25MB.
That looks quite major...
I'll see what I can do and keep you posted.
I submitted a PR to the xamarin-android repo with the proposed changes.
With this you will be able to use
I've tested that locally and it seems to reduce the size of libaot-Mono.Android.dll.so (for example)
In theory... once that has merged you might be able to get the build artifacts from the jenkins build system and replace your
Fixed in xamarin-android/master/da070383
needs to be applied to the monodroid repo now.
Should be fixed in the latest monodroid/master/a5091c65
I have checked this issue with latest master xamarin.android-7.0.99 build and observed that by adding the given argument manually:
<AndroidAotAdditionalArguments>no-write-symbols</AndroidAotAdditionalArguments> to the csproj file so that it utilizes the new MSBuild properties mentioned in the bug and resulting in reduction of size of APK and libaot-Mono.Android.dll.so file from 13 MB to 9 MB and 8.3 MB to 6.3 MB respectively.
Here is the screencast for the same.
Before fix merged into Master : http://www.screencast.com/t/lWN9B8Cb1
After fix merged into Master : http://www.screencast.com/t/4iqXBJZkO
Please merge the fixes into C8 builds so that I can verify this issue.
As per Comment 10, I am marking this issue as verified as this issue is fixed in Master lane and C9 is not yet split from Master.
## Note to the Xamarin.Android team
Apologies in advance for using the "REOPENED" status as the best available option to raise a question about release inclusion.
At the moment, these changes have not yet been backported to the Cycle 8 branch, but the target milestone is still set to C8SR1. If it has been decided that this change will indeed land on Cycle 9, then feel free to just update the target milestone accordingly and reset the resolution/verification status.
## Side note: link to "artifacts from the jenkins build system"
In case it might be of interest, the continuous builds lane for Mac OS installer packages that includes monodroid/master/a5091c65 is here:
The target was changed to C9. So changing the status back to fixed.
I have checked this issue with latest Cycle 9 XA 126.96.36.199 build and observed that the fix is merged into Cycle 9.
Hence, I am closing this issue.