JNI DETECTED ERROR IN APPLICATION: jarray was NULL

本文探讨了在OpenGL ES项目中遇到的Java内存管理问题,特别是如何正确使用ByteBuffer的allocateDirect方法来避免JNIDETECTEDERRORINAPPLICATION错误。通过对比三角形和方形的绘制代码,解释了native层内存分配的重要性。

项目中用到了opengles去展示三维点云数据,个人比较生疏,所以打算学一学。根据官方的示例先画了一个三角形,后面在画方形的时候怎么都不成功,报错:JNI DETECTED ERROR IN APPLICATION: jarray was NULL。可是对比别人的代码和自己的代码,根本看不出有什么区别,从别人的博客中看到以下内容:

在Java中当我们要对数据进行更底层的操作时,一般是操作数据的字节(byte)形式,这时经常会用到
ByteBuffer这样一个类。ByteBuffer提供了两种静态实例方式:
    public static ByteBuffer allocate(int capacity)  
    public static ByteBuffer allocateDirect(int capacity)  
为什么要提供两种方式呢?这与Java的内存使用机制有关。第一种分配方式产生的内存开销是在JVM中的,
而另外一种的分配方式产生的开销在JVM之外,以就是系统级的内存分配。当Java程序接收到外部传来的数据时,
首先是被系统内存所获取,然后在由系统内存复制复制到JVM内存中供Java程序使用。所以在另外一种分配方式
中,能够省去复制这一步操作,效率上会有所提高。可是系统级内存的分配比起JVM内存的分配要耗时得多,所以
并非不论什么时候allocateDirect的操作效率都是最高的

前面在写三角形之前已经了解到了,opengles是不能直接使用java jvm分配的内存的,要将数组转换到系统内存才能使用,

我的示例里面因为用了这个所以一直报数组是空的

改成这样,方形就绘制出来了。

三角形和方形源码

public class Triangle {
    private FloatBuffer vertextBuffer;

    //number of coordinates per vertex in this array
    //每个顶点的坐标包括x,y,z 三个
    static final int COORDS_PER_VERTEXT = 3;

    //顺时针的顺序
    static float triangleCoords[] = {   // in counterclockwise order:
            0.0f, 0.622008459f, 0.0f, // top
            -0.5f, -0.311004243f, 0.0f, // bottom left
            0.5f, -0.311004243f, 0.0f  // bottom right
    };

    // Set color with red, green, blue and alpha (opacity) values
    float color[] = {0.63671875f, 0.76953125f, 0.22265625f, 1.0f};

    //1.为顶点在native层分配缓冲区内存,然后将顶点坐标放进缓冲区

    //2.绘制需要顶点着色器和片段着色器

    //绘制形状需要一个顶点着色程序和一个片段着色程序
    private final String vertexShaderCode =
            "attribute vec4 vPosition;" +
                    "void main() {" +
                    "  gl_Position = vPosition;" +
                    "}";

    private final String fragmentShaderCode =
            "precision mediump float;" +
                    "uniform vec4 vColor;" +
                    "void main() {" +
                    "  gl_FragColor = vColor;" +
                    "}";

    private final int mProgram;


    private int positionHandle;
    private int colorHandle;

    //顶点数
    private final int vertexCount = triangleCoords.length / COORDS_PER_VERTEXT;

    //每个顶点占的字节数
    private final int vertexStride = COORDS_PER_VERTEXT * 4;

    public Triangle() {
        // 初始化顶点字节的缓冲区
        //需要在native 层分配内存
        ByteBuffer bb = ByteBuffer.allocateDirect(triangleCoords.length * 4);
        // 使用设备硬件的本机字节顺序
        bb.order(ByteOrder.nativeOrder());
        // 创建float缓冲区
        vertextBuffer = bb.asFloatBuffer();
        //将顶点坐标放进float缓冲区
        vertextBuffer.put(triangleCoords);
        // 设置缓冲区以读取第一个坐标
        vertextBuffer.position(0);


        int vertextShader = GlRender_1.loadShader(GLES20.GL_VERTEX_SHADER, vertexShaderCode);
        int fragmentShader = GlRender_1.loadShader(GLES20.GL_FRAGMENT_SHADER, fragmentShaderCode);
        // create empty OpenGL ES Program
        mProgram = GLES20.glCreateProgram();

        //将顶点着色器添加到项目
        GLES20.glAttachShader(mProgram, vertextShader);
        GLES20.glAttachShader(mProgram, fragmentShader);
        // creates OpenGL ES program executables
        GLES20.glLinkProgram(mProgram);
    }


