D/dalvikvm: <GC_Reason> <Amount_freed>, <Heap_stats>, <External_memory_stats>, <Pause_time>
D/dalvikvm( 9050): GC_CONCURRENT freed 2049K, 65% free 3571K/9991K, external 4703K/5261K, paused 2ms+2msGC Reason 导致GC的原因
- A concurrent GC that frees up memory as your heap begins to fill up.
- 并发GC，当堆填充满的时候来释放内存。
- A GC caused because your app attempted to allocate memory when your heap was already full, so the system had to stop your app and reclaim memory.
- 当你的堆已满时，你的应用尝试分配内存，这时系统必须停掉你的app并回收内存，此时发生GC。
- A GC that occurs when you request to create an HPROF file to analyze your heap.
- 当你请求创建一个HPROF文件来分析堆，触发GC。
-
An explicit GC, such as when you call
gc()(which you should avoid calling and instead trust the GC to run when needed). - 一个显式GC，例如你调用了gc()（你应该避免调用这个函数，而应该相信GC会在需要的时候运行。）
- This happens only on API level 10 and lower (newer versions allocate everything in the Dalvik heap). A GC for externally allocated memory (such as the pixel data stored in native memory or NIO byte buffers).
- 这个只有在API 10及更低版本上才会发生（新的版本会在Dalvik堆上分配所有东西）。为外部的内存分配而发生的GC（例如，存储在本地内存或NIO二进制缓存中的像素数据）。
GC_CONCURRENT
GC_FOR_MALLOC
GC_HPROF_DUMP_HEAP
GC_EXPLICIT
GC_EXTERNAL_ALLOC
- Percentage free of the heap and (number of live objects)/(total heap size).
- 空闲堆的百分比与(活动对象数量)/(堆的总大小)。
-
External memory stats 外部存储状态
- Externally allocated memory on API level 10 and lower (amount of allocated memory) / (limit at which collection will occur).
- API 10及更低版本上的外部存储分配 (分配的数量)/(发生GC的限制)。
-
Pause time 暂停时间
- Larger heaps will have larger pause times. Concurrent pause times show two pauses: one at the beginning of the collection and another near the end.
- 更大的堆将会有更长的暂停时间。并发暂停时间显示两次暂停：一次在GC的开始，一次在接近末尾的时候。
As these log messages accumulate, look out for increases in the heap stats (the 3571K/9991K value in the above example). If this value continues to increase, you may have a memory leak.
ART Log Messages ART日志信息
Unlike Dalvik, ART doesn't log messages for GCs that were not explicitly requested. GCs are only printed when they are they are deemed slow. More precisely, if the GC pause exceeds than 5ms or the GC duration exceeds 100ms. If the app is not in a pause perceptible process state, then none of its GCs are deemed slow. Explicit GCs are always logged.
与Dalvik不同，ART并不为非显式请求的GCs打印日志信息。只有当GCs被认为慢的时候，它们才会打印。更准确地说，如果GC暂停超过5ms或者持续超过100ms，就会打印。如果app不在一种可理解的进程暂停状态，那么GCs不会被认为慢。显式GCs总会打印日志。
ART includes the following information in its garbage collection log messages:
ART的垃圾收集日志消息中包括下面的信息：I/art: <GC_Reason> <GC_Name> <Objects_freed>(<Size_freed>) AllocSpace Objects, <Large_objects_freed>(<Large_object_size_freed>) <Heap_stats> LOS objects, <Pause_time(s)>
I/art : Explicit concurrent mark sweep GC freed 104710(7MB) AllocSpace objects, 21(416KB) LOS objects, 33% free, 25MB/38MB, paused 1.230ms total 67.216ms
- A concurrent GC which does not suspend app threads. This GC runs in a background thread and does not prevent allocations.
- 不挂起app线程的并发GC。这种GC在后台线程中运行，不会避免分配。
- The GC was initiated because your app attempted to allocate memory when your heap was already full. In this case, the garbage collection occurred in the allocating thread.
- 由于你的app在你的堆已满的时候尝试分配内存，这种GC得到初始化。在这种情况下，GC在分配线程中出现。
-
The garbage collection was explicitly requested by an app, for instance, by calling
gc()orgc(). As with Dalvik, in ART it is recommended that you trust the GC and avoid requesting explicit GCs if possible. Explicit GCs are discouraged since they block the allocating thread and unnecessarily was CPU cycles. Explicit GCs could also cause jank if they cause other threads to get preempted. - app显式地请求垃圾收集，例如，通过调用gc()。就跟Dalvik一样，ART中推荐你相信GC并避免显式请求GCs。不鼓励显式GCs，因为它们阻断分配线程。显式GCs如果导致其它线程抢先占用（preempted）会导致不稳定（jank）。
- The collection was caused by native memory pressure from native allocations such as Bitmaps or RenderScript allocation objects.
- 本地内存分配导致的压力——比如位图或者渲染脚本分配对象——所导致的GC。
- The collection was caused by a heap transition; this is caused by switching the GC at run time. Collector transitions consist of copying all the objects from a free-list backed space to a bump pointer space (or visa versa). Currently collector transitions only occur when an app changes process states from a pause perceptible state to a non pause perceptible state (or visa versa) on low RAM devices.
- 这个收集是由堆转变导致的；在运行时转变GC会导致这些。收集器转换包括从空闲列表备份区中拷贝所有对象到指针区（或者相反过程）。当前的收集器转换只有在一个app变化进程状态时才会发生——在低RAM设备上，从容易阻塞的状态到非容易阻塞的状态（或者相反过程）。
- Homogeneous space compaction is free-list space to free-list space compaction which usually occurs when an app is moved to a pause imperceptible process state. The main reasons for doing this are reducing RAM usage and defragmenting the heap.
- 齐次空间紧致是空闲列表空间对空闲列表空间压缩的对应，空闲列表空间压缩通常发生在一个应用进入到进程阻塞敏感状态时发生的。做这件事情的主要原因是缩减RAM使用与堆碎片整理。
- This is not a real GC reason, but a note that collection was blocked due to use of GetPrimitiveArrayCritical. while concurrent heap compaction is occuring. In general, the use of GetPrimitiveArrayCritical is strongly discouraged due to its restrictions on moving collectors.
- 这个不是真正的GC原因，但是是一个GC在并发对压缩发生时，由于使用GetPrimitiveArrayCritical而被阻止的提示。概括地说，GetPrimitiveArrayCritical的使用非常不被鼓励，因为它对移动收集器有严格限制。
- This is not a GC reason, but a note that collection was blocked until a heap trim finished.
- 这不是GC的原因，而是直到对裁剪完成之前，收集被阻塞的提示。
Concurrent 并发
Alloc 分配
Explicit 显式
NativeAlloc 本地分配
CollectorTransition 收集器转变
HomogeneousSpaceCompact 齐次空间紧致
DisableMovingGc 禁止移动GC
HeapTrim 堆裁剪
-
GC Name GC名称
- ART has various different GCs which can get run.
-
ART有不同的GC能够运行。
- A whole heap collector which frees collects all spaces other than the image space.
- 一个完整的堆收集器，释放除了图片空间之外的所有空间。
- A mostly whole heap collector which collects all spaces other than the image and zygote spaces.
- 一个部分完整的堆收集器，收集除了图片和zygote之外的空间。
- A generational collector which can only free objects allocated since the last GC. This garbage collection is run more often than a full or partial mark sweep since it is faster and has lower pauses.
- 一个代际收集器，只能释放从最近一次GC以来分配的对象。这个垃圾收集器比CMS和CPMS运行的更经常，因为它的速度更快，阻塞更低。
- A non concurrent, copying GC used for heap transitions as well as homogeneous space compaction (to defragement the heap).
- 一个非并发的、备份GC，用于堆转换和同类空间压缩（相对堆碎片整理而言）。
Concurrent mark sweep (CMS) 并发标记清除Concurrent partial mark sweep 并发部分标记清除Concurrent sticky mark sweep 并发静态标记清除Marksweep + semispace
Objects freed 释放的对象
- The number of objects which were reclaimed from this GC from the non large object space.
- 这次GC中，从非大对象空间中回收的对象数量。 Size freed 释放的大小
- The number of bytes which were reclaimed from this GC from the non large object space.
- 这次GC中，从非大对象空间中回收的字节数量。 Large objects freed 回收的大对象
- The number of object in the large object space which were reclaimed from this garbage collection.
- 这次GC中，从大对象空间中回收的对象数量。 Large object size freed 回收的大对象大小。
- The number of bytes in the large object space which were reclaimed from this garbage collection.
- 这次GC中，回收的大对象的字节数目。 Heap stats 堆状态
- Percentage free and (number of live objects)/(total heap size).
- 释放的百分比和(活动对象数量)/(堆的总大小) Pause times 暂停时间
- In general pause times are proportional to the number of object references which were modified while the GC was running. Currently, the ART CMS GCs only has one pause, near the end of the GC. The moving GCs have a long pause which lasts for the majority of the GC duration.
- 概括而言，暂停时间与在GC执行过程中改变的对象引用数量成比例。目前，ART CMS GC只有一次暂停，而且是在GC末尾。移动GC有长的暂停，将持续GC的大部分时间。
If you are seeing a large amount of GCs in logcat, look for increases in the heap stats (the 25MB/38MB value in the above example). If this value continues to increase and doesn't ever seem to get smaller, you could have a memory leak. Alternatively, if you are seeing GC which are for the reason "Alloc", then you are already operating near your heap capacity and can expect OOM exceptions in the near future.
Memory Monitor in Android Studio
Android Studio中的内存监视器
Use Android Studio to view your app's memory use:
使用Android Studio来查看app的内存使用情况。
- Start your app on a connected device or emulator.
- Open the Android run-time window, and view the free and allocated memory in the Memory Monitor.
- Click the Dump Java Heap icon (
) in the Memory Monitor toolbar.
Android Studio creates the heap snapshot file with the filename
Snapshot-yyyy.mm.dd-hh.mm.ss.hprofin theCaptures tab. - Double-click the heap snapshot file to open the HPROF viewer.
Note: To convert a heap dump to standard HPROF format in Android Studio, right-click a heap snapshot in theCaptures view and select Export to standard .hprof.
- Interact with your app and click the (
) icon to cause heap allocation.
- Identify which actions in your app are likely causing too much allocation and determine where in your app you should try to reduce allocations and release resources.
Device Monitor——注意使用这个工具。
- Open the Device Monitor.
From your
<sdk>/tools/directory, launch themonitortool. - In the Debug Monitor window, select your app's process from the list on the left.
- Click Update Heap above the process list.
- In the right-side panel, select the Heap tab.
The Heap view shows some basic stats about your heap memory usage, updated after every GC. To see the first update, click the Cause GC button.
Figure 1. The Device Monitor tool, showing the [1] Update Heap and [2] Cause GC buttons. The Heap tab on the right shows the heap results.
图1. 设备监视器工具。显示了[1] 更新堆和[2]触发GC按钮。右侧的堆信息页显示结果。
Continue interacting with your app to watch your heap allocation update with each garbage collection. This can help you identify which actions in your app are likely causing too much allocation and where you should try to reduce allocations and release resources.
As you start narrowing down memory issues, you should also use the Allocation Tracker to get a better understanding of where your memory-hogging objects are allocated. The Allocation Tracker can be useful not only for looking at specific uses of memory, but also to analyze critical code paths in an app such as scrolling.
当你开始收窄内存问题的范围，你应该使用Allocation Tracker来更好的理解明显占据内存的兑现是在哪里分配的。Allocation Tracker非常有用，一方面可以查找内存的特殊使用，另一方面可以分析app中的关键代码路径，例如滑动逻辑。
For example, tracking allocations when flinging a list in your app allows you to see all the allocations that need to be done for that behavior, what thread they are on, and where they came from. This is extremely valuable for tightening up these paths to reduce the work they need and improve the overall smoothness of the UI.
例如，跟踪内存分配可以让你在app中滑动一个列表的时候查看为实现这个操作而进行的而所有分配，这些分配在哪个线程，来自于哪里。通过紧缩路径来减少他们需要的工作，提升UI整体的流畅性，这非常有价值。
To use the Allocation Tracker, open the Memory Monitor in Android Studio and click the Allocation Tracker icon. You can also track allocations in the Android Device Monitor:
Android Studio
To use the Allocation Tracker in Android Studio:
- Start your app on a connected device or emulator
- Open the Android run-tme window, and view the free and allocated memory in the Memory Monitor.
- Click the Allocation Tracker icon (
) in the Memory Monitor tool bar to start and stop memory allocations.
Android Studio creates the allocation file with the filename
Allocations-yyyy.mm.dd-hh.mm.ss.allocin the Capturestab. - Double-click the allocation file to open the Allocation viewer.
- Identify which actions in your app are likely causing too much allocation and determine where in your app you should try to reduce allocations and release resources.
Device Monitor——使用这个工具！
- Open the Device Monitor.
From your
<sdk>/tools/directory, launch themonitortool. - In the DDMS window, select your app's process in the left-side panel.
- In the right-side panel, select the Allocation Tracker tab.
- Click Start Tracking.
- Interact with your app to execute the code paths you want to analyze.
- Click Get Allocations every time you want to update the list of allocations.
The list shows all recent allocations, currently limited by a 512-entry ring buffer. Click on a line to see the stack trace that led to the allocation. The trace shows you not only what type of object was allocated, but also in which thread, in which class, in which file and at which line.
Figure 2. The Device Monitor tool, showing recent app allocations and stack traces in the Allocation Tracker.
Note: You will always see some allocations from DdmVmInternal and else where that come from the allocation tracker itself.
Although it's not necessary (nor possible) to remove all allocations for your performance critical code paths, the allocation tracker can help you identify important issues in your code. For instance, some apps might create a new Paint object on every draw. Moving that object into a global member is a simple fix that helps improve performance.
adb shell dumpsys meminfo <package_name|pid> [-d]
The -d flag prints more info related to Dalvik and ART memory usage.
-d参数会打印与Dalvik和ART内存使用相关的信息。
The output lists all of your app's current allocations, measured in kilobytes.
输出会列出app所有当前的分配，以kb为单位。
When inspecting this information, you should be familiar with the following types of allocation:
当检查这些信息的时候，你必须对下面的分配类型非常熟悉：-
Private (Clean and Dirty) RAM 私有（干净和脏）RAM
- This is memory that is being used by only your process. This is the bulk of the RAM that the system can reclaim when your app’s process is destroyed. Generally, the most important portion of this is “private dirty” RAM, which is the most expensive because it is used by only your process and its contents exist only in RAM so can’t be paged to storage (because Android does not use swap). All Dalvik and native heap allocations you make will be private dirty RAM; Dalvik and native allocations you share with the Zygote process are shared dirty RAM.
- 这是仅供你的app使用的内存。这是当你的app被销毁时系统可以回收的内存量。一般而言，其中最重要的一部分是“private dirty” RAM，这是最昂贵的，因为它只供你的进程使用，并且只存在于RAM中，所以不能进行分页存储（因为Android并不使用swap）。所有Dalvik和本地堆分配都将是pirvate dirty RAM；Dalvik和与Zygote进场共享的本地分配是共享dirty RAM。
-
Proportional Set Size (PSS) 比例集大小
- This is a measurement of your app’s RAM use that takes into account sharing pages across processes. Any RAM pages that are unique to your process directly contribute to its PSS value, while pages that are shared with other processes contribute to the PSS value only in proportion to the amount of sharing. For example, a page that is shared between two processes will contribute half of its size to the PSS of each process.
- 这是你的app内存使用量的度量，它将进程间贡献页考虑其中。任何你进程独有的RAM页对PSS值都有贡献，与其它进程共享的页对PSS的贡献与共享的量成比例。例如，在两个进程间共享的页将会对每个进程的PSS贡献一半的大小。
A nice characteristic of the PSS measurement is that you can add up the PSS across all processes to determine the actual memory being used by all processes. This means PSS is a good measure for the actual RAM weight of a process and for comparison against the RAM use of other processes and the total available RAM.
PSS度量的一个非常好的特征是，你可以将跨进程的PSS叠加，来确定所有进程实际使用的的内存大小。这意味着PSS是一个进程实际RAM权重的好的度量，也是其它进程RAM使用量和全部可用RAM的好的度量。
For example, below is the the output for Map’s process on a Nexus 5 device. There is a lot of information here, but key points for discussion are listed below.
例如，下面是Nexus 5上Map进程的输出。这里有大量的信息，但是关键点列在了下面。
adb shell dumpsys meminfo com.google.android.apps.maps -d
Note: The information you see may vary slightly from what is shown here, as some details of the output differ across platform versions.
注意：你看到的信息可能会与这里的稍微不同，因为输出的细节因平台版本的不同而不同。
** MEMINFO in pid 18227 [com.google.android.apps.maps] **
Pss Private Private Swapped Heap Heap Heap
Total Dirty Clean Dirty Size Alloc Free
------ ------ ------ ------ ------ ------ ------
Native Heap 10468 10408 0 0 20480 14462 6017
Dalvik Heap 34340 33816 0 0 62436 53883 8553
Dalvik Other 972 972 0 0
Stack 1144 1144 0 0
Gfx dev 35300 35300 0 0
Other dev 5 0 4 0
.so mmap 1943 504 188 0
.apk mmap 598 0 136 0
.ttf mmap 134 0 68 0
.dex mmap 3908 0 3904 0
.oat mmap 1344 0 56 0
.art mmap 2037 1784 28 0
Other mmap 30 4 0 0
EGL mtrack 73072 73072 0 0
GL mtrack 51044 51044 0 0
Unknown 185 184 0 0
TOTAL 216524 208232 4384 0 82916 68345 14570
Dalvik Details
.Heap 6568 6568 0 0
.LOS 24771 24404 0 0
.GC 500 500 0 0
.JITCache 428 428 0 0
.Zygote 1093 936 0 0
.NonMoving 1908 1908 0 0
.IndirectRef 44 44 0 0
Objects
Views: 90 ViewRootImpl: 1
AppContexts: 4 Activities: 1
Assets: 2 AssetManagers: 2
Local Binders: 21 Proxy Binders: 28
Parcel memory: 18 Parcel count: 74
Death Recipients: 2 OpenSSL Sockets: 2
Here is an older dumpsys on Dalvik of the gmail app:
** MEMINFO in pid 9953 [com.google.android.gm] **
Pss Pss Shared Private Shared Private Heap Heap Heap
Total Clean Dirty Dirty Clean Clean Size Alloc Free
------ ------ ------ ------ ------ ------ ------ ------ ------
Native Heap 0 0 0 0 0 0 7800 7637(6) 126
Dalvik Heap 5110(3) 0 4136 4988(3) 0 0 9168 8958(6) 210
Dalvik Other 2850 0 2684 2772 0 0
Stack 36 0 8 36 0 0
Cursor 136 0 0 136 0 0
Ashmem 12 0 28 0 0 0
Other dev 380 0 24 376 0 4
.so mmap 5443(5) 1996 2584 2664(5) 5788 1996(5)
.apk mmap 235 32 0 0 1252 32
.ttf mmap 36 12 0 0 88 12
.dex mmap 3019(5) 2148 0 0 8936 2148(5)
Other mmap 107 0 8 8 324 68
Unknown 6994(4) 0 252 6992(4) 0 0
TOTAL 24358(1) 4188 9724 17972(2)16388 4260(2)16968 16595 336
Objects
Views: 426 ViewRootImpl: 3(8)
AppContexts: 6(7) Activities: 2(7)
Assets: 2 AssetManagers: 2
Local Binders: 64 Proxy Binders: 34
Death Recipients: 0
OpenSSL Sockets: 1
SQL
MEMORY_USED: 1739
PAGECACHE_OVERFLOW: 1164 MALLOC_SIZE: 62
Generally, you should be concerned with only the
Pss Total
and
Private Dirty
columns. In some cases, the
Private Clean
and
Heap Alloc
columns also offer interesting data. Here is some more information about the different memory allocations (the rows) you should observe:
Dalvik Heap
Pss Total
includes all Zygote allocations (weighted by their sharing across processes, as described in the PSS definition above). The
Private Dirty
number is the actual RAM committed to only your app’s heap, composed of your own allocations and any Zygote allocation pages that have been modified since forking your app’s process from Zygote.
Note: On newer platform versions that have the Dalvik Other section, the Pss Total and Private Dirtynumbers for Dalvik Heap do not include Dalvik overhead such as the just-in-time compilation (JIT) and GC bookkeeping, whereas older versions list it all combined under Dalvik.
注意：在有Delvik Other行的较新版本的平台上，Pss Total 和 Private Dirty数值并不包括常用的Dalvik，例如just-in-time编译和GC记录。然而，旧版本在Dalvik中一同列出。
The Heap Alloc is the amount of memory that the Dalvik and native heap allocators keep track of for your app. This value is larger than Pss Total and Private Dirty because your process was forked from Zygote and it includes allocations that your process shares with all the others.
Heap Alloc是Dalvik和本地堆分配器为你app跟踪的内存数量。这个值比Pss Total和Private Dirty大，因为你的进程是从Zygote孵化而来，它包括你的进程与其它进程共享的分配。
.so mmap
and
.dex mmap
.so
(native) and
.dex
(Dalvik or ART) code. The
Pss Total
number includes platform code shared across apps; the
Private Clean
is your app’s own code. Generally, the actual mapped size will be much larger—the RAM here is only what currently needs to be in RAM for code that has been executed by the app. However, the .so mmap has a large private dirty, which is due to fix-ups to the native code when it was loaded into its final address.
.oat mmap
.art mmap
Object
instances, it does not count towards your heap size.
.Heap
(only with -d flag)
.LOS
(only with -d flag)
.GC
(only with -d flag)
.JITCache
(only with -d flag)
.Zygote
(only with -d flag)
.NonMoving
(only with -d flag)
.IndirectRef
(only with -d flag)
Unknown
Pss Total
for Unknown takes into account sharing with Zygote, and
Private Dirty
is unknown RAM dedicated to only your app.
TOTAL
The Private Dirty and Private Clean are the total allocations within your process, which are not shared with other processes. Together (especially Private Dirty), this is the amount of RAM that will be released back to the system when your process is destroyed. Dirty RAM is pages that have been modified and so must stay committed to RAM (because there is no swap); clean RAM is pages that have been mapped from a persistent file (such as code being executed) and so can be paged out if not used for a while.
你进程使用的PSS RAM总量。这是上面各个PSS值得和。它表明你的进程的内存概况评估，可以直接与其它进程和全部可用内存量对比。Private Dirty 和 Private Clean是你进程中的全部分配，这并不与其它进程共享。与此同时（尤其是Private Dirty），这是当你的进程被销毁时重新释放到系统的内存量。Dirty RAM是已经因被修改过而必须常驻内存（因为没有swap）的页；clean RAM 是从持久性文件映射而来（例如正在执行的代码），所以在不被使用的时候被置换出来。
ViewRootImpl
AppContexts
and
Activities
Context
and
Activity
objects that currently live in your process. This can be useful to quickly identify leaked
Activity
objects that can’t be garbage collected due to static references on them, which is common. These objects often have a lot of other allocations associated with them and so are a good way to track large memory leaks.
Note: A View or Drawable object also holds a reference to the Activity that it's from, so holding a View orDrawable object can also lead to your app leaking an Activity.
A heap dump is a snapshot of all the objects in your app's heap, stored in a binary format called HPROF. Your app's heap dump provides information about the overall state of your app's heap so you can track down problems you might have identified while viewing heap updates.
一个堆仓库是一个app堆中所有对象的快照，以名称为HPROF的二进制文件存储。你的app的堆仓库提供app整体状态的信息，所以你可以跟踪在查看堆更新时定位的问题。
To retrieve your heap dump from within Android Studio, use the Memory Monitor and HPROF viewer.
为从你的Android Studio中检索你的堆仓库，使用Memory Monitor和HPROF 查看器。
You can also still perform these procedures in the Android monitor:
- Open the Device Monitor.
From your
<sdk>/tools/directory, launch themonitortool. - In the DDMS window, select your app's process in the left-side panel.
- Click Dump HPROF file, shown in figure 3.
- In the window that appears, name your HPROF file, select the save location, then click Save.
Figure 3. The Device Monitor tool, showing the [1] Dump HPROF file button.
If you need to be more precise about when the dump is created, you can also create a heap dump at the critical point in your app code by calling dumpHprofData().
如果你需要对仓库创建的时间点有更精确的把握，可以在你app中的关键点通过调用dumpHprofData()创建一个堆仓库。
The heap dump is provided in a format that's similar to, but not identical to one from the Java HPROF tool. The major difference in an Android heap dump is due to the fact that there are a large number of allocations in the Zygote process. But because the Zygote allocations are shared across all app processes, they don’t matter very much to your own heap analysis.
堆仓库以一种与Java HPROF 工具提供的形式类似但不一样的形式提供。Android堆仓库的主要不同是由于Zygote进程中有大量的分配造成的。但是，由于Zygote分配在多个app进程中共享，他们并不非常关心你的堆分析。
To analyze your heap dump, you can use Memory Monitor in Android Studio. You can also use a standard tool like jhat. However, first you'll need to convert the HPROF file from Android's format to the J2SE HPROF format. You can do this using the hprof-conv tool provided in the <sdk>/platform-tools/ directory. Simply run the hprof-conv command with two arguments: the original HPROF file and the location to write the converted HPROF file. For example:
hprof-conv heap-original.hprof heap-converted.hprof
为了分析你的堆仓，你可以使用Android Studio中的memory monitor。你也可以使用一个类似jhat的标准工具。然而，你首先需要将HPROF文件的Android格式转换为J2SE格式。你可以使用 <sdk>/platform-tools/目录下的hprof-conv工具。
You can now load the converted file into a heap analysis tool that understands the J2SE HPROF format.
When analyzing your heap, you should look for memory leaks caused by:
- Long-lived references to an Activity, Context, View, Drawable, and other objects that may hold a reference to the container Activity or Context.
- Non-static inner classes (such as a Runnable, which can hold the Activity instance).
- Caches that hold objects longer than necessary.
- 长时间存活的对Activity、Context、View、Drawable的引用，以及可能持有Activity或Context引用的对象。
- 非静态内部类（例如可能持有Activity实例的Runnable）
- 持有超过必要时间长度对象的缓存
While using the tools described above, you should aggressively stress your app code and try forcing memory leaks. One way to provoke memory leaks in your app is to let it run for a while before inspecting the heap. Leaks will trickle up to the top of the allocations in the heap. However, the smaller the leak, the longer you need to run the app in order to see it.
当使用上面描述的工具的时候，你应该强烈地给你的代码加压力，尝试强迫内存溢出。一个触发app中内存溢出的方法是，在检查堆之前，让它运行一段时间。溢出将会在堆分配的顶部慢慢形成。然而，溢出越小，你就需要运行更长的时间来看见它。
You can also trigger a memory leak in one of the following ways:
- Rotate the device from portrait to landscape and back again multiple times while in different activity states. Rotating the device can often cause an app to leak an
Activity,Context, orViewobject because the system recreates theActivityand if your app holds a reference to one of those objects somewhere else, the system can't garbage collect it. - Switch between your app and another app while in different activity states (navigate to the Home screen, then return to your app).
Tip: You can also perform the above steps by using the "monkey" test framework. For more information on running the monkey test framework, read the monkeyrunner documentation.
扫一扫
3733
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
