System_Server为什么要在Zygote中启动，而不是init直接启动
Zygote作为一个孵化器，可以提前加载一些资源，这样fork()时基于Copy-on-Write机制创建的其他进程就能直接使用这些资源，而不用重新加载，比如System_server就可以直接使用Zygote中的JNI函数、共用库、常用的类、以及主题资源。
为什么要专门用Zygote去孵化应用进程，而不是System_Server去孵化
首先System_server相比Zygote多运行了AMS、WMS、等服务，这些对一个应用程序来说是不需要的，另外进程fork()对多线程不友好，仅会将发起调用的线程拷贝到子线程，这可能不会导致死锁，而System_server中肯定是有很多线程的 在POSIX标准中，fork的行为是这样的，复制整个用户空间的数据（通常使用copy-on-write的策略，所以可以实现的速度很快）以及所有系统对象，然后仅复制当前线程到子进程，这里：所有父进程中别的线程，到了子进程中都突然蒸发掉的。对于锁来说，从OS看，每个锁有一个所有者，即子厚一次lock它的线程，假设这么一个环境，在fork之前，有一个子线程lock了某个锁，获得了对锁的所有权，fork以后，在子进程中，所有的额外线程都人间蒸发了，而锁却被正常复制了，在子进程看来，这个锁没有主人，所以没有任何人可以对它解锁，当子进程想lock这个锁时，不再有任何手段可以解开了，程序发生了死锁
Zygote为什么采用Binder机制进行IPC通信
Binder机制中存在Binder线程池，是多线程的，如果Zygote采用Binder的话，就存在上面的fork()与多线程的问题，其实严格来说，Binder机制不一定要多线程，所谓Binder线程只不过是在循环读取Binder驱动的消息而已，只注册一个Binder线程也是可以正常工作的，如Service_manager就是这样的，实际上Zygote尽管没有采用Binder机制，它也不是单线程的，但是它在fork()前停止了其他线程，fork()后重新启动了
