一，zygote通信为什么用socket，而不是binder?
1，binder通信依赖Servicemanager，socket通信不依赖用户空间进程。zygote与servicemanager, surfaceflinger等都是通过各自init.rc被init创建，时序上无法保证zygote启动时候servicemanager一定加载好了。
2，Linux推荐fork一个多线程的进程的。因为如果存在锁的情况下，fork容易导致锁异常。如果zygote使用binder，则至少有一个线程池。
3，如果使用binder通讯机制的话，从Zygote中fork出子进程也会有一块mmap的内存。这块内存无用。socket是使用时候copy_from_user 再copy_to_user，虽然两次拷贝，但是中间不会产生额外内存。
4，如果改成binder, 则binder组件需要设计逻辑清理fork出来子进程的服务端与上述mmap内存。除了封装的libbinder库，可能binder驱动要增加一套逻辑。而使用socket就简单了，直接在子进程中关闭server socket的句柄, 不影响父进程的server socket。
5，framework的确有很多模块，从以前的socket换成了binder, 比如lmkd模块。但是zygote逻辑已经稳定了，没必要再换。
二，为什么system_server需要在zygote中启动，而不是由init直接启动？
1，对于native层面，进程在init.rc里面只要没有one shot 或者disable标签，则默认是守护进程，可以在crash后重新启动。而system_server是JAVA代码，linux表示看不懂JAVA代码。
2，zygote是加载java虚拟机的native进程，加载了很多java需要用到的so。如果要init来启动system_server，那么system_server还需要先进行加载java虚拟机的过程。即必要的工作并不会减少，那何不在两个进程做自己的事情。
3，相对来说system_server容易出现watch dog, crash等异常。在它crash之后，可以由zygote重新拉起。
三，为什么要专门使用zygote进程来孵化应用进程，而不是让system_server来进行孵化呢？
1，Linux不推荐fork一个多线程的进程的。因为如果存在锁的情况下，fork会导致锁异常。system_server的线程池不是32就是64, 很容易出问题。
2，zygote比较小，孵化的子进程有java虚拟机最轻量级的资源加载。如果是system_server孵化，则孵化后的进程都跟system_server一样大，很占用资源且浪费。
3，子进程很多考虑父子进程关系的代码逻辑要处理。服务端基本上只能有一个进程注册，比如AMS，子进程中这些注册成服务端的模块要想办法关闭自己并释放内存以免跟父进程system_server冲突。而zygote fork出来的子进程只要记得关闭server socket即可。