    public void draw() {
        // Add program to OpenGL ES environment
        GLES20.glUseProgram(mProgram);

        // get handle to vertex shader's vPosition member
        positionHandle = GLES20.glGetAttribLocation(mProgram, "vPosition");
        // Enable a handle to the triangle vertices
        GLES20.glEnableVertexAttribArray(positionHandle);

        // Prepare the triangle coordinate data
        GLES20.glVertexAttribPointer(positionHandle,
                vertexCount,
                GLES20.GL_FLOAT,
                false,
                vertexStride,
                vertextBuffer);
        // get handle to fragment shader's vColor member
        colorHandle = GLES20.glGetUniformLocation(mProgram, "vColor");
        // Set color for drawing the triangle
        GLES20.glUniform4fv(colorHandle, 1, color, 0);

        // Draw the triangle
        GLES20.glDrawArrays(GLES20.GL_TRIANGLES, 0, vertexCount);
        // Disable vertex array
        GLES20.glDisableVertexAttribArray(positionHandle);
    }

}
public class Square {
    //1.顶点坐标缓冲区
    private FloatBuffer vertextBuffer;
    //2.绘制顺序缓冲区
    private ShortBuffer drawListBuffer;

    //每个顶点包含坐标个数
    static final int COORDS_PER_VERTEXT = 3;

    static float squareCoords[] = {
            -0.5f, 0.5f, 0.0f,   // top left
            -0.5f, -0.5f, 0.0f,   // bottom left
            0.5f, -0.5f, 0.0f,   // bottom right
            0.5f, 0.5f, 0.0f}; // top right

    static short drawOrder[] = {0, 1, 2, 0, 2, 3};

    private final int vertexCount = squareCoords.length / COORDS_PER_VERTEXT;
    private final int vertextStride = COORDS_PER_VERTEXT * 4;

    private final int mProgram;

    //绘制形状需要一个顶点着色程序和一个片段着色程序
    private final String vertexShaderCode =
            "attribute vec4 vPosition;" +
                    "void main() {" +
                    "  gl_Position = vPosition;" +
                    "}";

    private final String fragmentShaderCode =
            "precision mediump float;" +
                    "uniform vec4 vColor;" +
                    "void main() {" +
                    "  gl_FragColor = vColor;" +
                    "}";

    // Set color with red, green, blue and alpha (opacity) values
    float color[] = {0.63671875f, 0.76953125f, 0.22265625f, 1.0f};
    private int positionHandle;
    private int colorHandle;

    public Square() {
        //1.在native 层分配内存 float 占4个字节
        ByteBuffer bb = ByteBuffer.allocateDirect(squareCoords.length * 4);
        //字节顺序
        bb.order(ByteOrder.nativeOrder());

        vertextBuffer = bb.asFloatBuffer();
        vertextBuffer.put(squareCoords);
        vertextBuffer.position(0);

        ByteBuffer dlb = ByteBuffer.allocateDirect(drawOrder.length * 2);
        dlb.order(ByteOrder.nativeOrder());

        drawListBuffer = dlb.asShortBuffer();
        drawListBuffer.put(drawOrder);
        drawListBuffer.position(0);

        int vertexShader = GlRender_1.loadShader(GLES20.GL_VERTEX_SHADER, vertexShaderCode);
        int fragmentShader = GlRender_1.loadShader(GLES20.GL_FRAGMENT_SHADER, fragmentShaderCode);

        mProgram = GLES20.glCreateProgram();
        GLES20.glAttachShader(mProgram, vertexShader);
        GLES20.glAttachShader(mProgram, fragmentShader);
        GLES20.glLinkProgram(mProgram);
    }


