ListView Optimization Full Interpretation

First, re-use View II, the use of Viewholder

and preferably a static inner class. Static inner class, do not hold references to external classes, avoid memory leaks ...

As mentioned in Java, the effective scenario for static class is primarily intended to reduce the memory overhead associated with the large number of internal classes holding external class references

A non-static inner class holds a reference to an external class, which involves releasing dependent internal classes of external classes. If an internal class has too many references to an external class, it can easily cause the outer class to be freed.

Third, the ListView height is set to match-parent four, involving pictures and so on when it is best to use asynchronous loading

?? In my project, each item in the ListView has a picture and a lot of textview, and all the TextView have to set the non-system font; adapter uses Viewholder optimization, and the code in GetView is already very small. but still the card; the data in my ListView is a list of objects in which only the resource ID of the picture that the item needs to show, or the path to the picture, takes some action to get the picture, which is actually time-consuming; so I changed the original object. The picture objects are stored directly in the object corresponding to the item, and then initialized with adapter, although the ListView will take a little longer to display, but the result is that the ListView slides a lot smoother. And then I'll get the font typeface from assets in the adapter initialization method, and the font through the static variables are stored, and then getview only need to set TextView taptface, The time it takes to get a font from asset is not required; After two steps above, my ListView is not stuck at all, it is very smooth.
?? The optimization of the ListView is actually to find the time-consuming operation in GetView, then extract it, or use the asynchronous way to set the data for the layout of the item, if it really needs to be synchronized, it can only be prepared when the adapter is initialized, and then the GetView only need to bind the line.

V. Introduce the thread pool and thread queue when loading asynchronously

?? In Java, if a new thread is created every time a request arrives, the overhead is quite large. In practice, the amount of time and resources spent on creating and destroying threads for each server requesting the creation of a new thread may even be much more than the time and resource spent processing the actual user request. In addition to the overhead of creating and destroying threads, the active thread also consumes system resources. If you create too many threads in a single JVM, you may cause your system to be running out of resources due to excessive memory consumption or "over-switching". To prevent resource shortages, server applications need some way to limit the number of requests processed at any given moment, minimizing the number of threads that are created and destroyed, especially when some resources are expensive to create and destroy, and use existing objects to service as much as possible, which is why "pooled resources" technology. Thread pooling is primarily used to address thread life-cycle overhead and resource-poor issues. By reusing threads on multiple tasks, the cost of thread creation is shared across multiple tasks, and the delay caused by thread creation is eliminated because the thread already exists when the request arrives. In this way, you can immediately service the request and make the application respond faster. In addition, you can prevent resource shortages by adjusting the number of threads in the thread pool appropriately. So, here we have to maintain a task queue locally, all the images that need to be loaded into the queue, loading only the current task at a time, as the list is sliding, the current view display, the task will be pinned, priority loading. This can not only avoid excessive thread consumption of resources, but also to ensure the rational use of resources.

Six, the ListView multi-Layout Seven, the ListView page load eight, the picture memory optimization

?? When the program load the picture, the size of the picture may be very large, but when displayed on the phone, the actual display in the program, ImageView will reduce the large image display, in fact, many of the details of the picture will not be displayed. But when we use Bitmapfactory to parse the picture, Bitmapfactory will parse the complete picture, create the memory according to the resolution of the picture, convert to bitmap, it will occupy very large memory.

?? How to solve it?

1. The bitmap is set before loading, which reduces the image width and height after image decoding, as well as the sample rate of images to reduce memory consumption. You can use the image compression algorithm that is officially recommended by Google.
2. When the image is decoded, the pixel color information is reduced, from ARGB4 bytes, to Android-supported short-byte colors such as ARGB565, removing transparency.

Nine, the picture loading introduces the three-level cache mechanism Ten, the picture asynchronous loading causes the dislocation problem to solve

1. Because of the reuse of the ListView, resulting in a large number of calls to the GetView method when moving quickly, because multiplexing, resulting in each imageview can have a number of different URLs at the same time asynchronous task load, which led to the image of multiple confusion, Need to give each time load view when the ImageView set tag, this tag is the URL, in the asynchronous task to set the picture, to check whether the current URL and imageview tag consistent, only set the picture.
2. Because of the reuse, when the ListView is scrolling, it actually shows the previously loaded item, the contents of ImageView in the previous item, it may be the picture information loaded by the other entries, this time, the operation first shows the picture of the other items, then opens the network after loading, The correct data will be refreshed for itself. Workaround: At each GetView, the contents of the ImageView display are set to the "Loading" picture. Overwrite old and existing data.

Xi. slide does not load pictures stop loading pictures

?? Given the actual human-computer interaction situation, in the ListView adapter, no asynchronous operations should be triggered in each row. That is, there is no point in initiating any asynchronous operation when there is a fling (fast swipe) operation in the ListView. Once the scrolling stops or is about to stop, it's time to start to actually display the contents of each line.
?? When a quick slide list (scroll_state_fling), the picture in item or the view that needs to consume resources, can not be displayed, but in the other two states (Scroll_state_idle and Scroll_state_touch_ SCROLL), the view is displayed.

12, Recyclerview alternative to the cause of the ListView

1. The Recyclerview encapsulates the recovery reuse of the Viewholder.
2. Recyclerview uses the layout manager to manage the location of the child view (which is currently only available for Linearlayoutmanager), which means that you don't have to stick to the linear display of the ListView (that is, how the vertical column is displayed), and if you provide additional custom With LayoutManager support, you can use complex layouts to present a dynamic component.
3. With the itemanimation, you can set the animation when loading and removing, which makes it easy to make various dynamic browsing effects.

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

ListView Optimization Full Interpretation