Home Email Design Support Library Android Studio

Design Support Library Android Studio

Engineering Speaks: Putting Signeasy for Android on a diet

by stacy

The Signeasy app for Android has had a lot of updates and enhancements implemented by our team over the course of the previous several months. We have made significant headway in our efforts to provide a superior experience for our users, and as a result of our hard work over the past year and a half, we have transitioned from having a look like this (left, June 2015) to having a look like this (right, June 2016)!

Signeasey for the upgrade to Android

The redesigned mobile application adheres to the guidelines established by Material Design (which is an interesting story on its own). Not only does it have the sensation of being speedier, but it also offers an enhanced experience when signing documents. This update, however, came at a price, since the app’s storage capacity increased to over 35 megabytes as a result of the change. Unacceptable! We were able to empathise with our users and came to the conclusion that it was time to make some much-required changes to the software. Here are some of the methods that we put into practise.Libraries galore
I don’t mean to imply that the third-party library you installed for animations is the only library that apps would utilise to keep themselves operational when I say that they often employ a large number of libraries. You also need to incorporate SDKs for backward compatibility for any of the Google APIs, or even to make your programme material, so that it can be used. Particularly if your software has been in production for a considerable amount of time, each additional dependent that you add may make a big contribution to the APK file. Eliminating any libraries from your project that aren’t absolutely necessary is an excellent place to begin.

Carriage that is not required

This is an excellent tool for determining which libraries your application is utilising, along with providing a count of the amount of methods that are contained within each library. The higher the number, the greater the overall contribution it will make to your APK. Get rid of all the useless libraries, paying specific attention to the large ones.

In the event that your application makes use of Google Play Services, check to see that you are not incorporating the complete package into your build. Beginning with version 6.5, you will be able to selectively incorporate only the libraries that you require – neither more nor fewer. We were able to save a significant amount of MBs thanks to this nifty little trick.

At all times, ProGuard.
Verify that you are using the ProGuard protection on your APK. It is a very efficient tool that clears the bundled application of any and all useless classes, methods, and fields, including those that were imported from external libraries.

In the event that your application makes use of AppCompat-v7 or the support library-v4 (which it most likely does), check to see that your ProGuard file does not contain any of these lines.

-don’t delete the android.support.v4 class! ** *;
-remember to keep the android.support.v7.** and *; –
The support libraries are quite vast on their own, therefore it is to your advantage to let ProGuard get rid of any classes that aren’t being used.

A helpful hint: incorporating AppCompat’s SearchView into your app may result in unexpected behaviour if you add the two lines shown above. This is due to the fact that AAPT is unable to recognise any of the AppCompat components that are used in XML as a string, and therefore ProGuard removes the class from any such elements that it finds. You may prevent this from happening by re-adding this line to your ProGuard configuration.

-retain the android.support.v7.widget.SearchView class with an empty star; –
(You may use this trick with any class that has a string representation in XML.)

Getting smaller and more refined
When you package your app, a straightforward method is to instruct Gradle to reduce the size of the resources and delete any resources that are not in use on your behalf. Add the following to the build type in your build.gradle file that you want to be affected by the change you wish to make:

buildTypes = release minifyEnabled = true shrinkResources = true proguardFiles = getDefaultProguardFile(‘proguard-android.txt’), ‘proguard-rules.pro’ buildTypes = release minifyEnabled = true shrinkResources = true proguardFiles =
Managing drawables
Developers typically add assets for 5 various densities (mdpi, hdpi, xhdpi, xxhdpi, and xxxhdpi), as well as separate assets if you have a tablet-specific user interface (UI), like we do. This is because there is such a large variety of Android devices available on the market. The fact that all of these photos are bundled together in a single APK considerably contributes to the file’s overall size.

Be ruthless

Once upon a time, a Google Developer Advocate gave me some excellent guidance by saying the following: “Identify the devices that most of your customers are using, and if they do not fall into the mdpi-hdpi buckets, remove assets for these two densities.” This piece of guidance was extremely helpful to me. Although at first it can sound a little dangerous, this is actually one of the most efficient ways to get rid of a significant portion of those MBs. It is true that rendering the xhdpi asset on these devices takes a fraction of a second longer, but the difference is hardly imperceptible.

