JNI 是 Java平台中的一个强大特性。应用程序能够通过 JNI把 C/C++代码集成进 Java程序中。通过 JNI。开发人员在利用 Java平台强大功能的同一时候，又不必放弃对原有代码的投资。由于 JNI是 Java平台定义的规范接口。当程序猿向 Java代码集成本地库时。仅仅要在一个平台中攻克了语言互操作问题。就能够把该解决方式比較easy的移植到其它 Java平台中。
比方为 Dalvik加入了一个本地库，也能够把这个本地库非常easy的移植到 J2SE和 Apache Harmony中，由于在 Java与 C/C++互操作方面，大家都遵循一套 API接口，即 JNI。
Java 平台(Java Platform)的组成：Java VM和 Java API. Java应用程序使用 Java语言开发，然后编译成与平台无关的字节码(.class文件)。 Java API由一组提前定义的类组成。不论什么组织实现的 Java平台都要支持：Java编程语言，虚拟机，和 API(Sun对 Java 语言、虚拟机和 API有明白规范)。
平台环境:操作系统，一组本机库，和 CPU指令集。本地应用程序,通常依赖于一个特定的平台环境,用 C、C++等语言开发。并被编译成平台相关的二进制指令，目标二进制代码在不同 OS 间一般不具有可移植性。Java平台(Java VM和 Java API)一般在某个平台下开发。
比方，Sun的 Java Runtime Environment(JRE)支持类 Unix和 Windows 平台. Java平台做的全部努力。都为了使程序更具可移植性。
当 Java 平台部署到本地系统中。有必要做到让 Java 程序与本地代码协同工作。部分是因为遗留代码(保护原有的投资)的问题(一些效率敏感的代码用 C 实现。但如今 JavaVM 的运行效率全然可信赖)，project师们非常早就開始以 C/C++为基础构建 Java 应用，所以，C/C++代码将长时间的与 Java 应用共存。
JNI让你在利用强大 Java平台的同一时候，使你仍然能够用其它语言敲代码。
作为 JavaVM 的一部分，JNI 是一套双向的接口。同意 Java 与本地代码间的互操作。
作为双向接口。JNI 支持两种类型本地代码：本地库和本地应用。用本地代码实现 Java 中定义的 native method 接口，使 Java 调用本地代码通过 JNI 你能够把 Java VM 嵌到一个应用程序中，此时 Java 平台作为应用程序的增强，使其能够调用 Java 类库比方，在浏览器中执行 Applet, 当浏览器遇到"Applet"标签。浏览器就会把标签中的内容交给 Java VM 解释执行，这个实现，就是典型的把 JavaVM 嵌入 Browser 中。JNI 不仅仅是一套接口，还是一套使用规则。 Java 语言有"native"keyword，声明哪些方法是用本地代码实现的. 翻译的时候，对于"native method"，依据上下文意思做了不同处理，当native method 指代 Java 中用"native"keyword修饰的那些方法时，不翻译；而当代码用C/C++实现的部分翻译成了本地代码。
上述，在应用中嵌入 Java VM的方法。是用最少的力量，为应用做最强扩展的不二选择，这时你的应用程序能够自由使用 Java API 的全部功能；大家有兴趣能够读一读浏览器是怎么扩展 Applet 的，或者读一读
Palm WebOS 的东西。
我们整个小组做了两个平台的扩展，设计、编码、測试和 debug 用了近一年半时间，代码量在 14000 行左右，做完扩展后，平台功能空前增强。我感觉做软件，难得不在编码。难在開始的设计和后期的測试、调试和优化，并终于商用。这就要求终于产品是一个强大而稳定的平台，达到此目标是个旷日持久的事. 看看 Java，Windows，Linux，Qt。WebKit 发展了多少年?向全部软件project师致敬!
请记住，当 Java程序集成了本地代码，它将丢掉 Java 的一些优点。
首先，脱离 Java后。可移植性问题你要自己解决，且需又一次在其它平台编译链接本地库。
第二，要小心处理 JNI编程中各方面问题和来自 C/C++语言本身的细节性问题，处理不当。应用将崩溃。
一般性原则：做好应用程序架构，使 native methods定义在尽可能少的几个类里。
学习 JNI编程是个漫长的实践过程，会碰到无数问题。
用 C/C++编程。常见问题有内存泄露，指针越界...，此外使用了 JNI，还要面对JavaVM的问题：
•在本地代码中 new一个 Java 对象后期望在本地代码中维护此对象的引用，怎样避免被 GC；
• Java 面向对象语言的封装性被破坏了，Java 类中不论什么方法和属性对 JNI 都是可见的。无论它是 public 的，还是 private/protected/package 的
• 对LocalRef/GlobalRef 管理不善。会引发 Table Overflow Exception，导致应用崩溃
•从 JNI调用 Java 的过程不是非常直观，往往几行 Java 代码能搞定的事情。用 JNI 实现却要几百行
当你准备在项目中使用 JNI之前。请先考虑一下是否有其它更合适的方案。上节有关 JNI缺点的介绍，应该引起你足够的重视。这里介绍几个不通过 JNI 与其它语言交互的技术：
IPC 或者通过TCP/IP 网络方案 ( Android ASE)
数据库方面。能够使用 JDBC
使用 Java的分布式对象技术:Java IDL API IPC 与 TCP/IP 是经常使用的基于协议的信息交换方案. 能够參考 Android 上的Binder 和ASE(Android Script Environment)。
一典型的解决方式是。Java程序与本地代码分别执行在不同的进程中. 採用进程分置最大的优点是：一个进程的崩溃，不会马上影响到还有一个进程。可是，把Java 代码与本地代码置于一个进程有时是必要的。例如以下Java API 可能不支某些平台相关的功能。比方，应用程序运行中要使用 Java API 不支持的文件类型，而假设使用跨进程操作方式，即繁琐又低效避免进程间低效的数据拷贝操作多进程的派生：耗时、耗资源(内存)用本地代码或汇编代码重写Java 中低效方法
总之。假设 Java必须与驻留同进程的本地代码交互，请使用 JNI。写代码是技巧和艺术，看你想在设计上下多大功夫. 比方: Chrome。是多进程的典范。她的简洁、高效，令人叹服。关于 Java 应用程序怎样与本地代码互操作的问题，在 Java 平台早期就被提了出来.JDK1.0 包含了一套与本地代码交互的接口。当时很多 Java 方法和库都依赖本地方法实现(如 java.io, java.net)。可是，JDK release 1.0 有两个主要问题：Java 虚拟机规范没有定义对象布局。本地代码訪问对象的成员是通过訪问 C 结构的成员实现的本地代码能够得到对象在内存中的地址，所以。本地方法是 GC 相关的为解决上述问题对 JNI 做了又一次设计。让这套接口在全部平台都easy得到支持。
虚拟机实现者通过 JNI 支持大量的本地代码工具开发商不用处理不同种类的本地接口全部 JNI 开发人员面对的是操作
JavaVM 的规范 APIJNI 的首次支持是在 JDK release 1.1，但 1.1 内部 Java 与本地代码的交互仍然使用原始方式(JDK 1.0). 但这样的局面，没有持续非常久，在 Java 2 SDK release1.2 中 Java 层与本地代码的交互部分用 JNI 重写了。
作为 JavaVM规范的一部分，Java 层与本地代码的交互。都应通过 JNI实现