Android NDK學習筆記（一） 初識NDK

NDK是什么

NDK是Native Development Kit的簡稱，即本地開發工具包。通過NDK，Android允許開發人員使用本地代碼語言（例如C/C++）來完成應用的部分（甚至全部）功能。注意：由于翻譯原因，有些地方也把Native翻譯為“原生”。

NDK是SDK的一個補充，可以幫助你做這些事情：

• 生成可以在ARM CPU，Android 1.5（及以上）平臺運行的JNI兼容的共享庫。

• 將生成的共享庫放置在應用程序項目路徑的合適位置，使其能自動地添加進你最終的（和經過簽名的）apk包。

• 在后續NDK版本中，我們希望提供這樣的工具，通過遠程的GDB連接和盡可能多的源/符號信息來協助調試本地代碼。

此外，NDK還提供：

• 一個交叉工具鏈集合（編譯器、鏈接器、etc），可以在Linux、OS X、Windows上生成本地ARM 二進制代碼（Windows上需要使用Cygwin）。

• 一個系統API頭文件集合，這些API被保證向后兼容和穩定支持。

• 一個構建系統，允許開發者僅僅編寫非常短的構建文件來描述哪些文件需要被編譯、如何編譯。構建系統會負責處理工具鏈、Android平臺、CPU、ABI的繁冗的區別。此外，NDK的后續更新會增加更多的工具鏈、平臺、系統接口的支持，而不需要改變開發者的構建文件。

正確理解NDK

NDK是一個工具包，但圍繞這個工具包有很多誤解。作為初學者，我們應該對這些誤解有清醒的認識，避免掉進各種“坑”。

• 誤解一：NDK發布之前，Android不支持C/C++開發

眾所周知，Android的SDK基于Java實現，這意味著基于Android SDK進行開發的第三方應用都必須使用Java語言。但這并不等同于“第三方應用只能使用Java”。在Android SDK首次發布時，Google就宣稱其虛擬機Dalvik支持JNI編程方式，也就是第三方應用完全可以通過JNI調用自己的C動態庫，即在Android平臺上，“Java+C”的編程方式是一直都可以實現的。

當然這種誤解的產生是有根源的：在Android SDK文檔里，找不到任何JNI方面的幫助。即使第三方應用開發者使用JNI完成了自己的C動態鏈接庫（so）開發，但是so如何和應用程序一起打包成apk并發布？這里面也存在技術障礙。有的開發者安裝交叉編譯器創建so，并通過assets方式，實現捆綁so發布。但這種方式只能屬于投機取巧，并非官方支持。所以，在NDK出來之前，我們將“Java+C”的開發模式稱之為灰色模式，即官方既不聲明“支持這種方式”，也不聲明“不支持這種方式”。

• 誤解二：有了NDK，就可以完全使用C開發應用

在NDKr5之前，NDK并沒有提供各種系統事件處理支持，也沒有提供應用程序生命周期維護和應用程序UI方面的API，因此幾乎不可能做出一個完整的應用。但是，自從ndk r5發布以后，已經允許你完全用C/C++ 來開發應用或者游戲，而不再需要編寫任何Java 的代碼。

• 誤解三：使用NDK開發可以極大提高性能

業界對于Java的歧視由來已久，以致很多人對Java代碼不屑一顧，而對C/C++代碼有著狂熱的崇拜，認為C/C++寫的程序一定比Java跑得快。但是，經驗證明，糟糕的性能通常應該歸咎于混亂的數據結構和緩慢的算法，而不是編程語言本身。實際上，扣除虛擬機的必要消費，Java代碼并不比C/C++慢，有時甚至會快一些。Google的官方文檔里面也有說明：在Android上使用原生代碼通常不會帶來顯著的性能提升，但總是會增加應用程序的復雜度。一般來說，應該只在對你的應用程序很有必要的時候才使用NDK，而不是簡單的因為你喜歡使用C/C++編程。

• 誤解四：使用NDK開發應用不用擔心反編譯

很多人都知道Java代碼可以很容易進行反編譯，因此需要保密的業務邏輯放在so中去實現。這本身并無不妥，但很多人卻把這一點夸大了，認為只要使用原生代碼放進共享庫，就可以高枕無憂，不用擔心反編譯了。實際上，在百度和Google上搜索“反編譯so文件”，都可以得出數十萬條結果。如果只是單純地為了代碼安全，完全可以考慮SDK提供的代碼混淆工具，詳情可自行查閱相關資料，這里不作贅述。一句話：NDK并不能保證代碼安全！

NDK的適用范圍

Google官方推薦了一些CPU密集型任務，對于這些任務可以考慮使用NDK：

• 游戲引擎

• 信號處理

• 物理仿真

最后，Google對開發者的提醒：當你考慮是否需要使用NDK的時候，請先想想你的需求，并檢查在Android Framework API中是否已經提供你需要的功能。