Android NDK学习笔记（一）为什么要用NDK?

浏览数：592 / 时间：2015年06月11日

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：