作者：Shane Conder & Lauren Darcey

尽管效率已有提升，但通过正确编写代码促使Android应用能够流畅且反应灵敏地运行，还存在提升空间。有些应用可以在Android的Java VM界线（游戏邦注：也就是Dalvik VM）外运行代码。

Android平台提供了两种在传统Android应用界线外运行的方法。最被广泛使用的方式是使用Native Development Kit（游戏邦注：下文简称“NDK”）。还有种方法是使用RenderScript（游戏邦注：下文简称“RS”），这是种低层次高表现的编程语言。这两种方法均可用于3D播放和CPU密集计算。

在这篇文章中，我们将对NDK和RS两者进行比较，帮助你找出使用这两者方法的最佳时机。

Android NDK from androidcentral.com

NDK VS RS：编程语言和轻便性

NDK允许开发者用C或C++来编写代码，通过Java Native Interface（游戏邦注：下文简称“JNI”）机制与他们的Android应用接合。这里的存储库是标准模式，既有C/C++的移植通常伴随着些许调整。而且，C++与Java的差别并不大，许多开发者对这两种语言都很精通。

RS采用的方法有所不同，其运用带有新API的C99句法（游戏邦注：标准C源于1999年，当前标准是C11，出现于2011年），而新API最终会被编译至本地代码中。虽然这个句法为人所熟知，但是由于API的使用范围不广，所以开发者需要经过一段时间的学习才能够运用这个系统。

就轻便性而言，要点在于拥有能够适用于最多设备和平台的存储库。NDK可以利用你或许已经用在其他平台上的现有C/C++库。RS与其他C应用相比轻便性略差，但是比起NDK来它适用于更多Android设备。比如，RS能够在Google TV上运行，而目前Google TV平台上还无法使用NDK。

RenderScript from androidencyclopedia.com

NDK VS RS：编译和调试

用NDK编写的代码必须事先针对每个目标本地平台进行编译。如果应用发布平台包含不被支持的架构，那么应用的NDK端口就无法恰当地发挥作用。RS会先在你的开发机器上进行编译，接着是在目标设备，带来更高效的本地二进制代码。这意味着，任何支持RS的设备都能够运行你的代码，无论采用何种架构。

目前，RS形成的代码只会在主CPU上运行，在目标设备上运行时能够自动生成能够发挥多核特点的代码。但未来RS有可能也会在GPU上运行。这类似于CUDA或OpenCL平台。

运用NDK的应用可以通过gdb进行在线调试。但是，RS无法在运行时调试。从RS的本质及其利用多核的方式来看，这一点是可以预料到的，但这仍使得寻找和消除漏洞变得更为困难。

NDK VS RS：性能

就性能方面而言，NDK和RS两者都未提供绝妙方案。这两者都会增加项目的复杂性，减小便利性，增加测试需求，使调试变得更麻烦，以及增加项目的维护负担。如果你的项目不需要进行大量的计算，只利用OpenGL最基本的图像能力或者已经能够快速地运转，那么NDK或RS都不太可能会让你的项目获益。

如果针对单纯的计算用途，RS的设置和配置较为简单，所产生的结果或许能够胜过使用NDK。RS最适合用于3D用户界面或高性能的计算任务。而NDK则更适合需要访问更多图像SDK功能或访问第三方存储库的高性能OpenGL应用或游戏。

未在Java中与CPU绑定的简单OpenGL任务或计算最好单独处理。设备性能提升的总是Java编译器和Dalvik VM。将代码保留在Java中可以让你的应用利用这些提升的性能，实现在未来SDK版本或设备中进行更好的运转。

随着最终编译步骤的改善及更多硬件设备支持和计算支持被添加至GPU，RS代码将来或许会有所改善。但是，通过NDK执行的本地代码不太可能获得性能上的提升。因此，NDK代码的最大优势在于高效的运算法则和译码。

结论

运用NDK、RS还是停留在Java区域中，最终的选择权完全在开发者手中。这是个能产生很大影响的应用设计选择，它会影响我们使用的编程语言、应用运行的目标设备及项目维护的复杂性。

你已经看过上述有关NDK和RS的优势和劣势。它们可以进行互换，在某些情况下，两种技术都能够成为开发者的设计解决方案。深入把握NDK和RS能够帮助你进行更为恰当的选择。这两种技术都是能够帮助你提升应用在设备上的运行速度的可用工具。

