好吧,有几天没记了,主要是这几天都没怎么学JNI,弄别的去了,懒了。。
今天还是继续记录JNI学习,看一个工程里的代码,突然发现他的c++代码的函数命名和java代码函数命名是一样的,觉得很奇怪啊。为什么我的c++代码里的
函数名称那么奇葩呢?别人的为什么就可以自由命名呢?难道是人品问题?
继续往下看发现它里面有一段JNI_OnLoad方法,百度了一下,明白了当java程序中运行到System.loadLibrary()函数时,会立即先呼叫JNI_OnLoad()方法,因此
我看的那套代码在这个函数里做了处理,使c++中其他函数名可以自由命名了,不受用javah搞出来的头文件里面函数声明控制,因此我发现其实根本用不着
去用javah把头文件给搞出来,直接在c++源文件里面写要实现的方法就是了,还能和java中命名为一样的,这样既美观又好找。下面就来看看JNI_OnLoad()
的用法。
首先我们可以不要弄出来的c++头文件了,因为我们已经知道方法里要有JNIEnv和jobject或jclass存在。因此可以节省javah那一步。。
然后我们以前面的那个sayHello例子来看,以前在c++代码里面的声明是这样的:
JNIEXPORT void JNICALL Java_com_wang_TestNative_sayHello(JNIEnv* env ,jobject obj){
//.........
}
现在决定添加JNI_OnLoad方法后,我们的sayHello声明可以变成这样的:
void sayHello(JNIEnv* env ,jobject obj){
//.........
}
嗯,这样的命名方式就和普通的c++声明差不多了,看着美观大方易懂,而且和java中声明的名字一样,也容易找。
接下来这个方法写完之后:
void sayHello(JNIEnv *env, jobject obj){
jclass class_TestNative = env->GetObjectClass(obj);
jfieldID id_number = env->GetFieldID(class_TestNative,"number","I");
jint number = env->GetIntField(obj,id_number);
cout<<number<<endl;
env->SetIntField(obj,id_number,100L);
}
这当然和上次的一样。
然后开始写JNI_OnLoad方法,就是将函数对应一下下:
jint JNICALL JNI_OnLoad(JavaVM* vm,void* reserved){
JNIEnv* env;
if(vm->GetEnv((void**)&env,JNI_VERSION_1_6) != JNI_OK){
return -1;
}
JNINativeMethod nm[1];
nm[0].name = "sayHello";
nm[0].signature = "()V";
nm[0].fnPtr = (void*)sayHello;
jclass cls = env->FindClass("com/wang/TestNative");
env->RegisterNatives(cls,nm,1);
return JNI_VERSION_1_6;
}
其中的JNINativMethod是个结构体,里面就是要关联的信息,它的里面是这样的:
typedef struct {
const char* name;//java方法名称
const char* signature; //java方法签名
void* fnPtr;//c/c++的函数指针,指向其方法
} JNINativeMethod;
如上面,我们声明了一个 JNINativMethod数值,里面存放一个JNINativMethod,然后分别将方法的名字,签名,最后一个fnPtr传指向其方法的指针。
接下来发现一下我们要用这些本地方法的java类,用个RegisterNatives来弄一下,就好了。不过c和c++有点不同,c++里面用JNIEnv,JavaVM这些指针的地方
都是用的env啦,vm啦(如上),c中就会用(*env)、(*vm)啦,总之前面要加*号,方法里第一个参数要加一个环境(就是env这些JNIEnv*值)。
如此一来就可以编译成功了,然后同样能在java里面运行。
这种方法声明个人感觉要好些。。