2012-09-15 16:53:02 yangxi_001 阅读数 4225

1.   Dalvik内存

每一个Android应用在底层都会对应一个独立的Dalvik虚拟机实例,其代码在虚拟机的解释下得以执行。

很多人认为Dalvik虚拟机是一个Java虚拟机,因为Android的编程语言恰恰就是Java语言。但是这种说法并不准确,因为 Dalvik虚拟机并不是按照Java虚拟机的规范来实现的,两者并不兼容;

同时还要两个明显的不同:

  1.Java虚拟机运行的是Java字节码,而Dalvik虚拟机运行的则是其专有的文件格式DEX(Dalvik Executable)。

2.在Java SE程序中的Java类会被编译成一个或者多个字节码文件(.class)然后打包到JAR文件,而后Java虚拟机会从相应的CLASS文件和JAR文件中获取相应的字节码;Android应用虽然也是使用Java语言进行编程,但是在编译成CLASS文件后,还会通过一个工具(dx)将应用所有的 CLASS文件转换成一个DEX文件,而后Dalvik虚拟机会从其中读取指令和数据。

Dalvik虚拟机的简介:

Dalvik虚拟机主要是完成对象生命周期的管理,堆栈的管理,线程管理,安全和异常的管理,以及垃圾回收等等重要功能。

Dalvik虚拟机的主要特征Dalvik虚拟机非常适合在移动终端上使用,相对于在桌面系统和服务器系统运行的虚拟机而言,它不需要很快的CPU速度和大量的内存空间。

Dalvik虚拟机有如下几个主要特征:

1.专有的DEX文件格式

DEXDalvik虚拟机专用的文件格式,而问什么弃用已有的字节码文件(CLASS文件)而采用新的格式呢?一个应用中会定义很多类,编译完成后即会有很多相应的CLASS文件,CLASS文件间会有不少冗余的信息;而DEX文件格式会把所有的 CLASS文件内容整合到一个文件中。这样,除了减少整体的文件尺寸,I/O操作,也提高了类的查找速度。

2.增加了新的操作码的支

3.文件结构尽量简洁,使用等长的指令,借以提高解析速度

4.尽量扩大只读结构的大小,借以提高跨进程的数据共享

2.   Native内存

如何修改Android应用程序的默认最大内存值

Android应用程序的默认最大内存值为16M,有些应用程序可能会出现内存溢出,譬如ERROR/AndroidRuntime(264):java.lang.OutOfMemoryError: bitmap size exceeds VM budget

除了要检查修正代码之外,还可以考虑修改Android应用程序的默认最大内存值。

修改应用程序的默认最大内存有2种方法:

1、修改代码,适用于自己编译烧机:

当应用程序分配内存时,会调用到dalvik/vm/alloc/HeapSource.c中的dvmTrackExternalAllocation()方法,继而调用到externalAllocPossible()方法,该方法要求当前堆已使用的大小(由currentHeapSize和hs->externalBytesAllocated构成)加上我们需要再次分配的内存大小不能超过堆的最大内存值,如果超过就会报错。 

有两个地方决定了一个堆的最大内存: 

1)dalvik/vm/Init.c中的 

gDvm.heapSizeMax = 16 * 1024 * 1024;    // Spec says 75%physical mem 

2)frameworks/base/core/jni/AndroidRuntime.cpp中的 

property_get("dalvik.vm.heapsize", heapsizeOptsBuf+4,"16m"); 

因此解决办法就是将以上2点中默认的16M改大一点,譬如32M。

2、修改配置文件,适用于烧机后的版本。

修改或添加/system/build.prop中的配置项:

dalvik.vm.heapstartsize=20m

dalvik.vm.heapgrowthlimit=200m

dalvik.vm.heapsize=320m


2013-06-04 14:03:12 wangchun8926 阅读数 3151

进入命令行界面,然后cd到%ANDORID_HOME%/platform-tools,然后输入adb shell dumpsys meminfo 应用包名即可得到下列结果:

Android应用程序的内存分配包括dalvik和native,Android中的每一个app都运行在一个dalvik虚拟机进程中,故对于bimap这一类的大对象而言,应用程序GC默认只会清理dalvik上分配的内存(即堆内存).对于native分配的内存,需要手动调用recycle来进行回收

对于上图,当TOTAL项超过最大内存限制后,就会发生OOM Error!

2018-05-09 14:54:43 qq_34413557 阅读数 600

1、dalvik的Heap和Stack

这里说的只是dalvik  java部分的内存,实际上除了dalvik部分,还有native。这个以后再说。

下面针对上面列出的数据类型进行说明,只有了解了我们申请的数据在哪里,才能更好掌控我们自己的程序。

2、对象实例数据

实际上是保存对象实例的属性,属性的类型和对象本身的类型标记等,但是不保存实例的方法。实例的方法是属于数据指令,是保存在Stack里面,也就是上面表格里面的类方法。

