Study and optimization of ListView principles for Android

When sorting out the previous articles, a friend proposed to write about the performance optimization of ListView. This problem was also asked by others during the interview ..... Today, my pony took this opportunity to sort out a lot of similar information on the Internet. It would be better to write an article by myself, record it in this place for future use by myself, so I don't have to flip it over and find it again, write it by yourself... Well, I don't want to talk about anything else. I think the first response is the same as that of pony? Do you want to use ViewHolder to optimize ListView data loading? Actually, it is not. First of all, to optimize the ListView, you must first understand the principle of loading data in the ListView. This is a prerequisite, but Pony will make some simple additions here. You must take a closer look, there will be gains:

The display of the list requires three elements:

According to the list of adapter types, the list is divided into three types: ArrayAdapter, SimpleAdapter and SimpleCursorAdapter. You can learn how to use these three types of adapters on the official website or Baidu Google, a bunch of demos !!! ArrayAdapter is the simplest and can only display one line of words. SimpleAdapter has the best scalability and Can Customize various effects. SimpleCursorAdapter can be considered as a simple combination of SimpleAdapter on the database, which can easily display the database content in the form of a list.

The system wants to draw the ListView. He first uses the getCount function to get the length of the list to be drawn and then starts to draw the first line. How can this be drawn? Call the getView () function. In this function, you first obtain a View to see the actual situation. If it is a simple display, it is a View, if a custom widget contains many widgets, it is actually a ViewGroup), then instantiate and set each component and its data content and display it. Now, we have drawn this line. ThatDraw the next line until the painting is complete. pave the way for the above things and continue .......

Now let's take a look at the principle of ListView loading data. With this understanding, we can talk about optimization. Let's take a look at the basic principle of ListView loading data and then write it directly:

The working principle of ListView is as follows:

ListView requires the adapter to "return a view" (getView) for each item. That is to say, when the ListView starts to be drawn, the system first calls the getCount function to obtain the length of the ListView based on its return value, call getView according to the length) to draw each item of the ListView row. If your getCount) return value is 0, all rows in the list will not be displayed. If 1 is returned, only one row will be displayed. The number of returned rows is displayed. What if we want to display tens of thousands or even more items? Create a new View for each Item? Impossible !!! In fact, Android has already cached these views. You can take a look at the following to understand. This figure is the most classic image that explains the working principle of ListView. You can add it to your favorites, when you don't understand it, let's take a look at it and get a better understanding. In fact, there is a Recycler component in Android that lists the Recycler-related things that have been optimized by Google over N, such as AbsListView. recyclerListener, ViewDebug. recyclerTraceType and so on. If you want to know more about it, it is not difficult to understand it. It is because the working principle of ListView loading data cannot be clearly understood. Click here to see the big picture ):

The principle is as follows:

Run the program to view the log:

GetView is called nine times. convertView has a null value for all visible items as follows ):

Then scroll down the List until item10 appears:

ConvertView is still null, because the recycler does not have the item1 edge of the view, and is still visible at the top) and then scrolls the list to continue rolling:

ConvertView is not a null value! Item1 leaves the screen and goes to Recycler. item11 is created and then rolled down:

At this time, convertView is not empty. After item11 leaves the screen, its view (... 0f8) as convertView can accommodate item12. Now, based on the above principles, let's take a look at the most important topic of today. The optimization of the main character ListView:

First, remember two smaller points optimized by ListView:

1. expandableListView and ListActivity are officially provided. The ListView to be used in the list is an optimized ListView. If you can use the ListView provided by Google to meet your requirements, try to use the official one, absolutely!

2. As mentioned earlier by pony, ListView optimization does not actually refer to other optimizations, that is, memory optimization, or memory optimization... Having thought of OOM, it took me a lot of time) and a lot of time. Let's write it down first. If the options in our ListView are just some simple textviews, it would be easy to do, and it would not consume much, however, if your Item is a custom Item, for example, your custom Item layout ViewGroup contains: for buttons, images, flash, CheckBox, RadioButton, and other controls you can think of, you need to use ViewHolder mentioned at the beginning of the article in getView. If there is too much data, too many Loaded Images are too large. You BitmapFactory. if decode is so fierce, OOM will kill you. In this case, I will warn you again .......... Remind yourself:

The problem that pony encountered should have been encountered by everyone. The custom ListView items are out of order. I forcibly cleared the cached data convertView of ListView in getView, that is, convertView = null. Although it solved this problem and made another re-painting every time, it made a big mistake. If there was too much data, the most disgusting mistake would occur, the mobile phone is stuck or forced to shut down. Shut down, buddy ...... O_O, it is possible for a customer to kill me, but don't make such a mistake in the future. Simply clearing the cache convertView won't solve the actual problem. Continue ......

The following is a note: the correct release after the image is used up...

Let's list the optimizations in the true sense:

Okay, for the optimization problem of ListVIew, pony will understand so many records for the time being. If friends have any better optimization suggestions or something, leave a message and give pointers to the pony, which will be added in time, thank you! In fact, you can do a lot of optimization in the getView method of the ListView adapter. I remember there is also a way to optimize the findViewById () method to address the resource information efficiency, there are too many materials, and the pony will be updated in time when it finds out. It's too late. Let's take a rest first. Hey, come on, everyone, and study hard !!! O_O