Autoboxing, a little thing, can cause big problems for Android App Performance

April 22, 2017

To ensure your app performs well across a wide variety of devices, you always try to use best practices. On that front memory optimization is often a demanding task. Most of the time we always think on the bigger side of it and miss the small thing that can add up to a big problem. Autoboxing is a topic that often goes unnoticed when talking about performance issues.

Autoboxing is a great language feature, until you realize how much of your performance is being lost to its convenience. You cannot imagine a simple Autoboxing operations can easily tear through your Application’s memory.

What is Autoboxing?

Till JDK 1.4, when we work with primitive types, it requires repetitive work of converting the primitive types into wrapper classes and vice-versa. Let’s say if we want to create a List with Integers, we have to explicitly wrap them as Integer and we need to unwrap it to get int value.

So since JDK 1.5, Conversion from primitive types to corresponding wrapper objects and vice versa can happen automatically.

Boxing: Conversion of a primitive type to the corresponding reference type (int -> Integer).

Unboxing: Conversion of the reference type to the corresponding primitive type (Integer -> int).

How it causes problem?

As we discussed Java provides corresponding wrapper classes that match primitive types, and act as object wrappers. These classes give the same functionalities as primitives but can be used with generic collections. However their size in memory is not the same. An Integer object occupies 4 times more memory as primitive int.

In the example below, the API call adding a primitive int value but the collection API takes Integer object. This assignment will perform an Autoboxing operation from int to Integer object.

// Here is primitive variable

int value = 5;

List<Integer> list = new ArrayList<>();

//autoboxing to add primitive type (int) in collection class

list.add(value);

For a single call, this may not matter much. However, if we are using it frequently, for example in an inner loop, it might occupy a lot of memory unnecessarily and cause a big memory threat.

// Here is generic variable

Integer sum = 0;

for(int i= 0;i< 100;i++){

// autoboxing to convert int into Integer

sum = sum + i;

}

As you can see in the above example, 100 new objects allocation along with the sum calculation. But in case of primitive it doesn’t require any additional allocation overhead.

This will also overhead of more garbage collection and decrease the runtime performance. It can be especially painful with data structures like HashMap. Let’s consider another code:

HashMap<Integer, String> map = new HashMap< >();

// Put the value in the map where key is primitive type.

map.put(1, "TestValue"); // expected key is Integer type

// Get the value from the map where key is primitive type.

map.get(1); // expected key is Integer type

In the above code put and get operations will use Autoboxing and cause additional load. Basically anytime you insert, update or retrieve a value with this generic container when a primitive is involved you end up boxing or unboxing values.

How to resolve the problem?

To resolve the problem of autoboxing Android provided custom containers SparseArrays and ArrayMap to use instead of traditional containers like HashMap. These containers are design specifically to fight Autoboxing problem and eliminate both runtime overhead and additional memory allocation. These containers are more memory efficient than using a HashMap to map Integers to Objects.

Below are the example code to create SparseArray:

SparseArray sparseArray = new SparseArray();

sparseArray.put(1, “Value1”);

SparseLongArray sparseLongArray = new SparseLongArray();

sparseLongArray.put(1, 1L);

SparseBooleanArray sparseBooleanArray = new SparseBooleanArray();

sparseBooleanArray.put(1, true);

SparseIntArray sparseIntArray = new SparseIntArray();

sparseIntArray.put(1, 2);

This way you make your code more optimized and memory efficient. To understand SparseArray and ArrayMap refer my detailed post.

How to trace memory issues?

Android Studio provides profiling tools to records and compute memory allocations of your app. Allocation Tracker are such a powerful tools which shows object allocation and their size. It is also used to track memory leaks.

Another good tool is Traceview, which is a graphical viewer for execution logs that you create by using the Debug class to log tracing information in your code

Conclusion

Now a day’s most of the applications are handling thousands of data, so any optimization you make could potentially improve the performance across our application. Small change of Autoboxing matters a lot for a mobile developer where you have very limited memory and resources.

To find more interesting topics on Software development follow me at:

Medium Twitter Google+