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.heapgrowthlimit查看此值。

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

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

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

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

正确的观点：

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

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

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

涉及的文件：

[java] view plaincopyprint?

  1. framework/base/graphic/java/Android/graphics/BitmapFactory.java
  2. framework/base/core/jni/Android/graphics/BitmapFactory.cpp
  3. framework/base/core/jni/Android/graphics/Graphics.cpp
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方法的实现：

[java] view plaincopyprint?

  1. jobjectGraphicsJNI::createBitmap(JNIEnv* env, SkBitmap* bitmap, jbyteArray buffer,
  2. boolisMutable, jbyteArray ninepatch, int density)
  3. {
  4. SkASSERT(bitmap);
  5. SkASSERT(bitmap->pixelRef());
  6. jobject obj = env->NewObject(gBitmap_class, gBitmap_constructorMethodID,
  7. static_cast<jint>(reinterpret_cast<uintptr_t>(bitmap)),
  8. buffer, isMutable, ninepatch,density);
  9. hasException(env); // For the side effectof logging.
  10. return obj;
  11. }
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关键字。实例代码如下：

[java] view plaincopyprint?

  1. JNIEXPORT void JNICALLJava_com_example_demo_TestMemory_nativeMalloc(JNIEnv *, jobject)
  2. {
  3. void * p= malloc(1024*1024*50);
  4. SLOGD("allocate50M Bytes memory");
  5. if (p !=NULL)
  6. {
  7. //memorywill not used without calling memset()
  8. memset(p,0, 1024*1024*50);
  9. }
  10. else
  11. SLOGE("mallocfailure.");
  12. ….
  13. ….
  14. free(p); //free memory
  15. }
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
}

或者:

[java] view plaincopyprint?

  1. JNIEXPORT voidJNICALL Java_com_example_demo_TestMemory_nativeMalloc(JNIEnv *, jobject)
  2. {
  3. SLOGD("allocate 50M Bytesmemory");
  4. char *p = new char[1024 * 1024 * 50];
  5. if (p != NULL)
  6. {
  7. //memory will not usedwithout calling memset()
  8. memset(p, 1, 1024*1024*50);
  9. }
  10. else
  11. SLOGE("newobject failure.");
  12. ….
  13. ….
  14. free(p); //free memory
  15. }
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。

时间： 2024-08-15 02:29:13

android 内存进程管理分析的相关文章

Android内存进程管理机制

参考文章: http://www.apkbus.com/android-104940-1-1.htmlhttp://blog.sina.com.cn/s/blog_3e3fcadd0100yjo2.html 一.理论: Android采取了一种有别于Linux的进程管理策略,有别于Linux的在进程活动停止后就结束该进程,Android把这些进程都保留在内存中,直到系统需要更多内存为止.这些保留在内存中的进程通常情况下不会影响整体系统的运行速度,并且当用户再次激活这些进程时,提升了进程的启动速度

Android 内存溢出管理与测试

今天发现正在做的项目,时不时的会报错:dalvikvm heap out of memory on a 7458832-byte allocation (堆分配的内存溢出) 为什么会内存溢出呢?我以前从未遇见这种情况.后来在网上查了查资料,还是挺多的. 怎么说呢?因为Android开发基本上是以java语言为基础,那么程序是在java虚拟机上运行的.而虚拟机不允许单个程序中的Bitmap占用超过8M的内存,从报错的日志可以看出:7458832-byte大约就是7M多的样子,基本吻合上述数据.在我

Android内存泄露案例分析

一款优秀的Android应用,不仅要有完善的功能,也要有良好的体验,而性能是影响体验的一个重要因素.内存泄露是Android开发中常见的性能问题.这篇文章,通过我们曾经遇到的一个真实的案例,来讲述一个内存泄露问题,从发现到分析定位,再到最终解决的全过程. 这里把整个过程分为四个阶段: 第一阶段,现场勘查,分析Bug现象,找出有用线索: 第二阶段,初步推断,根据之前的线索,推断可能导致Bug的原因,并且进一步验证推断是否正确: 第三阶段,探究根源,找出导致Bug的真正原因: 第四阶段,解决方案,研

android内存泄漏系列- 分析hprof文件

转载请注明出处 http://www.cnblogs.com/weiwangnuanyang/p/5703702.html ,谢谢. 如果只是想确定一下某一个场景是否有内存泄漏,AndroidStadio的控制台就有一个好工具,反复操作观察曲线是否上扬,如果曲线上扬则说明内存泄漏 但是,上面的工具不够强大,不能看出内存中驻留的具体的类和类的引用关系. 下面就来重点介绍一下,解决android内存泄漏必备利器-Memory Analysis; 具体安装方式请移步度娘. 我们这里重点介绍如何利用Me

把握linux内核设计（八）：进程管理分析

[版权声明:尊重原创,转载请保留出处:blog.csdn.net/shallnet,文章仅供学习交流,请勿用于商业用途] 进程其实就是程序的执行时的实例,是处于执行期的程序.在linux内核中,进程列表被存放在一个双向循环链表中,链表中每一项都是类型为task_struct的结构,该结构称作进程描述符,进程描述符包含一个具体进程的所有信息,这个结构就是我们在操作系统中所说的PCB(Process Control Block).该结构定义于<include/linux/sched.h>文件中:

Android Zygote进程启动分析

dvm,app进程,linux进程三者关系 DVM指 dalivk 的虚拟机.每一个 Android 应用程序都在它自己的进程中运行,都拥有一个独立的 Dalvik 虚拟机实例.而每一个 DVM 都是在 Linux 中的一个进程,所以说可以认为是同一个概念 Zygote进程与app进程关系 Zygote是java层的进程即它也拥有一个独立的Dalvik 虚拟机实例,它是被linux层的第一个用户空间Init进程所启动的,它的主要作用就是用来孵化app进程和系统进程 fork一个app进程,是通过

android 内存溢出问题分析

最近的项目中,内存一直再增长,但是不知道是什么问题,导致内存溢出,在网上看到了这么一篇关于内存分析与管理的文章,解决了部分问题,感觉这篇文 章还不错,就转帖到我的blog上了,希望对大家有所帮助.如果哪里有不好的地方,给留下言,然后我们大家继续完善内存泄露的问题,对大家都会有所帮助 的,呵呵 一.概述 1 二.Android(Java)中常见的容易引起内存泄漏的不良代码 1 (一) 查询数据库没有关闭游标 2 (二) 构造Adapter时,没有使用缓存的 convertView 3 (三) Bi

我的手机管家（2） 进程管理布局

我的手机管家(2)  进程管理 (1)获取进程信息:所有的进程信息, 正在运行的进程信息, 剩余可用内存 (2)获取进程信息是一个耗时的操作, 首先在使用子线程获取进程信息的时候显示缓冲界面,缓冲加载完成后, 通知LIstView展示数据,加载适配器, 同时缓冲结束 获取进程信息的提供者: package com.ejob.phonesafe.provider; import java.io.BufferedReader; import java.io.FileReader; import ja

Android 7.0 ActivityManagerService(8) 进程管理相关流程分析(2)

前一篇博客进程管理相关流程分析(1)里, 我们介绍了AMS中updateLruProcessLocked函数相关的流程. updateLruProcessLocked只是按照进程中运行的组件,粗略地定义了不同进程的优先级. 实际上,Android根据进程的oom_adj进行了更加细致的进程分类, 而AMS中的updateOomAdjLocked函数,就是用于更新进程的oom_adj值. 本篇博客中,我们来看看AMS中updateOomAdjLocked相关的流程. 一.ProcessList.j