Android = Linux Kernel + C/C++ Runtime Framework + Davik Virtual Machine + Java Runtime Framework + Java SDK。下面我们再以APK的开发、编译、安装和运行来说明这些层次之间的关系。

首先，我们是在PC上使用Android SDK提供的接口来开发APK，用的Java语言。开发完成之后，使用Java编译器将源代码编译成Java字节码，也就是带.class后缀的文件。接下来这些.class再被Android SDK提供的dx工具转化成Dex字节码，最后打包在APK里面的classes.dex文件中。

接着，APK文件在手机上安装时，Java Runtime Framework里面的PacakgeManagerService就会对该APK文件进行解析，并且通过Socket IPC通知C/C++ Runtime Framework里面的installd守护进程对APK里面的classes.dex文件进行优化，得到另外一个classes.odex文件。

APK安装完成之后，就可以运行了。我们以APK从桌面Launcher启动的过程为例说明它的运行过程。当我们从Launcher点击应用图标的时候，Launcher向Java Runtime Framework里面的ActivityManagerService发送一个启动应用的请求。ActivityManagerService又通过Socket IPC向C/C++ Runtime Framework里面的zygote守护进程请求创建一个应用程序进程。这个应用程序进程包含有一个Dalvik虚拟机。应用程序进程创建并且启动起来之后，就会通过它里面的Dalvik虚拟机加载前面提到的classes.odex文件。这样我们的应用程序就运行起来了。

APK的运行过程是依赖于Dalvik虚拟机的。我们可以将它看成是将classes.odex里面的字节码解释成本地机器指令执行。例如，我们在APK里面通过FileInputStream或者FileOutputStream打开一个文件的时候，Dalvik虚拟机就会找到C/C++ Runtime Framework里面的C库bionic提供的系统接口open，并且通过它来打开指定的文件。

我们再以应用程序界面的绘制和渲染过程来详细说明各个层次的关系。首先是应用程序通过SDK提供的UI类向Java Runtime Framework里面的WindowManagerService申请分配一块图形缓冲区。WindowManagerService又是通过Binder IPC向C/C++ Runtime Framework里面的SurfaceFlinger申请分配图形缓冲区的。图形缓冲区实际上不是由SurfaceFlinger分配的，而是由显示系统分配的，可能在显存里面，也有可能在GPU里面。这时候SurfaceFlinger就要通过HAL层次Gralloc模块向Kernel里面的显卡或者GPU驱动申请分配真正的图形缓冲区。HAL层可以看作是运行在C/C++ Runtime Framework中。

应用程序得通过上述方式得到绘制UI所需要的图形缓冲区之后，就开始绘制自己的UI了。假设应用程序使用的是硬件绘制方式，也就是通过C/C++ Runtime Framework里面的OpenGL来绘制。这时候SDK的UI类的与绘制相关的函数调用通过Dalvik虚拟机都转化成了C/C++ Runtime Framework里面的OpenGL操作。

应用程序UI绘制完成之后，结果就保存上述的图形缓冲区中。这时候如果要将该图形缓冲区渲染到手机屏幕上，那么还需要通过Binder IPC将该图形缓冲区发送给C/C++ Runtime Framework里面的SurfaceFlinger。SurfaceFlinger通过使用OpenGL或者HWComposer将所有请求要渲染到手机屏幕上的图形缓冲区合成之后，得到一个主图形缓冲区。最后这个图形缓冲区又会被SurfaceFlinger提交给Kernel的显卡驱动，并且在手机屏幕上进行显示。

上面描述的就是Android系统各个层次的调用关系。总的来说，应用程序运行在Dalvik虚拟机上，并且通过SDK使用Java Runtime Framework里面的服务，而Java Runtime Framework里面的服务又通过C/C++ Runtime Framework里面的服务来实现自己的功能，最后C/C++ Runtime Framework里面的服务又会在需要的时候请求Kernel里面的模块或者驱动来为自己服务。