[[59727]]【51CTO獨家譯文】Android平臺為應用程序在傳統的Android應用邊界外面運行提供了兩種方法。***種、也是應用最廣泛的方法是使用原生開發工具包(NDK)。第二種方法是使用RenderScript(RS)，這是一種低級的高性能編程語言。這兩種機制都適用于3D渲染和處理器密集型計算。

我們在本文中將比較NDK和RS，幫助你決定何時使用其中一種方法。

NDK vs. RenderScript：編程語言和可移植性

NDK讓開發人員可以用C或C++編程，并通過Java原生接口(JNI)機制與Android應用程序進行聯系。可用的庫是標準庫，基本上不需要變更，就可以常常移植現有的C/C++代碼。此外，C++與Java區別不是很大，許多開發人員同時精通這兩種語言。

RenderScript則采取了不同的方法，它使用C99語法(標準C來自1999年，***標準是C11，來自2011年)，新的應用編程接口(API)最終編譯成原生代碼。雖然這種語法廣為人知，但是使用這套系統面臨一個學習過程，因為其API并非廣為人知。

最終的可移植性體現在有沒有在種類最廣泛的設備和平臺上使用的庫。NDK讓你可以利用現有的C/C++庫，你可能已經在其他平臺上使用這些庫。RenderScript無法從其他C應用程序移植過來，不過它在Android設備上比NDK更為常見。比如說，RenderScript可在谷歌電視(Google TV)設備上運行，但是目前NDK還缺少對谷歌電視平臺的支持，即使它運行Android。

NDK vs. RenderScript：編譯和調試

[[59728]]用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的工作機理，可以幫助你作出更明智的決定，決定在具體開展某個項目時使用哪一種方法。不管怎樣，目前有工具可以幫助你讓自己編寫的應用程序在盡可能多的設備上盡可能快速地運行。