幾個(gè)月之前看過(guò)一遍，結(jié)果過(guò)一陣子在查bitmap造成內(nèi)存泄露時(shí)又感覺忘得差不多了，不曉得android os RAM 到底怎么分配的了。干脆，再翻翻，翻譯翻譯。（粗翻，不對(duì)請(qǐng)指出）

https://developer.android.com/studio/profile/investigate-ram.html?

觀察所有的內(nèi)存分配

為了更深入的研究，你需要下面這個(gè)指令來(lái)觀察，你app的內(nèi)存在不同類型的RAM分配之下是如何分開使用的：

adb shell dumpsys meminfo[-d]

加入-d 標(biāo)識(shí)可以打印更多關(guān)于Dalvik 和 ART的內(nèi)存使用信息。

這條命令的輸出展示了app所有當(dāng)前的內(nèi)存分配，kb為單位。

當(dāng)查看這些信息時(shí)，你需要知道下面幾種分配類型：（之所以把英文也貼到文章結(jié)尾，是因?yàn)槊菜七@一塊貌似更新過(guò)，幾個(gè)月之前我看的分配類型好像不是這些，貼出英文，怕后期google有更新，好有一個(gè)對(duì)比）

私有RAM(分為Clean和Dirty)

這一部分內(nèi)存是被你的進(jìn)程獨(dú)占的。當(dāng)你的app進(jìn)程銷毀，這部分內(nèi)存絕大多數(shù)會(huì)被系統(tǒng)收回。通常，私有RAM里面最重要的部分是私有dirty RAM,因?yàn)樗粌H由你的進(jìn)程獨(dú)占，同時(shí)其所有內(nèi)容也只能在RAM里面，不能被分頁(yè)存入外存（因?yàn)閍ndroid沒有虛擬內(nèi)存？），所以他尤其珍貴。所有Dalvik和native heap使用的內(nèi)存都是私有dirty RAM 。你和Zygote 進(jìn)程共享的Dalvik與native內(nèi)存屬于 共享dirty RAM。

個(gè)人理解:內(nèi)存分

Private RAM (Dirty :上面已講 Clean:不明？)

Shared RAM（Dirty：上面已講 Clean:不明？）

PSS-實(shí)際使用的物理內(nèi)存（比例分配共享庫(kù)占用的內(nèi)存）

這是一種把你的app所有有共享部分的進(jìn)程內(nèi)存也計(jì)算在內(nèi)的測(cè)量手段。所有你的進(jìn)程獨(dú)占的RAM內(nèi)存首先會(huì)直接計(jì)入PSS,然后與其他進(jìn)程共享的內(nèi)存會(huì)只計(jì)算共享的那一部分。例如，一塊內(nèi)存被2個(gè)進(jìn)程共享，就會(huì)把這塊內(nèi)存的一半分別算入兩個(gè)進(jìn)程的PSS 里面去。

PSS這一測(cè)量規(guī)則的一個(gè)好處是你可以把所有的內(nèi)存的PSS加在一起，就可以看到所有進(jìn)程的實(shí)際使用總內(nèi)存。這意味著PSS是一個(gè)很好的,測(cè)量一個(gè)進(jìn)程實(shí)際使用內(nèi)存的方法，同時(shí)也很方便與其他進(jìn)程的內(nèi)存使用量進(jìn)行對(duì)比，而且方便計(jì)算總的可用內(nèi)存。 例如：... （見鏈接圖表）

通常，只需要關(guān)心 Pss Total和 Private Dirty 這兩列，在一些例子中，Private Clean和Heap Alloc 列也有一些有趣的數(shù)據(jù)。為了觀察更多的內(nèi)存分配信息，你需要關(guān)注下面的數(shù)據(jù):

Dalvik Heap:

Dalvik虛擬機(jī)所使用的那一部分RAM. PSS Total包含所有Zygote分配的內(nèi)存（按所有共享進(jìn)程的占比計(jì)入，上文對(duì)PSS的定義已經(jīng)說(shuō)過(guò)）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.(有些沒看懂，Private Dirty是 真實(shí)的RAM內(nèi)存，只屬于app堆中，當(dāng)app進(jìn)程從zygote進(jìn)程fork出來(lái)后，app所分配的和zygote所分配的內(nèi)存就會(huì)發(fā)生改變？)

.so mmapand.dex mmap:

.oat mmap:

... Please stay tuned

View overall memory allocations

