Launcher启动Acivity（未启动Activity所在进程）
public abstract class LauncherActivity extends ListActivity {
@Override
protected void onListItemClick(ListView l, View v, int position, long id) {
Intent intent = intentForPosition(position);
startActivity(intent);
}
}已有进程启动Acivity
无论是那种方式，事件都是从Activity的startActivity(intent)开始的。
这是一张我画的已有进程启动Activity的时序图：
通过这张时序图我们可以发现Activity的启动是一件很复杂的东西，这里面隐藏了很多的细节，涉及到了多次的IPC（进程间通信），上面的场景可以想象成Activity_A启动Activity_B,这张时序图里包含很多的知识点.
知识点1:
不知道大家有没有看过我的Binder机制图解那篇文章，client端持有Proxy代理对象，访问Server端的本地对象时,Server端是通过Binder线程池中的线程来处理进程间通信的,这也是为什么程序会设计的一个名为H的内部类，因为当ApplicationThreadProxy调用ApplicationThread执行相应的pause或者create操作的时候，ApplicationThread这个Binder本地对象实际上是在Binder线程中执行的，所以才需要H这个Handler来和ActivityThread主线程进行线程间通信，ActivityThread只是一个普通的java类，并不是一个线程，但它位于进程中，那ActivityThread的动力是什么？
这里我引用了http://mp.weixin.qq.com/s/JSrMjvBVBYeq6iBOWTGUng凶残的程序员文章中的一段话和图片
ActivityThread 的动力是什么？
进程
每个app运行时前首先创建一个进程，该进程是由 Zygote fork 出来的，用于承载App上运行的各种 Activity/Service等组件。进程对于上层应用来说是完全透明的，这也是google有意为之，让App程序都是运行在 Android Runtime。大多数情况一个App就运行在一个进程中，除非在 AndroidManifest.xml 中配置 Android:process 属性，或通过 native 代码 fork 进程。
线程
线程对应用来说非常常见，比如每次 new Thread().start 都会创建一个新的线程。该线程与App所在进程之间资源共享，从Linux 角度来说进程与线程除了是否共享资源外，并没有本质的区别，都是一个 task_struct结构体，在CPU看来进程或线程无非就是一段可执行的代码，CPU 采用 CFS调度算法，保证每个 task 都尽可能公平的享有 CPU时间片。
其实承载 ActivityThread 的主线程就是由 Zygote fork 而创建的进程。
扫描二维码关注公众号，回复： 2879429 查看本文章
知识点2:
onPause中为什么不推荐执行耗时操作，我们知道Activity_A启动Activity_B会先启动Activity_A生命周期中的onPause回调函数，然后才执行Activity_B的生命周期中的onCreate回调函数，从时序图中我们可以发现H类将pause相关的信息转发给了位于主线程的ActivityThread，而ActivityThread又调用了Instrumentation的callActivityOnPause函数，最终执行Activity的onPause，也就是说这一系列的过程都是在主线程执行的，当然不可以进行耗时操作，这是其一，其二只有当onPause执行完成才会执行activityPaused方法调用ActivityManagerProxy执行下一步的操作，也就是说如果onPause逻辑过多，过于耗时将不能很好的启动Activity_B。
区别
那么已有进程和Launcher启动未启动进程的区别在于ActivityStack.startSpecificActivityLocked函数执行后，会进行要启动Activity是否有对应进程的判断，如果有直接执行realStartActivityLocked，如果没有就需要先创建进程。然后在进程启动后再执行realStartActivityLocked来启动Activity。
关于应用进程的创建我将单独发一篇博客来说明，然后大家再结合这张时序图将空白进程创建部分补上。