    public void draw() {
        GLES20.glUseProgram(mProgram);
        //顶点
        positionHandle = GLES20.glGetAttribLocation(mProgram, "vPosition");
        GLES20.glEnableVertexAttribArray(positionHandle);
        GLES20.glVertexAttribPointer(positionHandle, COORDS_PER_VERTEXT, GLES20.GL_FLOAT,
                false, vertextStride, vertextBuffer);
        //颜色
        colorHandle = GLES20.glGetUniformLocation(mProgram, "vColor");
        GLES20.glUniform4fv(colorHandle, 1, color, 0);
        /**索引法绘制矩形*/
        Log.i("test", "draw: "+drawListBuffer.toString());
        Log.i("test", "draw: "+ Arrays.toString(drawOrder));
        GLES20.glDrawElements(GLES20.GL_TRIANGLES, drawOrder.length, GLES20.GL_UNSIGNED_SHORT, drawListBuffer);
        //Disable vertex array
        GLES20.glDisableVertexAttribArray(positionHandle);
    }


}

 

说明:博客的所有内容均为自己探索实现的,受自身知识点的限制很多地方不一定正确的

<think>好的,我现在需要解决用户提到的JNI报错问题:“JNI DETECTED ERROR IN APPLICATION: can't call java.io.InputStream in call to CallObjectMethodV”。首先,我得理解这个错误的具体原因和可能的情况。 用户可能在JNI代码中调用了某个Java对象的CallObjectMethodV方法,但参数类型不匹配。错误信息指出无法调用java.io.InputStream,可能是在调用某个返回InputStream的方法时出了问题。常见的情况可能有以下几种: 1. **方法签名错误**:JNI调用方法时,需要准确的方法签名。如果方法签名与实际Java方法不匹配,JNI会找不到正确的方法,导致调用失败。比如,假设Java方法返回的是InputStream,但签名写成了其他类型,如Ljava/lang/Object;,或者参数类型不正确,就会出问题。 2. **对象引用问题**:可能调用方法的对象不是正确的Java实例。比如,如果获取实例的方法有误,或者对象已经被回收,导致调用时对象不存在,进而引发错误。 3. **JNIEnv的使用错误**:在多线程环境下,JNIEnv是每个线程独有的,如果在错误的线程中使用,或者JNIEnv指针被错误使用,可能导致问题。 接下来,我需要逐步分析可能的解决步骤。首先,用户应该检查他们调用的方法签名是否正确。可以使用javap -s命令获取准确的签名。例如,假设Java类中有一个方法public InputStream getInputStream(String path),其签名应该是类似(Ljava/lang/String;)Ljava/io/InputStream;。用户需要确保在JNI代码中使用的是这个正确的签名。 然后,检查在JNI中是否正确获取了方法ID。例如,调用GetMethodID时,传入的类对象、方法名和签名是否正确。如果方法名拼写错误,或者类名不正确(如使用了错误的包路径),GetMethodID会返回NULL,这时候继续调用CallObjectMethodV就会导致崩溃。 另外,需要确认调用CallObjectMethodV时传入的对象是否是该方法所属的实例。例如,如果调用的是一个实例方法,必须确保传入的jobject参数是该类的有效实例;如果是静态方法,则需要使用CallStaticObjectMethod,并且传入jclass而不是jobject。 还有可能是在调用方法时参数不匹配,例如方法需要参数但未正确传入,或者参数类型不对。例如,方法需要一个jstring参数,但实际传入的是其他类型,或者没有正确转换本地字符串到jstring。 另外,考虑JNI异常处理的问题。在调用JNI方法时,如果有异常抛出,应该检查异常并处理,否则后续的JNI调用可能会导致未定义行为。用户可以在调用JNI方法后使用ExceptionCheck或ExceptionOccurred来检查是否有异常发生,并及时处理。 可能还需要检查是否在正确的上下文中使用JNIEnv。比如,在异步回调或者不同线程中调用JNI时,需要确保每个线程都正确获取了JNIEnv指针,否则会导致错误。 总结一下,解决步骤可能包括: 1. 检查方法签名是否正确,使用javap工具确认。 2. 确保正确获取方法ID,并且方法ID不为NULL。 3. 确认调用方法的对象实例是否正确有效。 4. 检查参数类型和数量是否与方法签名匹配。 5. 处理JNI异常,避免异常未捕获导致后续错误。 6. 确保在多线程环境下正确使用JNIEnv。 此外,用户可能需要注意内存管理问题,比如局部引用是否溢出,或者没有正确释放局部引用导致的内存泄漏,这些也可能间接引发问题。不过这个错误更可能直接与方法调用相关。 最后,建议用户提供一个代码片段,这样能更具体地分析问题所在。例如,展示JNI中获取方法ID和调用CallObjectMethodV的部分代码,以便检查是否有明显的错误。</think>--- ### 逐步解析:`JNI DETECTED ERROR IN APPLICATION: can't call java.io.InputStream in call to CallObjectMethodV` 这个错误通常是由于 **JNI代码调用Java方法时,方法签名不匹配** 或 **对象类型错误** 导致的。以下是具体原因和解决方案: --- #### 1. **检查方法签名是否正确** - **问题根源**:JNI调用Java方法时,需通过方法签名(Method Signature)匹配目标方法。如果签名错误,JNI会调用错误的方法,导致类型不兼容。 - **解决方法**: 1. 使用 `javap -s` 获取方法的准确签名。例如,对于以下Java方法: ```java public class MyClass { public InputStream getInputStream(String path) { ... } } ``` 执行 `javap -s MyClass`,输出结果中会显示签名: ``` descriptor: (Ljava/lang/String;)Ljava/io/InputStream; ``` 2. 在JNI代码中使用此签名: ```c jmethodID methodID = env->GetMethodID( cls, "getInputStream", "(Ljava/lang/String;)Ljava/io/InputStream;" ); ``` --- #### 2. **确认方法ID获取成功** - **问题根源**:如果 `GetMethodID()` 返回 `NULL`,调用 `CallObjectMethodV()` 会崩溃。 - **解决方法**: - 检查方法名和签名是否与Java代码完全一致(包括大小写)。 - 确保 `jclass` 参数 `cls` 是目标类的正确引用(例如通过 `FindClass("com/example/MyClass")` 获取)。 --- #### 3. **验证对象实例有效性** - **问题根源**:如果调用方法的Java对象(`jobject`)无效(如已被释放或未正确初始化),会导致错误。 - **解决方法**: - 确保 `jobject` 是通过合法途径获得的实例(如构造函数调用或其他方法返回)。 - 使用 `env->IsSameObject(obj, NULL)` 检查对象是否为 `null`。 --- #### 4. **参数类型匹配** - **问题根源**:调用方法时传入的参数类型与签名不匹配,例如: - Java方法需要一个 `String`,但JNI传入了一个 `jint`。 - 参数数量错误(如方法需要1个参数,但传入了0个)。 - **解决方法**: - 对照签名检查参数类型和数量: ```c // 正确示例:传入一个jstring参数 jstring path = env->NewStringUTF("/data/file.txt"); jobject inputStream = env->CallObjectMethod( obj, methodID, path ); ``` --- #### 5. **处理JNI异常** - **问题根源**:Java代码可能抛出未处理的异常,导致后续JNI调用失败。 - **解决方法**: - 在关键JNI操作后检查异常: ```c if (env->ExceptionCheck()) { env->ExceptionDescribe(); // 打印异常信息 env->ExceptionClear(); // 清除异常 return; } ``` --- ### 示例代码对比(错误 vs 正确) #### ❌ 错误代码 ```c // 假设方法签名错误写成了 (I)Ljava/io/InputStream; jmethodID methodID = env->GetMethodID(cls, "getInputStream", "(I)Ljava/io/InputStream;"); jobject inputStream = env->CallObjectMethod(obj, methodID, 123); // 传入int而非String ``` #### ✅ 正确代码 ```c // 正确签名 (Ljava/lang/String;)Ljava/io/InputStream; jmethodID methodID = env->GetMethodID(cls, "getInputStream", "(Ljava/lang/String;)Ljava/io/InputStream;"); jstring path = env->NewStringUTF("/data/file.txt"); jobject inputStream = env->CallObjectMethod(obj, methodID, path); ``` --- ### 总结 - **关键点**:方法签名、对象有效性、参数匹配、异常处理。 - **调试建议**:使用 `adb logcat` 查看完整堆栈,定位JNI调用位置。 - **扩展阅读**:参考Oracle官方JNI文档中的 [Type Signatures](https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/types.html#type_signatures)。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值