Java 如何在 Android 中发现我的应用程序的内存使用情况？

Question

提问by Andrea Baccega

How can I find the memory used on my Android application, programmatically?

如何以编程方式找到我的 Android 应用程序使用的内存？

I hope there is a way to do it. Plus, how do I get the free memory of the phone too?

我希望有办法做到这一点。另外，我如何获得手机的可用内存？

Answer 1

采纳答案by hackbod

Note that memory usage on modern operating systems like Linux is an extremelycomplicated and difficult to understand area. In fact the chances of you actually correctly interpreting whatever numbers you get is extremely low. (Pretty much every time I look at memory usage numbers with other engineers, there is always a long discussion about what they actually mean that only results in a vague conclusion.)

请注意，Linux 等现代操作系统上的内存使用是一个极其复杂且难以理解的领域。事实上，你真正正确地解释你得到的任何数字的机会是极低的。（几乎每次我与其他工程师一起查看内存使用量数据时，总会对它们的实际含义进行长时间的讨论，结果只能得出一个模糊的结论。）

Note: we now have much more extensive documentation on Managing Your App's Memorythat covers much of the material here and is more up-to-date with the state of Android.

注意：我们现在有更广泛的关于管理应用程序内存的文档，其中涵盖了此处的大部分材料，并且与 Android 的状态保持同步。

First thing is to probably read the last part of this article which has some discussion of how memory is managed on Android:

第一件事可能是阅读本文的最后一部分，其中讨论了如何在 Android 上管理内存：

Service API changes starting with Android 2.0

从 Android 2.0 开始的服务 API 更改

Now ActivityManager.getMemoryInfo()is our highest-level API for looking at overall memory usage. This is mostly there to help an application gauge how close the system is coming to having no more memory for background processes, thus needing to start killing needed processes like services. For pure Java applications, this should be of little use, since the Java heap limit is there in part to avoid one app from being able to stress the system to this point.

现在ActivityManager.getMemoryInfo()是我们用于查看整体内存使用情况的最高级别 API。这主要是为了帮助应用程序衡量系统接近没有更多内存用于后台进程的程度，因此需要开始杀死所需的进程，例如服务。对于纯 Java 应用程序，这应该没什么用，因为 Java 堆限制在一定程度上是为了避免一个应用程序对系统造成压力到这一点。

Going lower-level, you can use the Debug API to get raw kernel-level information about memory usage: android.os.Debug.MemoryInfo

进入较低级别，您可以使用 Debug API 获取有关内存使用情况的原始内核级信息：android.os.Debug.MemoryInfo

Note starting with 2.0 there is also an API, ActivityManager.getProcessMemoryInfo, to get this information about another process: ActivityManager.getProcessMemoryInfo(int[])

请注意，从 2.0 开始，还有一个 API，ActivityManager.getProcessMemoryInfo用于获取有关另一个进程的信息：ActivityManager.getProcessMemoryInfo(int[])

This returns a low-level MemoryInfo structure with all of this data:

这将返回一个包含所有这些数据的低级 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;

But as to what the difference is between Pss, PrivateDirty, and SharedDirty... well now the fun begins.

但对于不同的是什么之间Pss，PrivateDirty以及SharedDirty......现在好了，有趣的开始。

