Lists can be seen in almost any app. It’s an easy way to show items such as recipes, contacts, or any type of category really. It only makes sense that Android should have a built-in way to show this type of data representation. The latest implementation is the RecyclerView. It’s built for efficiency as it reuses views instead of recreating them every time a row comes on screen. Before the RecyclerView we had the ListView, which is still used widely today. While the ListView also recycles views, it continues to hold a place as one of the most misconfigured views in Android today. We know this topic has been written about many times before, but we’re bringing it up on the blog today because we still get many applicants who configure them incorrectly.

Here is what the standard novice ArrayAdapter for a ListView looks like:

Writing an AdapterView this way is not an issue when your list can be shown on the screen all at once, but then you could have created a basic view and avoided the hassle of an ArrayAdapter altogether right? When using a ListView we plan on showing a large list, often one with complex views. This is where performance takes a hit. The above way is costly to performance. When a user scrolls, each view is inflating and calling findViewById() every time. When findViewById() is called, the View Hierarchy is traversed until the proper Id is found. It does this for each sub-view you have to find! And the quicker the user scrolls, the more noticeable the sluggishness of the scrolling becomes. To remedy this, we can use a static class in combination with the convertView that we didn’t use earlier.

当所有列表项都能够一次性在一屏中显示的时候，这种写法并没有什么问题，但这样你就创建了一个基本视图，并完全避免了ArrayAdapter的麻烦了吗？当ListView需要显示一个很大的列表集，而且列表子项是一个非常复杂的视图的时候，上面的方式会消耗大量的性能。当用户滑动屏幕的时候，每个视图都会被inflat并且调用findViewById()方法。当findViewById()方法被调用的时候，会遍历整个视图层级，直到找到正确的Id。每个子视图都要执行上述过程！并且用户滑动的越快，卡顿现象愈加明显。为了解决这个问题，我们可以使用一个静态类来绑定还没被使用的convertView。

But what is the convertView ? Well, it allows the ListView to skip some of the setup needed to display the contents of a row. It is the view of a row that is now off the screen. We can reuse the view for the new row that will now be displayed. When the ListView is displayed in the beginning, everything happens like normal. Since there aren’t any views that can be reused, convertView is null. The view is inflated just like in our previous version, but the TextViews are found and the references are kept in a ViewHolder. We can then store the ViewHolder within the view by calling setTag(). This allows us to store data in the view which we can reference later, as shown in the latter half of the revised getView().

The changes we made might not seem like a huge impact, but as our views become more complicated and the number of them grows, inefficiencies will become noticeable. The last thing we want to do as developers is create an app with a negative user experience. Remember, just one sub-par ListView could be the life or death of an app, so let’s not take the chance!

我们所做的更改可能看起来并没有太大的效果，但是随着布局越来越复杂并且数量也越来越多，效果将变得越来越明显。作为开发者，我最不想做的事就是开发一个用户体验很差的app。所以请记住，仅仅一个低水平的ListView都有可能让一个app死掉，我们一定得避免这种情况发生。