On Feb 8, 2012, at 4:35 AM, John Murray wrote:
> I recall some time ago a thread about this – the size of Monodroid apks –
> cant seem to find it.
Who needs a thread when we have docs? :-)
http://docs.xamarin.com/android/advanced_topics/linking
> I have a reviewer making an issue of the size – strangely Android Market is
> reporting it at 12mb whereas the apk I uploaded was only 6mb
That's rather odd. It might be interesting to download your app and compare it
to the .apk you uploaded. Perhaps Google is doing something screwy to increase
.apk sizes?
> Does the whole apk 6mb translate into a 6mb footprint in memory ?
No, and "memory" doesn't necessarily mean much either.
The .apk will contain three sets of data: native libraries, assemblies, and
everything else. ;-)
Native libraries, including libmonodroid.so, are compressed, as is everything
else (usually...).
Assemblies are _not_ compressed within the .apk, they're "stored." The reason
for this is that during startup we mmap the .apk and read the (stored)
assemblies from the mmap'd memory region.
Does this use process address space? Yes. Does this use RAM? No. It's backed by
the disk, is readonly, and can be discarded by the kernel whenever it feels
like it. :-)
Similarly, loading the native libraries will require process address space, but
that's also largely up to ld.so and ELF; it's hard to say how much of
libmonodroid.so will actually be in memory, and (again) is that r+w memory or
read-only?
In short, it's horrendously complicated, and will likely be swamped by objects
your code creates. The GC adds an entirely new complication here, even in Java.
Anyone who thinks that .apk size can be equate to memory use, in any way, is
delusional.
- Jon
_______________________________________________
Monodroid mailing list
[email protected]
UNSUBSCRIBE INFORMATION:
http://lists.ximian.com/mailman/listinfo/monodroid