In addition, as was indicated previously, the Signeasy app possesses various elements that are uniquely suited to the form factor of tablets. These photographs typically have a greater file size because their dimensions are larger compared to the assets that can be stored on a phone. It was a pleasant surprise to find that the majority of tablet devices were either of mdpi or xhdpi density when we conducted research to determine which density bucket the majority of our tablet customers fell into (this helped a great deal). After removing all other components for tablets, the size of the APK was significantly reduced.

Adopt the use of vector drawables… really.

Forcing your engineers and designers to begin using SVGs for picture assets so that they may be included in your project as vector drawables is one of the best practises you can embrace as an Android developer. This is one of the finest practises you can implement. This enables you to replace many PNGs with a single vector graphic that retains its sharpness regardless of the density of the device it is rendered on, which is another way of saying that it is pure magic. Support for vector drawables is included in support library 23.2, despite the fact that it was initially only available for Lollipop and higher when it was released. This support goes all the way back to API 7. In addition, Android Studio version 1.4 has a handy small tool that assists you in importing vector graphics into the project you are working on. This will most certainly assist in reducing the size of the APK.

Everything that was not utilised
The following are some strategies that will assist you in chipping away at those tiny resources that are currently underused. Even though they don’t have much of an effect on the overall size of the APK, every single kilobyte does count in the end. In addition to that, it helps maintain a tidy code base.

Android Lint
This is an extremely useful tool that is integrated directly into Android Studio (but oddly hard to find). Navigate to the Analyze menu and select Run inspection by name. In the Inspection window, enter unused resources, select your scope (it is advised that you choose the full project), and click Run. Lint does an analysis on all of the resources (strings, drawables, dimens, and so on) that are present in your code but aren’t being used anywhere. You have the option of going through each suggestion and deleting the resource on your own, or you can simply ask Lint to do it for you. Especially if you’ve never done this before, it’s easier to do the latter and then re-add something you accidentally deleted, as Lint will probably end up suggesting a very large number of resources that aren’t being used. Doing the latter also makes it easier to re-add something you deleted by accident.

Pick your languages

At Google I/O 2016, a fascinating method called “specifying which languages you localise in your Gradle script” was brought up in conversation. This is an interesting concept. This removes any and all other string files that may have been introduced to the project by other libraries written in languages that you do not even support. To accomplish this, declare the languages that you do support within the build of your application. gradle file:

defaultConfig { … resConfigs “en”, “es”, “ja”, “in” … }
dividing up your APK file
You are able to generate numerous APKs for a single build using the Gradle system, with the number of APKs generated dependent on the split criteria. Cutting up the APK into smaller pieces might often be the most efficient way to reduce the size of the app package (APK), despite the fact that the official Android guidelines does not recommend doing so. You can accomplish this in a number of ways, including:

ABI split
This is especially helpful if your project includes libraries written in native code (files with the extension.so) that are compatible with a variety of CPU architectures. You have the option of splitting your APK according to the architecture being used by the user. This ensures that a user operating an arm ABI will not receive the code intended for x86, and so on. To accomplish this, add the following to the build.gradle file that is located at the app level:

android { … splits { abi { enable true reset() include ‘x86’, ‘armeabi-v7a’, ‘mips’ universalApk false } } }
Density level split
This method enables you to build various APKs that are differentiated based on the density of the device. As a result, a user who possesses a device with xhdpi does not need to carry assets that are designed for xxxhdpi. To accomplish this, add the following to the build.gradle file that is associated with your app:

android { … divides { abi { enable true reset() include ‘mdpi’, ‘hdpi’, ‘xhdpi’, ‘xxhdpi’, ‘xxxhdpi’ compatible

Screens with the “small,” “regular,” “large,” and “xlarge” designations
You should read here for a thorough list of additional split choices.

If you are looking for other approaches to lessen the size of your application, I suggest watching this session from Google I/O 2016 and reading this blog post linked to it.

The Signeasy Android team was able to successfully reduce the size of our software by over 30 percent after patiently executing the majority of the approaches outlined above. Having said that, we aren’t totally satisfied just yet, and we intend to test out even more techniques to minimise the impact that our users’ devices have on their storage capacity. Keep in mind that every single KB counts.

Related Posts

This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish. Accept Read More