So we started with the famous, but not friendly, Allocation Tracker, included in Android Studio. Some scroll ups and scroll downs and we had a considerable sample to work on.

Analyzing the Tracker’s report it was pretty obvious that the TableLayout we were using for a part of the Candidate’s layout was consuming too many resources. We used TableLayout to overcome some technical difficulties we had, when designing the aforementioned part. But as you might already know for every problem in layouts there is always a solution. So, LinearLayout to the rescue. Using LinearLayout and its weight factors efficiently, let us overcome those design issues and free ourselves from the resource-demanding TableLayout.

Candidate part with TableLayout before

And the result when using LinearLayout.

Candidate Part after switching to LinearLayout

It might not be such a huge difference, but based on the allocations that we saved this alone might have saved us a frame or two.

Another tricky part, that was causing a lot of allocations, was that one of the things that characterise a Candidate had to be drawn in capital letters. What easier way than setting an XML flag for it on the TextView. After all though, that did not seem to be such a good idea. Our approach on this, was to just use Java’s String transformation .toUpperCase().

textAllCaps attribute before

Use of .toUpperCase() after

Here is also a screenshot of the generated allocations from TextView’s “textAllCaps” attribute.

AllCapsTransformationMethod allocations

You can see here that internally the TextView is generating a new Transformation method each time:

That is probably fine in a common scenario where we just use it in a static layout, but when we have to deal with scrolling, it can create some overhead.

It might seem a little thing as well, but it really played its part on the overall optimization.