Memory usage and optimization of Android resource Images

Two optimization methods: 1. Large background image: 9.pngand 9png can not only save the APK package capacity, but also effectively save the stack memory. 2 Tips 1: use multi-resolution image design [hdpi, mdpi, ldpi, xhdpi]. UI pictures are designed with multiple specifications, such as hdpi, mdpi, ldpi, and xhdpi, which is also officially recommended. The advantage of this method is that it can reduce the peak memory and avoid memory overflow first. In android, image loading scales automatically according to the resolution. [The scaling process consumes extra memory.] Check the android image's Internal loading method [BitmapFactory. java] A inefficient in Android: private static Bitmap finishDecode (Bitmap bm, Rect outPadding, Options opts ){//.... float scale = targetDensity/(float) density; // TODO: This is very inefficient and shocould be done in native by Skia final Bitmap oldBitmap = bm; bm = Bitmap. createScaledBitmap (oldBitmap, (int) (bm. getWidth () * scale + 0.5f), (int) (bm. getHeight () * scale + 0.5f), true); oldBitmap. recycle ();//...} 3 Tips 2: placing image resources in assets or no-dpi can also avoid high peak memory caused by scaling. If your program often loads an image, but if you want to continue using it, you can also directly use: try {// load big memory data} catch (java. lang. outOfMemoryError e) {// TODO alternative solution} test: 1 place image A in no-dpi, the memory is loaded only once, and no scaling is performed. 2 only in drawable-hdpi: put A-PNG Image, 2.1 when the test machine is avd2.3.3-320-480-mdpi 2.1.1, the original image A is first loaded into the memory [480-800] 2.1.2 and then A reduced image B is created based on the original image A [480-800 ]. dual-copy memory] -- causes memory overflow 2.1.3 Releases Original Image A. If you place another-PNG Image A in drawable-mdpi, only one creation will be executed: image A to memory 2.2 When the test machine for the AVD2.3.3-1024-600-mdpi 2.2.1 will first load the original image A to the memory [480-800] 2.2.2 In the original image A [480-800] on the basis of creating A reduced image B [occupies dual-copy memory at this time] -- causes memory overflow 2.2.3 release the original image A. If you place A-PNG Image A in drawable-mdpi, only one creation will be performed: Image A to the memory test conclusion: 1. Will the image be scaled twice when it is created? It is only related to the screen density [not related to the screen size] 2. The image finally adapts to the screen size, bitmapDrawable will be used in BitmapDrawable to package Bitmap [internal scaling will be performed] if (mApplyGravity) {Gravity. apply (state. mGravity, mBitmapWidth, mBitmapHeight, getBounds (), mDstRect); mApplyGravity = false;} canvas. drawBitmap (bitmap, null, mDstRect, state. mPaint); 2.3 when the test machine for the AVD2.3.3-320-480-hdpi: Picture loaded only once conclusion: for large images in the mdpi/xhdpi/ldpi placement similar to the image hdpi figure --> mdpi needs: create one, and then scale down [more memory is needed during the intermediate process] hdpi Diagram --> In xhdpi, create one, zoom in again [the intermediate process requires more memory] two ways to save the peak memory: www.2cto.com 1 for large-size charts: Design hdpi, mdpi, xhdpi resource Diagram 2 puts the large size chart into: no-dpi, this will only create one umeng background-an exception in the memory burst when the scaled image is created [2nd memory killer] java. lang. outOfMemoryError: bitmap size exceeds VM budget at android. graphics. bitmap. nativeCreate (Native Method) at android. graphics. bitmap. createBitmap (Bitmap. java: 477) at android. graphics. bitmap. createBitmap (Bitmap. java: 444) at android. graphics. bitmap. createScaledBitmap (Bitmap. java: 349) at android. graphics. bitmapFactory. finishDecode (BitmapFactory. java: 498) at android. graphics. bitmapFactory. decodeStream (BitmapFactory. java: 473) at android. graphics. bitmapFactory. decodeResourceStream (BitmapFactory. java: 336) at android. graphics. drawable. drawable. createFromResourceStream (Drawable. java: 697) at android. content. res. resources. loadDrawable (Resources. java: 1709) at android. content. res. resources. getDrawable (Resources. java: 581) at android. view. view. setBackgroundResource (View. java: 7533)