Android Compress pictures to resolve oom errors

Your ImageView only 128*96 pixel size, just to display a thumbnail, it is not worthwhile to load a picture of 1024x768 pixel completely into memory.

So we need a way to solve this problem.

[Java]View Plaincopy

2. Public Static int calculateinsamplesize (bitmapfactory.options Options,
4. int reqwidth, int reqheight) {
6. //height and width of the source picture
8. Final int height = options.outheight;
10. Final int width = options.outwidth;
12. int insamplesize = 1;
14. if (Height > Reqheight | | width > reqwidth) {
16. //Calculate the ratio of the actual width to the target width and height
18. Final int heightratio = Math.Round ((float) height/(float) reqheight);
20. Final int widthRatio = Math.Round ((float) width/(float) reqwidth);
22. //Select width and high school minimum ratio as the value of the insamplesize, which guarantees the width and height of the final image
24. //must be greater than or equal to the width and height of the target.
26. Insamplesize = HeightRatio < WidthRatio? Heightratio:widthratio;
28. }
30. return insamplesize;
32. }

[Java]View Plaincopy

2. Public Static Bitmap Decodesampledbitmapfromresource (Resources res, int resId,
4. int reqwidth, int reqheight) {
6. ///First resolution set Injustdecodebounds to True to get the picture size
8. Final Bitmapfactory.options Options = new bitmapfactory.options ();
10. Options.injustdecodebounds = true;
12. Bitmapfactory.decoderesource (res, resId, options);
14. //Call the method defined above to calculate the Insamplesize value
16. Options.insamplesize = calculateinsamplesize (options, Reqwidth, reqheight);
18. //Use the obtained Insamplesize value to parse the picture again
20. Options.injustdecodebounds = false;
22. return Bitmapfactory.decoderesource (res, resId, options);
24. }

This method can be very convenient to compress the picture. Prevent Oom

=============================================

[Java]View Plaincopy

1. Mimageview.setimagebitmap (
2. Decodesampledbitmapfromresource (Getresources (), R.id.myimage, (+ ));

This method can also be very convenient to compress the picture.

===========================================

In order to load images efficiently, usually we are accustomed to using image caching techniques

Loading a picture in your application's UI interface is a simple matter, but when you need to load a lot of pictures on the interface, things get complicated. In many cases (such as using widgets such as ListView, GridView, or Viewpager), images displayed on the screen can be continuously increased through events such as sliding screens, eventually resulting in oom.

In order to ensure that the memory usage is always maintained in a reasonable range, the image removed from the screen is usually recycled. The garbage collector will also assume that you no longer have a reference to these pictures to perform GC operations on them. Using this approach to solve the problem is very good, but in order to allow the program to run quickly, in the interface to quickly load the picture, you have to consider that some pictures are recycled, the user then re-slide it into the screen this situation. It is a performance bottleneck to reload the images that have just been loaded, and you need to find a way to avoid the situation.

This time, the use of memory caching technology can be a good solution to this problem, it allows the component to quickly reload and process the picture. Let's take a look at how memory caching technology can be used to cache images so that your application will be able to improve responsiveness and fluency when loading many images.

Memory caching technology provides quick access to images that consume valuable memory from applications. The most core of these classes is LRUCache (this class is provided in the ANDROID-SUPPORT-V4 package). This class is ideal for caching images, and its main algorithm is to store recently used objects in linkedhashmap with strong references, and to remove the least recently used objects from memory before the cached value reaches a predetermined value.

In the past, we often used an implementation of a very popular memory caching technique, either soft or weak (SoftReference or weakreference). However, this is no longer recommended because, starting with Android 2.3 (API Level 9), the garbage collector is more inclined to reclaim objects holding soft or weak references, which makes soft and weak references less reliable. In addition, in Android 3.0 (API level 11), image data is stored in local memory, so it cannot be released in a predictable way, which poses a potential risk of memory overflow and crash of the application.

To be able to choose a suitable cache size for LRUCache, there are several factors that should be taken into account, such as:

• How much memory can your device allocate for each application?
• How many pictures can be displayed on the device screen at a time? How many images need to be preloaded, as it is possible to be displayed on the screen soon?
• What is the screen size and resolution of your device? An ultra-high-resolution device, such as a Galaxy nexus, requires more cache space than a lower-resolution device, such as a Nexus S, when holding the same number of images.
• The size and size of the picture, and how much memory space each image occupies.
• How often are the images accessed? Will there be some images that are more frequently accessed than other images? If so, you might want to have some images reside in memory, or use multiple LRUCache objects to distinguish different groups of pictures.
• Can you maintain a good balance between quantity and quality? In some cases, it is more effective to store multiple low-pixel images, while loads in the background to load high-resolution images.

And not a specified cache size can satisfy all applications, which is up to you. You should analyze the usage of the program's memory and then work out a suitable solution. A cache space that is too small can cause images to be released and reloaded frequently, which does not benefit. A cache space that is too large can still cause java.lang.OutOfMemory exceptions.

About LRUCache technology See my next blog, loading images asynchronously:

From for notes (Wiz)

Android Compress pictures to resolve oom errors