Tips to reduce the size of your Android application – The Free Android

Each day, the applications that we tend to occupy more and more space. When in early versions of Android apps we were about 2 MB, now is very normal to see these applications have come to occupy 10 to 20 MB.

But why now occupy more

This has led us to ask the question of where the reasons that now occupy more and more applications are, and consequently their APKs. The answer is not due to a single reason, but a set of arguments that have been affected by Android:

• multiplication of categories dpi now have a lot more variety of screens, for which we must cover their resources. Specifically we have: [l | m | tv | h | x | xx | xxx | dpi]
• own evolution of Android , their tools development and the libraries available in the ecosystem
• user expectations based on the high quality of the new graphical interfaces
• …

It is true that not all cases can avoid that growth, but we can try to control as much as possible. So there comes a time that a light application on Google Play can be an advantage over the rest. Why? First, because the code can be simpler and easier to maintain , which may mean it is better developed. Second, because developers continue fighting not reach the 50MB limit Google Play , thus avoiding having to download additional extensions. And finally, for the limitations that are: bandwidth, space …

The APK file format

The first thing to know how we can reduce the file is to understand its structure. Basically it is a file that contains multiple files in a compressed form. As such, we could decompress with the simple command unzip

Most directories that we can see and familiar to us as developers. resources see the Manifest, bookstores … And in classes.dex the compiled version of our Java code

Now let’s look at some techniques that we can use to reduce as far as possible the size of this file, but we must mention that it is important to remember that it is a compressed file has two sizes: the compressed and decompressed. But in this case, we focus on the compressed size, always still remember that the smaller the APK, the lower the uncompressed version.

Reducing the size of the APK

For starters there’s bad news: every application is different, so there is no absolute standard to lighten our APK. But the good thing is we have 3 important points on which we can work easily components:

• Java source code
• Resources / Assets
• Native Code

Cleaning the programming

The first step is to know the code like the back of our hand. This will lead us to get rid of all the unused code and libraries that already have stopped using … In this way, as we code only the essentials. We must avoid ending up with what is called dead code , which is the obsolete code that no longer use and have forgotten to remove. Luckily, we have some tools that can help us …

Run ProGuard

This tool allows us to obfuscate, optimize and reduce the code at compile time. One of the functions performed is precisely identify the code fragments that do not travel through the tree makes the code so that all code not reached (or unnecessary) will be extracted from the APK are used. Also, we added security features, as it will rename fields, classes and interfaces, forms the code is lightweight and more unreadable against reverse engineering.

“With great power colleva great responsibility”. And is that Proguard, if we do not set well to show you where you can not act, you can break some applications due to reflection.

Use Lint extensively

Proguard serves to the Java code, but if we want to improve the resources, we use Lint to detect all unused resources, by calling ./ gradlew lint . This will generate an exhaustive list of resources and can see those who are not in use. But keep in mind that working with the resources under the res folder which is ignoring the assets folder. For the files in this folder, we do it manually.

Rationing resources well

It is true that Android has fragmentation worthy of mention. But it is also true that Android has been designed to support devices regardless of their configuration (screen density, shape, size …) From Android 4.4, including new densities as tvdpi included. But this does not mean that our app should support them all. We must be able to think about what devices will use our app, or even think about group those densities, for example, where we have few users.

There are people who only support eg IPAP, xhdpi and xxhdpi, Android then automatically calculates the missing resources climbing the resource as necessary. Why these densities? In many cases, it covers more than 80% of users. Why not include xxxhdpi ? Right now it’s just a test for the future.

Minimize resource settings

Many times, we include libraries as Seller Support, or Google Play Services, or Facebook SDK … All resources that come with them are not useful for our application. So for this we use the plugin Android Gradle Plugin 0.7 , which we pass information about configuring our app so that it prevents resources that do not match our app included. This will also save space.

Compress Pictures

AAPT comes with a compression algorithm for lossless image. This allows us to reduce the size of the resource itself will use, but should not prevent also use other tools, such as pngquant, ImageAlpha or ImageOptim. and all depend on what best fits our needs.

But it only happens with our generic images, but Android specific images can also be optimized. We talked about the 9-patches . These images are the images that will stretch without deforming. Although no specific tools, yes we can minimize stretch zones to a minimum.

Limit the number of architectures

Although we program our applications in Java, is in some cases may need some native code (NDK). To do this, we must also consider reducing the native code. Normally it is sufficient to architectures and x86 armeabi .

Reuse where possible

Reuse is one of the main tools to optimize. To do this, we can for example change the color of a asset, and even rotate such an image, with a bit of code in XML. Here, we could forget ic_arrow_collapse, through the code we can see below. And this brings us more space savings.

Rendering with code when you can

Images are one of the factors that affect the size of our application, and we must think about reducing them to the fullest. To do this, we can come to ask render such animations, avoiding having to mount an animation with lots of images, and in so doing by code.

If in case we have just seen, we did every 16ms, we would have a library twice the size … Is it really viable? To do this, we can consider doing the animation by code, although we take time to program, but allow us to save space while maintaining a sufficiently smooth animation at 60fps for example. However, we hope that Google is working on a rendering system more optimized animations.

To go further?

All this allows us to optimize the application and libraries from the developer’s point of view. But the distribution chain affects you? We might be thinking something like the app only includes libraries that are really needed in the device that the app is installed. Could even imagine that only pack the device configuration where installed. But this would lead us to break one of the most important features of Android. How Android fits configuration changes dynamically

This leads us to think packaging by APK of lservidor is very powerful but also very risky because each user will have a different package shipped to Play Store, and it may even cause no guarantee that the app works perfectly.

Are you influencing review the sizes of the applications that you install will

Via Cyril Mottier