对象实例在Heap中分配好以后,会在stack中保存一个4字节的Heap内存地址,用来查找对象的实例。因为在Stack里面会用到Heap的实例,特别是调用实例的时候需要传入一个this指针。

3、方法内部变量

类方法的内部变量分为两种情况:简单类型保存在Stack中;对象类型在Stack中保存地址,在Heap 中保存值。

4、非静态方法和静态方法

非静态方法有一个隐含的传入参数,这个参数是dalvik虚拟机传进去的,这个隐含参数就是对象实例在Stack中的地址指针。因此非静态方法(在Stack中的指令代码)总是可以找到自己的专用数据(在Heap 中的对象属性值)。当然非静态方法也必须获得该隐含参数,因此非静态方法在调用前,必须先new一个对象实例,获得Stack中的地址指针,否则dalvik虚拟机将无法将隐含参数传给非静态方法。

静态方法没有隐含参数,因此也不需要new对象,只要class文件被ClassLoader load进入JVM的Stack,该静态方法即可被调用。所以我们可以直接使用类名调用类的方法。当然此时静态方法是存取不到Heap 中的对象属性的。

5、静态属性和动态属性

静态属性是保存在Stack中的,而不同于动态属性保存在Heap 中。正因为都是在Stack中,而Stack中指令和数据都是定长的,因此很容易算出偏移量,所以类方法(静态和非静态)都可以访问到类的静态属性。也正因为静态属性被保存在Stack中,所以具有了全局属性。

6、总结

