The theory behind your phone’s incredible long, but smooth lists.

Introduction

First of all I want to let you know that this is the first time I’m writing on Medium, and also that I claim not to be anything near an expert in this field. I’ve just been programming a bit and found this subject to be pretty interesting and relevant. It should be noted that my experience comes from the Android platform, but the practices may apply to other platforms aswell. I also want to get started writing Medium post, so any feedback regarding my writing is appreciated.

And now that we’re over the pity-seeking part, let’s get started on the topic.

The problem

So, you are probably using a lot of time scrolling lists on your phone, in the endless stream of new content every day. But with all this content, how does our phones exactly handle it? I mean, if my mid-range Moto G, should save all those list rows (cards, contacts, tweets etc.) in its memory, it would run out of it pretty fast. Therefore, some bright men (or women for that sake) have developed a way to control the visual elements of a list, so we won’t lose all our memory while viewing our contacts list.

To see how basic mobile lists were done in the beginning, we can use an example. Imagine you have a list of contacts with, say, 300 contacts. Each contact is an row or item in the list. For the example’s sake beneath is list row we imagine.

Image for post
Image for post
Figure 1: List row

The row item contains several different “elements” or “views”. First there is the image, then there’s the two text labels and finally the call button. Now that is 4 views with unique data attached to them. All of these views are contained in some kind of “container view” that is then inserted in our actual list. Following our example with 300 contacts — we must also have 300 of these “container views”. Without getting too technically correct; this means that we have 1200 views, that our phone has to store in its memory.

The solution

300 contacts is far from unrealistic for average person, but 1200 views is a bit too many for the average phone. So how do we create a situation where our phone can actually handle our contacts list, but still scroll smoothly without annoying us too much with lag or delay?

It should be noted that the following method works, because the actual data (like the title, phone number and a reference to where the image is located on the device), consumes less memory than view data. Views contain information like the width, height and color of the view, and have actually loaded the image into the view.

This means that having a view in memory uses more memory that just having the raw data.

So instead of having a list with a fixed but big amount of list rows taking up your phone’s memory, like seen on the left, where we have all the views for the 300 contacts in a long list, we use a different solution. As you can see, the user is actually only viewing 3 of the views (in this scenario), so this means there are 297 hidden views. Since raw data uses less memory than the data for all the views, we seperate the views from the raw data. Now we have a “raw data”-list saved in our memory and then we create a list containing much less views (six in our scenario).

Image for post
Image for post

As illustrated above we have a list containing only six views. This means that when the user scrolls down, the views that are disappearing at the top, moves down to the bottom, for instance Row 1 moves down below Row 6, when Row 5 becomes visible. That way we will always have the same amount views in our memory. We are “recycling” the views by just getting the information from the “raw data”-list and inserting it when it is needed. In real life we would probably have more than six views, but this illustrates the general idea.

The smart part is the seperation of the raw data, that I mentioned before. Now, everytime a view is in the “display zone”, it gets the data from the raw data list in our memory, according to the perceived position.

Conclusion

So while the constant switching of data in our views might be more CPU intensive, the amount of memory we save is enormous. I mean only having to save 6 views and its properties instead of saving 300 views!

So yeah, this is the technique behind long but smooth and performant lists. I hoped you enjoyed this read, and please give me any feedback you might have.

Written by

Aspiring web developer and designer. Loving technology, mathematics and beautiful UI design.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store