C#结构体和类的区别 代码实例解释

1.jni的基本工作原理　　
       （1）java的本质
　　想搞明白jni的本质，还要从java的本质说起.从本质上来说，java这门语言就是一门脚本语言（这是偶的个人理解，希望java大侠们不要用板砖拍我），它的运行完全依赖于脚本引擎对java的代码进行解释和执行（当然了，现代的java已经先进许多，可以从源代码编译成.class之类的中间格式的二进制文件，这种处理会大大地加快java脚本的运行速度，但是基本的执行方式仍然不变，由脚本引擎（我们称之为JVM）来执行，与python、perl之类的纯脚本相比，它只是把脚本变成了二进制格式而已.另外就是java本身对面向对象的概念支持得很好，拥有完善的功能库可供调用，把这个脚本引擎移植到所有平台上，那么这个脚本自然就实现所谓的“跨平台”了）.绝大多数的脚本引擎都支持一个很显著的特性，就是可以通过c/c++编写模块，在脚本中调用这些模块，以此来类比java，也是一样的，java一定要提供一种在脚本中调用c/c++编写的模块的机制，才能称得上是一个相对完善的脚本引擎.
　　（2）android中的java
　　android平台从本质上是 由arm-linux操作系统 和一个叫做dalvik的java虚拟机组成的.所有在android模拟器上面看到的那些华丽的界面，都是用java语言编写的（参见android平台源代码的frameworks/base目录）.目前看来dalvik只是提供了一个标准的支持jni调用的java虚拟机环境.android平台中所有的硬件相关的操作均是采用jni技术进行了封装，由java去调用jni模块，而jni模块使用c/c++调用android本身的arm-linux底层驱动.
　　例如，frameworks/base/libs/ui目录下面有一个叫做“EGLDisplaySurface.cpp”的文件，里面的：
　　status_t EGLDisplaySurface：：mapFrameBuffer（）函数中，就有直接对android的arm-linux中的framebuffer的初始化代码.
　　这也更加印证了，android其实是依靠java+jni建立起来的王国.hoho，如此一来，就凸显出jni在android开发中的重要性（当然，一些简单的小程序是完全可以只用java就搞定的）.
　　“jni”的子目录，这个目录将用来存放.c的文件.
　　（3）编写jni模块的java调用类
　　这是必然的了，jni嘛，一定要有调用者才能够工作在src的最内层目录里面添加一个叫做JniModule.java的原文件，看上去如下所示：
java代码：
public class JniModule {
static {
System.loadLibrary("aaaa") ;
}
public native static int jni_add(int a, int b) ;
}
复制代码
注意，偶们最终会生成一个叫做libaaaa.so的arm兼容的二进制动态库，但是在使用System.loadLibrary动态载入的时候，只需要填写lib和.so之间的名字aaaa即可，在此实验的功能仅仅是两个数字a和b的求和计算以及如何在jni的c语言模块中把log日志打印到logcat中.
        在JniTest.java中，偶们可以如下调用这个类：
java代码：
public void onClick(View v) {
String ss ;
int a = 3 ;
int b = 4 ;
ss = "" ;
switch(v.getId()) {
case R.id.button1:
ss = "a="+String.valueOf(a)+","+"b=" + String.valueOf(b) + "," + "a+b=" +
String.valueOf(JniModule.jni_add(a, b));
setTitle(ss) ;
break ;
case R.id.button2:
setTitle("button2 click") ;
break ;
case R.id.button3:
int pid = android.os.Process.myPid();
android.os.Process.killProcess(pid);
break ;
}
}
复制代码
注意，这里的button3是很重要的，功能是得到当前程序的进程id，然后显示地杀掉它！
       为什么要这么做呢？原因在于，android里面的常规退出函数并没有真正地关闭当前运行的进程，而是切换到后台去了。这对普通的java应用看上去很平常，而且可以加速再次启动该程序的速度，但是对于带有jni模块的java程序而言就是恶梦，因为程序没有真的关闭。所以那个libaaaa.so库，会一直停留在内存中，这时候如果你希望把旧的so库替换成新的库，那就要重启手机才行。。。很痛苦，所以想到了这种办法，直接杀掉自己，那么下一次启动的时候就会自动重新载入最新的so库。
