本文分析so加载的步骤，其实在之前dalvik浅析二中也有提及，但那重点关注的是jni。android中so库的加载，代码如下：
loadLibrary("nanosleep");我们来看下它的执行流程吧：
先调用dlopen来载入so文件；find_library在soinfo结构(进程加载的so链)中查找当前so是否已载入，否则去执行so载入流程。so载入后，find_library会返回soinfo，去执行so的CallConstructors函数；如果so包含init、init_array段，则此函数会先执行这init和init_array。dlopen函数执行完毕表示系统对so操作告一段落，接着通过dlsym获取地址去执行JNI_LOAD。对一般而言so的加载和执行到此为止了，下图是我们通常会关注到的执行流程：
普通而言就这样了，但这并不能满足我们的求知欲。下面以android4.4的linker代码来分析下后续的流程：
上面说到通过find_library函数来判断so是否已加载，而在该函数中实质是调用find_library_internal函数去实现全部功能的。来看下find_library_internal的执行流程，
在find_loaded_library中通过soinfo结构提取出so的name比较来进行判别so是否已加载。load_library函数分三步执行：1.打开so文件得到文件描述符；2.ElfReader(linker_phdr.h)结构体去加载(mmap)elfheader、elf_phdr、elf_segment;3.将ElfReader解析到的elf信息填充到soinfo结构体中。这里我们先看下load函数，究竟是load了哪些东东
bool ElfReader::Load(const android_dlextinfo* extinfo) {
return ReadElfHeader() && //读取elf头到rc
VerifyElfHeader() && //验证rc是否为elf头，主要是验证magic、type、version
ReadProgramHeader() && //mmap映射segment 头
ReserveAddressSpace(extinfo) && //
LoadSegments() && //映射load segment:代码段和数据段
FindPhdr(); //判断是否有PT_PHDR segment
}当然这里soinfo_link_image是重头戏：
elf文件格式(强烈建议在看本文之前观看)。不知各位看官注意到没有，对于载入so来说，只需segment就可以开工了(elf_shdr在这里没有用)。再来看so加载的重定位操作。
rel节中取出elf32_rel并解析其type和elf32_sym，接着根据elf32_sym.name调用soinfo_do_lookup在其他so库(先前已加载)中找到对应的符号。soinfo_elf_lookup先将name hash并将此值作为hash表的索引得到funIndex，然后判断elf32_sym[funIndex].name是否相同。没说清楚，直接看源码吧
static Elf32_Sym* soinfo_elf_lookup(soinfo* si, unsigned hash, const char* name) {
Elf32_Sym* symtab = si->symtab;
const char* strtab = si->strtab;
TRACE_TYPE(LOOKUP, "SEARCH %s in %s@0x%08x %08x %d",
name, si->name, si->base, hash, hash % si->nbucket);
for (unsigned n = si->bucket[hash % si->nbucket]; n != 0; n = si->chain[n]) {
Elf32_Sym* s = symtab + n;
if (strcmp(strtab + s->st_name, name)) continue;
/* only concern ourselves with global and weak symbol definitions */
switch(ELF32_ST_BIND(s->st_info)){
case STB_GLOBAL:
case STB_WEAK:
if (s->st_shndx == SHN_UNDEF) { //SHN_UNDEF表示为外部调用，不是本so的函数，故还是没找到真正地址，继续找
continue;
}
TRACE_TYPE(LOOKUP, "FOUND %s in %s (%08x) %d",
name, si->name, s->st_value, s->st_size);
return s;
}
}
return NULL;
}
ok，从其他共享库中找到了对应的elf32_sym立刻保存其函数地址elf32_sym.st_value为sys_addr。然后根据type，将sys_addr处理后赋值给elf32_rel.r_offset所指向的值(这一步就是修改.got的值,.got保存着so外部调用符号的地址，类似于PE文件的IAT)。以上就是重定位的全部流程，就是帮外部调用找到其执行位置。
find_library就这样啦，来看看CallConstructors函数
void soinfo::CallConstructors() {
if (constructors_called) {
return;
}
if ((flags & FLAG_EXE) == 0 && preinit_array != NULL) {
// The GNU dynamic linker silently ignores these, but we warn the developer.
PRINT("\"%s\": ignoring %d-entry DT_PREINIT_ARRAY in shared library!",
name, preinit_array_count);
}
if (dynamic != NULL) {
for (Elf32_Dyn* d = dynamic; d->d_tag != DT_NULL; ++d) {
if (d->d_tag == DT_NEEDED) {
const char* library_name = strtab + d->d_un.d_val;
TRACE("\"%s\": calling constructors in DT_NEEDED \"%s\"", name, library_name);
find_loaded_library(library_name)->CallConstructors();
}
}
}
TRACE("\"%s\": calling constructors", name);
// DT_INIT should be called before DT_INIT_ARRAY if both are present.
CallFunction("DT_INIT", init_func);
CallArray("DT_INIT_ARRAY", init_array, init_array_count, false);
}
void soinfo::CallDestructors() {
TRACE("\"%s\": calling destructors", name);
// DT_FINI_ARRAY must be parsed in reverse order.
CallArray("DT_FINI_ARRAY", fini_array, fini_array_count, true);
// DT_FINI should be called after DT_FINI_ARRAY if both are present.
CallFunction("DT_FINI", fini_func);
}
CallConstructors里主要执行2个函数CallFunction、CallArray，即执行.init和.init_array节区的函数(可以在写so函数时指定在.init_array节)：
通过__attribute__((constructor(num)))声明某一函数(num 值越小， 越先执行 )， 即指定了在.init_array 中的位置， 修改其顺序即可实现。 例如：void __attribute__((constructor(101))) kingcoming(); ——by ThomasKing
CallDestructors在卸载so调用，也是执行2个函数与CallConstructors相对应的。值得一提的是constructors_called，它防止so的Constructors被重复调用，当前so有调用其他共享库的函数，则先执行其他共享库的Constructors。
dlopen完结了，而dlsym实质就是soinfo_elf_lookup来找到对应的函数。
