Android平台为应用程序在传统的Android应用边界外面运行提供了两种方法。第一种、也是应用最广泛的方法是使用原生开发工具包(NDK)。第二种方法是使用RenderScript(RS)，这是一种低级的高性能编程语言。这两种机制都适用于3D渲染和处理器密集型计算。
NDK vs. RenderScript：编程语言和可移植性
NDK让开发人员可以用C或C++编程，并通过Java原生接口(JNI)机制与Android应用程序进行联系。可用的库是标准库，基本上不需要变更，就可以常常移植现有的C/C++代码。此外，C++与Java区别不是很大，许多开发人员同时精通这两种语言。
RenderScript则采取了不同的方法，它使用C99语法(标准C来自1999年，最新标准是C11，来自2011年)，新的应用编程接口(API)最终编译成原生代码。虽然这种语法广为人知，但是使用这套系统面临一个学习过程，因为其API并非广为人知。
NDK vs. RenderScript：编译和调试
用NDK编写的代码必须事先针对每一个目标原生平台来编译。如果应用程序在架构未得到支持的平台上运行，应用程序的NDK代码部分就无法正常运行。RenderScript在你的开发机器上进行第一遍编译，然后在目标设备上进行最后一遍编译，因而带来了更高效的原生二进制代码。这意味着，凡是支持RenderScript的设备都可以运行你的代码，不管采用什么架构。
目前，RenderScript带来的代码只能在主处理器上运行，它会自动生成可以利用多个核心的代码——如果目标设备上有多个核心。不过在将来，有计划让RenderScript代码在图形处理器(GPU)上也可以运行。这类似CUDA或OpenCL平台。
采用NDK的应用程序可以使用gdb进行行级调试。另一方面，RenderScript应用程序在运行时无法调试。考虑到RenderScript具有的性质及其处理多个核心的方式，这没什么好大惊小怪的，不过这也加大了查找和消除代码错误的难度。
NDK vs. RenderScript：性能
NDK和RenderScript都未能在性能方面提供完美方案。两者都增加了项目的复杂性，降低了可移植性，提高了测试需求，加大了调试难度，还给项目增加了维护负担。如果你的项目不需要进行大量计算，只使用OpenGL的基本图像功能，或者已经在足够快速地运行，那么NDK和RenderScript都不太可能给项目带来足够明显的好处。
如果纯粹是用于计算，RenderScript的设置和配置很容易，最终的运行速度实际上可能胜过使用NDK的类似实现方法，需要编写的代码比较少。RenderScript最适合处理3D用户界面或高性能计算任务。另一方面，NDK比较适合高性能OpenGL应用程序或需要访问图形软件开发工具包(SDK)更多功能或访问第三方库的游戏。
简单的OpenGL任务或不受制于处理器的计算任务最好别去管它。Java编译器和Dalvik VM的性能总是在不断提升。就让你的代码继续使用Java，这让你编写的应用程序可以充分利用这些性能上的提升，在将来的SDK版本或设备上可以更好地运行。
随着最后一个编译步骤得到改进，为GPU添加更多的硬件支持和计算支持，RenderScript代码在将来可能会有所改进。另一方面，除了通过硬件改动获得的性能提升外，通过NDK编写的本地代码不太可能出现性能提升。因此，NDK代码从高效的算法和代码得到的好处最大
结束语
最后，选择使用NDK、RenderScript还是继续使用Java，完全取决于开发人员。应用程序设计方面的这个决定具有重大影响：它影响着你使用什么编程语言、编写的应用程序可以在什么设备上运行，以及从维护的角度来看你的软件项目有多复杂。
你已经了解了NDK和RenderScript的诸多优缺点。它们未必可以换着使用，但在许多情况下，可以用这两种技术开发出相似的解决方案。了解NDK和RenderScript的工作机理，可以帮助你作出更明智的决定，决定在具体开展某个项目时使用哪一种方法。不管怎样，目前有工具可以帮助你让自己编写的应用程序在尽可能多的设备上尽可能快速地运行。