生成java程序与c程序的接口文件
　　谈到这里，自然就会联想到是c语言的。h文件了，现在的问题在于如何从。java文件生成我们需要的。h格式的c/c++文件。答案就是javah这个小工具基本上所有的jdk都会提供：
　　javah -classpath "java类的地址" <你的java模块位置>
　　利用javah就可以很容易地将JniModule。java代码的native标记的部分转换为c/c++的。h文件中定义的导出函数。
　　以下是偶用于测试的makefile，相信懂makefile语法的朋友可以很容易就看明白偶在做什么，
　　为了实验能够非常“精确”地进行，在这个makefile中的全部路径都采用了绝对路径，其实用相对路径也是可以的。
java代码：
CC=arm-none-linux-gnueabi-gcc
LD=arm-none-linux-gnueabi-ld
MV=mv
JH=javah
JHFLAGS=-classpath "/home/wayne/works/workspace/JniTest/bin"
LDFLAGS=-T "/home/wayne/CodeSourcery/Sourcery_G++_Lite/arm-none-linux-gnueabi/lib/ldscripts/armelf_linux_eabi.xsc" -shared
CFLAGS=-I. -I/home/wayne/works/workspace/JniTest/jni/include -I/home/wayne/works/workspace/JniTest/jni/include/linux -I/home/wayne/works/workspace/JniTest/jni -fpic
all: libaaaa.so
com_hurraytimes_jnitest_JniModule.h:
$(JH) $(JHFLAGS) com.hurraytimes.jnitest.JniModule
aaaa.o: aaaa.c com_hurraytimes_jnitest_JniModule.h
$(CC) $(CFLAGS) -c -o aaaa.o aaaa.c
libaaaa.so: aaaa.o
$(LD) $(LDFLAGS) -o libaaaa.so aaaa.o libcutils.a
$(RM) ../libs/armeabi/libaaaa.so
$(MV) libaaaa.so ../libs/armeabi/
clean:
$(RM) *.o *.so *~
复制代码
这里需要特别提一点的，就是关于arm-none-linux-gnueabi-gcc的使用问题，这个编译器自从到了2008版本就开始琢磨着实现更加方便地“cross compiler”的功能了.以往的版本是arm-xxx-linux-gcc，就是为了编译arm-linux平台的软件的，如果你的芯片从三星的变为菲利普的，那么整条工具链就要重新编译.现在的这个2008版的为了让广大开发者（尤其是多种不同芯片平台的嵌入式开发者）的计算机里面不要安装好多套for不同芯片组的gcc工具链，弄了一个-T的参数，这里就可以让开发者使用一个gcc工具链生成不同平台和格式的可执行代码以及链接的库.虽然如此，但是偶还是觉得不大习惯，总之谢谢CodeSourcery很贴心的功能，让偶花了半个多小时在琢磨和查资料，到底是什么原因导致生成的jni模块无法在android上工作.
　　jni模块的打包问题
　　再次声明，在android 1.5 cupcake以后的版本才可以用偶下文提到的打包方法.
　　在查看了ndk的脚本以后，我才知道原来android 1.5版本在打包apk的时候，是完全可以支持直接将.so的jni库打包到apk安装包中去的，解决了偶们这种铁杆c/c++开发者开发自己的jni组件的发布问题，java脚本嘛，做个事件啥的中转就完成它的使命了.
　　其实具体操作起来非常简单，在当前项目的跟目录下创建如下目录：
　　/libs/armeabi
　　然后把自己生成好的so库拷贝到这个armeabi目录下面即可，运行ant生成apk发布包的时候，就会自动地将/libs/armeabi目录下的so库打包到apk文件中，然后就是直接安装就好了！非常简单方便.
　　关于ant里面实现jni的makefile调用的方法
　　首先肯定一下，ant是个不错的东西.但是如果说它要取代makefile的地位，偶个人固执地认为很难.makefile语法简单，随手就可以敲一个，但回头看看ant的build.xml，第一眼看上去就头晕.
　　xml很不错，但是就是他大爷的乱七八糟，而且居然宣称说是给人看的东西...凡事真正有些实质性的用处，用xml存储的数据（用于演示hello world之类的xml就免了），让人看起来都会头晕.
　　ant采用xml作为基本输入，偶个人认为还不如仿效makefile弄一套相对简单的语法来得方便.
　　好了不再发牢骚了，开始看一下，如何为android的build.xml添加ant支持的xml实现自动调用jni的makefile文件.
　　以下是偶用ant来编译jni模块的xml，稍加修改就可以用于开发和实验中，把这些加到</project>之前就可以了：
java代码：
<target name="mk" >
<exec dir="./jni" executable="make" os="Linux" failonerror="true">
</exec>
</target>
<target name="mkclr" >
<exec dir="./jni" executable="make" os="Linux" failonerror="true">
<arg line=" clean" />
</exec>
</target>
复制代码
使用方法就是ant mk和ant mkclr一个是相当于调用make，另一个是相当于调用make clean。其余的操作都放到makefile里面去了。
最后需要说的就是，在偶传上来的代码中，可能会发现有一个叫做libcutils.a的编译好的静态库，这个东西就“说来话长”了，主要原因是偶在做实验的

补充：软件开发 , C# ,