Android Framework一些问题思考

一，zygote通信为什么用socket，而不是binder?

1，binder通信依赖用户空间进程Servicemanager，socket通信不依赖用户空间进程。zygote与servicemanager, surfaceflinger等都是通过各自init.rc文件被init进程解析加载，时序上无法保证zygote启动时候servicemanager一定加载好了。

2，Linux不推荐fork一个多线程的进程的。因为在存在锁的情况下，fork容易导致锁异常。如果zygote使用binder，作为binder服务端至少有一个线程池，要考虑死锁问题。

3，如果zygote使用binder通讯机制的话，从Zygote中fork出的子进程也会有一块mmap的内存。这块内存无用。socket是使用时候copy_from_user 再copy_to_user，虽然两次拷贝，但是中间不会产生额外内存。

4，如果通信从socket改成binder, 则binder组件需要设计逻辑清理fork出来子进程的服务端实例。除了要修改封装的libbinder库，可能binder驱动要增加一套（ioctl）逻辑。而使用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，JAVA环境。如果直接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虚拟机最基本的资源加载。如果JAVA进程是system_server孵化，则孵化后的进程都跟system_server一样大，臃肿且浪费。

3，子进程需要考虑许多父子进程关系的代码逻辑。AMS, PMS等各种服务基本上只能让父system_server进程注册。子进程中这些fork出来的对象要想办法关闭自己并释放内存以免跟父进程各种模块冲突。而zygote fork出来的子进程只要记得关闭server socket即可，其他的组件可以根据自己的代码逻辑慢慢创建。