Android Performance Optimization-image optimization,

Android Performance Optimization-image optimization,

Android Performance Optimization-image Optimization

In the performance optimization of Android, we will find that image resources and control resources are the most memory-consuming and most influential to performance. The impact of other resources is relatively small. Here I will explain the optimization of image resources first. If anything is wrong, I hope you can correct it.

1. First, we can perform Secondary Sampling on the image to reduce the memory usage of the image in essence. It is to narrow down the large image and put it into the memory to reduce the memory. The Code is as follows:

1 // create a thumbnail 2 private Bitmap onCreateThumbnail (String filePath2, int I) {3 4 // obtain Option 5 BitmapFactory. options options = new BitmapFactory. options (); 6 // set it to not read content, and the value reads the boundary value 7 options. inJustDecodeBounds = true; 8 // You can edit the value to obtain the Boundary Value and add it to option 9 BitmapFactory. decodeFile (filePath2, options); 10 // get the scaling ratio of 11 int ratiowidth = (options. outWidth)/I; 12 // assign a zoom ratio of 13 options. inSampleSize = ratiowidth; 14 // set the displayed image format to 15 options. inPreferredConfig = Config. RGB_565; 16 // set to read content, 17 options. inJustDecodeBounds = false; 18 // get the thumbnail 19 return BitmapFactory. decodeFile (filePath2, options); 20}

 

Of course, there are a lot of third-party frameworks that can quickly implement this function, such as Picasso. Its usage is just to call a method, which is quite easy (no friend, you can search on the Internet for a simple and practical framework ).

2. The third-layer Cache architecture is adopted to increase the image access speed. The three-tier Cache architecture is memory-file-network.

Memory is the fastest part of the access speed, but the allocated space is limited, so it is impossible to occupy too much. The memory cache can use the LRU algorithm (the least recently used algorithm) to determine the images in the memory to be deleted and save the images.

Files are saved to the local device, which can be stored in the SD card or in the internal storage of the mobile phone.

The network is used to download images from the network and load images.

3. Common images in png, JPG, webp, and other formats must be decoded before they are set to the UI. Different bit rates may also cause different memory usage. The following describes several common decoding rates:

1) the decoding rate of the ALPHA_8 format. At this time, the image has only the alpha value and no RGB value. one pixel occupies one byte, and the memory usage is the smallest, but it is also the least clear, it is easy to render the image distorted and is not recommended for use.

2) the decoding rate of ARGB_4444 format. The image in this format looks of poor quality and is no longer recommended. We strongly recommend that you use ARGB_8888 instead. A pixel occupies 2 bytes, And the alpha (A), Red (R), Green (G), and Blue (B) Values each occupy 4 bites. A total of 16 bites, that is, 2 bytes

3) ARGB_8888 Format Decoding rate. A pixel occupies 4 bytes, alpha (A) value, Red (R) value, Green (G) value, Blue (B) each value occupies 8 bites, a total of 32 bites, that is, 4 bytes. This is a high-quality image format, which is commonly used on computers. It is also the default format of a BitMap on the Android phone.

4) decoding rate in the RGB_565 format. A pixel occupies 2 bytes and has no alpha (A) value. That is, transparency and translucent are not supported. The Red (R) value occupies 5 bites, green (G) accounts for 6 bites, and Blue (B) accounts for 5 bites. A total of 16 bites are 2 bytes. For a translucent image, the format of the image can achieve a better display effect, compared with ARGB_8888, it can also reduce the memory overhead by half, so it is a good choice.

In general, it is recommended to use the last one, with good performance and no alpha value. The system does not need to perform secondary rendering, which can greatly improve the efficiency and performance.

 

4. The last point is also the most important aspect of image optimization. Reuse Bitmap.

We all know that bitmap occupies a large amount of memory space, such:

 

Therefore, you can reuse the existing bitmap memory area. The inBitmap attribute can improve the Bitmap cycle efficiency. Memory usage:

 

Using this attribute, we can tell the Bitmap decoder to try to use an existing memory area. The new decoded bitmap will try to use the pixel data memory area occupied by the previous bitmap in the heap, instead of asking the memory to re-apply for a region to store bitmap. With this feature, even thousands of images only occupy the memory size of the number of images displayed on the screen.

Code:

// Obtain the option BitmapFactory. Options = new BitmapFactory. options (); Options. inBitmap = mCurrentBitmap; mCurrentBitmap = BitmapFactory. decodeFile (filename, options );

 

 

Note the following restrictions when using this attribute:

1. In SDK 11-> 18, the size of the reused bitmap must be consistent. For example, the image size assigned to inBitmap is 100-100, the new bitmap must be-to be reused. Starting from SDK 19, the size of the new bitmap must be smaller than or equal to the size of the bitmap that has been assigned.

2. The new bitmap and the old bitmap must have the same decoding format. For example, if the previous bitmap is 8888, therefore, bitmap 4444 and 565 formats are not supported.