About picture optimization, it is roughly as follows

Why image optimization



I believe that when I started to learn Android, I had a picture that was too large and directly reported an error. Here is a brief introductionOOM issues,Android support picture format and picture optimization of several ways



What is OOM? : Android processes (APP level) have the maximum memory limit,Beyond this limit the system will throw) OOM error

Picture OOM problem produces several cases

  1. Loading too many images on one page at a time
  2. Loading large images without compression

3.Android lists load lots of Bitmaps without caching (third-party frameworks)

Image formats supported by Android

Webp: released by Google in 2010, supports lossless and lossy, which is ideal. GIF: supports multi-frame animation, but Android’s own image library does not support it, so you need to use a third-party framework

How much memory is occupied by an image? How much memory is occupied by an image

Therefore, it can be seen from the above that the picture storage optimization is as follows

  1. Size optimization: by reducing width and height
  2. Quality compression: Change the memory footprint of a pixel (optimize decoding rate)
  3. Memory reuse: The inBitmap attribute is required

Size of the compression

There are two main methods that work

IntJustDecodeBounds =true (can get width and height of image without loading image)

InSampleSize (with appropriate compression ratio)

!!!!!!!!! Simply resize the ImageView will have no effect on the image (bitmap optimization is required)

Maybe it’s not clear, so post a picture

The quality of compressed

Common image formats need to be decoded before they can be set on the UI

Using RGB-565 instead of ARGB-8888 can reduce the memory footprint of the image, which is already available in the red rectangle class below

Memory reuse

InBItmap, the following image should be <= the size of the first image, the following image is the second image reuse the first image

MCurrentBitmap is the Bitmap of the first graph



And then a little mentionBitmap memory management

Prior to 3.0, support for pixel data was kept in local memory,

After 3.0, pixel data and bitmaps are stored in the Dalvik heap

First of all, we need to understand the two resource folders mipmap and Drawable. Generally, the startup icon is placed in the Mipmap folder. And then the difference between these two folders is setHasMipmap mipmap is true and drawable is false

How to make the Android image resource adapter various mobile phone to understand resolution and DPI resolution unit 1.240 px – 320-2.320-480 xxhdpi xhdpi!!!!!! Mainstream xxxhdpi 3.480-640

There are two options

Scheme 1: Create a set of image resources for each DPI (which increases the workload of designers and the size of APK)

Scheme 2: provide a set of pictures with the maximum DPI to be supported (the concept of automatic rendering);

Here are the rules for picture matching (assuming that my mobile phone has a resolution of 480dpi, I will put the pictures I need under the XHDPI folder, and the system will process them as follows)

  1. First look xxhdPI folder, not found, go down
  2. Look for xxxHDPI folder again, not found, go down
  3. Then look for the noHDPI folder, if not found, will go to the xHDPI folder

One of the problems is that when a phone takes pictures from different folders, the display effect is different. If the folder is not a match, the system will zoom in or out of the picture

** Common image loading optimization methods

  1. Asynchronous optimization: Images are requested in the background (no use of resources in the main UI)
  2. Image caching: Cache images in a list (cache in a local file)
  3. Web requests: Image requests using OkHttp (many advantages)
  4. Lazy loading: loading the image when it is rendered in the viewable area

The loading of pictures is generally usedMulti-level cache loading process



The main reasons are as follows

If you use network request every time (the server can not tolerate, and waste user traffic), usually use memory and local file two-level cache (how to use only local file, unsafe, easy to be removed).

BitmapRegionDecoder is used to solve the problem of loading large images using image compression to load large images

Universal ImageLoader, multithreading, support download monitor bitmap clipping ListView pause load free configuration better control the image loading process to provide images under a slower network load

Picasso: Use ARGB-8888 when storing the original image locally.

3.Glide (From Google), which is designed to change the size of an image and load it into memory in line with the Activity/Fragment life cycle

4.Fresco (From Facebook) features the following features: Fast first time image loading, good user experience, excellent memory performance, efficient memory block image management (shared memory mechanism to solve the OOM problem) Multi-image requests encapsulate loading bottom resolution images first, then displaying high resolution images: custom placeholders, rounded image GIfs, Webp format under 5.0, Fresco places images in a special memory area. Of course, when the image is not displayed, the occupied memory will be released automatically. This will make the APP more fluid and reduce the number of OOM images. Loading GIFs and WebP giFs is a huge headache for any Android developer. Each frame is a large Bitmap, and each animation has many frames. Fresco takes care of every frame and manages your memory.

The above is the general content, depending on the time of the blogger, I will write about the use of frame and the small case about image optimization in the future