A lot of memory in Android (and Linux systems in general) is actually shared across multiple processes. So how much memory a processes uses is really not clear. Add on top of that paging out to disk (let alone swap which we don't use on Android) and it is even less clear.

Android（以及一般的 Linux 系统）中的大量内存实际上是跨多个进程共享的。所以一个进程使用多少内存真的不清楚。再加上分页到磁盘（更不用说我们不在 Android 上使用的交换），它甚至不太清楚。

Thus if you were to take all of the physical RAM actually mapped in to each process, and add up all of the processes, you would probably end up with a number much greater than the actual total RAM.

因此，如果您将实际映射到每个进程的所有物理 RAM 都计算在内，并将所有进程相加，则最终得到的数字可能远大于实际的总 RAM。

The Pssnumber is a metric the kernel computes that takes into account memory sharing -- basically each page of RAM in a process is scaled by a ratio of the number of other processes also using that page. This way you can (in theory) add up the pss across all processes to see the total RAM they are using, and compare pss between processes to get a rough idea of their relative weight.

该Pss数字是内核计算的一个度量标准，它考虑了内存共享——基本上一个进程中的每个 RAM 页都按其他进程数量的比例进行缩放。通过这种方式，您可以（理论上）将所有进程的 pss 相加以查看它们使用的总 RAM，并比较进程之间的 pss 以粗略了解它们的相对权重。

The other interesting metric here is PrivateDirty, which is basically the amount of RAM inside the process that can not be paged to disk (it is not backed by the same data on disk), and is not shared with any other processes. Another way to look at this is the RAM that will become available to the system when that process goes away (and probably quickly subsumed into caches and other uses of it).

这里另一个有趣的指标是PrivateDirty，它基本上是进程内无法分页到磁盘的 RAM 量（它不受磁盘上相同数据的支持），并且不与任何其他进程共享。另一种看待这个问题的方法是当该进程消失时系统将可用的 RAM（并且可能很快包含在缓存和它的其他用途中）。

That is pretty much the SDK APIs for this. However there is more you can do as a developer with your device.

这几乎就是用于此的 SDK API。但是，作为开发人员，您可以使用您的设备做更多事情。

Using adb, there is a lot of information you can get about the memory use of a running system. A common one is the command adb shell dumpsys meminfowhich will spit out a bunch of information about the memory use of each Java process, containing the above info as well as a variety of other things. You can also tack on the name or pid of a single process to see, for example adb shell dumpsys meminfo systemgive me the system process:

使用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

The top section is the main one, where sizeis the total size in address space of a particular heap, allocatedis the kb of actual allocations that heap thinks it has, freeis the remaining kb free the heap has for additional allocations, and pssand priv dirtyare the same as discussed before specific to pages associated with each of the heaps.

顶部部分是主要部分，其中size是特定堆的地址空间总大小，allocated是堆认为它拥有的实际分配的 kb，是堆free剩余的空闲 kb 用于额外分配，pss并且priv dirty是相同的如前所述，特定于与每个堆相关联的页面。

If you just want to look at memory usage across all processes, you can use the command adb shell procrank. Output of this on the same system looks like:

如果您只想查看所有进程的内存使用情况，可以使用命令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

Here the Vssand Rsscolumns are basically noise (these are the straight-forward address space and RAM usage of a process, where if you add up the RAM usage across processes you get an ridiculously large number).

这里的Vss和Rss列基本上是噪音（这些是一个进程的直接地址空间和 RAM 使用量，如果你将跨进程的 RAM 使用量相加，你会得到一个大得离谱的数字）。

Pssis as we've seen before, and Ussis Priv Dirty.

Pss就像我们之前看到的那样，并且Uss是Priv Dirty。

Interesting thing to note here: Pssand Ussare slightly (or more than slightly) different than what we saw in meminfo. Why is that? Well procrank uses a different kernel mechanism to collect its data than meminfodoes, and they give slightly different results. Why is that? Honestly I haven't a clue. I believe procrankmay be the more accurate one... but really, this just leave the point: "take any memory info you get with a grain of salt; often a very large grain."

这里需要注意的有趣事情是：Pss与Uss我们在meminfo. 这是为什么？procrank 使用不同的内核机制来收集数据meminfo，它们给出的结果略有不同。这是为什么？老实说，我没有任何线索。我相信procrank可能是更准确的……但实际上，这只是离开了一点：“用一粒盐获取您获得的任何内存信息；通常是一个非常大的颗粒。”

Finally there is the command adb shell cat /proc/meminfothat gives a summary of the overall memory usage of the system. There is a lot of data here, only the first few numbers worth discussing (and the remaining ones understood by few people, and my questions of those few people about them often resulting in conflicting explanations):

最后是adb shell cat /proc/meminfo提供系统总体内存使用情况摘要的命令。这里的数据很多，只有前几个数字值得讨论（剩下的数字很少有人理解，我对那几个人的问题经常导致解释相互矛盾）：

MemTotal:         395144 kB
MemFree:          184936 kB
Buffers:             880 kB
Cached:            84104 kB
SwapCached:            0 kB

MemTotalis the total amount of memory available to the kernel and user space (often less than the actual physical RAM of the device, since some of that RAM is needed for the radio, DMA buffers, etc).

MemTotal是内核和用户空间可用的内存总量（通常小于设备的实际物理 RAM，因为其中一些 RAM 需要用于无线电、DMA 缓冲区等）。

MemFreeis the amount of RAM that is not being used at all. The number you see here is very high; typically on an Android system this would be only a few MB, since we try to use available memory to keep processes running

MemFree是根本没有使用的 RAM 量。你在这里看到的数字非常高；通常在 Android 系统上这只有几 MB，因为我们尝试使用可用内存来保持进程运行

Cachedis the RAM being used for filesystem caches and other such things. Typical systems will need to have 20MB or so for this to avoid getting into bad paging states; the Android out of memory killer is tuned for a particular system to make sure that background processes are killed before the cached RAM is consumed too much by them to result in such paging.

Cached是用于文件系统缓存和其他此类事情的 RAM。典型的系统需要有 20MB 左右的空间来避免进入糟糕的分页状态；Android 内存不足杀手针对特定系统进行了调整，以确保后台进程在缓存的 RAM 被它们消耗过多而导致此类分页之前被杀死。

Answer 2

回答by yanchenko

1) I guess not, at least not from Java.
2)

