2015.07.22
Wiki_Tree:
--NDK开发；
--NDK特征；
--MK文件编写规则；
NDK开发：
Ndk-build编译时会生成的两个同名的so库，位于不同的目录/project path/libs/armeabi/xxx.so和/project path/obj/local/armeabi/xxx.so，比较两个so文件会发现体积相差很大。前者会跟随App一起发布，所以尽可能地小，而后者包含了很多调试信息，主要为了gdb调试的时候使用，当然，NDK的日志符号化信息也包含其中。
C++崩溃的符号化工具ndk-stack、addr2line、objdump
readelf可以查看so文件的结构信息,so是shared object区别于executable\relocatable,统称 EFL。
ELF Header
ELF Header文件头的结构如下，记录了文件其他内容在文件中的偏移以及大小信息。这里以32bit为例：
typedef struct {
unsigned char e_ident[EI_NIDENT];
Elf32_Half e_type; // 目标文件类型，如relocatable、executable和shared object
Elf32_Half e_machine; // 指定需要的特定架构，如Intel 80386，Motorola 68000
Elf32_Word e_version; // 目标文件版本，通e_ident中的EI_VERSION
Elf32_Addr e_entry; // 指定入口点地址，如C可执行文件的入口是_start()，而不是main()
Elf32_Off e_phoff; // program header table 的偏移量
Elf32_Off e_shoff; // section header table的偏移量
Elf32_Word e_flags; // 处理器相关的标志
Elf32_Half e_ehsize; // 代表ELF Header部分的大小
Elf32_Half e_phentsize; // program header table中每一项的大小
Elf32_Half e_phnum; // program header table包含多少项
Elf32_Half e_shentsize; // section header table中每一项的大小
Elf32_Half e_shnum; // section header table包含多少项
Elf32_Half e_shstrndx; //section header table中某一子项的index，该子项包含了所有section的字符串名称
} Elf32_Ehdr;
ELF结构：
其中e_ident为固定16个字节大小的数组，称为ELF Identification，包含了处理器类型、文件编码格式、机器类型等，具体结构如下：
ndk(native development kit) 解压：tar -xf ndk-linux-x86.tar
1.添加：export PATH="/target/bin:$PATH"
2.source .bashrc
NDK特征：
1.NDK集成了交叉编译器，并提供了相应的mk文件隔离CPU、平台、ABI等差异，开发人员只需要简单修改mk文件（指出“哪些文件需要编译”、“编译特性要求”等），就可以创建出so。
2.
2.NDK提供了一份稳定、功能有限的API头文件声明
Google明确声明该API是稳定的，在后续所有版本中都稳定支持当前发布的API。从该版本的NDK中看出，这些API支持的功能非常有限，包含有：C标准库（libc）、标准数学库（libm）、压缩库（libz）、Log库（liblog）。
Jni使用:
//声明函数
public native void method();
static{
System.LoadLibrary("what_jni");
}
1.编写java代码；
2.编写c代码,javah生成了h、class文件；编写mk文件，ndk-build生成so文件。
3.联合编译。
MK编写规则
LOCAL_PATH :=
$(call my-dir)
Android.mk
文件首先必须定义好LOCAL_PATH变量。它用于在开发树中查找源文件。在这个例子中，宏函数’my-dir’,
由编译系统提供，用于返回当前路径（即包含Android.mk file文件的目录）。
include $(
CLEAR_VARS)
CLEAR_VARS由编译系统提供，指定让GNU MAKEFILE为你清除许多LOCAL_XXX变量（例如
LOCAL_MODULE, LOCAL_SRC_FILES,
LOCAL_STATIC_LIBRARIES, 等等...),
除LOCAL_PATH 。这是必要的，因为所有的编译控制文件都在同一个GNU MAKE执行环境中，所有的变量都是全局的。
LOCAL_MODULE :=
hello-jni
编译的目标对象，LOCAL_MODULE变量必须定义，以标识你在Android.mk文件中描述的每个模块。名称必须是唯一的，而且不包含任何空格。
注意：编译系统会自动产生合适的前缀和后缀，换句话说，一个被命名为‘hello-jni‘的共享库模块，将会生成‘libhello-jni.so‘文件。
重要注意事项：如果你把库命名为‘libhello-jni’，编译系统将不会添加任何的lib前缀，也会生成
‘libhello-jni.so‘，这是为了支持来源于Android平台的源代码的Android.mk文件，如果你确实需要这么做的话。
LOCAL_SRC_FILES :=
hello-jni.c
LOCAL_SRC_FILES变量必须包含将要编译打包进模块中的C或C++源代码文件。注意，你不用在这里列出头文件和包含文件，因为编译系统将会自动为你找出依赖型的文件；仅仅列出直接传递给编译器的源代码文件就好。
注意，默认的C++源码文件的扩展名是’.cpp’.
指定一个不同的扩展名也是可能的，只要定义LOCAL_DEFAULT_CPP_EXTENSION变量，不要忘记开始的小圆点（也就是’.cxx’,而不是’cxx’）
include
$(BUILD_SHARED_LIBRARY)
BUILD_SHARED_LIBRARY表示编译生成共享库，是编译系统提供的变量，指向一个GNU
Makefile脚本，负责收集自从上次调用‘include
$(CLEAR_VARS)‘以来，定义在LOCAL_XXX变量中的所有信息，并且决定编译什么，如何正确地去做。还有
BUILD_STATIC_LIBRARY变量表示生成静态库：lib$(LOCAL_MODULE).a， BUILD_EXECUTABLE 表示生成可执行文件。