Android 查看内存使用情况

转：Android 查看内存使用情况

再看开发过程中，经常要通过内存的使用量来优化程序。

查看应用程序的命令：adb shell procrank

显示如下：

  PID      Vss      Rss      Pss      Uss  cmdline
  190   79560K   74736K   49624K   43604K  system_server
14335   55776K   55740K   31308K   26676K  com.android.launcher2
13074   47408K   47380K   24947K   22428K  com.android.settings
 7626   42060K   42028K   21312K   18432K  com.android.systemui
13948   32992K   32944K   11687K    9800K  android.process.acore
  283   25516K   25476K    8136K    7148K  com.android.phone

注：

VSS - Virtual Set Size 虚拟耗用内存（包含共享库占用的内存）

RSS - Resident Set Size 实际使用物理内存（包含共享库占用的内存）

PSS - Proportional Set Size 实际使用的物理内存（比例分配共享库占用的内存）

USS - Unique Set Size 进程独自占用的物理内存（不包含共享库占用的内存）

查看单个应用程序内存占用量的命令：adb shell dumpsys meminfo $包名 或者 $进程号 //当然你也可以adb shell进去后在输入余下部分。

显示如下：

Applications Memory Usage (kB):
Uptime: 70102403 Realtime: 104776333


** MEMINFO in pid 14335 [com.android.launcher2] **
                    native   dalvik    other    total
            size:    27576     8455      N/A    36031
       allocated:    26850     5311      N/A    32161
            free:      385     3144      N/A     3529
           (Pss):    13830     1134    16034    30998
  (shared dirty):     2980     1932    13776    18688
    (priv dirty):    13736      184    12504    26424
 
 Objects
           Views:        0        ViewRoots:        0
     AppContexts:        0       Activities:        0
          Assets:        3    AssetManagers:        3
   Local Binders:      162    Proxy Binders:       81
Death Recipients:        1
 OpenSSL Sockets:        0
 
 SQL
               heap:     3063         MEMORY_USED:     3063
 PAGECACHE_OVERFLOW:     2266         MALLOC_SIZE:       50
 
 DATABASES
      pgsz     dbsz   Lookaside(b)  Dbname
         1     2544            500  launcher.db

有了这些，调试应用程序的内存问题容易多了

转：点击打开链接

众所周知，在写 android 程序的时候，很容易出现 OOM ，而出现的时机大多数是由 Bitmap decode 引发的：
ERROR/AndroidRuntime(16350): java.lang.OutOfMemoryError: bitmap size exceeds VM budget
我们知道，android程序内存一般限制在16M，当然也有24M的，而android程序内存被分为2部分：native和dalvik，dalvik就是我们平常说的java堆，我们创建的对象是在这里面分配的，而bitmap是直接在native上分配的，对于内存的限制是 native+dalvik 不能超过最大限制。
用以下命令可以查看程序的内存使用情况：
adb shell dumpsys meminfo $package_name or $pid   //使用程序的包名或者进程id
用android自带的launcher程序为例：
run: adb shell dumpsys meminfo com.android.launcher
<BR>results:
Applications Memory Usage (kB):
Uptime: 113017 Realtime: 113017

** MEMINFO in pid 129 [com.android.launcher] **

native   dalvik    other    total

size:     4572     3527      N/A     8099

allocated:     4113     2684      N/A     6797

free:      406      843      N/A     1249

(Pss):     1775     3572     3953     9300

(shared dirty):     1448     4020     4792    10260

(priv dirty):     1652     1308      708     3668

Objects

Views:        0        ViewRoots:        0

AppContexts:        0       Activities:        0

Assets:        5    AssetManagers:        5

Local Binders:       14    Proxy Binders:       21

Death Recipients:        0

OpenSSL Sockets:        0

SQL

heap:       64       memoryUsed:       64

pageCacheOverflo:        4  largestMemAlloc:       50

DATABASES

Pagesize   Dbsize  Lookaside  Dbname

1024        4         48  launcher.db

具体每一项代表什么，参考： http://stackoverflow.com/questions/2298208/how-to-discover-memory-usage-of-my-application-in-android#2299813，我们比较关心的是这2行：
             native   dalvik    other    total
     size:     4572     3527      N/A     8099
allocated:     4113     2684      N/A     6797

其中size是需要的内存，而allocated是分配了的内存，对应的2列分别是native和dalvik，当总数也就是total这一列超过单个程序内存的最大限制时，OOM就很有可能会出现了。

       多数时候，发生OOM 都是在做一些跟图片相关的操作，以下提出一些建议尽量可以减少这种情况的发生：

1.decode bitmap 的时候，尽量配置下Options，例如：inSameSize
2.Bitmap使用完以后，调用 bitmap.recycle()来释放内存
3.如果应用是基于图片的应用，尽量采用LazyLoad和DymanicRecycle
4.decode bitmap 的时候，将decode代码 try catch 出来，catch oom error，避免程序crash，可以在catch里面做一些释放内存操作

推荐阅读：