Android : Getting Fancy with Lists - Better. Stronger. Faster.

The getView() implementation shown in the FancyLists/DynamicEx project works, but it's inefficient. Every time the user scrolls, we have to create a bunch of new View objects to accommodate the newly shown rows. This is bad.

It might be bad for the immediate user experience, if the list appears to be sluggish. More likely, though, it will be bad due to battery usage—every bit of CPU that is used eats up the battery. This is compounded by the extra work the garbage collector needs to do to get rid of all those extra objects we create. So the less efficient our code, the more quickly the phone's battery will be drained, and the less happy the user will be. And we want happy users, right?

So, let's take a look at a few tricks to make our fancy ListView widgets more efficient.

1. Using convertView

The getView() method receives, as one of its parameters, a View named, by convention, convertView. Sometimes, convertView will be null. In those cases, we need to create a new row View from scratch (e.g., via inflation), just as we did in the previous example. However, if convertView is not null, then it is actually one of our previously created View objects! This will happen primarily when the user scrolls the ListView. As new rows appear, Android will attempt to recycle the views of the rows that scrolled off the other end of the list, to save us from having to rebuild them from scratch.

Assuming that each of our rows has the same basic structure, we can use findViewById() to get at the individual widgets that make up our row and change their contents, and then return convertView from getView(), rather than create a whole new row. For example, here is the getView() implementation from the earlier example, now optimized via convertView (from the FancyLists/Recycling project):

public class RecyclingDemo extends ListActivity {
  private TextView selection;
  private static final String[] items={"lorem", "ipsum", "dolor",
          "sit", "amet",
          "consectetuer", "adipiscing", "elit", "morbi", "vel",
          "ligula", "vitae", "arcu", "aliquet", "mollis",
          "etiam", "vel", "erat", "placerat", "ante",
          "porttitor", "sodales", "pellentesque", "augue", "purus"};

  @Override
  public void onCreate(Bundle icicle) {
    super.onCreate(icicle);
    setContentView(R.layout.main);
    setListAdapter(new IconicAdapter());
    selection=(TextView)findViewById(R.id.selection);
  }

  public void onListItemClick(ListView parent, View v,
                             int position, long id) {
    selection.setText(items[position]);
  }

  class IconicAdapter extends ArrayAdapter<String> {
    IconicAdapter() {
      super(RecyclingDemo.this, R.layout.row, items);
    }

    public View getView(int position, View convertView,
                        ViewGroup parent) {
      View row=convertView;

      if (row==null) {
        LayoutInflaterinflater=getLayoutInflater();

        row=inflater.inflate(R.layout.row, parent, false);
      }

      TextView label=(TextView)row.findViewById(R.id.label);
      label.setText(items[position]);

      ImageView icon=(ImageView)row.findViewById(R.id.icon);
      if (items[position].length()>4) {
        icon.setImageResource(R.drawable.delete);
      }
      else {
        icon.ysetImageResource(R.drawable.ok);
      }

      return(row);
    }
  }
}

					  

Here, we check to see if the convertView is null. If so, we inflate our row; otherwise, we just reuse it. The work to fill in the contents (icon image and text) is the same in either case. The advantage is that we avoid the potentially expensive inflation step. In fact, according to statistics cited by Google at the 2010 Google I|O conference, a ListView that uses a recycling ListAdapter will perform 150 percent faster than one that does not. For complex rows, that might even understate the benefit.

Not only is this faster, but it uses much less memory. Each widget or container—in other words, each subclass of View—holds onto up to 2KB of data, not counting things like images in ImageView widgets. Each of our rows, therefore, might be as big as 6KB. For our list of 25 nonsense words, consuming as much as 150KB for a nonrecycling list (25 rows at 6KB each) would be inefficient but not a huge problem. A list of 1000 nonsense words, though, consuming as much as 6MB of RAM, would be a much bigger issue. Bear in mind that your application may have only 16MB of Java heap memory to work with. Recycling allows us to handle arbitrary list lengths with only as much View memory consumed as is needed for the rows visible onscreen.

Note that row recycling is an issue only if we are creating the rows ourselves. If we let ArrayAdapter create the rows, by leveraging its implementation of getView(), as shown in the FancyLists/Dynamic project, then it deals with the recycling.

2. Using the Holder Pattern

Another somewhat expensive operation commonly done with fancy views is calling findViewById(). This dives into our inflated row and pulls out widgets by their assigned identifiers, so we can customize the widget contents (e.g., to change the text of a TextView or change the icon in an ImageView). Since findViewById() can find widgets anywhere in the tree of children of the row's root View, this could take a fair number of instructions to execute, particularly if we need to find the same widgets repeatedly.

In some GUI toolkits, this problem is avoided by having the composite View objects, like rows, be declared totally in program code (in this case, Java). Then, accessing individual widgets is merely a matter of calling a getter or accessing a field. And we can certainly do that with Android, but the code gets rather verbose. What would be nice is a way that enables us still to use the layout XML, yet cache our row's key child widgets so that we need to find them only once. That's where the holder pattern comes into play, in a class we'll call ViewHolder.

All View objects have getTag() and setTag() methods. These allow us to associate an arbitrary object with the widget. The holder pattern uses that "tag" to hold an object that, in turn, holds each of the child widgets of interest. By attaching that holder to the row View, every time we use the row, we already have access to the child widgets we care about, without having to call findViewById() again.

So, let's take a look at one of these holder classes (taken from the FancyLists/ViewHolder sample project):

package com.commonsware.android.fancylists.five;

import android.view.View;
import android.widget.ImageView;

class ViewHolder {
  ImageView icon=null;

  ViewHolder(View base) {
    this.icon=(ImageView)base.findViewById(R.id.icon);
  }
}

ViewHolder holds onto the child widgets, initialized via findViewById() in its constructor. The widgets are simply package-protected data members, accessible from other classes in this project, such as a ViewHolderDemo activity. In this case, we are holding onto only one widget—the icon—since we will let ArrayAdapter handle our label for us.

Using ViewHolder is a matter of creating an instance whenever we inflate a row and attaching said instance to the row View via setTag(), as shown in this rewrite of getView(), found in ViewHolderDemo:

public View getView(int position, View convertView,
                   ViewGroup parent) {
  View row=super.getView(position, convertView, parent);
  ViewHolder holder=(ViewHolder)row.getTag();

  if (holder==null) {
    holder=new ViewHolder(row);
    row.setTag(holder);
  }

  if (getModel(position).length()>4) {
    holder.icon.setImageResource(R.drawable.delete);
  }
  else {
    holder.icon.setImageResource(R.drawable.ok);
  }

  return(row);
}

Here, we go back to allowing ArrayAdapter to handle our row inflation and recycling for us. If the call to getTag() on the row returns null, we know we need to create a new ViewHolder, which we then attach to the row via setTag() for later reuse. Then, accessing the child widgets is merely a matter of accessing the data members on the holder. The first time the ListView is displayed, all new rows need to be inflated, and we wind up creating a ViewHolder for each. As the user scrolls, rows get recycled, and we can reuse their corresponding ViewHolder widget caches.

Using a holder helps performance, but the effect is not as dramatic. Whereas recycling can give you a 150 percent performance improvement, adding in a holder increases the improvement to 175 percent. Hence, while you may wish to implement recycling up front when you create your adapter, adding in a holder might be something you deal with later, when you are working specifically on performance tuning.

In this particular case, we certainly could simplify all of this by skipping ViewHolder and using getTag() and setTag() with the ImageView directly. This example is written as it is to demonstrate how to handle a more complex scenario, where you might have several widgets that would need to be cached via the holder pattern.