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掉。
參考资料
http://developer.android.com/guide/components/processes-and-threads.html#Lifecycle