Hacker News Reader

Comment by aw4y | Hacker News Reader

removing support library, layouts...please.

Back when they introduced them, I was pretty strongly opposed, and you can see the effect. We now have half the Android UI shoved in each app package. Back when I started using Android, apps were rarely over 1 MB in size. Now, with no real improvement in functionality, apps are regularly over 50 MB.

Unfortunately, that seems to be the only way to get a reasonable baseline, given that Google has no way to actually update Android devices.

No, the libs could be shared between apps, with at most one per API level, and shipped through the Play Store. If you want your app to work without Play Store, bundle the libs like today.

So, basically the Visual C++ Redistributable[1] but for Android? Seems to work well for Windows, from what I can tell.

1: https://en.wikipedia.org/wiki/Microsoft_Visual_C%2B%2B

They already have one distributed through the Play Store. That's the proprietary bits. The Support libs are open source, they can work without the Play Store, and different apps can have different versions of it.

Yes, and they can ship a shared version of the open source libs (like the system webview). And as I specified, with one per API level (different versions). Maybe that would force them to have better QA of those libs as well.

These packages certainly add bloat, and make it hard to fit under 1MB (can't really do it if a hello world is 1.5MB), but developers are adding a lot of their own bloat to get to 50 MB.

That said, Google could have (and probably should have) done a better job for Play store downloads with common libraries, especially common libraries they provide. They also could and should do a better job on translation strings -- the translation file must be stored uncompressed in the apk, because it wants to be memory mapped.

Last year I was invited to interview at Google Aarhus for a job on exactly this topic. We discussed fun, very simple ways to avoid including loads unused library code, and I was told that they already had some ridiculously efficient, practical way of compressing translation strings. I was there last November, and I had the impression that a lot of low hanging fruit would be picked off very quickly. Not sure what parts of this work actually shipped in these last 11 months. But work may still be ongoing.

At this point, I don't think there is anything simple you can do for translations in Android. Some of the translations are loaded outside of app context, and app developers may not know which ones those are. Allowing the files to be compressed in the apk would require support in the Android system, and there are a billion devices already shipped that don't know how to do that.

If you can tell what strings need to be in the old way and what can be done differently, you could do any number of easy things to compress the strings that don't need to be accessible by the system.

Either I'm whooshing some sarcasm, or you're missing the point.

Indeed. I thought the fact that he removed the Launcher Intent would be of more concern.

yeah, i had the same thought. this post cannot be taken as practical advice. interesting to see just how much bloat an apk contains though.

Is it bloat if it is required to make good app?

What made you think this article was meant to be taken as practical advice? It's code golf, which has never been about practical advice.

Bloat would imply that stuff does not serve a purpose.

Reply on news.ycombinator.com