1) 我猜不是，至少不是来自 Java。
2)

ActivityManager activityManager = (ActivityManager) getSystemService(ACTIVITY_SERVICE);
MemoryInfo mi = new MemoryInfo();
activityManager.getMemoryInfo(mi);
Log.i("memory free", "" + mi.availMem);

Answer 3

回答by Ryan Beesley

This is a work in progress, but this is what I don't understand:

这是一项正在进行的工作，但这是我不明白的：

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");
    }
}

Why isn't the PID mapped to the result in activityManager.getProcessMemoryInfo()? Clearly you want to make the resulting data meaningful, so why has Google made it so difficult to correlate the results? The current system doesn't even work well if I want to process the entire memory usage since the returned result is an array of android.os.Debug.MemoryInfo objects, but none of those objects actually tell you what pids they are associated with. If you simply pass in an array of all pids, you will have no way to understand the results. As I understand it's use, it makes it meaningless to pass in more than one pid at a time, and then if that's the case, why make it so that activityManager.getProcessMemoryInfo() only takes an int array?

为什么 PID 没有映射到 activityManager.getProcessMemoryInfo() 中的结果？很明显，您想让结果数据有意义，那么为什么 Google 使结果关联如此困难？如果我想处理整个内存使用情况，当前系统甚至不能很好地工作，因为返回的结果是一个 android.os.Debug.MemoryInfo 对象数组，但这些对象实际上没有一个告诉您它们与哪些 pid 相关联。如果你只是简单地传入一个包含所有 pid 的数组，你将无法理解结果。据我所知，它的用途是一次传入多个 pid 变得毫无意义，如果是这种情况，为什么要让 activityManager.getProcessMemoryInfo() 只接受一个 int 数组？

Answer 4

回答by Xavi Gil

Hackbod's is one of the best answers on Stack Overflow. It throws light on a very obscure subject. It helped me a lot.

Hackbod 是 Stack Overflow 上最好的答案之一。它照亮了一个非常晦涩的主题。这对我帮助很大。

Another really helpful resource is this must-see video: Google I/O 2011: Memory management for Android Apps

另一个非常有用的资源是这个必看视频：Google I/O 2011：Android 应用程序的内存管理

UPDATE:

更新：

Process Stats, a service to discover how your app manages memory explained at the blog post Process Stats: Understanding How Your App Uses RAMby Dianne Hackborn:

Process Stats，一项用于发现您的应用程序如何管理内存的服务，在Dianne Hackborn的博客文章Process Stats：了解您的应用程序如何使用 RAM 中进行了解释：

Answer 5

回答by coocood

Yes, you can get memory info programmatically and decide whether to do memory intensive work.

是的，您可以通过编程方式获取内存信息并决定是否进行内存密集型工作。

Get VM Heap Size by calling:

通过调用获取 VM 堆大小：

Runtime.getRuntime().totalMemory();

Get Allocated VM Memory by calling:

通过调用获取分配的 VM 内存：

Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory();

Get VM Heap Size Limit by calling:

通过调用获取 VM 堆大小限制：

Runtime.getRuntime().maxMemory()

Get Native Allocated Memory by calling:

通过调用获取本机分配的内存：

Debug.getNativeHeapAllocatedSize();

I made an app to figure out the OutOfMemoryError behavior and monitor memory usage.

我制作了一个应用程序来找出 OutOfMemoryError 行为并监控内存使用情况。

https://play.google.com/store/apps/details?id=net.coocood.oomresearch

You can get the source code at https://github.com/coocood/oom-research

你可以在https://github.com/coocood/oom-research获取源代码

Answer 6

回答by Machado

Android Studio 0.8.10+ has introduced an incredibly useful tool called Memory Monitor.

Android Studio 0.8.10+ 引入了一个非常有用的工具，称为Memory Monitor。

What it's good for:

它有什么好处：

Showing available and used memory in a graph, and garbage collection events over time.
Quickly testing whether app slowness might be related to excessive garbage collection events.
Quickly testing whether app crashes may be related to running out of memory.

