请注意，像 Linux 这样的现代操作系统上的内存使用是一个非常复杂且难以理解的领域。事实上，你实际正确地解释你得到的任何数字的可能性非常低。 （几乎每次我与其他工程师一起查看内存使用数量时，总会有很长时间讨论它们实际上意味着什么只会导致模糊的结论。）
注意：我们现在有更多关于管理您的应用程序内存的文档，其中涵盖了大部分内容，并且更新了 Android 的最新状态。
首先要阅读本文的最后一部分，其中讨论了如何在 Android 上管理内存：
现在， ActivityManager.getMemoryInfo()是我们用于查看总体内存使用情况的最高级 API。这主要是为了帮助应用程序测量系统与后台进程没有更多内存的接近程度，因此需要开始杀死所需的进程，如服务。对于纯 Java 应用程序，这应该没用，因为 Java 堆限制部分是为了避免一个应用程序能够强调系统到此为止。
在较低级别，您可以使用 Debug API 获取有关内存使用情况的原始内核级信息： android.os.Debug.MemoryInfo
注意从 2.0 开始，还有一个 API， ActivityManager.getProcessMemoryInfo ，用于获取有关另一个进程的信息： ActivityManager.getProcessMemoryInfo（int []）
这将返回包含所有这些数据的低级 MemoryInfo 结构：
/** The proportional set size for dalvik. */
public int dalvikPss;
/** The private dirty pages used by dalvik. */
public int dalvikPrivateDirty;
/** The shared dirty pages used by dalvik. */
public int dalvikSharedDirty;
/** The proportional set size for the native heap. */
public int nativePss;
/** The private dirty pages used by the native heap. */
public int nativePrivateDirty;
/** The shared dirty pages used by the native heap. */
public int nativeSharedDirty;
/** The proportional set size for everything else. */
public int otherPss;
/** The private dirty pages used by everything else. */
public int otherPrivateDirty;
/** The shared dirty pages used by everything else. */
public int otherSharedDirty;但至于Pss ， PrivateDirty和SharedDirty之间的区别是什么...... 现在好玩的开始了。
Android（以及一般的 Linux 系统）中的大量内存实际上是在多个进程之间共享的。那么进程使用多少内存实际上并不清楚。将该页面分页添加到磁盘（更不用说我们在 Android 上不使用的交换），它甚至不太清楚。
因此，如果您将实际映射到的每个物理 RAM 都放到每个进程中，并将所有进程相加，那么最终可能会得到比实际总 RAM 大得多的数字。
Pss编号是内核计算的一个度量，它考虑了内存共享 - 基本上每个进程中的 RAM 页面都按照使用该页面的其他进程数量的比例进行缩放。通过这种方式，您可以（理论上）将 pss 添加到所有进程中以查看它们正在使用的总 RAM，并比较进程之间的 pss 以大致了解它们的相对权重。
另一个有趣的指标是PrivateDirty ，它基本上是进程内部无法分页到磁盘的 RAM 数量（它不受磁盘上相同数据的支持），并且不与任何其他进程共享。另一种看待这种情况的方法是当该进程消失时系统可用的 RAM（并且可能很快被包含在缓存和其它用途中）。
这就是 SDK API。但是，作为开发人员，您可以使用设备做更多事情。
使用adb ，您可以获得有关正在运行的系统的内存使用的大量信息。常见的一个是命令adb shell dumpsys meminfo ，它会发出一堆关于每个 Java 进程的内存使用情况的信息，包含上述信息以及其他各种信息。您还可以查看单个进程的名称或 pid，例如adb shell dumpsys meminfo system给我系统进程：
** MEMINFO in pid 890 [system] **
native dalvik other total
size: 10940 7047 N/A 17987
allocated: 8943 5516 N/A 14459
free: 336 1531 N/A 1867
(Pss): 4585 9282 11916 25783
(shared dirty): 2184 3596 916 6696
(priv dirty): 4504 5956 7456 17916
Objects
Views: 149 ViewRoots: 4
AppContexts: 13 Activities: 0
Assets: 4 AssetManagers: 4
Local Binders: 141 Proxy Binders: 158
Death Recipients: 49
OpenSSL Sockets: 0
SQL
heap: 205 dbFiles: 0
numPagers: 0 inactivePageKB: 0
activePageKB: 0顶部是主要部分，其中size是特定堆的地址空间中的总大小， allocated是堆认为它具有的实际分配的 kb， free是堆具有的额外分配的剩余 kb，以及pss和priv dirty ，与之前讨论的相同，特定于与每个堆相关联的页面。
如果您只想查看所有进程的内存使用情况，可以使用命令adb shell procrank 。在同一系统上输出的内容如下：
PID Vss Rss Pss Uss cmdline 890 84456K 48668K 25850K 21284K system_server 1231 50748K 39088K 17587K 13792K com.android.launcher2 947 34488K 28528K 10834K 9308K com.android.wallpaper 987 26964K 26956K 8751K 7308K com.google.process.gapps 954 24300K 24296K 6249K 4824K com.android.phone 948 23020K 23016K 5864K 4748K com.android.inputmethod.latin 888 25728K 25724K 5774K 3668K zygote 977 24100K 24096K 5667K 4340K android.process.acore ... 59 336K 332K 99K 92K /system/bin/installd 60 396K 392K 93K 84K /system/bin/keystore 51 280K 276K 74K 68K /system/bin/servicemanager 54 256K 252K 69K 64K /system/bin/debuggerd
这里的Vss和Rss列基本上都是噪声（这些是进程的直接地址空间和 RAM 使用情况，如果你在各个进程中加入 RAM 使用量就会得到一个非常大的数字）。
Pss就像我们以前见过的那样， Uss是Priv Dirty 。
有趣的是这里需要注意的是： Pss和Uss与我们在meminfo看到的略有不同（或稍微不同）。这是为什么？好的 procrank 使用不同的内核机制来收集它的数据，而不是meminfo ，它们给出的结果略有不同。这是为什么？老实说，我没有任何线索。我相信procrank可能是更准确的...... 但实际上，这只是留下了一点：“记下你得到的任何记忆信息，通常是一粒非常大的颗粒。”
最后是命令adb shell cat /proc/meminfo ，它给出了系统总体内存使用情况的摘要。这里有很多数据，只有前几个数字值得讨论（其余的数据很少被人理解，而我对这些人的问题经常会导致相互矛盾的解释）：
MemTotal: 395144 kB MemFree: 184936 kB Buffers: 880 kB Cached: 84104 kB SwapCached: 0 kB
MemTotal是内核和用户空间可用的内存总量（通常小于设备的实际物理 RAM，因为无线电，DMA 缓冲区等需要一些 RAM）。
MemFree是根本没有使用的 RAM 量。你在这里看到的数字非常高; 通常在 Android 系统上，这只有几 MB，因为我们尝试使用可用内存来保持进程运行
Cached是用于文件系统缓存和其他此类事物的 RAM。为此，典型系统需要大约 20MB 才能避免陷入错误的寻呼状态; 针对特定系统调整 Android 内存不足以确保后台进程在高速缓存的 RAM 被其消耗过多而导致此类分页之前被杀死。
是的，您可以通过编程方式获取内存信息，并决定是否进行内存密集型工作。
通过调用获取 VM 堆大小：
Runtime.getRuntime().totalMemory();通过调用以获取分配的 VM 内存：
Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory();通过调用以获取 VM 堆大小限制：
Runtime.getRuntime().maxMemory()通过调用获取本机分配的内存：
Debug.getNativeHeapAllocatedSize();我做了一个应用程序来弄清楚 OutOfMemoryError 行为并监视内存使用情况。
https://play.google.com/store/apps/details?id=net.coocood.oomresearch
这是一项正在进行的工作，但这是我不明白的：
ActivityManager activityManager = (ActivityManager) context.getSystemService(ACTIVITY_SERVICE);
MemoryInfo memoryInfo = new ActivityManager.MemoryInfo();
activityManager.getMemoryInfo(memoryInfo);
Log.i(TAG, " memoryInfo.availMem " + memoryInfo.availMem + "\n" );
Log.i(TAG, " memoryInfo.lowMemory " + memoryInfo.lowMemory + "\n" );
Log.i(TAG, " memoryInfo.threshold " + memoryInfo.threshold + "\n" );
List<RunningAppProcessInfo> runningAppProcesses = activityManager.getRunningAppProcesses();
Map<Integer, String> pidMap = new TreeMap<Integer, String>();
for (RunningAppProcessInfo runningAppProcessInfo : runningAppProcesses)
{
pidMap.put(runningAppProcessInfo.pid, runningAppProcessInfo.processName);
}
Collection<Integer> keys = pidMap.keySet();
for(int key : keys)
{
int pids[] = new int[1];
pids[0] = key;
android.os.Debug.MemoryInfo[] memoryInfoArray = activityManager.getProcessMemoryInfo(pids);
for(android.os.Debug.MemoryInfo pidMemoryInfo: memoryInfoArray)
{
Log.i(TAG, String.format("** MEMINFO in pid %d [%s] **\n",pids[0],pidMap.get(pids[0])));
Log.i(TAG, " pidMemoryInfo.getTotalPrivateDirty(): " + pidMemoryInfo.getTotalPrivateDirty() + "\n");
Log.i(TAG, " pidMemoryInfo.getTotalPss(): " + pidMemoryInfo.getTotalPss() + "\n");
Log.i(TAG, " pidMemoryInfo.getTotalSharedDirty(): " + pidMemoryInfo.getTotalSharedDirty() + "\n");
}
}为什么 PID 不映射到 activityManager.getProcessMemoryInfo（）中的结果？显然，您希望使得结果数据有意义，那么为什么 Google 难以将结果关联起来呢？如果我想处理整个内存使用情况，那么当前系统甚至不能正常工作，因为返回的结果是 android.os.Debug.MemoryInfo 对象的数组，但这些对象实际上都没有告诉你它们与哪些 pids 相关联。如果您只是传入一个包含所有 pid 的数组，您将无法理解结果。据我了解它的使用，它一次传递多个 pid 是没有意义的，然后如果是这样的话，为什么要使 activityManager.getProcessMemoryInfo（）只接受一个 int 数组？