For further analysis, you might want to observe how your app's memory is divided between different types of RAM allocation with the followingadbcommand:

adb shell dumpsys meminfo [-d]

The -d flag prints more info related to Dalvik and ART memory usage.

The output lists all of your app's current allocations, measured in kilobytes.

When inspecting this information, you should be familiar with the following types of allocation:

Private (Clean and Dirty) 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 isprivate dirtyRAM, 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.

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.

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.

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.

adb shell dumpsys meminfo com.google.android.apps.maps -d

Note:The information you see might vary slightly from what is shown here, because 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

In general, be concerned with only thePss TotalandPrivate Dirtycolumns. In some cases, thePrivate CleanandHeap Alloccolumns also offer interesting data. More information about the different memory allocations (the rows) you should observe follows:

Dalvik Heap

The RAM used by Dalvik allocations in your app. ThePss Totalincludes all Zygote allocations (weighted by their sharing across processes, as described in the PSS definition above). ThePrivate Dirtynumber 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 theDalvik Othersection, thePss TotalandPrivate 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 underDalvik.

TheHeap Allocis the amount of memory that the Dalvik and native heap allocators keep track of for your app. This value is larger thanPss TotalandPrivate Dirtybecause your process was forked from Zygote and it includes allocations that your process shares with all the others.

.so mmapand.dex mmap

The RAM being used for mapped.so(native) and.dex(Dalvik or ART) code. ThePss Totalnumber includes platform code shared across apps; thePrivate Cleanis 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

This is the amount of RAM used by the code image which is based off of the preloaded classes which are commonly used by multiple apps. This image is shared across all apps and is unaffected by particular apps.

.art mmap

This is the amount of RAM used by the heap image which is based off of the preloaded classes which are commonly used by multiple apps. This image is shared across all apps and is unaffected by particular apps. Even though the ART image containsObjectinstances, it does not count towards your heap size.

.Heap(only with -d flag)

This is the amount of heap memory for your app. This excludes objects in the image and large object spaces, but includes the zygote space and non-moving space.

.LOS(only with -d flag)

This is the amount of RAM used by the ART large object space. This includes zygote large objects. Large objects are all primitive array allocations larger than 12KB.

.GC(only with -d flag)

This is the amount of internal GC accounting overhead for your app. There is not really any way to reduce this overhead.

.JITCache(only with -d flag)

This is the amount of memory used by the JIT data and code caches. Typically, this is zero since all of the apps will be compiled at installed time.

.Zygote(only with -d flag)

This is the amount of memory used by the zygote space. The zygote space is created during device startup and is never allocated into.

.NonMoving(only with -d flag)

This is the amount of RAM used by the ART non-moving space. The non-moving space contains special non-movable objects such as fields and methods. You can reduce this section by using fewer fields and methods in your app.

.IndirectRef(only with -d flag)

This is the amount of RAM used by the ART indirect reference tables. Usually this amount is small, but if it is too high, it might be possible to reduce it by reducing the number of local and global JNI references used.

Unknown

Any RAM pages that the system could not classify into one of the other more specific items. Currently, this contains mostly native allocations, which cannot be identified by the tool when collecting this data due to Address Space Layout Randomization (ASLR). Like the Dalvik heap, thePss Totalfor Unknown takes into account sharing with Zygote, andPrivate Dirtyis unknown RAM dedicated to only your app.

TOTAL

The total Proportional Set Size (PSS) RAM used by your process. This is the sum of all PSS fields above it. It indicates the overall memory weight of your process, which can be directly compared with other processes and the total available RAM.

ThePrivate DirtyandPrivate Cleanare the total allocations within your process, which are not shared with other processes. Together (especiallyPrivate 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.

ViewRootImpl

The number of root views that are active in your process. Each root view is associated with a window, so this can help you identify memory leaks involving dialogs or other windows.

AppContextsandActivities

The number of appContextandActivityobjects that currently live in your process. This can help you to quickly identify leakedActivityobjects that can’t be garbage collected due to static references on them, which is common. These objects often have many other allocations associated with them, which makes them a good way to track large memory leaks.

Note:AVieworDrawableobject also holds a reference to theActivitythat it's from, so holding aVieworDrawableobject can also lead to your app leaking anActivity.

Trigger memory leaks

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.

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 anActivity,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 themonkeytest framework. For more information on running the monkey test framework, read themonkeyrunnerdocumentation.