在图表中显示可用和已用内存，以及随时间变化的垃圾收集事件。
快速测试应用程序缓慢是否与过多的垃圾收集事件有关。
快速测试应用程序崩溃是否与内存不足有关。

Figure 1. Forcing a GC (Garbage Collection) event on Android Memory Monitor

图 1. 在 Android 内存监视器上强制执行 GC（垃圾收集）事件

You can have plenty good information on your app's RAM real-time consumption by using it.

通过使用它，您可以获得有关应用程序 RAM 实时消耗的大量信息。

Answer 7

回答by Dmitry Shesterkin

We found out that all the standard ways of getting the total memory of the current process have some issues.

我们发现所有获取当前进程总内存的标准方法都有一些问题。

Runtime.getRuntime().totalMemory(): returns JVM memory only
ActivityManager.getMemoryInfo(), Process.getFreeMemory()and anything else based on /proc/meminfo- returns memory info about all the processes combined (e.g. android_util_Process.cpp)
Debug.getNativeHeapAllocatedSize()- uses mallinfo()which return information about memory allocations performed by malloc()and related functions only (see android_os_Debug.cpp)
Debug.getMemoryInfo()- does the job but it's too slow. It takes about 200mson Nexus 6for a single call. The performance overhead makes this function useless for us as we call it regularly and every call is quite noticeable (see android_os_Debug.cpp)
ActivityManager.getProcessMemoryInfo(int[])- calls Debug.getMemoryInfo()internally (see ActivityManagerService.java)

Runtime.getRuntime().totalMemory(): 只返回JVM内存
ActivityManager.getMemoryInfo()，Process.getFreeMemory()以及其他任何基于/proc/meminfo- 返回有关所有进程组合的内存信息（例如android_util_Process.cpp）
Debug.getNativeHeapAllocatedSize()- 使用mallinfo()which 仅返回有关由malloc()相关函数执行的内存分配的信息（请参阅android_os_Debug.cpp）
Debug.getMemoryInfo()- 可以完成工作，但速度太慢。在Nexus 6上一次通话大约需要200 毫秒。性能开销使这个函数对我们毫无用处，因为我们经常调用它，每次调用都很明显（参见android_os_Debug.cpp）
ActivityManager.getProcessMemoryInfo(int[])-Debug.getMemoryInfo()内部调用（参见ActivityManagerService.java）

Finally, we ended up using the following code:

最后，我们最终使用了以下代码：

const long pageSize = 4 * 1024; //`sysconf(_SC_PAGESIZE)`
string stats = File.ReadAllText("/proc/self/statm");
var statsArr = stats.Split(new [] {' ', '\t', '\n'}, 3);

if( statsArr.Length < 2 )
    throw new Exception("Parsing error of /proc/self/statm: " + stats);

return long.Parse(statsArr[1]) * pageSize;

It returns VmRSSmetric. You can find more details about it here: one, twoand three.

它返回VmRSS指标。您可以在此处找到有关它的更多详细信息：一、二和三。

P.S.I noticed that the theme still has a lack of an actual and simple code snippet of how to estimatethe private memory usage of the process if the performance isn't a critical requirement:

PS我注意到如果性能不是关键要求，主题仍然缺乏如何估计进程的私有内存使用的实际和简单的代码片段：

Debug.MemoryInfo memInfo = new Debug.MemoryInfo();
Debug.getMemoryInfo(memInfo);
long res = memInfo.getTotalPrivateDirty();

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) 
    res += memInfo.getTotalPrivateClean(); 

return res * 1024L;

Answer 8

回答by Iamat8

There are a lot of answer above which will definitely help you but (after 2 days of afford and research on adb memory tools)I think i can help with my opiniontoo.

上面有很多答案肯定会对您有所帮助，但是（在对 adb 内存工具进行了 2 天的负担和研究之后）我想我也可以提供我的意见。

As Hackbod says : Thus if you were to take all of the physical RAM actually mapped in to each process, and add up all of the processes, you would probably end up with a number much greater than the actual total RAM.so there is no way you can get exact amount of memory per process.

正如 Hackbod 所说：因此，如果您将实际映射到每个进程的所有物理 RAM 都加起来，然后将所有进程相加，最终得到的数字可能会远大于实际的总 RAM。因此您无法获得每个进程的确切内存量。

But you can get close to it by some logic..and I will tell how..

但是你可以通过某种逻辑接近它......我会告诉你如何......

There are some API like android.os.Debug.MemoryInfoand ActivityManager.getMemoryInfo()mentioned above which you already might have being read about and used but I will talk about other way

