本文基于MTK2601 – Android5.1分析
1、所有的进程都是init进程的子孙进程，也就是说，所有的进程都是直接或者间接地由init进程fork出来的。Zygote进程也不例外，它是在系统启动的过程，由init进程创建的。在系统启动脚本system/core/rootdir/init.zygote32.rc文件中，我们可以看到启动Zygote进程的脚本命令：
zygote入口
2、app_process运行后且传入参数（SystemServer得到加载），对应源码如下：
frameworks/base/cmds/app_process/app_main.cpp:
截取main函数关键代码：
Android运行时环境
运行时环境加载Java层Zygote
frameworks/base/core/jni/AndroidRuntime.cpp:
截取start函数关键代码：
加载虚拟机
运行ZygoteInit.java的main方法
由以上代码可知，VM运行后会直接获得JNIEnv* env指针；剩下的就是JNI的用法了。
截取startVm部分关键代码：
参数；注释
初始化
jni.h
3、如此一来，代码顺序来到Java层，ZygoteInit的main方法关键代码：
ZygoteInit.java
1) registerZygoteSocket:创建了一个ServerSocket接口，用来和ActivityManagerService通讯
这部分代码可自行查看源码，说白了就是Android系统封装的Java套接字；
ZygoteInit是套接字服务端。
2) 调用startSystemServer函数来启动SystemServer组件
孵化SystemServer进程
handleSystemServerProcess方法截取：
子进程关闭serversocket
goes runtime init
goes applicationInit
最终调用对应类的main方法
RuntimeInit的invokeStaticMain方法
此时的class就是上文代码中的com.android.server.SystemServer
3) 调用runSelectLoop函数进入一个无限循环在前面创建的socket接口上等待ActivityManagerService请求创建新的应用程序进程。
此处是一个while(true); 并且调用ZygoteConnection的runOnce方法
ZygoteConnection.java
handleChildProc调用对应的main方法
ZygoteInit的invokeStaticMain方法
ActivityManagerService会通过Process的start方法和ZygoteInit进行socket通信，并且创建一个子进程，相当于Java套接字的客户端；此套接字在Process中维护：
Process.java
ActivityManagerService中的调用关系：
开启新的进程
发送新进程的参数
把相关参数发送给Zygote（上文有zygoteconnection接收参数的代码，并且会调用handleChildProc方法，此方法就已经是子进程了）；
由以上代码分析此时classname就是android.app.ActivityThread；并且作为新进程的主进程。
ActivityThread想必都熟悉了，典型的Looper线程，且不会退出。
4、SystemServer分析：
由上可知，SystemServer的main方法在子进程中被调用。
main
run方法如下：
又一个典型的Loop而线程
向ServiceManager中add系统服务
1）startBootstrapServices();
例如：Installer、ActivityManagerService、PowerManagerService、DisplayManagerService、PackageManagerService、UserManagerService
2）startCoreServices();
例如：LightsService、BatteryService、UsageStatsService、WebViewUpdateService
3）startOtherServices();
此处服务较多。。。看源码吧
服务加载完成后，不过有一个地方需要贴出来：
大名鼎鼎的SystemUI
另外，SystemServer有一个非常重要的方法：
大名鼎鼎的SystemUI
以后要定制一些服务可以直接加在ServiceManager里面了；应该不太容易被系统杀死吧O(∩_∩)O哈哈哈~
4、分析新应用的启动（两种情况）：
1）非SystemServer应用进程：
入口是ActivityThread的main函数：
attach是false
也就是fork完子进程后的线程就是主线程，另外可以看下Looper.prepareMainLooper函数。
2）SystemServer的run方法有一句：
// Initialize the system context.
createSystemContext();
可在之前截图中查看；接下来：
初始化ActivityThread和上下文对象
attach是true
SystemServer中的上下文就此初始化
跟到attach方法中：
通过boolean区分system进程
1）先看else里面：
mInitialApplication就是一个Application实例，且直接调用了onCreate方法。
貌似没有看出有啥猫腻，Application在SystemServer中有啥用呢？
2）另一种情况下（可以看见有heap限制）：
我们可以看见，直接拿到ActivityManagerNative，调用attachApplication方法，ActivityManagerNative是抽象类，其实现类就是ActivityManagerService。
attachApplication方法调用attachApplicationLocked方法：
thread对象实质是就是Binder对象
thread和ActivityThread的mAppThread是同一个Binder。
由此发现，ActivityManagerService实际上是和ActivityThread的内部类ApplicationThread直接进行交互的（由于Binder的存在），具体有activity的生命周期、service的生命周期以及服务的绑定、解绑等搔操作，哈哈。
ApplicationThread的bindApplication方法最后会用Handler向ActivityThread发消息：
……
BIND_APPLICATION消息
消息处理如下：
……
通过Instrumentation回调app的onCreate
Application至此创建完毕
回到上面attachApplicationLocked方法，有一句：
mStackSupervisor.attachApplicationLocked(app)；方法内部会调用自己的realStartActivityLocked方法：
同样是Binder操作
LAUNCH_ACTIVITY消息
同样是用Handler给ActivityThread发消息；
消息处理
performLaunchActivity方法应该就比较熟悉了，截取关键部分吧：
实例化Activity
初始化上下文，完成onCreate回调
callActivityOnCreate跟进去就对应到Activity的onCreate了。
图中的appContext对象就是ContextImpl的实例；也就是我们常常在Activity中用的上下文O(∩_∩)O哈哈~
