进程内存Android进程的内存管理分析

最近应用开发的过程中涌现了一个小问题，顺便记录一下原因和方法--进程内存

    尊敬原创作者，转载请注明出处：

    http://blog.csdn.net/gemmem/article/details/8920039

    

    最近在网上看了不少Android内存管理方面的博文，但是文章大多都是就单个方面去分析内存管理，没有能全局掌控，缺乏系统性阐述，而且有些观点有误。

    这样对Android内存管理停止局部性分析，很难使读者建立系统性概念，没法真正懂得内存管理，对提高系统优化和系统稳定性分析方面的能力是不敷的。

    我结合自己的一些思考和懂得，从微观层面上，对内存管理做一个全局性的分析，在此与大家交流分享。

    

    首先，回想一下基础知识，基础知识是懂得系统机制的前提和关键：

    1、  进程的地址空间

    在32位操纵系统中，进程的地址空间为0到4GB，

    示意图如下：

    

    

 

    图1

 

    这里主要说明一下Stack和Heap：

    Stack空间（进栈和出栈）由操纵系统控制，其中主要存储函数地址、函数参数、局部变量等等，所以Stack空间不须要很大，一般为几MB大小。

    Heap空间由程序控制，程序员可以应用malloc、new、free、delete等函数调用来操纵这片地址空间。Heap为程序完成各种复杂任务提供内存空间，所以空间比较大，一般为几百MB到几GB。正是因为Heap空间由程序员管理，所以容易涌现应用不当导致严重问题。

 

    2、进程内存空间和RAM之间的关系

    进程的内存空间只是虚拟内存（或者叫作逻辑内存），而程序的运行须要的是实实在在的内存，即物理内存（RAM）。在必要时，操纵系统会将程序运行中请求的内存（虚拟内存）映射到RAM，让进程能够应用物理内存。

    RAM作为进程运行不可或缺的资源，对系统性能和稳定性有着决定性影响。另外，RAM的一部分被操纵系统留作他用，比如显存等等，内存映射和显存等都是由操纵系统控制，我们也不必过量地关注它，进程所操纵的空间都是虚拟地址空间，没法直接操纵RAM。

    示意图如下：

    

    

    图2

    

    基础知识分析到这里，如果读者懂得以上知识有障碍，请好好恶补一下基础知识，基础理论知识至关重要。 

    

 

    3、  Android中的进程

    （1）   native进程：采取C/C++实现，不包括dalvik实例的进程，/system/bin/目录上面的程序文件运行后都是以native进程形式存在的。如图           3，/system/bin/surfaceflinger、/system/bin/rild、procrank等就是native进程。

 

    （2）   java进程：Android中运行于dalvik虚拟机之上的进程。dalvik虚拟机的宿主进程由fork()系统调用创建，所以每一个java进程都是存在于一个native进程中，因此，java进程的内存分配比native进程复杂，因为进程中存在一个虚拟机实例。如图3，Android系统中的应用程序基本都是java进程，如桌面、电话、联系人、状态栏等等。

    

    

    

    图3

 

 

    4、  Android中进程的堆内存

    图1和图4分别分析了native process和java process的结构，这个是我们程序员须要深刻懂得的，进程空间中的heap空间是我们须要重点关注的。heap空间完全由程序员控制，我们应用的malloc、C++ new和java new所请求的空间都是heap空间， C/C++请求的内存空间在native heap中，而java请求的内存空间则在dalvik heap中。

    

    

    

    图4

 

    5、  Android的 java程序为什么容易涌现OOM

    这个是因为Android系统对dalvik的vm heapsize作了硬性限制，当java进程请求的java空间超越阈值时，就会抛出OOM异常（这个阈值可以是48M、24M、16M等，视机型而定），可以通过adb shell getprop | grep dalvik.vm.heapsize查看此值。

    也就是说，程序发生OMM并不表示RAM不足，而是因为程序请求的java heap对象超越了dalvik vm heapsize。也就是说，在RAM充分的情况下，也可能发生OOM。

    这样的计划仿佛有些不合理，但是Google为什么这样做呢？这样计划的目的是为了让Android系统能同时让比较多的进程常驻内存，这样程序启动时就不必每次都重新加载到内存，能够给用户更快的响应。迫使每一个应用程序应用较小的内存，移动设备非常有限的RAM就能使比较多的app常驻其中。但是有一些大型应用程序是没法忍受vm heapsize的限制的，后面会分析如何让自己的程序跳出vm heap size的限制。

 

    6、  Android如何应答RAM不足

    在第5点中提到：java程序发生OMM并不是表示RAM不足，如果RAM真的不足，会发生什么呢？这时Android的memory killer会起作用，当RAM所剩不多时，memory killer会杀死一些优先级比较低的进程来释放物理内存，让高优先级程序得到更多的内存。我们在分析log时，看到的进程被杀的log，如图5，往往就是属于这种情况。

    

    

    

    图5

    7、  如何查看RAM应用情况

    可以应用adb shell cat /proc/meminfo查看RAM应用情况：

    MemTotal:        396708 kB

    MemFree:           4088 kB

    Buffers:           5212 kB

    Cached:          211164 kB

    SwapCached:           0 kB

    Active:          165984 kB

    Inactive:        193084 kB

    Active(anon):    145444 kB

    Inactive(anon):     248 kB

    Active(file):     20540 kB

    Inactive(file):  192836 kB

    Unevictable:       2716 kB

    Mlocked:              0 kB

    HighTotal:            0 kB

    HighFree:             0 kB

    LowTotal:        396708 kB

    LowFree:           4088 kB

    SwapTotal:            0 kB

    SwapFree:             0 kB

    Dirty:                0 kB

    Writeback:            0 kB

    AnonPages:       145424 kB

    ……

    ……

    这里对其中的一些字段停止解释：

    MemTotal：可以应用的RAM总和（小于实际RAM，操纵系统预留了一部分）

    MemFree：未应用的RAM

    Cached：缓存（这个也是app可以请求到的内存）

    HightTotal：RAM中地址高于860M的物理内存总和，只能被用户空间的程序应用。

    HightFree：RAM中地址高于860M的未应用内存

    LowTotal：RAM中内核和用户空间程序都可以应用的内存总和（对于512M的RAM: lowTotal= MemTotal）

    LowFree: RAM中内核和用户空间程序未应用的内存（对于512M的RAM: lowFree = MemFree）

 

    8、  如何查看进程的内存信息

    (1)、应用adb shell dumpsys meminfo + packagename/pid:

    从图6可以看出，com.example.demo作为java进程有2个heap，native heap和dalvik heap，

    native heap size为159508KB，dalvik heap size为46147KB

    

    

 

    图6 

 

 

    （2）、应用adb shell procrank查看进程内存信息

        如图7：

    

    

    图7

 

    解释一些字段的意思：

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

    RSS- Resident Set Size 实际应用物理内存（包括同享库占用的内存）

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

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

    一般来说内存占用大小有如下法则：VSS >= RSS >= PSS >= USS

 

    注意：procrank可以查看native进程和java进程，而dumpsys meminfo只能查看java进程。

    每日一道理 
