NDK开发之一

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结构:

NDK开发之一

其中e_ident为固定16个字节大小的数组,称为ELF Identification,包含了处理器类型、文件编码格式、机器类型等,具体结构如下:

NDK开发之一

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 表示生成可执行文件。

上一篇:【P4语言学习】Parser解析器


下一篇:recv send 阻塞和非阻塞