Java的堆是一个运行时数据区,类的(对象从中分配空间。这些对象通过new、newarray、anewarray和multianewarray等指令建立,它们不需要程序代码来显式的释放。堆是由垃圾回收来负责的,堆的优势是可以动态地分配内存大小,生存期也不必事先告诉编译器,因为它是在运行时动态分配内存的,Java的垃圾收集器会自动收走这些不再使用的数据。但缺点是,由于要在运行时动态分配内存,存取速度较慢。

栈的优势是,存取速度比堆要快,仅次于寄存器,栈数据可以共享。但缺点是,存在栈中的数据大小与生存期必须是确定的,缺乏灵活性。栈中主要存放一些基本类型的变量(,int, short, long, byte, float, double, boolean, char)和对象句柄。

对比上面的解析可以看出,其实Java处理Heap和Stack的大致原理跟C++是一样的。只是多了一个内存回收机制,让程序员不用主动调用delete释放内存。就像在C++里面,一般使用new申请的内存才会放到堆里面,而一般的临时变量都是放到栈里面去。



1、APP默认分配内存大小

在Android里,程序内存被分为2部分:native和dalvik,dalvik就是我们普通的java使用内存,也就是我们上一篇文章分析堆栈的时候使用的内存。我们创建的对象是在这里面分配的,对于内存的限制是 native+dalvik 不能超过最大限制。android程序内存一般限制在16M,也有的是24M(早期的Android系统G1,就是只有16M)。具体看定制系统的设置,在Linux初始化代码里面Init.c,可以查到到默认的内存大小。有兴趣的朋友,可以分析一下虚拟机启动相关代码。这块比较深入,目前我也没时间去分析,后面有空会去钻研一下。

  1. gDvm.heapSizeStart = 2 * 1024 * 1024;   // heap初始化大小为2M 
  2. gDvm.heapSizeMax = 16 * 1024 * 1024;    // 最大的heap为16M 

2、Android的GC如何回收内存

Android的一个应用程序的内存泄露对别的应用程序影响不大。为了能够使得Android应用程序安全且快速的运行,Android的每个应用程序都会使用一个专有的Dalvik虚拟机实例来运行,它是由Zygote服务进程孵化出来的,也就是说每个应用程序都是在属于自己的进程中运行的。Android为不同类型的进程分配了不同的内存使用上限,如果程序在运行过程中出现了内存泄漏的而造成应用进程使用的内存超过了这个上限,则会被系统视为内存泄漏,从而被kill掉,这使得仅仅自己的进程被kill掉,而不会影响其他进程(如果是system_process等系统进程出问题的话,则会引起系统重启)。

做应用开发的时候,你需要了解系统的GC(垃圾回收)机制是如何运行的,Android里面使用有向图作为遍历回收内存的机制。对象不再被引用,可以被GC回收。

因此对于我们已经不需要使用的对象,我们可以把它设置为null,这样当GC运行的时候,就好遍历到你这个对象已经没有引用,会自动把该对象占用的内存回收。我们没法像C++那样马上释放不需要的内存,但是我们可以主动告诉系统,哪些内存可以回收了。

3、查看应用内存使用情况

下面我们看看如何在开发过程中查看我们程序运行时内存使用情况。我们可以通过ADB的一个命令查看:

  1. //$package_name:应用包名 
  2. //$pid:应用进程ID,可以用PS命令查看 
  3. adb shell dumpsys meminfo $package_name or $pid 

上面是我使用包名查看Gallery例子的内存使用情况图,里面信息很多,不过我们主要关注的是native和Davilk的使用情况。(Android2.X和Android4.X查看的信息排序是不一样的,内容差不多,不过排布有差异,我上面是4.0的截图)

Android底层内核是基于Linux的,而Linux里面相对Window来说,有一点很特别的是,会尽量使用系统内存加载一些缓存数据或者进程间共享数据。Linux本着不用白不用的原则,会尽量使用系统内存,加快我们应用的运行速度。当然,如果我们期待某个需要大内存的应用,系统也能马上释放出一定的内存使用,这是系统内部调度实现。因此严格来说,我们要准备计算Linux下某个进程内存大小比较困难。 因为有paging out to disk(换页),所以如果你把所有映射到进程的内存相加,它可能大于你的内存的实际物理大小。

  • dalvik:是指dalvik所使用的内存。
  • native:是被native堆使用的内存。应该指使用C\C++在堆上分配的内存。
  • other:是指除dalvik和native使用的内存。但是具体是指什么呢?至少包括在C\C++分配的非堆内存,比如分配在栈上的内存。puzlle!
  • Pss:它是把共享内存根据一定比例分摊到共享它的各个进程来计算所得到进程使用内存。网上又说是比例分配共享库占用的内存,也就是上面所说的进程共享问题。
  • PrivateDirty:它是指非共享的,又不能换页出去(can not be paged to disk )的内存的大小。比如Linux为了提高分配内存速度而缓冲的小对象,即使你的进程结束,该内存也不会释放掉,它只是又重新回到缓冲中而已。
  • SharedDirty:参照PrivateDirty我认为它应该是指共享的,又不能换页出去(can not be paged to disk )的内存的大小。比如Linux为了提高分配内存速度而缓冲的小对象,即使所有共享它的进程结束,该内存也不会释放掉,它只是又重新回到缓冲中而已。

上面针对meminfo里面的信息给出解析,这些很多我是参考了网上一些文章,所以如果有理解不到位的,欢迎各位指出。

4、程序中获取内存信息

通过ActivityManager获取相关信息,下面是一个例子代码:

  1. private void displayBriefMemory()  
  2. {     
  3.     final ActivityManager activityManager = (ActivityManager) getSystemService(ACTIVITY_SERVICE);     
  4.     ActivityManager.MemoryInfo info = new ActivityManager.MemoryInfo();    
  5.     activityManager.getMemoryInfo(info);     
  6.   
  7.     Log.i(tag,"系统剩余内存:"+(info.availMem >> 10)+"k");    
  8.     Log.i(tag,"系统是否处于低内存运行:"+info.lowMemory); 
  9.     Log.i(tag,"当系统剩余内存低于"+info.threshold+"时就看成低内存运行"); 

另外通过Debug的getMemoryInfo(Debug.MemoryInfo memoryInfo)可以得到更加详细的信息。跟我们在ADB Shell看到的信息一样比较详细。

5、总结

今天主要是分析了如何获取我们应用的内存使用情况信息,关于这方面的信息,其实还有其他一些方法。另外还介绍APP应用的默认内存已经Android的GC回收,不过上面只是很浅薄地分析了一下,让大家有个印象。这些东西真要深入分析得花不少精力。因为我们的目的只是解决OOM问题,所以目前没打算深入分析,后面有时间进行Android系统分析的时候,我们再深入分析。下一次我们用以前写的Gallery例子讲解如何避免OOM问题,以及内存优化方法。


2014-10-28 14:34:08 u013425527 阅读数 1441
开发图片视频应用常遇到这个错误。

android 内存由 dalvik 和 native 2部分组成,dalvik 也就是 java 堆,创建的对象就是在这里分配的,

而 native 是通过 c/c++ 方式申请的内存,

Bitmap 就是以一种方式分配的(android3.0 以后,系统默认是通过 dalvik 分配的)。当然无论以何种方式分

配,2部分加起来不能超过 android 对单个程序的内存限制。



1.一个进程的内存可以由2个部分组成:java 使用内存 ,C 使用内存 ,这两个内存的和必须小于16M,不然就会出现大

家熟悉的OOM,这个就是第一种OOM的情况。

2.更加奇怪的是这个:一旦内存分配给Java后,以后这块内存即使释放后,也只能给Java的使用,这个估计跟java虚拟

机里把内存分成好几块进行缓存的原因有关,反正C就别想用到这块的内存了,所以如果Java突然占用了一个大块内

存,即使很快释放了:

C能使用的内存 = 16M - Java某一瞬间占用的最大内存。

而Bitmap的生成是通过malloc进行内存分配的,占用的是C的内存,MBitmap无法生成的原

因,因为Java用的内存太多,剩下C能用的内存太少了。
没有更多推荐了,返回首页