共和国迎来了她五十诞辰。五十年像一条长河，有急流也有缓流；五十年像一幅长卷，有冷色也有暖色；五十年像一首乐曲，有低音也有高音；五十年像一部史诗，有痛苦也有欢乐。长河永远奔流，画卷刚刚展开，乐曲渐趋高潮，史诗还在续写。我们的共和国正迈着坚定的步伐，跨入新时代。

 

    9、  应用程序如何绕过dalvikvm heapsize的限制

    对于一些大型的应用程序（比如游戏），内存应用会比较多，很容易超超出vm heapsize的限制，这时怎么保证程序不会因为OOM而崩溃呢？

    （1）、创建子进程

               创建一个新的进程，那么我们就可以把一些对象分配到新进程的heap上了，从而达到一个应用程序应用更多的内存的目的，当然，创建子进程会增长系统开销，而且并不是全部应用程序都合适这样做，视需求而定。

    创建子进程的方法：应用android:process标签

    （2）、应用jni在native heap上请求空间（推荐应用）

      nativeheap的增长并不受dalvik vm heapsize的限制，从图6可以看出这一点，它的native heap size已经远远超越了dalvik heap size的限制。

    只要RAM有剩余空间，程序员可以一直在native heap上请求空间，当然如果 RAM快耗尽，memory killer会杀进程释放RAM。大家应用一些软件时，有时候会闪退，就多是软件在native层请求了比较多的内存导致的。比如，我就碰到过UC web在浏览内容比较多的网页时闪退，原因就是其native heap增长到比较大的值，占用了大批的RAM，被memory killer杀掉了。

    （3）、应用显存（操纵系统预留RAM的一部分作为显存）

    应用OpenGL textures等API，texture memory不受dalvik vm heapsize限制，这个我没有实际过。再比如Android中的GraphicBufferAllocator请求的内存就是显存。

     

    10、Bitmap分配在native heap还是dalvik heap上？

    一种风行的观点是这样的：

    Bitmap是jni层创建的，所以它应该是分配到native heap上，并且为了解释bitmap容易导致OOM，提出了这样的观点：

              native heap size + dalvik heapsize <= dalvik vm heapsize

    详情请看：http://devspirit.blog.163.com/blog/static/16425531520104199512427/

 

    但是请大家看看图6，native heap size为159508KB，远远超越dalvik vm heapsize，所以，事实证明以上观点是不正确的。

 

    正确的观点：

    大家都晓得，过量地创建bitmap会导致OOM异常，且native heapsize不受dalvik限制，所以可以得出结论：

    Bitmap只能是分配在dalvik heap上的，因为只有这样才能解释bitmap容易导致OOM。

 

    但是，有人可能会说，Bitmap确实是应用java native方法创建的啊，为什么会分配到dalvik heap中呢？为了解决这个疑难，我们还是分析一下源码：

    触及的文件：

