dalvik内存 native内存_dalvik java内存和native内存 - CSDN
  • 1. Dalvik内存 每一个Android应用在底层都会对应一个独立的Dalvik虚拟机实例,其代码在虚拟机的解释下得以执行。 很多人认为Dalvik虚拟机是一个Java虚拟机,因为Android的编程语言恰恰就是Java语言。但是...

    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


    展开全文
  • 1、dalvik的Heap和Stack这里说的只是dalvik java部分的内存,实际上除了dalvik部分,还有native。这个以后再说。下面针对上面列出的数据类型进行说明,只有了解了我们申请的数据在哪里,才能更好掌控我们自己的程序...

    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问题,以及内存优化方法。


    展开全文
  • Android内存管理详细介绍 时间 2013-05-13 16:06:32 CSDN博客 原文  http://blog.csdn.net/gemmem/article/details/8920039 主题 Java 安卓开发 尊重原创作者,转载请注明出处: ...

    Android内存管理详细介绍

    尊重原创作者,转载请注明出处:

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

    最近在网上看了不少Android内存管理方面的博文,但是文章大多都是就单个方面去介绍内存管理,没有能全局把握,缺乏系统性阐述,而且有些观点有误,仅仅知道这些,还是无法从整体上理解内存管理,对培养系统优化和系统稳定性分析方面的能力是不够的。

        我结合自己的一些思考和理解,从宏观层面上,对内存管理做一个全局性的介绍,在此与大家交流分享。

    首先,回顾一下基础知识,基础知识是理解系统机制的前提和关键:

    1、  进程的地址空间

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

    示意图如下:

     

    图1

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

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

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

    2、 进程内存空间和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中进程的堆内存

    RAM作为进程运行不可或缺的资源,对Android系统性能和稳定性有着决定性影响,RAM的一部分被操作系统留作他用,比如显存等等,当然这个程序员无法干预,我们也不必过多地关注它。图1和图4分别介绍了native process和javaprocess的结构,这个是我们程序员需要深刻理解的,进程空间中的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。

    展开全文
  • 应用的限制大小以前16M到24M再到32M。 adb shell dumpsys meminfo 包名或pid 例如 adb shell dumpsys meminfo com.tencent.qqpimsecure

    应用的限制大小以前16M到24M再到32M。

    adb shell dumpsys meminfo 包名或pid

    例如

    adb shell dumpsys meminfo com.tencent.qqpimsecure

    展开全文
  • 后来通过DDMS观察发现,是某一个模块一直内存泄漏使得内存接近上限,导致一些大图(需要的内存比较大)申请内存失败,一直加载不出来。为什么会出现这种状况呢?   通过getprop拿到两个手机上dalvik虚拟机的参数...
  • Android Bitmap的内存分配是在Dalvik Heap而不是Native Heap最近一直在查内存泄露问题,发现Bitmap是最容易出现内存泄露的,然后查看源码以及资料一下颠覆了我的认知观,首先以上结论是建立在Android2.3以后的版本。...
  • Dalvik虚拟机的内存分为三种类型: Java Object Heap, Bitmap Memory, Native Heap. 下面,就这三种类型进行详细讲解: 一. Java Object Heap: Java Object Heap是用来分配Java对象的,代码中new出来的Java...
  • GT工具内存测试详解

    2018-01-19 10:58:58
    GT一款可以对APP进行测试的软件,可以在任何情况下快速测试手机app的CPU、内存、流量、电量、帧率/流畅度等性能测试。有安卓版本和ios版本。... android程序内存被分为2部分:nativedalviknative + d
  • adb shell top 命令中 从以上打印可以看出,一般来说内存占用大小有如下规律:VSS >= RSS >= PSS >=...RSS - Resident Set Size 实际使用物理内存(包含共享库占用的内存)是单个进程实际占用的内存大小,对于单个
  •  项目开发中遇到一个内存溢出问题,抓内存数据分析,发现有的bitmap在java层生成,占用的Dalvik虚拟机堆栈,这也符合我当前粗略的认知,恕本人知识浅陋。原来研究内存,一直认为Android2.2之后的各个版本Android中...
  • 测试Android native malloc实际内存分配的体现 代码 buttno点击一次调用一次分配 extern "C" JNIEXPORT void JNICALL Java_com_albertsnow_graphicdemo_SecondActivity_mallocInt( JNIEnv *env, ...
  • 内存泄漏并非指内存在物理上的消失,而是应用程序分配某段内存后,由于设计错误,导致在释放该段内存之前就失去了对该段内存的控制,从而造成了内存的浪费。 详情请看wikipedia内存泄漏。 内存不是无穷无尽的,是...
  • 慎不留神,要么内存泄漏,要么内存破坏。虚拟机要解决的问题之一就是帮助应用程序自动分配和释放内存。为了达到这个目的,虚拟机在启动的时候向操作系统申请一大块内存当作对象堆。之后当应用程序创建对象时,虚拟机...
  • 在前面一篇文章中,我们分析了Dalvik...当然,Dalvik虚拟机除了可以执行Java代码之外,还可以执行Native代码,也就是C和C++代码。在本文中,我们就将继续以Zygote进程的启动过程为例,来分析Dalvik虚拟机的运行过程。
  • 2019独角兽企业重金招聘Python工程师标准>>> ...
  • 一、前言 最近在弄脱壳的时候发现有些...其实原理就是基于运行时修改内存中的Dalvik数据,本文就来用一个简单的例子来介绍一下如何在内存中去修改Dalvik指令代码来改变代码本生的运行逻辑。 首先来说一下案例场景:
  • 为保证项目的质量前移,输入法内核测试小组的同学分配到了一个新的任务,就是在andriod平台上监测输入法内核 native 代码的内存使用情况。 为了完成这个任务,我们先将任务拆解成重要的几步: 1. 了解 andriod ...
1 2 3 4 5 ... 20
收藏数 10,674
精华内容 4,269
关键字:

dalvik内存 native内存