本章节所有内容皆为原创，如需转载，请注明出处。
http://blog.csdn.net/manoel/article/details/38471825
Android是一个多用户，多任务的系统。
允许多个app在同一时刻执行，在多个程序之间切换并不会有明显的延迟。
多任务是由Linux内核负责处理的，而程序的运行基于Linux进程。
Linux进程
Linux为每一个用户分配一个唯一的用户ID（User ID），用于区分不同的User。
因为权限的原因，每一个用户只能访问私有资源，没有用户（除了Root用户，即超级管理员。我们这里不考虑这个用户。）可以访问其他用户的私有资源。因而，“沙盒”就用来独立这些用户。
在Android中，每一个应用都有一个唯一的用户ID，也就是说，Android中的App对应着Linux中的用户，并且App之间不能互访资源。
Android为每一个进程都添加了一个Dalvik虚拟机，也就是每一个app都对应一个Dalvik虚拟机。
下图展示了Linux进程，Dalvik虚拟机和App之间的关系。
默认地，App和进程有一对一的关系。
但如果有需要的话，一个App可以在几个进程中运行，或者几个App在同一个进程中运行。
生命周期
App的生命周期被封装在它自己的Linux进程中，从Java的视角来说，就是android.app.Application类。
当Dalvik调用Application的onCreate()方法时，Applicationg对象就被生成了。理想情况下，Dalvik调用Application的onTerminate()的时候，app就停止了。
但切记，不能依靠这个去判断一个Application对象被销毁了！
因为潜在的Linux进程或许已经被Kill掉了，这个时候Dalvik还没有调用onTerminate()。
总之，Application对象是在一个进程中第一个被实例化的对象，也是最后一个被销毁的。
App启动
当一个App的任何一个组件被激活的时候，这个App就被开启了。
任何组件都是App的入口。还记得吗，组件包括：Activity，BroadcastReceiver，Service和ContentProvider。
当第一个组件被激活的时候，这个App的Linux进程就被激活了，除非这个Linux进程已经处于运行状态。
App开启的过程总结如下：
- 开启Linux进程.
- 创建Dalvik虚拟机.
- 创建Application实例.
- 创建App的入口组件.
建立一个新的Linux进程和Dalvik虚拟机并不是一个瞬时的操作。这个过程会降低性能，并且对用户体验稍有影响。
因此，Linux系统通过在启动（系统启动）的时候开启一个特别的Zygote进程去缩短App的启动时间。
这是怎么回事呢。Zygote包括了所有预加载的核心库，新的App进程就是从这个Zygote进程孵化出来的，但是App进程并不会复制那些预加载的核心库，而是共用Zygote的核心库。
就是这样，缩短了App的启动时间。
App终结
在App启动的时候，Linux进程被创建，当系统需要回收资源的时候Linux进程终结。为了保证用户每次进入App时不会重复上面的流程。如果不是真的到了资源缺的地步，Dalvik是不会销毁这个App的所有资源的。因此，尽管一个App的所有组件都被销毁了，这个App也不会自动终结。
当系统处于资源紧缺的时候，Dalvik负责决定哪一个进程要被Kill掉。那到底是基于什么去决定是哪一个进程呢？
基于App的可见性和它的组件运行情况，系统对进程进行分级处理。也就是说，低级别进程在高级别进程之前被Kill掉。
下面是进程的各个级别：
- Foreground
- App在前台有可见的组件，或者有一个Service与其他进程中的某个可见的Activity处于绑定状态，或者BroadcastReceiver正在运行。
- Visible
- App有一个部分可见的组件。
- Service
- Service处于运行状态，但是并没有和一个可见的组件绑定。
- Background
- 不可见的Activity。
- Empty
- 没有活跃组件的进程。空进程之所以存在，就是为了改善App的启动次数，但是它们也会第一个被Kill掉。