Android optimizes the speed of loading pictures from the network.

Loading pictures from the network there are two main issues to note:

1. Memory management: The image occupies a large amount of memory, the number of fake pieces, it is easy to let the system throw out of memory of the exception.

At the same time, we should also pay attention to different versions of Android memory management differences.

2. Performance: Picture loading speed, and loading pictures do not affect the smoothness of the UI

Especially in Viewpager,gridview and ListView and so on need to load a lot of pictures in a short time, the above two problems are more prominent ...

To solve the above two problems, we need to use the technology

1. Reduce the bitmap of loaded images

You can calculate the desired bitmap by implementing the view size of the display picture, as well as the way you can generate thumbnails only first.

2. Using MemoryCache and DiskCache (to prevent activity from being interrupted by an external event (such as a phone call) that causes the memory cache data to be erased,

Can recover as soon as possible, do not go to the network to pull the image data.

You can use the system-provided support classes LRUCache and Disklrucache (ANDROID.SUPPORT.V4), and you need to be aware of the use of caching

Problems with multithreading synchronization (multiple threads need to be emitted in a short period of time, and these threads all use a single piece of memory).

The 3.I/O operation uses asynchronous loading of picture data to prevent the UI thread from blocking.

Wait a minute......

last quote from the Android official website on bitmap memory management:

To set the stage for this lesson, here's how Android's management of bitmap memory has evolved:

• On Android Android 2.2 (API level 8) and lower, when garbage collection occurs, your app ' s threads get stopped. This causes a lags that can degrade performance. Android 2.3 Adds concurrent garbage collection, which means that the memory are reclaimed soon after a bitmap are no Lon Ger referenced.
• On Android 2.3.3 (API level) and lower, the backing pixel data for a bitmap are stored in native memory. It is separate from the bitmap itself, which are stored in the Dalvik heap. The pixel data in native memory isn't released in a predictable manner, potentially causing an application to briefly exc Eed its memory limits and crash. as of Android 3.0 (API level One), the pixel data is stored on the Dalvik heap along with the associated bitmap.

Above, the general meaning is that in android2.2 and previous versions, Android garbage collection can cause the application thread to stall. Garbage collection in android2.3 and later versions is concurrent and does not affect the application thread, which may result in non-referenced bitmap data being recycled quickly.

In adroid2.3.3 and prior versions of pixel data, there is local memory, which causes it to not be freed and may cause application memory overflow to crash. After android3.0, the pixel data and bitmap data are saved in the Java heap.

Please crossing the instructions on the net above for detailed introduction http://developer.android.com/training/displaying-bitmaps/index.html