心的代码

——如果目标设备上有多个核心。不过在将来，有计划让 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 的工作机理

可以帮助你作出更明智的决定，决定在具体开展某个项目时使用哪一种方法。不管怎样，目
前有工具可以帮助你让自己编写的应用程序在尽可能多的设备上尽可能快速地运行。