还有像一些APIandroid.os.Debug.MemoryInfo和ActivityManager.getMemoryInfo()上面提到你已经有可能被了解和使用，但我会再谈其他方式

So firstly you need to be a root user to get it work. Get into console with root privilege by executing suin process and get its output and input stream. Then pass id\n(enter)in ouputstream and write it to process output, If will get an inputstream containing uid=0, you are root user.

所以首先你需要成为一个 root 用户才能让它工作。通过su在进程中执行以 root 权限进入控制台并获取其output and input stream. 然后在输出流中传递id\n（输入）并将其写入处理输出，如果将获得包含的输入流uid=0，则您是root用户。

Now here is the logic which you will use in above process

现在这是您将在上述过程中使用的逻辑

When you get ouputstream of process pass you command (procrank, dumpsys meminfo etc...) with \ninstead of idand get its inputstreamand read, store the stream in bytes[ ] ,char[ ] etc.. use rawdata..and you are done!!!!!

当你得到进程的输出流传递你的命令（procrank、dumpsys meminfo 等...）\n而不是 id并获取它inputstream并读取时，将流存储在字节 []、char[] 等中。使用原始数据......然后你完成！！！！！

permission :

允许：

<uses-permission android:name="android.permission.FACTORY_TEST"/>

Check if you are root user :

检查您是否是 root 用户：

// su command to get root access
Process process = Runtime.getRuntime().exec("su");         
DataOutputStream dataOutputStream = 
                           new DataOutputStream(process.getOutputStream());
DataInputStream dataInputStream = 
                           new DataInputStream(process.getInputStream());
if (dataInputStream != null && dataOutputStream != null) {
   // write id to console with enter
   dataOutputStream.writeBytes("id\n");                   
   dataOutputStream.flush();
   String Uid = dataInputStream.readLine();
   // read output and check if uid is there
   if (Uid.contains("uid=0")) {                           
      // you are root user
   } 
}

Execute your command with su

执行你的命令 su

Process process = Runtime.getRuntime().exec("su");         
DataOutputStream dataOutputStream = 
                           new DataOutputStream(process.getOutputStream());
if (dataOutputStream != null) {
 // adb command
 dataOutputStream.writeBytes("procrank\n");             
 dataOutputStream.flush();
 BufferedInputStream bufferedInputStream = 
                     new BufferedInputStream(process.getInputStream());
 // this is important as it takes times to return to next line so wait
 // else you with get empty bytes in buffered stream 
 try {
       Thread.sleep(10000);
 } catch (InterruptedException e) {                     
       e.printStackTrace();
 }
 // read buffered stream into byte,char etc.
 byte[] bff = new byte[bufferedInputStream.available()];
 bufferedInputStream.read(bff);
 bufferedInputStream.close();
 }
}

logcat :

日志猫：

You get a raw data in a single string from console instead of in some instance from any API,which is complex to store as you will need to separate it manually.

您可以从控制台获取单个字符串中的原始数据，而不是在某些情况下从任何 API 获取，这存储起来很复杂，因为您需要手动将其分开。

This is just a try, please suggest me if I missed something

这只是一个尝试，如果我错过了什么，请建议我

Answer 9

回答by Akash Patel

In android studio 3.0 they have introduced android-profiler to help you to understand how your app uses CPU, memory, network, and battery resources.

在 android studio 3.0 中，他们引入了 android-profiler 来帮助您了解您的应用程序如何使用 CPU、内存、网络和电池资源。

https://developer.android.com/studio/profile/android-profiler

Java 如何在 Android 中发现我的应用程序的内存使用情况？

提问by Andrea Baccega

采纳答案by hackbod

回答by yanchenko

回答by Ryan Beesley

回答by Xavi Gil

回答by coocood

回答by Machado

回答by Dmitry Shesterkin

回答by Iamat8

回答by Akash Patel

相关推荐

最近更新

标签

Java 如何在 Android 中发现我的应用程序的内存使用情况？

提问by Andrea Baccega

采纳答案by hackbod

回答by yanchenko

回答by Ryan Beesley

回答by Xavi Gil

回答by coocood

回答by Machado

回答by Dmitry Shesterkin

回答by Iamat8

回答by Akash Patel

相关推荐

什么是用于词性标记的好 Java 库？

Java Hibernate 的 load() 方法上下文中的代理是什么？

Java Tomcat 启动 (web.xml) 问题

通过 Java API 将具有值的字段添加到 MongoDB 中的现有文档

相关推荐

最近更新

标签