Fork us on GitHub

Shrinking Sizes & Optimizing

How to reduce the size of your app, shorten build times & make the runtime faster...
Shrinking Sizes & Optimizing

Shrinking Sizes & Optimizing

Our build servers are really fast, even if your laptop is relatively slow our iOS build servers are powerful machines equipped with fast SSD's and they generate a full clean build of a typical app (with screenshots etc.) in a couple of minutes!
So the real source of delay when building an app is size, it both slows the build but most of all it slows your upload process (upload is typically much slower than download). Reducing the size of your app will make it faster in runtime as well, e.g. if you have too many redundant resources you might be running into too many GC cycles slowing down execution. In this post we provide some tips to shrink your app size.

Compress JAR

When we released Codename One's beta we released a version that didn't compress the built JAR. This wasn't a big deal for small projects but it became an issue as Codename One applications grew. Make sure that the JAR output is compressed, so that server builds would be significantly smaller. This is crucial since it reduces upload time in the client side which is a huge contributor to the total build time.

Notice that apps created in the past year should have this on by default but its always important to check.

Inspect the Sent JAR

When optimizing the jar size its often hard to see where to begin. After you send a build if you open your dist folder (or bin folder for Eclipse) you will see what seems to be the jar of your application. However, in this case its the jar that was sent to the server including the native bits that need to be compiled on the server side.
You can use a zip utility such as 7-zip to inspect the content of the jar and see what takes up space and how well are files compressed. Its possible that a specific file within the zip isn't supposed to be there and its possible that things can be shrunk further.

Shrinking Resources

The most likely case for a large file is the resource file and here there are two distinct tasks: finding out what is taking up the space and reducing the size. For the former we have Image->Image Sizes, in the designer tool. It returns the list of images ordered by the space they take up in the resource file, since images can't be further compressed they are the biggest space hog in the resource file.

Unless you found a specific image that takes up most of the space its probable that space is taken up by many multi-images. Multi-images are essentially a single image in multiple resolutions for different device densities, these images can grow to a very large size as we store a lot of resolutions for every such image. If there are densities you don't need such as LOW & VERY_LOW (both of which don't exist in smart devices) you can just delete all of these images from existing multi-image's thru the menu item: Image->Advanced->Remove DPI.

Image->Delete Unused Images presents you with a dialog containing the images that are unused. It allows you to select the images you wish to delete (all are selected by default). Notice that this method was designed for GUI builder applications and doesn't scan the code for image usage. It will also miss images from code although it tries to scan the state machine class intelligently.

Share this Post:

Posted by Shai Almog

Shai is the co-founder of Codename One. He's been a professional programmer for over 25 years. During that time he has worked with dozens of companies including Sun Microsystems.
For more follow Shai on Twitter & github.