ddms heap native_ddms heap - CSDN
  • DDMS调试native heap实战

    2016-02-25 14:31:10
    第一步:setprop libc.debug.malloc 1。这里有四种prop可以设置,1是mem leak,5和10是内存越界,20是虚拟机。可悲的是5和10并没有被libc_malloc_debug库完美地支持,所以只有1好用。 第二步,stop, start。...
    第一步:setprop libc.debug.malloc 1。这里有四种prop可以设置,1是mem leak,5和10是内存越界,

    20是虚拟机。可悲的是5和10并没有被libc_malloc_debug库完美地支持,所以只有1好用。


    第二步,stop, start。这些操作都是在device shell里面做的。设备会快速重启。


    第三步,验证prop。getprop看看结果,然后ls一下,去logcat里看一下结果。如果结果都能对的上,那就可以继续了。


    第四步,在ddms.cfg文件最后增加一行native=true并save。ddms.cfg位于c:\Users\xxx\.android目录下。


    第五步,打开单独的ddms(确保eclipse没有在跑),选择Native Heap页面,点击snapshot按钮。

    snapshot的过程有点慢。最后能看到每个so占用了多少内存以及百分比。

    过一段时间snapshot一次就能看到每个so的趋势了。


    第六步,分析。snapshot显示了分配内存的地址(记做addressA),

    这个地址是RAM地址,不是so的相对地址。为了得到相对地址,

    需要ps一下,找到你的pid,然后cat /proc/pid/maps,找到so的起始地址

    (记做addressB)。然后拿addressA - addressB,得到相对地址,用addr2line定位到哪一处调用。

    这里我还用过objdump -dS libXXX.so > XXX.dump,把so反编译出来,分析XXX.dump,

    找到相对地址的调用位置



    跑脚本,启动和关闭联系人
    
     for i in `seq 10000`; do adb shell am start com.android.contacts; sleep 1; adb shell am force-stop com.android.contacts; done
    
    

    第七步:snapshort current native heap usage 对比观察库文件(libhwui.so)

    占用的内存是否增加不减少


    展开全文
  • Android tools中的DDMS就带有一个很不错的内存监测工具Heap(这里我使用eclipse的ADT插件,并以真机为例,在模拟器中的情 况类似)。用Heap监测应用进程使用内存情况的步骤如下:1. 启动eclipse后,切换到DDMS视图,...

    无 论怎么小心,想完全避免bad code是不可能的,此时就需要一些工具来帮助我们检查代码中是否存在会造成内存泄漏的地方。 Android tools中的DDMS就带有一个很不错的内存监测工具Heap(这里我使用eclipse的ADT插件,并以真机为例,在模拟器中的情 况类似)。用Heap监测应用进程使用内存情况的步骤如下:

    1. 启动eclipse后,切换到DDMS视图,并确认Devices视图、Heap视图都是打开的;

    2. 将手机通过USB链接至电脑,链接时需要确认手机是处于“USB调试”模式;

    3. 链接成功后,在DDMS的Devices视图中将会显示手机设备的序列号,以及设备中正在运行的部分进程信息;

    4. 点击选中想要监测的进程,比如system_process进程;

    5. 点击选中Devices视图界面中最上方一排图标中的“Update Heap”图标;

    6. 点击Heap视图中的“Cause GC”按钮;

    7. 此时在Heap视图中就会看到当前选中的进程的内存使用量的详细情况[如图所示 右键查看大图]。

     

    说明:

    a) 点击“Cause GC”按钮相当于向虚拟机请求了一次gc操作;

    b) 当内存使用信息第一次显示以后,无须再不断的点击“Cause GC”,Heap视图界面会定时刷新,在对应用的不断的操作过程中就可以看到内存使用的变化;

    如何才能知道我们的程序是否有内存泄漏的可能性呢。这里需要注意一个值:Heap视图中部有一个Type叫做data object,即数据对 象,也就是我们的程序中大量存在的类类型的对象。在data object一行中有一列是“Total Size”,其值就是当前进程中所有Java数据 对象的内存总量,一般情况下,这个值的大小决定了是否会有内存泄漏。可以这样判断:

    a) 不断的操作当前应用,同时注意观察data object的Total Size值;

    b) 正 常情况下Total Size值都会稳定在一个有限的范围内,也就是说由于程序中的的代码良好,没有造成对象不被垃圾回收的情况,所以说虽然我们 不断的操作会不断的生成很多对象,而在虚拟机不断的进行GC的过程中,这些对象都被回收了,内存占用量会会落到一个稳定的水平;

    c) 反之如果代码中存在没有释放对象引用的情况,则data object的Total Size值在每次GC后不会有明显的回落,随着操作次数的增多Total Size的值会越来越大,
    直到到达一个上限后导致进程被kill掉。

    d) 此处已system_process进程为例,在我的测试环境中system_process进程所占用的内存的data object的Total Size正常情况下会稳定在2.2~2.8之间,而当其值超过3.55后进程就会被kill。

    总之,使用DDMS的Heap视图工具可以很方便的确认我们的程序是否存在内存泄漏的可能性。

     

    如果使用DDMS确实发现了我们的程序中存在内存泄漏,那又如何定位到具体出现问题的代码片段,最终找到问题所在呢?

    如果从头到尾的分析代码逻 辑,那肯定会把人逼疯,特别是在维护别人写的代码的时候。

    这里介绍一个极好的内存分析工具 -- Memory Analyzer Tool(MAT)。

    MAT工具介绍和使用请看前面blog

    展开全文
  • native程序如果发生内存问题,一般都比较难查,幸好DDMS有集成native memory leak(仅仅针对app,无法分析mediaserver等非app的进程)功能,通过DDMS可以观察native堆的使用状况以及每个chunk的调用栈等信息,有助于...

        native程序如果发生内存问题,一般都比较难查,幸好DDMS有集成native memory leak(仅仅针对app,无法分析mediaserver等非app的进程)功能,通过DDMS可以观察native堆的使用状况以及每个chunk的调用栈等信息,有助于分析native memory leak。
    详情可参考:https://source.android.com/devices/tech/debug/native-memory.html

     

    1. 请使用eng版本测试。

    2. 首先要先开启bionic memory debug 1模式(bionic malloc debug信息可以到网络搜索相关资源),然后连上adb。

        方法如下:

          KK及以前版本:

            adb shell setprop persist.libc.debug.malloc 1
            adb shell reboot

          L及以后版本:

      $ adb shell setprop libc.debug.malloc 1
      $ adb shell stop
      $ adb shell start

        确认是否有开启的方法,查看main log,如有看到以下log,就说明开启成功啦

    3. 开启DDMS隐藏的功能 (建议用linux版本的DDMS)

        需要改一个配置. 找到

            linux版本:~/.android/ddms.cfg

            windows版本:C:\Documents and Settings\$user\.android\ddms.cfg

         在ddms.cfg结尾新增一行: native=true 保存后重启ddms

         就可以看到新加的一个'native heap'的tab了

    4. 打开DDMS,选择需要查看native memory的进程:

    选择process

    5. 切换到native heap菜单,填入symbols search path(因为是linux路径,所以windows不能用,这导致第6步的结果没有函数名称信息,只有函数地址!),点击snapshot current native heap usage就可以看到当前native heap的状况
    native heap菜单
    6. 点击保存后,可以导出一个文本文件,打开后,可以看到一个个记录,它们分配大小*分配次数从大到小排列,所以如果有泄露的话,一般看一个记录就够了,拿到调用栈再结合代码分析可能的泄露点
    导出的文本文件
    展开全文
  • enable native heap in ddms

    2015-05-04 17:13:23
    When searching for memory leaks, we often need to examine how a process’ memory usage evolves over time... DDMS provides easy-to-use features to track Java virtual machine heap usage. However, when it c



    When searching for memory leaks, we often need to examine how a process’ memory usage evolves over time. DDMS provides easy-to-use features to track Java virtual machine heap usage. However, when it comes to native heap usage, DDMS make things much harder.  This article provides a step-by-step guide to help you configure native heap tracking in DDMS.

    In order to configure an Android device to track native heap usage, you will need:

    • a Mac, Linux or Windows machine with the Android SDK and ADB installed
    • an Android device with either:
      • an eng or userdebug Android build OR
      • a regular user build that has been rooted and has SuperUser installed.

    Instructions on how to root specific phone models are available elsewhere on the web, and the rooting procedure usually includes the installation of SuperUser.

    All the native memory allocation functions (malloccalloc, etc.) reside in Android’s libc library. To track heap allocations we need special versions of this library, which can log each allocation as it happens, and report back the data when required. Such special versions of libc (called libc_malloc_debug_leak.soand libc_malloc_debug_qemu.so) are included with Android, but only in the eng and userdebug Android builds. If you have either  an eng or userdebug build on your phone, then no additional steps are needed for libc installation and you can jump to the next section.

    If you have a regular user build, you can add the missing libraries as follows:

    1. Download the version of CyanogenMod ROM that most closely matches your phone’s model and minor Android OS version (e.g 2.3, 4.0). If your exact model is not supported, try to find the closes match by processor type (e.g. Tegra2) and minor Android OS version. Once you have the right image, extract the libc_malloc_debug_leak.so and libc_malloc_debug_qemu.so from the system/lib directory.
    2. Copy the libc_malloc_debug_leak.so and libc_malloc_debug_qemu.so files via USB to the root of the SDCARD.
    3. Install BusyBox so you can later use the cp command to copy files.
    4. From your computer”s command prompt, log into the device shell and get a list of mounted devices using the mount command:
      adb shell
      su
      mount
    5. The mount output will list all mounted partitions with the corresponding devices and file system types. Examine the output and make a note of the the device and file system type for your system partition. As an example, the lines below show the system entries for two different Android phones:
      LG G2x:
      ...
      /dev/block/mmcblk0p1 /system ext3 ro,noatime,errors=continue,data=ordered 0 0
      ...
       
      Nexus S:
      ...
      /dev/block/platform/s3c-sdhci.0/by-name/system /system ext4 ro,relatime,barrier=1,data=ordered 0 0
      ...

      The first phone has /dev/block/mmcblk0p1 as the device and ext3 as the file system type. The second phone has /dev/block/platform/s3c-sdhci.0/by-name/system as the device and ext4 as the file system type.

    6. Using the partition device name and file system type you obtained in step 5 above, remount the system partition in read-write mode. The section below shows the remount command for the two phones above:
      LG G2x:
      mount -o remount,rw -t ext3 /dev/block/mmcblk0p1 /system
       
      Nexus S:
      mount -o remount,rw -t ext4 /dev/block/platform/s3c-sdhci.0/by-name/system /system
    7. Copy the two libc files from the SDCARD to the /system/lib directory:
      cp /sdcard/libc_malloc_debug_leak.so /system/lib/libc_malloc_debug_leak.so
      cp /sdcard/libc_malloc_debug_qemu.so /system/lib/libc_malloc_debug_qemu.so
    8. Set the proper permissions:
      chmod 0644 /system/lib/libc_malloc_debug_leak.so
      chmod 0644 /system/lib/libc_malloc_debug_qemu.so
    9. Reboot the phone to reset the system partition to read only.

    Once the device has the new libc files installed, you need to tell the system to use the new libc files for memory allocation.

    1. Set the libc.debug.malloc property to one of the supported values below, depending on your needs. If you are using a device with a rooted user build, then you must perform these commands from the device’s root prompt (use su to get root privileges, as shown below).
      adb shell
      su
      setprop libc.debug.malloc 1

      Supported property values:

      1  - perform leak detection
      5  - fill allocated memory to detect overruns
      10 - fill memory and add sentinels to detect overruns
      20 - use special instrumented malloc/free routines for the emulator
    2. Restart the application framework from the same root prompt. For this to work you must use a prompt with root privileges.
      stop
      start

      If the commands are successful, your device will seem to reboot 1-2 seconds after the commands were issued. However, it’s not a full reboot, and you will notice that the root prompt you opened earlier remains connected.

    3. From the same prompt used earlier, check that the property was successfully set:
      getprop

      The command above will display a list of custom properties, which should contain a line like the following:

      ...
      [libc.debug.malloc]: [1]
      ...
    4. As an additional check, issue the ls command from the device prompt. If the setup was successful, then you should see something like the following line in the device log:
      05-10 20:34:01.494: I/libc(6978): ls using MALLOC_DEBUG = 1 (leak checker)

    By default, DDMS does not display the native heap tab. To enable that tab, we must modify the DDMS configuration.

    1. Open the ddms.cfg file located at ~/.android/ddms.cfg.
    2. At the bottom of the file, add the following line:
      ...
      native=true
    3. Save and close the configuration file.
    4. Open the stand alone DDMS tool from the Android SDK tools folder. Make sure that no Eclipse instance is open, since only one instance of DDMS can operate at a time.
    5. Select one of the processes from the list of running processes, and in right hand side panel open the Native Heap tab. Press the Snapshot Current Native Heap Usage button and you should see a list of allocations similar to the one shown in the graphic at the top of this article.

    The native tab is not populated with data.

    Couple of things to check:

    • Use adb shell followed by ls /system/lib/libc* to confirm that  libc_malloc_debug_leak.so and libc_malloc_debug_qemu.so are present on the device.
    • Perform a computer restart. Also shut down the Android device and remove the battery for 20 seconds before restarting. Once that is complete, redo all the steps in the Property Configuration section. Double check that you are using the root command prompt  (adb shell followed by su) to issue all the shell commands, and that you are typing the commands correctly.
    • Make sure that after issuing the stop and start commands the device successfully resets the application framework (it should look like a reboot but without losing the adb connection).

    When I issue the start command the adb connection breaks.

    You are probably using the wrong versions of the libc files. Make sure that the libc files are compatible with your device’s processor and Android version. If you are using CyanogenMod to get the libc files, try to get them from the same phone model (or one with a similar processor) with the same Android OS level (2.3, 4.0, etc.)

    The log shows the following error: “/system/bin/sh: Missing module /system/lib/libc_malloc_debug_leak.so required for malloc debug level 1″

    You are missing the libc libraries required for debug. Please follow the steps in the Libc Installation section to correct the problem.

    展开全文
  • native  内存分配函数 ( malloc ,  calloc , etc.)  都在 Android 的 libc 库中。为了跟踪堆内存的分配,需要使用这个库的特别版本,可以将每次内存开销记录下来。 这些特殊版本...
  • [FAQ05872]如何用DDMS分析native memory leak 2016-08-10 平台MT6572MT6589MT6582MT6588... 软件分支JB2GB3JB3JB5... 内容 [DESCRIPTION] native程序如果发生内存问题,一般都...
  • 检查手机上目录system/lib(system/lib64)下存在libc_malloc_debug_leak.so、libc_malloc_debug_qemu.so(eng或者user-debug版本自带) setprop libc.debug.malloc 1(android7.0以后设置新属性 :setprop libc....
  • Native Heap分析和优化

    2015-05-04 16:54:00
    最后一部分是关于native heap,.dex,/dev/other的优化。 Native Heap分析和优化 android的DDMS可以帮助查看c++ native heap的使用,但需要一定的配置,而且必须是root的手机。 在~/.android/ddms.cfg增加...
  • Heap监测应用进程使用内存情况的步骤如下:  1. 启动eclipse后,切换到DDMS透视图,并确认Devices视图、Heap视图都是打开的;  2. 将手机通过USB链接至电脑,链接时需要确认手机是处于“USB调试”模式,而...
  • 一、先说DDMS中的Heap的使用,通过可以观察VM中的Java内存,但是无法查看通过JNI分配的内存。 直接上图,废话少说。。。 图一:将要查看内存使用情况的项目Update heap 图二:操作项目,通过...
  •  所有的 native 内存分配函数 ( malloc , calloc , etc.) 都在 Android 的 libc 库中。为了跟踪堆内存的分配,需要使用这个库的特别版本,可以将每次内存开销记录下来。 这些特殊版本的 libc ( ...
  • 概述:我们可以同DDMS中的heap可以观察VM中的Java内存,但是无法查看通过JNI分配的内存。 一、用 Heap监测应用进程使用内存情况的步骤如下: 1. 启动eclipse后,切换到DDMS透视图,并确认Devices视图、Heap视图都...
  • $ adb shell setprop libc.debug.malloc 1  $ adb shell stop  $ adb shell start Open C:\Users\ian\.android\ddms.cfg Add a line "native=true" ...打开DDMS,点Native Heap标签,就可以Snapshot了
  • 前言 一个好的app除了极具渲染力的ui设计外,app的性能也是是否能够增加用户粘性中一个...Heap Viewer的作用是什么?(1).动态实时查看我们的App分配的内存大小 (2).经过分析视图可以发现Memory LeaksHeap Viewer使用条
  • DDMS中的Heap的使用

    2014-05-08 19:16:00
    一、先说DDMS中的Heap的使用,通过可以观察VM中的Java内存,但是无法查看通过JNI分配的内存。   直接上图,废话少说。。。 图一:将要查看内存使用情况的项目Update heap 图二:操作项目,通过图表可以很...
  • Android开发——使用DDMS分析Native层内存泄漏针对Java层的内存泄漏,Android提供了方便的内存泄漏检测工具,例如MAT、LeakCanary。但对于native层开发,要追查C/C++代码的内存泄漏,valgrind等常用工具并不适用。...
  • 获取Java堆内存详细信息,可以分析出内存泄漏的问题Heap Dump启动在内存面包中,点击图中红色标注的按钮,就会显示我们的Heap Snapshot面包Heap Snapshot面板Heap Snapshot详细信息面板 该面板里的信息可以有三种...
1 2 3 4 5 ... 20
收藏数 1,248
精华内容 499
关键字:

ddms heap native