* 译文出自 : [开发技术前线 www.devtf.cn。未经允许，不得转载!](http://www.devtf.cn)

* 译者 : [liuling07](https://github.com/liuling07)

* 校对者: [这里校对者的github用户名](github链接)

* 状态 : 未完成 / 校对中 / 完成

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.

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!