Ore Miner is an addictive clicking game where you mine ores to craft new picks and equipment to increase your ore income!

Post tutorial Report RSS Reducing mobile app download size (part 4)

Splitting APKs for ARM and x86 and removing unused code.

Posted by on - Basic Other

Merging icons into tilemaps

This one didn’t actually work out and took quite some time to do. Because of our use of shaders, the 11 stone types, 10 stone destruction states and 9 on-hit particles (209 icons) turned into 38. (20 for ore destruction states and 18 for particles – half of each for the fill and the other half for outlines.) I wondered how much extra space we could save by making the files a large tilemap instead. Turns out that not a lot – only about 200kB (from 1.6MB to 1.4MB). I got stones and particles to work this way, it however took much more time for very little reduction in APK size. I did another experiment and merged all the remaining smaller icons into a single sprite-sheet. This reduced the file size by another 200kB, I however did not pursue to make it all work with these generated sprite-sheets, as it would have been way too time-consuming to do for just 200kB size difference. If I had way more time to invest, I’d have done this, however it really wasn’t worth it for the amount of time it would have taken.

Splitting APKs: ARM and x86

This part is only relevant to Android devices, however it matters a lot. By default Unity creates APK files which can be run on both ARM and x86 based Android handhelds. This can be changed in Player settings, and it makes a huge difference. Making APKs only able to run on ARM based devices reduces the APK size by 8MB, same by making them only able to run on x86 devices. According to Unity’s numbers, ARM based devices make up 98.2% of all Android devices (May 2016). Plus you can provide separate APKs on Google Play for different processor architectures. All in all, this was an awesome way to decrease the APK size.

Automatic removal of unused code

Using Mono2x as the stripping backend allows us to specify the stripping level. This removes unused code and engine components. Of course it can be a challenge for the scripting backend to determine what is and isn’t used. Assuming you don’t use reflections in your code or libraries, the scipting backend should be able make that decision correctly and only remove unused stuff. If you however do use reflections (namely interact with an object’s members by providing their name as a string), then you will likely run into trouble. Fortunately we didn’t use reflections anywhere, so this worked out great and reduced the APK size by another 3 MB.

Conclusion

The most effective ways to reduce the size of our app turned out to be the things Unity provides: For audio: Automatic bitrate optimisation and forcing it to mono; for images: setting maximum image sizes and disabling mipmaps; for code: splitting support for CPU architectures (ARM and x86) and automatic removal of unused code. The things which required way more work were quite a bit less effective in saving space. However, you can only save space by dropping x86 support once. The rest needs to be done by optimising your icons, merging them into sprite-sheets, etc. The turn-key things should be done every time, the more time consuming and tedious ones should be done when reducing the file size becomes important – which will likely be when your game ships.



That’s it from me regarding app size reduction. I hope my contribution will help you solve some of the difficulties you may encounter.

Matevž Baloh, programmer

Post a comment

Your comment will be anonymous unless you join the community. Or sign in with your social account: