dalvik和native_native memory和dalvik memory - CSDN
  • 关于Android的Native内存和Dalvik内存

    千次阅读 2012-09-15 16:53:02
    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


    展开全文
  • 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

    展开全文
  • 我们知道,Java native方法的注册形式有两种,一种是主动注册,一种是默认的被动注册,如果我们希望弄清楚java native方法的调用过程,我们首先就需要搞清楚两种注册方式的实现原理,下面我们先分别看看这两种... ... ...

     

    我们知道,Java native方法的注册形式有两种,一种是主动注册,一种是默认的被动注册,如果我们希望弄清楚java native方法的调用过程,我们首先就需要搞清楚两种注册方式的实现原理,下面我们先分别看看这两种注册方式。

    一、Java native方法的主动注册

    首先说说JNINativeMethod,它是一个结构体,表示了我们需要注册的本地方法,主要是将java方法跟native方法进行了一个对应,也可以理解为一种映射。

    第一个变量name是Java中函数的名字。
    第二个变量signature,表示函数的参数和返回值
    第三个变量fnPtr是函数指针,指向native层的C函数

     

    所以可以看到JNINativeMethod表示的就是java native函数以及其对应的native层的JNI函数。

     

    下面我们来看看具体的注册过程,在进行native方法注册的时候,其实调用的就是JNIEnv的RegisterNatives函数。

    我们在进行java native方法注册的时候,由于一个java类可能包含有多个native方法,所以在注册的时候将需要注册的方法放在一个数组中,上面代码的作用就是遍历这个数组,然后调用dvmRegisterJNIMethod方法来对每个方法进行一一的注册。

    可以看到,JNI方法注册实际上是将Dalivk里面表示方法的Method对象的nativeFunc成员指向bridge函数,如果不打开CheckJni开关的话,bridge函数就是dvmCallJNIMethod,将Method对象的insns成员指向实际的native方法。具体我们可以看看dvmSetNativeFunc函数。

    看到这里我们就可以知道,注册的过程就是将Method的nativeFunc指向dvmCallJNIMethod,将Method的insns成员指向实际的native方法,其实,当java层调用native函数的时候会进入dvmCallJNIMethod函数,而真正的native函数指针则存储在Method->insns中。dvmCallJNIMethod函数会先准备参数,再调用dvmPlatformInvoke执行对应的native方法,也就是method->insns所指向的方法,这样就完成了native函数的调用。

    下面来看看dvmCallJNIMethod方法。

    正如上面所说,dvmCallJNIMethod函数准备完参数之后,就会调用dvmPlatformInvoke来执行具体的native层的JNI方法,也就是method->insns所指向的方法。dvmPlatformInvoke通过libffi进行JNI方法调用,主要为了屏蔽Dalvik虚拟机运行在不同目标平台的细节。下面就不展开了。 

    二、Java native方法的被动注册

    JNI函数也可以不主动注册,而是根据一定的规则进行命名,然后由Dalvik自己去查找对应的native方法。对于这类JNI方法,Dalvik在进行类加载类时会默认将对应的Method对象的nativeFunc成员设置为dvmResolveNativeMethod函数地址。
    前面我们讲过Dalvik虚拟机中Java类的加载过程,但是分析到loadClassFromDex的时候就结束了,并没有展开分析Java类的具体加载过程,下面我们来继续看看loadClassFromDex方法。

     

    上面的代码中,我们重点关注java类方法的加载过程,下面看看loadMethodFromDex方法。

    从上面代码可以看到,在dalvik中,当加载类并解析其中的函数时,如果标记为native函数,则会把Method->nativeFunc设置为dvmResolveNativeMethod
    所以,当我调用对应native函数的时候,如果这个方法不是经过主动注册的,那么首先会执行dvmResolveNativeMethod方法。下面我们来看看该方法。

    如果不是主动注册的话,native层的JNI方法需要按照一定的命名规则进行命名,这个具体就展开了,使用过JNI应该都清楚,dvmResolveNativeMethod首先遍历查找所有已加载的so,根据对应的JNI方法的名称来查找对应的JNI方法,如果找到该方法之后,再调用dvmUseJNIBridge函数设置Method的nativeFunc和insns成员,这个函数在主动注册已经介绍过了,执行完这个函数之后,Method的nativeFunc就是指向dvmCallJNIMethod函数,接着我们可以看到它执行的是method->nativeFunc指向的函数,也就是dvmCallJNIMethod函数,所以最终还是调用dvmCallJNIMethod,再由dvmCallJNIMethod执行相应的JNI方法。
    从上面整个过程我们可以知道,不管是主动注册的java native方法还是被动注册的java native方法,它们的调用过程最终都是通过dvmCallJNIMethod这个bridge函数来实现对具体JNI方法的调用的。下面把上面过程通过画图表示如下:

    三、作用

    1、定位到java native方法对应的JNI方法
    2、拦截java native方法的调用

     

    总结

    在Android中,不管是java方法还是java native方法,它在虚拟机中对应的都是一个Method对象,如果这个方法是一个java native方法的话,那么Method对象的nativeFunc会指向一个bridge函数,这个函数为dvmCallJNIMethod,当我们在调用java native函数的时候就会进入这个bridge函数,bridge函数的作用就是调用该java native方法对应的JNI方法。所以,我们可以这么理解,所有java native函数的执行都是通过一个名为dvmCallJNIMethod的bridge函数来实现对应JNI方法的调用的。

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

    万次阅读 多人点赞 2017-01-06 12:46:32
    在前面一篇文章中,我们分析了Dalvik...当然,Dalvik虚拟机除了可以执行Java代码之外,还可以执行Native代码,也就是CC++代码。在本文中,我们就将继续以Zygote进程的启动过程为例,来分析Dalvik虚拟机的运行过程。
  • diff --git a/vm/native/dalvik_system_Zygote.cpp b/vm/native/dalvik_system_Zygote.cpp index 8224656..f4102e8 100644 --- a/vm/native/dalvik_system_Zygote.cpp +++ b/vm/native/dalvik_system_Zygote.cpp ...
  • Dalvik虚拟机简要介绍学习计划

    万次阅读 多人点赞 2017-01-06 12:46:37
    除了指令集类文件格式不同,Dalvik虚拟机与Java虚拟机共享有差不多的特性,例如,它们都是解释执行,并且支持即时编译(JIT)、垃圾收集(GC)、Java本地方法调用(JNI)Java远程调试协议(JDWP)等。...
  • Dalvik虚拟机进程线程的创建过程分析

    万次阅读 多人点赞 2017-01-06 12:46:28
    事实上,我们的确是可以在Java代码中创建进程线程,也就是Dalvik虚拟机进程线程。那么,这些Dalvik虚拟机所创建的进程线程与其宿主Linux内核的进程线程有什么关系呢?本文将通过Dalvik虚拟机进程线程的...
  • Android Bitmap的内存分配是在Dalvik Heap而不是Native Heap最近一直在查内存泄露问题,发现Bitmap是最容易出现内存泄露的,然后查看源码以及资料一下颠覆了我的认知观,首先以上结论是建立在Android2.3以后的版本。...
  • -- @page { margin: 2cm } P { margin-bottom: 0.21cm } -->为了挖掘Dalvik虚拟机的秘密,需要仔细分析Dalvik的每一个目录,每一个文件,才能把它的细节了然于胸。下面就开始吧! Android.mk 这个文件是虚拟机...
  • Android ART运行时无缝替换Dalvik虚拟机的过程分析

    万次阅读 多人点赞 2017-01-06 12:46:10
    Android 4.4发布了一个ART运行时,准备用来替换掉之前一直使用的Dalvik虚拟机,希望籍此解决饱受诟病的性能问题。老罗不打算分析ART的实现原理,只是很有兴趣知道ART是如何无缝替换掉原来的Dalvik虚拟机的。毕竟在...
  • Dalvik虚拟机的启动过程分析

    万次阅读 多人点赞 2017-01-06 12:46:35
    Zygote进程在启动时会创建一个Dalvik虚拟机实例,每当它孵化一个新的应用程序进程时,都会将这个Dalvik虚拟机实例复制到新的应用程序进程里面去,从而使得每一个应用程序进程都有一个独立的Dalvik虚拟机实例。...
  • 这是一个同时支持ART和Dalvik两种模式,理论上支持安卓4.0.3以上所有版本,同时支持JAVA和NATIVE层,使用全局注入技术的侵入式HOOK框架。 本框架不需要额外的安装,可以静态编译到自己的APP中
  • 出现这个 Couldn't load native-lib from loader dalvik情况是因为没有在apk中找到相应的.so文件,我看了些文章总结原因一共只有两种可能: 1:真的没有这个.so文件 2:文件名写错了 判断原因:1使用Build-Analyze APK...
  • Dalvik虚拟机JNI方法的注册过程分析

    万次阅读 多人点赞 2017-01-06 12:46:32
    在前面一文中,我们分析了Dalvik虚拟机的运行过程。从中可以知道,Dalvik虚拟机在调用一个成员函数的时候,如果发现该成员函数是一个JNI方法,那么就会直接跳到它的地址去执行。也就是说,JNI方法是直接在本地操作...
  • 之前在百度看了好几多资料,耐烦出现好多坑,估计是时间太久了,导致不适用,现在我贴上我的代码,大家看一下,本人已通过编译,可以正常运行 public static String[] getHeap(String packageName) { ...
  • 内存由 dalvik native 2部分组成。dalvik 也就是 java 堆,创建的对象就是在这里分配的, 而 native 是通过 c/c++ 方式申请的内存。 Bitmap 就是以一种方式分配的(android3.0 以后,系统默认是...
  • native和java堆栈不同可能引发的问题

    千次阅读 2016-11-28 17:38:22
    但是在ART中,native和java使用相同的堆栈。ART线程的堆栈大小通常情况下和Dalvik中相同,如果堆栈太小引发程序出错,可以在程序中指定堆栈的大小。在java中,Thread类的构造方法可以指定堆栈的大小。在JNI中,对于...
1 2 3 4 5 ... 20
收藏数 20,937
精华内容 8,374
关键字:

dalvik和native