Native进程的运行过程

一般程序的启动步骤，可以用下图描述。程序由内核加载分析，使用linker链接需要的共享库，然后从c运行库的入口开始执行。

通常，native进程是由shell或者init启动，启动的过程如下：

Shell接收到命令，启动一个程序，此时shell首先会fork一个新的进程

新fork的进程，通过execve系统调用，陷入到内核中，内核检查和加载需要执行的二进制映像文件，检验其合法性及权限。通常用户态进程要启动一个新的程序(如shell)，fork后，execve要紧跟着执行，这样会有更好的效率(由于使用COW技术，这样可以避免页表复制，而execve后，之前进程中的所有内容都是无用的，若execve紧跟fork后，可以避免COW引起的拷贝);

通常二进制文件都会要依赖一些系统动态库，此时kernel会启动加载器/system/bin/linker，执行linker的__linker_init()

Linker的linker_init()，会分析二进制的elf文件，加载依赖的动态库文件，然后转入二进制映像的入口函数__start中执行

__start会调用C库的初始化函数__libc_init()

__libc_init()会调用映像的main函数，这个main函数也就是用户app的入口函数

main() 函数执行完毕后，通过exit()退出进程执行

需要注意的是，Android bionic提供的加载器是/system/bin/linker，而普通linux系统用的glibc是/lib/ld-linux-xx.so.2。这也是为何其他linux平台同指令架构的二进制文件，不能在android上运行的原因之一：启动用户进程的加载器这个程序运行的第一步就出错了。

Java进程的运行过程

Java进程的启动比较特殊，Java进程是zygote启动的，zygote在folk进程之后，并没有执行execve指令，因此是共享了zygote的代码段和数据段。其它的java进程，可以看做都是zygote的克隆，克隆之后的进程，各自根再据自己的需求(java代码),解释java语言。

也就是说：Android的所有进程，从native角度看都是zygote。 其对应的程序都是 /system/bin/app_process，虚拟机是运行在其中的。

那为何java进程又如此的不同呢？ 实际上，从native的角度看，不同的各种java程序，可以如此理解：只是/system/bin/app_process 这个程序，因为不同的输入(Java dex字节码)而引起的。

上图中，user APK实际上市zygote的一个克隆(启动->进入main等之前的流程没有画出， app进程没有这个步骤，是从zygote进程中克隆过来)，差别主要在dvm虚拟机执行的java代码的不同导致的表现的行为差异巨大。

Java进程没有执行exec调用，这样有一个很大的好处：使用linux的COW(copy on Write)技术，就可以在多个java进程间，共享内存资源——主要是java的核心库。

Java程序也可以使用native库，此时的native库需要通过dlopen来打开(即java中，使用System.loadLibrary()方法加载so库，虚拟机对应会调用的C库方法)，dlopen加载so库的过程中，依旧会通过linker分析处理so库的elf信息，加载其它依赖的动态库。

(注：zygote实际上是/system/bin/app_process，zygote只是app_process的别名)