framework/base/graphic/java/Android/graphics/BitmapFactory.java framework/base/core/jni/Android/graphics/BitmapFactory.cpp framework/base/core/jni/Android/graphics/Graphics.cpp

    BitmapFactory.java里头有几个decode***方法用来创建bitmap，终究都市调用：

    private staticnative Bitmap nativeDecodeStream(InputStream is, byte[] storage,Rect padding,Options opts);

    而nativeDecodeStream()会调用到BitmapFactory.cpp中的deDecode方法，终究会调用到Graphics.cpp的createBitmap方法。

 

    我们来看看createBitmap方法的实现：

jobjectGraphicsJNI::createBitmap(JNIEnv* env, SkBitmap* bitmap, jbyteArray buffer, boolisMutable, jbyteArray ninepatch, int density) { SkASSERT(bitmap); SkASSERT(bitmap->pixelRef()); jobject obj = env->NewObject(gBitmap_class, gBitmap_constructorMethodID, static_cast<jint>(reinterpret_cast<uintptr_t>(bitmap)), buffer, isMutable, ninepatch,density); hasException(env); // For the side effectof logging. return obj; }

 

    从代码中可以看到bitmap对象是通过env->NewOject( )创建的，到这里困惑就解开了，bitmap对象是虚拟机创建的，JNIEnv的NewOject方法返回的是java对象，并不是native对象，所以它会分配到dalvik heap中。

 

    11、java程序如何才能创建native对象

    必须应用jni，而且应该用C语言的malloc或者C++的new关键字。实例代码如下：

JNIEXPORT void JNICALLJava_com_example_demo_TestMemory_nativeMalloc(JNIEnv *, jobject) { void * p= malloc(1024*1024*50); SLOGD("allocate50M Bytes memory"); if (p !=NULL) { //memorywill not used without calling memset() memset(p,0, 1024*1024*50); } else SLOGE("mallocfailure."); …. …. free(p); //free memory }

    或者:

JNIEXPORT voidJNICALL Java_com_example_demo_TestMemory_nativeMalloc(JNIEnv *, jobject) { SLOGD("allocate 50M Bytesmemory"); char *p = new char[1024 * 1024 * 50]; if (p != NULL) { //memory will not usedwithout calling memset() memset(p, 1, 1024*1024*50); } else SLOGE("newobject failure."); …. …. free(p); //free memory }

    这里对代码中的memset做一点说明：

       new或者malloc请求的内存是虚拟内存，请求以后不会立即映射到物理内存，即不会占用RAM，只有调用memset应用内存后，虚拟内存才会真正映射到RAM。

    

    本文旨在让大家对Android内存管理有一个整体性的意识，侧重全局性懂得，希望对大家有效。