Memory management in Android development has always been a headache. The most memory occupied is generally bitmap. In the MIUI development version released in Friday, I added the ability to view bitmap information in memory. When you develop apps, you can use this feature to view bitmap in your Analytics app. How to use:
adb shell Dumpsys gfxinfo [package name] [-b] [-e]ADB shell Dumpsys Gfxinfo is the original feature of Android. I have added some parameters above this to output the bitmap information.
- bOutputs the bitmap information for all memory in the process that is greater than the threshold (default 100k), format: [hash value] [memory size] [width]x[high] [if preload is displayed as preload] [picture resource/file name, may be empty] for example,
adb shell Dumpsys gfxinfo com.android.systemui-b：All big bitmaps (debug.bitmap_threshold_size = k):0x42da9af8 2,477k 1566x405 res/drawable-xxhdpi/overscroll_glow.png ...Total count:16, size:25m
- eThe bitmap will be saved in the phone. For example
adb shell Dumpsys gfxinfo com.android.systemui-e：[Other ibid., but one more line]:Export bitmaps finished. Path:/data/data/com.android.systemui/cache/_exportbitmap/com.android.systemuiBecause saving bitmap is time consuming, you may get an error:Failure While dumping the app:processrecord{4334ef80 1271:com.android.systemui/1000}It doesn't matter, wait in the Logcat:D/dumpbitmapinfo (1271): Export bitmaps finished. Path:/data/data/com.android.systemui/cache/_exportbitmap/com.android.systemuiThat means it's done. The ADB pull/data/data/com.android.systemui/cache/_exportbitmap/com.android.systemui can then be used to access the computer. The Advanced parameter--NOGC specifies that the GC is not called before dump (that is, the GC is triggered by default before dump). The Advanced parameter--includepreload specifies the picture that contains the preload (that is, the preload picture is not output by default). Advanced parameter--recycle:[bitmap Hashcode] through this can recycle the specified bitmap, to verify whether a bitmap will be used. You can change the threshold by changing the prop:debug.bitmap_threshold_size, by default 100, unit K, only if it is greater than or equal to it. It will take effect to kill the process restart app after the change. For example: adb shell SetProp debug.bitmap_threshold_size 10 We can often use this method to see if the bitmap in memory is in line with expectations, and when we find bitmap that we think should not exist, We need to change the program not to let it load or let it release early. Sometimes we don't know where this bitmap is used, so we can combine the mat (Eclipse Memory analysis Tools) to find out its source of reference.
In addition, when the outofmemoryerror appears or we think there is a memory leak, we can also use this method to analyze if the compromised object has bitmap. Step: 1. ADB shell Dumpsys Gfxinfo [package name]-B. Find out the leaked pictures and write down their hashcode. (This method is currently not available on a 64-bit system phone, and its hashcode and mat do not correspond to the logo) 2. DDMS dump HPROF file. Open the mat view of histogram > Find bitmap > List Object, with outgoing references > find the corresponding hashcode > Merge bitmap via the above Shorte St Paths to GC Roots, exclude all .... This will find the root that holds the bitmap.(Tip, find a way to specify the item in the list: Right-click on the "Total ..." button on the bottom line and select Expand All to enter what you are looking for on the keyboard, such as: "Graphics. Bitmap, and then press ESC, the Bitmap key is selected. )
MIUI adding memory Debugging Tools: Viewing bitmap information in a process
