3
\$\begingroup\$

I've just finished my (openGL ES 2.0 Android) game and it's almost ready for Alpha-testing.

When I export the application to an APK File, the file is taking up 16MB and I would like to reduce this as much as I can.

Here are some points about what the project contains and what I've tried to reduce the size already:

  • 222kb of Ogg Vorbis files used for Sound Effects
  • 1 x MP3 file at 5.59MB (128kbps Bitrate)
  • 4 x sets of PNG files used for textures (XHDPI, HDPI, MDPI & LDPI - I'm not using XXHDPI)
  • Just over 1MB of code

What I've tried thus far to get where I am:

  • I've optimised the PNG files using Optiping
  • I've applied ProGuard to my code before exporting, this didn't really help by much as 99% of my app is resources.

So my question is, is there really much else I can do to reduce the size of the APK? I was thinking about maybe using JPG format source files for my Background OpenGL textures instead of PNG - anyone have any experience with this? Does it hurt performance at all? I can see that it would make quite a difference - my atlas of backgrounds in PNG format for XHDPI is 1.7MB - and a 90% compressed JPG comes in at around 650KB. I'm just not sure if it's a good idea as everyone always advocates PNG > JPG.

Any pointers from personal experience would be helpful & also if I've overlooked anything other than using JPG's.

Improve this question
\$\endgroup\$

3 Answers 3

Reset to default
3
\$\begingroup\$

If you use an alpha-channel for your assets (which is most likely), then you're out of luck with vanilla JPEG anyway.

PNG provides a pretty good compression while also being lossless and a format with alpha-channel. There's not much you can improve there, except using a specialized GPU format such as PVR or similar which will allow you to specify different bit-depths per channel. But the real strength of a format like PVR is that it will consume less GPU memory, not the reduced disk-space requirement.

All that being said: I think you're overreacting. 16MB is nothing for a game and there's really no point in reducing the file-size to shave off some MB. It will only make your workflow more tedious in the long run.

Update: Another approach would be to ship your game with just one set of assets (eg. MDPI) and then load the higher-resolution ones on-demand. For example you could detect the presence of an HDPI display and show a dialog to the user, asking him if he wants to download the high-res assets.

Of course this makes your code and also your app-deployment more complicated. I would only suggest this approach if it's impossible to stay within some file-size boundaries imposed by others (eg. the iTunes AppStore has a 100 MB limit on downloads over cellular-networks).

Google has already a mechanism for this in place, which is called APK Expansion Files. So if your app gets larger than 100 MB (the limit for Apps in the Google Play store), then you should move your high-res assets into APK Expansion Files, which will allow additional downloads up to several GB (2 x 2GB at the time of writing this).

If you're certain you'll hit the 100 MB threshold, you could already start moving your hi-res assets into an expansion-file. Otherwise just pack everything into one APK.

Improve this answer
\$\endgroup\$
2
  • \$\begingroup\$ Aha. I honestly didn't realise that JPG's didn't support alpha, the backgrounds actually don't use alpha, but they are bundled into a larger atlas with other textures that do, so that's out of the window! I'm beginning to think you're right though I may be thinking to much about this. \$\endgroup\$
    – BungleBonce
    Jun 30, 2014 at 15:55
  • \$\begingroup\$ The alpha channel isn't such a big obstacle. I've seen games use two jpegs — one for colour information, and one for alpha — and combine the channels into one RGBA image for rendering when needed. \$\endgroup\$
    – DMGregory ♦
    Sep 12, 2016 at 12:08
2
\$\begingroup\$

First of all I'd start with the MP3 file. If you've got Ogg Vorbis already, why having a MP3 as well? Especially 128 kbit/s on a mobile device sounds excessive.

The MP3 is taking like 1/3 of your assets, with the PNG files being significantly smaller.

As such I'd start trying to convert the MP3 to Ogg Vorbis. I'd expect the file to become smaller. Also let it downsample to 32 or 64 kbit/s at most (same applies for the other sound effects IMO).

Also are you sure you need all the different resolutions of your images? Do they scale that bad? Especially the background might scale far better than any tiles or sprites.

Improve this answer
\$\endgroup\$
2
  • \$\begingroup\$ Thanks, I tried Ogg Vorbis for the music. It did make a difference but it wasn't huge. I'll experiment with it a bit more. Regards to holding all 4 sets of assets, the way I think about it is, if I get rid of say the LDPI ones, then a phone which would usually use these would then use the MDPI ones, and it would likely be a low-end phone, therefore this would take more memory that it should. If I get rid of the XHDPI, then the bigger tablets for example would scale up the HDPI ones and wouldn't look very good on the tablets's big screen. Just want it to look the best on all devices!! Cheers \$\endgroup\$
    – BungleBonce
    Jun 30, 2014 at 15:49
  • \$\begingroup\$ @user22241 For music the bit-rate is what defines the size, OGG just has higher quality at the same bit rate. \$\endgroup\$
    – API-Beast
    Jun 30, 2014 at 19:52
1
\$\begingroup\$

JPG is a photo format. It's a very efficient format for real-world images. PNG is a successor to GIF. It's a very efficient format for artificial images.

The reason is that the compression algorithms differ. The compression for both works by assuming some data is more common than others, and optimizing for that. Photo's have lots of smooth gradients, and very few hard edges. A diagram, on the other hand has many lines with sharp edges and no smooth gradients (the same applies to text rendered as image). Thus PNG does well on sharp edges, and JPG causes visual artifacts. But on smooth gradients, JPG excels.

Your textures may be closer to pictures, depending on how they're generated.

Improve this answer
\$\endgroup\$
2
  • 1
    \$\begingroup\$ Another thing to note is that PNG is losless, i.e. the compressed versions pixels are identical to the uncompressed version. JPEG is not losless. \$\endgroup\$
    – Elva
    Jun 30, 2014 at 13:41
  • \$\begingroup\$ The lack of transparency might be an even bigger factor there. \$\endgroup\$
    – Mario
    Jul 1, 2014 at 6:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .