Android image loading and OOM Problems

Android image loading and OOM Problems

 

 

First, it took a week to solve the problem. I tried very hard to find out where the OOM memory overflow problem exists, but no result was found, I always thought that I was using Picaso to load the image framework and only loaded the image. However, when the activity was destroyed, the memory was not released, so I tried to solve the problem myself:

 

1. Change the image frame: Xutil Image Frame

The result is not to change the dressing. OOM and memory overflow still occur.

 

2. Image Processing independently: Online scaling and memory processing for the generated BitMap object are required for the larger image.

 

Private void initDisplayImageOption () {options = new DisplayImageOptions. builder (). showImageOnLoading (R. drawable. video_default) // sets the image displayed during the download process. showImageForEmptyUri (R. drawable. image_background_empty) // sets the image to be displayed when the image Uri is null or incorrect //. showImageOnFail (R. drawable. image_background_erro) // sets the image displayed when an error occurs during image loading/decoding. cacheInMemory (false) // sets whether the downloaded image is cached in memory. cacheOnDisk (true) // sets whether the downloaded image is cached in the SD card. considerExifParams (True) // whether to consider the JPEG image EXIF parameter (rotation, flip ). imageScaleType (ImageScaleType. EXACTLY_STRETCHED) // sets how the image is encoded. bitmapConfig (Bitmap. config. RGB_565) // sets the image decoding type ////. decodingOptions (android. graphics. bitmapFactory. options decodingOptions) // sets the image decoding configuration. delayBeforeLoading (0) // int delayInMillis sets the pre-download delay time for you. resetViewBeforeLoading (true) // sets whether the image is reset and reset before being downloaded. displayer (new FadeInBitmapDisplayer (100) // specifies the animation time after the image is loaded.. Build (); // build complete} @ Override protected void onDestroy () {mam. popOneActivity (HostessDetailUI. this); Log. e ("onDestroy () isRun !!! "); MHostessImgs. setAdapter (null);/** release image, control image reference resource */BitmapDrawable bitmapDrawable = (BitmapDrawable) mHostessMiddle. getBackground (); mHostessMiddle. setBackgroundResource (0); bitmapDrawable. setCallback (null); drawable. setCallback (null); Bitmap bitmap = bitmapDrawable. getBitmap (); if (bitmap! = Null &&! Bitmap. isRecycled () {bitmap. recycle (); // reclaim the memory occupied by the image bitmap = null;} btp. recycle (); // reclaim the memory occupied by the image System. gc (); super. onDestroy ();}

As a result, the oom problem is still reported, and the GC operation is not seen in the log, and the memory is directly flushed from 16 MB to 96 MB,

 

 

3. For a powerful image frame: Universal-Image_loader (UIL)

I saw that UIL is currently the most popular image framework with the largest number of users and the most complete personal configuration. As a result, I switched my picaso to UIL, but it still reported the OOM problem, every time I read the log, I ran to 96 MB to crash.

I suspect that I do not have a deep understanding of UIL, the configuration is incomplete, or the memory is not released. (Take A Look At The UIL source code implementation with time)

 

4. Change to the latest image processing framework: the fresco framework recommended by Facebook

 

dependencies {            compile 'com.facebook.fresco:fresco:0.5.0+'        }

I thought it was very complicated because I had very few explanations in this regard. So I went to the official website to introduce the use of the document on the AS and added some simple operations to my project, there is no such thing as someone else's saying that you need to configure NDK and compile it. Then run it !! The memory heap does not reach 96 mb oom as before. The latest stuff will be better.

 

 

5. Remove the large image from the background to display the complete image.

The program will not crash, and I feel a lot of comfort. After all, the problem has been around for a week. However, some images cannot be loaded for a long time. The fresco framework is so good, why can't you load images. After reading the log, the following message is displayed: The image is too large to be downloaded, so the image size pulled from the background is displayed. Nana ., 7 MB for one image !! There is no way to use the perfect framework for such images, so let the background process the image specifications.

 

Final Solution: change to fresco framework + background image shrinking. Now the program will not have an OOM problem. So happy! (However, the memory is not ready yet, so it needs to be improved !)