游戏邦注：本文发稿于2012年2月7日，所涉时间、事件和数据均以此为准。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Writing Native Android Code: NDK vs. RenderScript

Shane Conder & Lauren Darcey

While efficient, correct coding goes a long way towards making Android applications smooth and highly responsive, some applications can benefit from running code outside the boundaries of Android’s Java VM, known as the Dalvik VM. These apps instead run their code natively.

The Android platform provides two methods for operating outside the traditional Android application boundaries. The first and most widely available method is to use the Native Development Kit (NDK). The second method is to use RenderScript (RS), a low-level, high-performance programming language. Both mechanisms can be useful for 3D rendering and CPU-intensive computations.

In this article, we compare the NDK and RS to help you decide when to use one over the other.

NDK vs. RenderScript: Programming Languages and Portability

The NDK allows developers to write code in C or C++ and interface with their Android applications through the Java Native Interface (JNI) mechanism. The libraries available are standard, and existing C/C++ code can often be ported with few changes. Also, C++ is not that different from Java and many developers are well versed in both languages.

RenderScript takes a different approach, using C99 syntax (standard C from 1999, the current standard is C11, from 2011) with new APIs that are ultimately compiled to native code. While this syntax is well known, there’s a learning curve to using this system because the APIs are not.

The ultimate in portability is to have libraries that work across the broadest range of devices and platforms. The NDK lets you leverage your existing C/C++ libraries, which you may already be using on other platforms. RenderScript is not portable from other C apps, however it’s more widely available across Android devices than the NDK. For example, RenderScript works on Google TV devices, but there is currently no NDK support available for the Google TV platform, even though it runs Android.

NDK vs. RenderScript: Compilation and Debugging

Code written with the NDK must be compiled for each target native platform ahead of time. If the app is launched on a platform with an unsupported architecture, the NDK portions of the application will not function properly. RenderScript does a first pass compile on your development machine and then a final pass on the target device, resulting in more efficient native binary code. This means that any device that supports RenderScript will run your code, regardless of the architecture.

Currently, RenderScript results in code that runs only on the main CPU, and automatically generates code that can leverage multiple cores when they are available on the target device. However, in the future, there are plans have it run on the GPU as well. This is similar to the CUDA or OpenCL platforms.

Applications that leverage the NDK can be line-level debugged using gdb. RenderScript, on the other hand, can’t be debugged while it’s running. Given the nature of RenderScript and how it works with multiple cores, this isn’t a huge surprise, but this can make finding and eliminating bugs more difficult.

NDK vs. RenderScript: Performance

Neither the NDK nor RenderScript provides a magic bullet for performance. Both increase project complexity, reduce portability, increase testing requirements, complicate debugging, and increase the maintenance burden on the project. If your project doesn’t require a lot of computation, leverages only the basic graphic capabilities of OpenGL, or runs fast enough already, neither the NDK nor RenderScript are likely to benefit your project enough to bother with.

For pure computational uses, RenderScript setup and configuration is easy and the results may in fact outperform similar implementations that use the NDK, with less coding necessary. RenderScript is best used for 3D user interfaces or high-performance computational tasks. The NDK on the other hand is better suited for high-performance OpenGL apps or games that need access to more features of the graphics SDK or access to third-party libraries.

Simple OpenGL tasks or computations that aren’t CPU bound in Java are best left alone. Performance improvements are always being made to the Java compiler and the Dalvik VM. Leaving your code alone in Java will allow your applications to take advantage of these performance improvements and run better on future SDK versions or devices.

RenderScript code may improve in the future as the final compile step improves and more hardware support and compute support are added for GPUs. Native code through the NDK, on the other hand, is unlikely to see performance improvements other than those that come about through hardware changes. Consequently, NDK code benefits the most from highly efficient algorithms and coding.

Conclusion

Ultimately, the choice to use the NDK, RenderScript , or stay within the realm of Java is entirely up to you, the developer. It’s an application design decision with considerable ramifications — it effects what programming language you’re using, what devices your application can run on, and how complicated your source project is from a maintenance perspective.

You have read a variety of the pros and cons of both the NDK and RenderScript. They are not necessarily interchangeable, but similar solutions can be achieved with both technologies in many instances. Understanding how both NDK and RenderScript can work for you will help you make a better decision on which to use on a given project. Either way, there are tools available to help you make your application run as fast as possible on as many devices as possible. (Source: developer)