Android adb shell View App memory (java heap memory/vss virtual memory/detailed memory status/memory snapshot hprof) and system available memory

1.adb shell gets the pid of the app process

adb shell "ps|grep com.xxx包名"

According to a channel package, to query the corresponding pid, as follows:
insert image description here

2. View the maximum value of the java dalvik heap memory of the device through the adb shell

Execute the command line:

adb shell  getprop dalvik.vm.heapgrowthlimit

insert image description here
If the java heap (dalvik heap size) heap memory exceeds 384m in the app process, oom will be thrown.

If largeHeap="true" is set in the app manifest.xml, the app process dalvik heap limit corresponds to the 512m limit.

insert image description here

3. View the physical rss and virtual memory vss of the app process :

adb shell procrank (requires phone root authority), this command can be ignored.

Consider using the Top command-line format:

adb shell top -n 1 |findstr "packageInfo"

Take the 4399 channel package as an example, execute adb shell top -n 1 |findstr "\<com.minitech.mixxxxx.m4399\> \<PID\>" :
insert image description here
or query process status through adb shell:

Execution command format:

adb shell  cat /proc/app的pid/status

insert image description here
Points to note: Under 32-bit (non-arm64-bit), the peak virtual memory in the app process is more than 3G, and it is easier to trigger the oom situation.

4. View the memory status in the app process through the adb shell command line:

Format:

adb shell dumpsys meminfo [pkg/pid]

It can be used to view the memory usage of the specified process package name .
Execute adb shell dumpsys meminfo com.minitech.xxxx.m4399, you can clearly know java heap, native heap, database, asset, etc. The memory value is in KB.

C:\Users\hexingen>adb shell dumpsys meminfo com.minitech.xxx.m4399
Applications Memory Usage (in Kilobytes):
Uptime: 4282829 Realtime: 4282829

** MEMINFO in pid 14622 [com.minitech.miniworld.m4399] **
                   Pss  Private  Private  SwapPss     Heap     Heap     Heap
                 Total    Dirty    Clean    Dirty     Size    Alloc     Free
                ------   ------   ------   ------   ------   ------   ------
  Native Heap   455496   455468        8        0   596992   484213   112777
  Dalvik Heap    26347    26328        0        0    45768    29384    16384
 Dalvik Other     6178     6176        0        0
        Stack     3844     3844        0        0
       Ashmem     5561     5092        0        0
    Other dev       28        0       28        0
     .so mmap    62819     5104    55760       36
    .jar mmap        4        0        4        0
    .apk mmap    49281     9980    38240        0
    .ttf mmap     1031        0      768        0
    .dex mmap    24272       16    24228        0
    .oat mmap     8604        0     3968        0
    .art mmap     3794     2224      588        2
   Other mmap     6361       20     6076        0
    GL mtrack   152964   152964        0        0
      Unknown    79528    79528        0        1
        TOTAL   886151   746744   129668       39   642760   513597   129161

 App Summary
                       Pss(KB)
                        ------
           Java Heap:    29140 //java 堆所占用的物理内存
         Native Heap:   455468 //native 堆所占用的物理内存
                Code:   138068
               Stack:     3844
            Graphics:   152964
       Private Other:    96928
              System:     9739
               //app进程中占有物理内存(等于uss+按比列的共享库物理内存)
               TOTAL:   886151       TOTAL SWAP PSS:       39

 Objects // 进程中关键对象情况 ,activity \binder 个数,可看内存泄漏
               Views:      166         ViewRootImpl:        2
         AppContexts:        5           Activities:        4
              Assets:        7        AssetManagers:        4
       Local Binders:       71        Proxy Binders:       40
       Parcel memory:       40         Parcel count:      155
    Death Recipients:        2      OpenSSL Sockets:        8

 SQL
         MEMORY_USED:     1092
  PAGECACHE_OVERFLOW:      342          MALLOC_SIZE:       79

 DATABASES //进程中数据库db 打开情况
      pgsz     dbsz   Lookaside(b)          cache  Dbname
         4       40            480      222/96/23  /data/user/0/com.minitech.miniworld.m4399/databases/pangle_com.byted.pangle_bd_embed_tea_agent.db
         4       24             31         2/20/3  /data/user/0/com.minitech.miniworld.m4399/databases/tracker.db
         4       52             91       21/29/12  /data/user/0/com.minitech.miniworld.m4399/databases/bugly_db_
         4       92            200     478/108/25  /data/user/0/com.minitech.miniworld.m4399/databases/pangle_com.byted.pangle_ttopensdk.db
         4       24             98         1/37/4  /data/user/0/com.minitech.miniworld.m4399/databases/pangle_com.byted.pangle_downloader.db
         4       20             17         0/30/3  /data/user/0/com.minitech.miniworld.m4399/databases/pangle_com.byted.pangle_npth_log.db
         4       16             41        13/21/6  /data/user/0/com.minitech.miniworld.m4399/files/MobSDK/comm/dbs/.dh

 Asset Allocations  //进程中asset 打开情况
    : 1K
    zip:/data/user/0/com.minitech.miniworld.m4399/files/pangle_p/com.byted.pangle/version-4908/apk/base-1.apk:/resources.arsc: 98K

In general, only the Pss Total and Private Dirty columns are of interest. In some cases, the data provided by the Private Clean and Heap Alloc columns are also of interest.

Next, analyze the above data in detail:

Check the java heap memory usage :
insert image description here
If the dalvik heap size exceeds the jvm threshold (usually 384M or 512M), the java heap will be triggered to cause oom.

Check the pss physical memory usage in the process :

  • Pss total: physical memory occupied
  • Private Dirty: After the app process dies, the arm physical memory that the system can reclaim
  • Private clean: The arm physical memory that has been reclaimed by the system in the current app process.
    insert image description here
    If the pss physical memory in the app process is getting larger and larger, the available physical memory of the arm processor in the system will become less and less until the available physical memory is not enough to allocate. will trigger oom.

Check for memory leaks :

1. AppContexts, Activities and ViewRootImpl represent the number of contexts and activities in the current process, the root view (ie phonewindow) data, combined with the business to check whether the number exceeds the current number, if it exceeds, a memory leak occurs, and is static Or held indirectly by the singleton class.
Objects that are strongly referenced in java se cannot be recycled .

More adb shell dumpsys meminfo detailed explanation: https://blog.51cto.com/u_4387387/6077172.

In addition: /proc/pid/maps 和/proc/pid/smaps Execution through adb shell requires permission, which is temporarily unavailable.
insert image description here

5. Check the current memory status of the mobile phone system:

Execute adb shell cat /proc/meminfo , you can view the mobile phone processor memory, the currently available memory
insert image description here
When MemAvailable, the available memory size is getting smaller and smaller, until it is exhausted, oom will be triggered.

6.adb shell gets memory snapshot hrop:

Execute the command line:

adb shell am dumpheap package包名 /data/local/tmp/xxx.hprof

insert image description here
Execute the command line and wait for the execution to complete. Through the file browser or the file management of the studio, find the file, double-click to open it, and you can view the detailed memory snapshot.
insert image description here

Guess you like

Origin blog.csdn.net/hexingen/article/details/131934734