ListView Optimization 2

ListView Optimization 2:

If a ListView does not do any optimization, and there are many entries, when we quickly drag the ListView interface, the constant GCGC (garbage Collection) garbage collection, What is the cause of this problem when the GC outofmemory memory overflow At some point and the application hangs out? We know that the ListView feature is that each entry will be called once GetView method, if we do not optimize, each call to execute all the statements in the GetView method, and will be in the top of the entry to remove the interface when the object is removed, this is a waste of resources.

At this point we will think, if the item is removed from the interface when it is not recycled, but to take it back to use again, so that the efficiency of the ListView is not optimized? Fortunately, the force of the Google engineers have provided us with a ListView cache mechanism, it will cache an entry in the entry, when the interface at the top of the entry display is complete, a cache entry appears, That is, Baseview in the GetView method of Convertview, the role of Convertview is actually a system has been reclaimed by the historical cache view object, we can use this object there is no need to re-go to the XML file to parse the layout. Determines whether the passed in parameter Convertview is NULL, creates a convertview if NULL, and returns, if not NULL, for direct use. This is the first optimization method, which is simply to reuse the view object of the historical cache, reducing the number of times the View object was created.

The second optimization method is to reduce the number of Findviewbyid (), Findviewbyid is a relatively performance-intensive operation, because each time in GetView, you need to re-findviewbyid, re-find the control, The control is then assigned and the event is set accordingly. This is actually doing the duplication of things, because the getview, in fact, contains these controls, and the IDs of these controls are the same, that is, as long as the view in Findviewbyid once, there is no need to findviewbyid each time. The solution to this problem is to encapsulate the control in item as a JavaBean, and find the corresponding control when the item entry is loaded.

The first two optimization methods are the most general optimization, generally we use the ListView when the two optimizations are used, but only these two ways is not enough, for example, when the ListView view object has a picture resource, it will occupy a lot of memory, so it is easy to cause memory overflow, For this situation there are two optimization methods, batch loading and paging loading, and I consider these two methods to take advantage of the different optimizations of time and the use of space. Loading in batches, we load only a certain amount at a time, as if it were loaded at different time periods. Page loading is like putting a certain number of entries in different spaces, using these two ideas to implement batch loading and paging loading.

Batch loading is mainly to solve the problem of user experience, if the amount of data is too large, the user waits for a long time, and there will be a ANR exception. For example, we want to read 100 data from the database, if a one-time read, it will take a long period, but then we modify the SQL statement, specify from the beginning to get the data, how much data obtained, the SQL statement is:

"Selectphone,mode from Blacknumber limit?" Offset? ", New String[]{string.valueofa (MaxNumber), string.valueof (Stateindex)}

The newly acquired data is added to the end of the collection.

Say page load, its implementation idea is such, implement Onscrolllistener interface, rewrite onscrollstatechanged and onscroll method, use Onscroll method to realize "sliding" post processing check whether there is a new record, if there is, Call Addfooterview, add record to Adapter,adapter call notifydatasetchanged update data; If there is no new record, remove the custom Mfooterview, You can use onscrollstatechanged to detect if you are rolling to the last line and stop rolling to and performing the load.

There is also a way to optimize the use of images asynchronous loading method, the realization of the idea is:

1. Get the picture display from the memory cache first (memory buffer)

2. Get the words from the SD card (SD card buffer, the image from the SD card is placed in the sub-thread execution, otherwise the quick bottle will not smooth enough)

3. Can not get the words from the network download pictures and save to the SD card at the same time add memory and display (depending on the situation to see if you want to display)

When we use the ListView, there may be a problem with the image jumping (dislocation):

Picture dislocation the nature of the problem stems from our ListView using the cache Convertview, suppose a scene, a ListView one screen display nine item, then when pulling out the tenth item, in fact the item is reused the first item, In other words, when the first item is downloaded from the network and is finally displayed, the item is not in the current display area, and the result of the display will probably output the image on the tenth item, which leads to the problem of image dislocation. So the solution is to show that it is visible, not visible. In the Imageloader, there is a Imageviews map object, which is used to save the current display area image corresponding to the URL set, before the display to determine the processing can be.

ListView Optimization 2