NDK mk文件学习
概述
Java原生接口JNI将Android Java代码由NDK预编译的原生代码结合在一起
尽可能减少对JNI的调用，因为并不一定能提升性能，如果涉及到CPU密集运算时，有一定提升，否则可能会降低性能。
NDK需要一个Android.mk文件和一个Application.mk文件（可选），其中Application文件用于描述应用需要哪些原生模块。Android文件用于控制如何和从哪里构建一个模块（静态/共享库）。
一个简单的Android.mk文件片段
LOCAL_MODULE := test
LOCAL_SRC_FILES :=
test.c
LOCAL_LDLIBS := -llog
LOCAL_CFLAGS := -fopenmp
构件系统将在前端添加“lib”，生成名为libtest.so的库。LOCAL_SRC_FILES中，开发人员将提供工程源文件的名称。LOCAL_LDLIBS和LOCAL_CFLAGS分别用于指定链接标记和编译标记
Application.mk文件
参考http://hualang.iteye.com/blog/1149359
* 该文件描述在应用程序中所需要的模块（即静态库或动态库）
* 该文件通常放置在$PROJECT/jni/Application.mk下
* APP_PROJECT_PATH，
* APP_OPTIM，可选的，用来定义release或debug，编译时用来改变优先级，默认release会做高度优化，debug模式生成未优化的，用于调试
* 如果你的应用程序是可调试的（即，如果你的清单文件中设置了android:debuggable的属性是”true”）。默认的是”debug”而不是”release”。这可以通过设置APP_OPTIM为”release”来将其覆盖。
* APP_CFLAGS，一个C编译器开关集合，在编译任意模块的任意C或C++源代码时传递。它可以用于改变一个给定的应用程序需要依赖的模块的构建，而不是修改它自身的Android.mk文件
* APP_CPPFLAGS，当编译的只有C++源文件的时候，可以通过这个C++编译器来设置
* APP_ABI，默认情况下，NDK的编译系统根据 “armeabi” ABI生成机器代码。可以使用APP_ABI 来选择一个不同的ABI。
* APP_STL，默认，NDK构建系统提供由Android系统给出的最小C++运行时库（/system/lib/libstdc++.so）的C++头文件。然而，NDK带有另一个C++实现，你可以在你自己的应用程序中使用或链接它。
system –> 系统默认的最小支持的C++运行时库
stlport_static –> 以静态链接的方式使用stlport版本的STL
stlport_shared –> 以动态链接的方式使用stlport版本的STL
gnustl_static –> 以静态链接的方式使用gnu版本的STL
官方提供的这个stlport版本不支持RTTI和异常，换言之，如果你使用了stlport版本的STL，则不能使用-fexceptions和-frtti这两个编译选项。
Android.mk文件语法
参考http://www.cnblogs.com/yaozhongxiao/archive/2012/03/06/2382225.html
* 该文件用来描述build system编译系统的，是一个微型的GNU Makefile片段，由build system解析一次或者多次
* 这个文件的目的是用来允许你将源文件组织成模块，这个模块中含有：一个静态库(.a文件) 或 一个动态库(.so文件)，只有动态库才会被安装/复制到你的应用程序包，尽管静态库可以被用来生成动态库。
* 你可以在每个模块中都定义一个Android.mk文件，你也可以让多个模块共用一个Android.mk文件。build system可以为你处理许多细节，例如：你不需要在Android.mk文件中列出头文件或者其他的依赖关系，这些NDK的build system会自动为你计算并处理。这也意味着，当更新到新版本的NDK的时候，你应该得益于新的toolchain/platform的支持，而无需修改你的Android.mk文件。
* 例子
-----------------Android.mk------------------- LOCAL_PATH := $(call my-dir) include $(CLEAR_VARS) LOCAL_MODULE := hello-jni LOCAL_SRC_FILES := hello-jni.c include $(BUILD_SHARED_LIBRARY) ----------------------------------------------
LOCAL_PATH：=$(call my-dir) ,必须，文件要以这句话开始，用于在树中定位文件
include $(CLEAR_VARS)，必须，CLEAR_VARS变量是由build system提供的，并且指明了一个GNU makefile文件，这个功能会清理掉所有以LOCAL_开头的内容（例如LOCAL_MODULE,LOCAL_SRC_FILES,LOCAL_STATIC_LIBRARIES等），除了LOCAL_PATH，这句话是必须的，因为如果所有的变量都是全局变量的话，所有的可控的编译文件都需要在一个单独的GNU中被解析并执行
LOCAL_MODULE :=hello-jni，必须被定义，用以区分android.mk中的每个模块
LOCAL_SRC_FILES := hello-jni.c，这里包括一个C和C++源文件的列表，会编译聚合到一个模块中，有时这里可能会漏掉一些需要编译的文件。这里并不需要你列出头文件和被包含的文件，因为编译系统会自动为你计算相关的属性，源代码中的列表会直接传递给编译器。
include $(BUILD_SHARED_LIBRARY)，BUILD_SHARED_LIBRARY这个变量是由系统提供的，并且指定给GNU Makefile的脚本，它可以收集所有你定义的include $(CLEAR_VARS)中以LOCAL_开头的变量，并且决定哪些要被编译，哪些应该做的更加准确。
LOCAL_SHORT_COMMANDS := true /flase，当你的module有很多的源文件，或者依赖很多的静态或动态库。这会强制编译系统使用一个中间的列表文件，并通过@$(listfile) 语法和library archiver 或者 static linker一起使用。这在Windows上是非常有用的，因为它的命令行只接收最大8191个字符，这对于复杂的工程来说太小了。这同样也会影响单个源文件的编译，如果将所有的编译器选项放在列表文件里面。注意如果设置了‘true’以外的值，都会恢复成默认行为。你也可以在Android.mk文件中定义APP_SHORT_COMMANDS来强制使你的工程中的所有modules使用这项功能注意：默认我们不推荐启用这个功能，因为它会使得编译变慢。该变量可以解决如下编译问题：make: execvp: /home/android-ndk-r9d/toolchains/arm-linux-androideabi-4.6/prebuilt/windows-x86_64/bin/arm-linux-androideabi-g++: Argument list too long
APP_SHORT_COMMANDS , LOCAL_SHORT_COMMANDS 可以解决链接时参数太长的问题（生成.a .so时中间文件过多）
然而，编译，生成 libcrypto.so时
在libcrypto模块中采用LOCAL_SHORT_COMMANDS:=true来指定会导致编译错误，
在Application.mk中指定 APP_SHORT_COMMANDS:=true可以顺利编译，链接
<p>版权声明：本文为博主原创文章，未经博主允许不得转载。</p>