重学系列--系统启动到Activity(下)

Zygote 进程间通信原理

不熟悉Linux编程的同学看到死循环最后这一段，可能就有点懵。这里我解释一遍，在构造一下整个流程以及模型估计就能明白了。

虽然是socket通信，但是实际上和我们常说Java的socket编程稍微有一点点不一样。实际上更加像驱动中的文件描述的监听。这里和Android4.4的有点不一样，但是思路是一样。

Zygote监听服务端

从上面的代码，根据我的理论，peers这个ZygoteConnection是一个Zygote的链接对象，用来处理从远端的socket过来的消息。这个是一个关键类。我们看看这个ZygoteConnection究竟是怎么构造的。

    private static ZygoteConnection acceptCommandPeer(String abiList) {
        try {
            return new ZygoteConnection(sServerSocket.accept(), abiList);
        } catch (IOException ex) {
            throw new RuntimeException(
                    "IOException during accept()", ex);
        }
    }

实际上此处会new一个ZygoteConnection，会把LocalServerSocket的accpet传进去。此时就和普通的socket一样进入阻塞。

让我先把LocalSocket这一系列的UML图放出来就能明白，这几个类之间关系。

实际上，所有的LocalSocket，无论是服务端LocalServerSocket还是客户端LocalSocket都是通过LocalServerImpl实现的。

protected void accept(LocalSocketImpl s) throws IOException {
        if (fd == null) {
            throw new IOException("socket not created");
        }

        try {
            s.fd = Os.accept(fd, null /* address */);
            s.mFdCreatedInternally = true;
        } catch (ErrnoException e) {
            throw e.rethrowAsIOException();
        }
    }

这个Os对象通过Libcore.os.accept(fd, peerAddress);调用native层。
文件：/libcore/luni/src/main/native/libcore_io_Posix.cpp

static jobject Posix_accept(JNIEnv* env, jobject, jobject javaFd, jobject javaSocketAddress) {
    sockaddr_storage ss;
    socklen_t sl = sizeof(ss);
    memset(&ss, 0, sizeof(ss));
//判断java层的socket对象是否为NULL
    sockaddr* peer = (javaSocketAddress != NULL) ? reinterpret_cast<sockaddr*>(&ss) : NULL;
    socklen_t* peerLength = (javaSocketAddress != NULL) ? &sl : 0;

//核心，此处等待阻塞线程
    jint clientFd = NET_FAILURE_RETRY(env, int, accept, javaFd, peer, peerLength);
    if (clientFd == -1 || !fillSocketAddress(env, javaSocketAddress, ss, *peerLength)) {
        close(clientFd);
        return NULL;
    }
//一旦socket回调之后，将会通过底层的fd对象转化为java对象
    return (clientFd != -1) ? jniCreateFileDescriptor(env, clientFd) : NULL;
}

此处分为三步：

• 第一步，通过解析address是否为空，来决定阻塞的等待时长，此时传下来为null，为无限期的等待。
• 第二步，核心方法，通过define声明的NET_FAILURE_RETRY代码段，阻塞线程
• 第三步，一旦等待的socket链接有数据回调进来，则转化为java层的fd返回。

此处是阻塞的核心代码

#define NET_FAILURE_RETRY(jni_env, return_type, syscall_name, java_fd, ...) ({ \
    return_type _rc = -1; \
    int _syscallErrno; \
    do { \
        bool _wasSignaled; \
        { \
//转化java的fd，对Java进行监听
            int _fd = jniGetFDFromFileDescriptor(jni_env, java_fd); \
            AsynchronousCloseMonitor _monitor(_fd); \
            _rc = syscall_name(_fd, __VA_ARGS__); \
            _syscallErrno = errno; \
            _wasSignaled = _monitor.wasSignaled(); \
        } \
        if (_wasSignaled) { \
            jniThrowException(jni_env, "java/net/SocketException", "Socket closed"); \
            _rc = -1; \
            break; \
        } \
        if (_rc == -1 && _syscallErrno != EINTR) { \
            /* TODO: with a format string we could show the arguments too, like strace(1). */ \
            throwErrnoException(jni_env, # syscall_name); \
            break; \
        } \
    } while (_rc == -1); /* _syscallErrno == EINTR && !_wasSignaled */ \
    if (_rc == -1) { \
        /* If the syscall failed, re-set errno: throwing an exception might have modified it. */ \
        errno = _syscallErrno; \
    } \
    _rc; })

这里稍微解释一下，这段阻塞的核心方法的意思。
这循环代码的跳出条件有三个：

• _wasSignaled 为true 也就是说此时AsynchronousCloseMonitor通过线程锁ScopeThreadMutex上锁的线程被唤醒，说明了该socket断开，也就断开了阻塞。

• _rc 为-1 以及 _syscallErrno 错误标示位不为EINTER。rc为syscall_name（此时传进来的是socket的accept方法）。也就是说当accept链接出现异常的时候（返回-1）会一直在循环里面等待，除非为全局错误_syscallErrno 不是系统抛出的中断，则抛出异常。

• 当_rc不为-1，也就是说socket链接成功。则继续向下走。

因此从这里可以知道，Zygote在初始化runSelectLoop的时候，一开始会加入一个ZygoteConnection用于阻塞监听。一旦有链接进来，则唤醒则加入到peers队列中。在死循环下一个轮回的时候，通过执行runOnce执行fork新的进程。

虽然到这里似乎就完成整个流程了。但是实际上，google工程师写代码才不会这么简单就完成，而是做了一定的优化。

如果用Linux c写过服务器的哥们，就会明白这样不断的阻塞只会不断的消耗的cpu的资源，并不是很好的选择。

因此，runSelectLoop才有这一段代码

            StructPollfd[] pollFds = new StructPollfd[fds.size()];
            for (int i = 0; i < pollFds.length; ++i) {
                pollFds[i] = new StructPollfd();
                pollFds[i].fd = fds.get(i);
                pollFds[i].events = (short) POLLIN;
            }
            try {
                Os.poll(pollFds, -1);
            } catch (ErrnoException ex) {
                throw new RuntimeException("poll failed", ex);
            }

根据这段代码，从表面上可以清楚的知道，一开始把描述符都设置进去StructPollfd等长数组中。把这个数组交给Os.poll中。

我们先看看StructPollfd这个类是个什么存在。
文件/libcore/luni/src/main/java/android/system/StructPollfd.java

public final class StructPollfd {
  /** The file descriptor to poll. */
  public FileDescriptor fd;

  /**
   * The events we're interested in. POLLIN corresponds to being in select(2)'s read fd set,
   * POLLOUT to the write fd set.
   */
  public short events;

  /** The events that actually happened. */
  public short revents;

  /**
   * A non-standard extension that lets callers conveniently map back to the object
   * their fd belongs to. This is used by Selector, for example, to associate each
   * FileDescriptor with the corresponding SelectionKey.
   */
  public Object userData;

  @Override public String toString() {
    return Objects.toString(this);
  }
}

这个类十分简单。里面只有那么3个参数，events，revents，fd.分别是做什么的呢？

我们直接看看Os.poll方法底层的实现
文件：/libcore/luni/src/main/native/libcore_io_Posix.cpp

static jint Posix_poll(JNIEnv* env, jobject, jobjectArray javaStructs, jint timeoutMs) {

//反射获取structPollfd.java属性的属性id
    static jfieldID fdFid = env->GetFieldID(JniConstants::structPollfdClass, "fd", "Ljava/io/FileDescriptor;");
    static jfieldID eventsFid = env->GetFieldID(JniConstants::structPollfdClass, "events", "S");
    static jfieldID reventsFid = env->GetFieldID(JniConstants::structPollfdClass, "revents", "S");
//转化为ndk底层的文件描述符
    // Turn the Java android.system.StructPollfd[] into a C++ struct pollfd[].
    size_t arrayLength = env->GetArrayLength(javaStructs);
    std::unique_ptr<struct pollfd[]> fds(new struct pollfd[arrayLength]);
    memset(fds.get(), 0, sizeof(struct pollfd) * arrayLength);
    size_t count = 0; // Some trailing array elements may be irrelevant. (See below.)
    for (size_t i = 0; i < arrayLength; ++i) {
        ScopedLocalRef<jobject> javaStruct(env, env->GetObjectArrayElement(javaStructs, i));
        if (javaStruct.get() == NULL) {
            break; // We allow trailing nulls in the array for caller convenience.
        }
        ScopedLocalRef<jobject> javaFd(env, env->GetObjectField(javaStruct.get(), fdFid));
        if (javaFd.get() == NULL) {
            break; // We also allow callers to just clear the fd field (this is what Selector does).
        }
        fds[count].fd = jniGetFDFromFileDescriptor(env, javaFd.get());
        fds[count].events = env->GetShortField(javaStruct.get(), eventsFid);
        ++count;
    }

    std::vector<AsynchronousCloseMonitor*> monitors;
    for (size_t i = 0; i < count; ++i) {
        monitors.push_back(new AsynchronousCloseMonitor(fds[i].fd));
    }
//循环监听
    int rc;
    while (true) {
        timespec before;
        clock_gettime(CLOCK_MONOTONIC, &before);
//poll 阻塞进程
        rc = poll(fds.get(), count, timeoutMs);
        if (rc >= 0 || errno != EINTR) {
            break;
        }

        // We got EINTR. Work out how much of the original timeout is still left.
        if (timeoutMs > 0) {
            timespec now;
            clock_gettime(CLOCK_MONOTONIC, &now);

            timespec diff;
            diff.tv_sec = now.tv_sec - before.tv_sec;
            diff.tv_nsec = now.tv_nsec - before.tv_nsec;
            if (diff.tv_nsec < 0) {
                --diff.tv_sec;
                diff.tv_nsec += 1000000000;
            }

            jint diffMs = diff.tv_sec * 1000 + diff.tv_nsec / 1000000;
            if (diffMs >= timeoutMs) {
                rc = 0; // We have less than 1ms left anyway, so just time out.
                break;
            }

            timeoutMs -= diffMs;
        }
    }

    for (size_t i = 0; i < monitors.size(); ++i) {
        delete monitors[i];
    }
    if (rc == -1) {
        throwErrnoException(env, "poll");
        return -1;
    }
//唤醒之后更新runSelectLooper中的revents标识位，revents
    // Update the revents fields in the Java android.system.StructPollfd[].
    for (size_t i = 0; i < count; ++i) {
        ScopedLocalRef<jobject> javaStruct(env, env->GetObjectArrayElement(javaStructs, i));
        if (javaStruct.get() == NULL) {
            return -1;
        }
        env->SetShortField(javaStruct.get(), reventsFid, fds[i].revents);
    }
    return rc;
}

这个代码做了三件事情：

• 1.通过反射获取structPollfd.java中fd属性，revents，events属性。把这些参数设置到pollfd[] fds队列中。
• 2. 把fds设置到poll进行监听
• 3. 更新java层的structPollfd队列。

核心是第二步骤，linux的poll的函数。
而poll函数的作用就是如果没有检测到文件描述符的变化，则进程进入到睡眠状态，等到有人唤醒。由于此时传入的timeout为0，则不设置超时等待时间。

那么我们可以清楚的知道了，structPollfd做三个属性是什么。

• 第一个文件描述符，用来poll监听该文件描述符是否出现了变化。在这里还记得，传入的是zygote的socket文件吗？也就是说此时poll在监听socket是否出现了变化。

• 第二个event，作为pollfd中事件掩码的参数

• 第三个revent，代表了该文件描述符是否产生了变化。

因此,在每一次调用完Os.poll之后，如果socket有唤醒之后，会更新StructPollfd中的数据，也就有了下面这段判断逻辑

            for (int i = pollFds.length - 1; i >= 0; --i) {
                if ((pollFds[i].revents & POLLIN) == 0) {
                    continue;
                }
...
             }

唤醒之后直接循环pollFds中，判断revents是否有变化，和POLLIN（实际上是0）相于不为0则表示socket文件变化了，才有下面的加入peers列表以及通过runOnce启动进程。

通过这样的优化，就能做到，当没有socket接入的时候，进程休眠，腾出了cpu资源。当socket接入，则唤醒进程，进入到accept，等待数据的接入。这样就能大大的提升了其中的资源利用率。（一些普通的web服务器也是如此的设计的）

这里只是解释了LocalSocket的服务端。

###Zygote 客户端
实际上一般的ZygoteSocket的客户端，一般为SystemServer中的ActivitymanagerService.

我们看看在Android 7.0中当不存在对应的应用进程时候，会调用startProcessLocked方法中Process的start方法。
最终会调用

 public static final String ZYGOTE_SOCKET = "zygote";


    private static ZygoteState openZygoteSocketIfNeeded(String abi) throws ZygoteStartFailedEx {
        if (primaryZygoteState == null || primaryZygoteState.isClosed()) {
            try {
                primaryZygoteState = ZygoteState.connect(ZYGOTE_SOCKET);
            } catch (IOException ioe) {
                throw new ZygoteStartFailedEx("Error connecting to primary zygote", ioe);
            }
        }

        if (primaryZygoteState.matches(abi)) {
            return primaryZygoteState;
        }

        // The primary zygote didn't match. Try the secondary.
        if (secondaryZygoteState == null || secondaryZygoteState.isClosed()) {
            try {
            secondaryZygoteState = ZygoteState.connect(SECONDARY_ZYGOTE_SOCKET);
            } catch (IOException ioe) {
                throw new ZygoteStartFailedEx("Error connecting to secondary zygote", ioe);
            }
        }

        if (secondaryZygoteState.matches(abi)) {
            return secondaryZygoteState;
        }

        throw new ZygoteStartFailedEx("Unsupported zygote ABI: " + abi);
    }

这里的核心会调用一次ZygoteState的connect方法。

        public static ZygoteState connect(String socketAddress) throws IOException {
            DataInputStream zygoteInputStream = null;
            BufferedWriter zygoteWriter = null;
            final LocalSocket zygoteSocket = new LocalSocket();

            try {
                zygoteSocket.connect(new LocalSocketAddress(socketAddress,
                        LocalSocketAddress.Namespace.RESERVED));

                zygoteInputStream = new DataInputStream(zygoteSocket.getInputStream());

                zygoteWriter = new BufferedWriter(new OutputStreamWriter(
                        zygoteSocket.getOutputStream()), 256);
            } catch (IOException ex) {
                try {
                    zygoteSocket.close();
                } catch (IOException ignore) {
                }

                throw ex;
            }

            String abiListString = getAbiList(zygoteWriter, zygoteInputStream);
            Log.i("Zygote", "Process: zygote socket opened, supported ABIS: " + abiListString);

            return new ZygoteState(zygoteSocket, zygoteInputStream, zygoteWriter,
                    Arrays.asList(abiListString.split(",")));
        }

此时会尝试的通过zygoteSocket也就是LocalSocket 去连接名为zygote的socket。也就是我们最开始初始化的在ZygoteInit中registerZygoteSocket的socket名字。

调用connect方法，唤醒Os.poll方法之后，再唤醒LocalServerSocket.accept方法，在循环的下一个，调用runOnce。

那么zygote又是怎么启动ActivityThread，这个应用第一个启动的类呢？

第一次看runOnce代码的老哥可能会被这一行蒙蔽了：

ZygoteConnection newPeer = acceptCommandPeer(abiList);

实际上在ZygoteConnection中，这个abiList不起任何作用。真正起作用的是ZygoteConnection.runOnce中readArgumentList
方法。
文件/frameworks/base/core/java/com/android/internal/os/ZygoteConnection.java

private String[] readArgumentList()
            throws IOException {

        /**
         * See android.os.Process.zygoteSendArgsAndGetPid()
         * Presently the wire format to the zygote process is:
         * a) a count of arguments (argc, in essence)
         * b) a number of newline-separated argument strings equal to count
         *
         * After the zygote process reads these it will write the pid of
         * the child or -1 on failure.
         */

        int argc;

        try {
            String s = mSocketReader.readLine();

            if (s == null) {
                // EOF reached.
                return null;
            }
            argc = Integer.parseInt(s);
        } catch (NumberFormatException ex) {
            Log.e(TAG, "invalid Zygote wire format: non-int at argc");
            throw new IOException("invalid wire format");
        }

        // See bug 1092107: large argc can be used for a DOS attack
        if (argc > MAX_ZYGOTE_ARGC) {
            throw new IOException("max arg count exceeded");
        }

        String[] result = new String[argc];
        for (int i = 0; i < argc; i++) {
            result[i] = mSocketReader.readLine();
            if (result[i] == null) {
                // We got an unexpected EOF.
                throw new IOException("truncated request");
            }
        }

        return result;
    }

看吧实际上所有的字符串都是通过zygote的SocketReader读取出来，再赋值给上层。进行fork出新的进程。
在ActivityManagerService的startProcessLocked

if (entryPoint == null) entryPoint = "android.app.ActivityThread";

    Process.ProcessStartResult startResult = Process.start(entryPoint,
                    app.processName, uid, uid, gids, debugFlags, mountExternal,
                    app.info.targetSdkVersion, app.info.seinfo, requiredAbi, instructionSet,
                    app.info.dataDir, entryPointArgs);

第一个参数就是ActivityThread，通过start方法，来打runOnce之后，进去handleChildProc，把ActivityThread的main反射出来，开始了Activity的初始化。而实际上Process.start方法就是一个socket往Zygote中写数据。

handleChildProc

文件:/frameworks/base/core/java/com/android/internal/os/ZygoteInit.java

因此，当fork之后，我们继续回到ZygoteInit的handleChildProc子进程处理。

private void handleChildProc(Arguments parsedArgs,
            FileDescriptor[] descriptors, FileDescriptor pipeFd, PrintStream newStderr)
            throws ZygoteInit.MethodAndArgsCaller {
        closeSocket();
        ZygoteInit.closeServerSocket();

        if (descriptors != null) {
            try {
                Os.dup2(descriptors[0], STDIN_FILENO);
                Os.dup2(descriptors[1], STDOUT_FILENO);
                Os.dup2(descriptors[2], STDERR_FILENO);

                for (FileDescriptor fd: descriptors) {
                    IoUtils.closeQuietly(fd);
                }
                newStderr = System.err;
            } catch (ErrnoException ex) {
                Log.e(TAG, "Error reopening stdio", ex);
            }
        }

        if (parsedArgs.niceName != null) {
            Process.setArgV0(parsedArgs.niceName);
        }

        // End of the postFork event.
        Trace.traceEnd(Trace.TRACE_TAG_ACTIVITY_MANAGER);
        if (parsedArgs.invokeWith != null) {
            WrapperInit.execApplication(parsedArgs.invokeWith,
                    parsedArgs.niceName, parsedArgs.targetSdkVersion,
                    VMRuntime.getCurrentInstructionSet(),
                    pipeFd, parsedArgs.remainingArgs);
        } else {
            RuntimeInit.zygoteInit(parsedArgs.targetSdkVersion,
                    parsedArgs.remainingArgs, null /* classLoader */);
        }
    }

子进程将关闭socket，关闭socket的观测的文件描述符。这里就能完好的让进程的fdtable(文件描述符表)腾出更多的控件。接着走RuntimeInit.zygoteInit.接下来的逻辑就和SystemServer一样。同样是反射了main方法，nativeZygoteInit 同样会为新的App绑定继承新的Binder底层loop,commonInit 为App的进程初始化异常处理事件。我们可以来看看ActivityThread中的main方法。

文件：/frameworks/base/core/java/android/app/ActivityThread.java

public static void main(String[] args) {
...

        Looper.prepareMainLooper();

        ActivityThread thread = new ActivityThread();
        thread.attach(false);

        if (sMainThreadHandler == null) {
            sMainThreadHandler = thread.getHandler();
        }

        if (false) {
            Looper.myLooper().setMessageLogging(new
                    LogPrinter(Log.DEBUG, "ActivityThread"));
        }

        Looper.loop();

        throw new RuntimeException("Main thread loop unexpectedly exited");
    }

在这里面初始化了ActivityThread对象，并且传入attach方法。

ActivityThread的绑定

private void attach(boolean system) {
        sCurrentActivityThread = this;
        mSystemThread = system;
        if (!system) {
            ViewRootImpl.addFirstDrawHandler(new Runnable() {
                @Override
                public void run() {
                    ensureJitEnabled();
                }
            });
            android.ddm.DdmHandleAppName.setAppName("<pre-initialized>",
                                                    UserHandle.myUserId());
            RuntimeInit.setApplicationObject(mAppThread.asBinder());
            final IActivityManager mgr = ActivityManagerNative.getDefault();
            try {
                mgr.attachApplication(mAppThread);
            } catch (RemoteException ex) {
                // Ignore
            }
            // Watch for getting close to heap limit.
            BinderInternal.addGcWatcher(new Runnable() {
                @Override public void run() {
                    if (!mSomeActivitiesChanged) {
                        return;
                    }
                    Runtime runtime = Runtime.getRuntime();
                    long dalvikMax = runtime.maxMemory();
                    long dalvikUsed = runtime.totalMemory() - runtime.freeMemory();
                    if (dalvikUsed > ((3*dalvikMax)/4)) {
                        if (DEBUG_MEMORY_TRIM) Slog.d(TAG, "Dalvik max=" + (dalvikMax/1024)
                                + " total=" + (runtime.totalMemory()/1024)
                                + " used=" + (dalvikUsed/1024));
                        mSomeActivitiesChanged = false;
                        try {
                            mgr.releaseSomeActivities(mAppThread);
                        } catch (RemoteException e) {
                        }
                    }
                }
            });
        } else {
...
        }

        // add dropbox logging to libcore
        DropBox.setReporter(new DropBoxReporter());

        ViewRootImpl.addConfigCallback(new ComponentCallbacks2() {
            @Override
            public void onConfigurationChanged(Configuration newConfig) {
                synchronized (mResourcesManager) {
                    // We need to apply this change to the resources
                    // immediately, because upon returning the view
                    // hierarchy will be informed about it.
                    if (mResourcesManager.applyConfigurationToResourcesLocked(newConfig, null)) {
                        // This actually changed the resources!  Tell
                        // everyone about it.
                        if (mPendingConfiguration == null ||
                                mPendingConfiguration.isOtherSeqNewer(newConfig)) {
                            mPendingConfiguration = newConfig;

                            sendMessage(H.CONFIGURATION_CHANGED, newConfig);
                        }
                    }
                }
            }
            @Override
            public void onLowMemory() {
            }
            @Override
            public void onTrimMemory(int level) {
            }
        });
    }

实际上这里做的事情核心有两个:

• 第一个把ApplictionThread绑定到AMS，让之后我们startActivity能够通过这个Binder对象找到对应的方法，从而正确的执行Activity中的正确的生命周期。同时为Binder添加gc的监听者。Binder的详细情况会在Binder解析中了解到
• 第二个就是为ViewRootImpl设置内存管理。这个类将会在后的view的绘制了解到。

至此，从Linux内核启动到应用的AcivityThread的大体流程就完成了。

优化与思考

Android系统这么写Zygote孵化流程真的最佳的吗？辉哥曾经提问过一个问题，framework的启动流程该怎么优化。

我们去翻翻4.4的整个流程和android 7.0做对比。发现除了加载虚拟机是从art变成dvm之外，其他逻辑大体上一致。

唯一不同的就是runSelectLoop方法出现了变化。
android 4.4.4
/frameworks/base/core/java/com/android/internal/os/ZygoteInit.java

static final int GC_LOOP_COUNT = 10;

private static void runSelectLoop() throws MethodAndArgsCaller {
        ArrayList<FileDescriptor> fds = new ArrayList<FileDescriptor>();
        ArrayList<ZygoteConnection> peers = new ArrayList<ZygoteConnection>();
        FileDescriptor[] fdArray = new FileDescriptor[4];

        fds.add(sServerSocket.getFileDescriptor());
        peers.add(null);

        int loopCount = GC_LOOP_COUNT;
        while (true) {
            int index;

            /*
             * Call gc() before we block in select().
             * It's work that has to be done anyway, and it's better
             * to avoid making every child do it.  It will also
             * madvise() any free memory as a side-effect.
             *
             * Don't call it every time, because walking the entire
             * heap is a lot of overhead to free a few hundred bytes.
             */
//做一次gc为了给每个子进程腾出内存空间
            if (loopCount <= 0) {
                gc();
                loopCount = GC_LOOP_COUNT;
            } else {
                loopCount--;
            }

//每一次通过select检测array中的fd有什么变化。
            try {
                fdArray = fds.toArray(fdArray);
                index = selectReadable(fdArray);
            } catch (IOException ex) {
                throw new RuntimeException("Error in select()", ex);
            }

//下面的逻辑一样和之前的一样
            if (index < 0) {
                throw new RuntimeException("Error in select()");
            } else if (index == 0) {
                ZygoteConnection newPeer = acceptCommandPeer();
                peers.add(newPeer);
                fds.add(newPeer.getFileDesciptor());
            } else {
                boolean done;
                done = peers.get(index).runOnce();

                if (done) {
                    peers.remove(index);
                    fds.remove(index);
                }
            }
        }
    }

这里稍微解释一下，在低版本fds和peers的意义还是没有多少变动，多了一个限制一次性最多也就4个ZygoteConnection监听。主要去看看下面的死循环之前的操作。

            try {
                fdArray = fds.toArray(fdArray);
                index = selectReadable(fdArray);
            } catch (IOException ex) {
                throw new RuntimeException("Error in select()", ex);
            }

这里面的代码实际上和上面的Os.poll那一段的类似。是为了监听socket中哪些出现了变化，而后唤醒进程。
这个方法直接调用的是native方法。

static jint com_android_internal_os_ZygoteInit_selectReadable (
        JNIEnv *env, jobject clazz, jobjectArray fds)
{
...
    FD_ZERO(&fdset);
//获取ndk层的fd
    int nfds = 0;
    for (jsize i = 0; i < length; i++) {
        jobject fdObj = env->GetObjectArrayElement(fds, i);
        if  (env->ExceptionOccurred() != NULL) {
            return -1;
        }
        if (fdObj == NULL) {
            continue;
        }
        int fd = jniGetFDFromFileDescriptor(env, fdObj);
        if  (env->ExceptionOccurred() != NULL) {
            return -1;
        }

        FD_SET(fd, &fdset);

        if (fd >= nfds) {
            nfds = fd + 1;
        }
    }
//select死循环阻塞
    int err;
    do {
        err = select (nfds, &fdset, NULL, NULL, NULL);
    } while (err < 0 && errno == EINTR);

    if (err < 0) {
        jniThrowIOException(env, errno);
        return -1;
    }
//查看哪些fd出现了变化，把index回调上去
    for (jsize i = 0; i < length; i++) {
        jobject fdObj = env->GetObjectArrayElement(fds, i);
        if  (env->ExceptionOccurred() != NULL) {
            return -1;
        }
        if (fdObj == NULL) {
            continue;
        }
        int fd = jniGetFDFromFileDescriptor(env, fdObj);
        if  (env->ExceptionOccurred() != NULL) {
            return -1;
        }
        if (FD_ISSET(fd, &fdset)) {
            return (jint)i;
        }
    }
    return -1;
}

这个函数分为三个部分：

• 1. 从java层获取fd的对象，通过jniGetFDFromFileDescriptor转化为具体的fd。每一次都加一个一,为select函数做准备。
• 2.调用select，监听所有的文件描述符中的变化
• 3.寻找变化的文件描述符（socket）对应的index，唤醒并且接受socket。

如果不太懂Linux api select函数，这里放出一个写select的比较好的博文：
https://www.cnblogs.com/skyfsm/p/7079458.html

这里简单的解释一下，select的参数。第一个参数，代表了有多少文件描述符加入了，此时只有一个，第二个参数，把fd每个参数对应的标志位，一旦这个标志位出现了变动，则代表这个文件描述符出现变化，socket接入了。其他先可以不管。

因此在最下面的那一段函数中，通过FD_ISSET的方法，判断变动的标志位，找到对应的fd，把对应的index返回。

这样就能正确找到哪个socket。并且处理对应的ZygoteConnection。

上个图总结：

思考

经过两者的比较，为什么在4.4.4版本使用select()去做，而到了7.0版本使用了poll。为什么这么做？先说说两个函数之间的区别。

简单的说，select和poll本质上都是对文件描述符的集合进行轮询查找，哪些socket出现了变化并且告诉Zygote。然而api的不同导致两者之间的策略不一样。

在4.4时代，大部分的手机内存吃紧（这一点从runLoop每隔10次就要gc一次就知道了），而select的好处就是每一次轮询都是直接修正每一个fd对应的标志位，速度较快。缺点是，一段标志位使用过每一个位上的0或者1来判断，也就限制了最大连接数量。

而7.0时代，大部分手机的性能变得比较好了。资源不再吃紧了，此时更换为poll函数。该函数的作用和select很相似。不过每一次轮询fd，都要修改pollfd结构体内部的标志位。这样就脱离标志位的限制了。

所以说，对于不同的api的，没有最好，只有最适用。

愚见

难道没办法，更好的办法吗？有！这只是个人看法，还记得前几年流行的ngnx吗？这个的底层是用epoll来实现的。

这种实现和单一的阻塞不一样。而是异步的IO。这方法只有Linux 2.6才开始支持。这个方法相比于select和poll。不是简单的轮询，因为当量级到了一定的时候，轮询的速度必定慢下来。而是通过回调的机制去处理。每一次通过内存映射的方式查找对应的fd，并且回调。这样就省去了内存在调用fd时候造成的拷贝（从内核空间到用户空间）。

其次，epoll这个函数没有数量的限制，而是由一个文件描述符去控制所有的文件描述符。

基于这两个理由，很明显epoll才是最佳的选择。

但是，最佳就必须选择吗？不，我们只选择了最合适的。我刚才看了下android 9.0的源码。发现还是继续使用poll机制。对于android来说zygote诞生出新的进程的情况不多见，量级远没有达到服务器的地步，加上使用epoll，下面的fork的机制可能变动大，没有选择也是情理之中。

当然，如果有哥们看过Handler的源码，就知道Handler有一层ndk层，下层也是用epoll做等待死循环处理。有机会再源码解析解析。

总结

实际上最后这一段Zygote孵化原理，我发现老罗的书，还有网上的资料都说不详细，但是这却是最重要的一环，是Zygote沟通应用程序的核心代码。特此在此记录一下。

那么Zygote诞生做了什么？在Activity启动前的角色是什么？现在就明白了。

• 1.Zygote是init进程之后第一个诞生出来的孵化进程。就以Android系统的framework来说，Zygote是Android系统一切进程的母亲。

• 2.Zygote第一个孵化的进程是SystemServer进程。

• 3.初始化虚拟机是通过jniInvoaction，加载对应的so库

• 4.SystemServer进程初始化，AMS，WMS，PMS，DisplayManager（显示），InputManager（键盘）,PowerManager（电源）…

• 5.Zygote 诞生新的进程都是通过fork诞生的。

• 6.Zygote 开启socket监听死循环，在低版本使用select来阻塞，高版本使用poll来阻塞。

参考资料：
https://segmentfault.com/a/1190000003063859?utm_source=tag-newest

https://www.cnblogs.com/amanlikethis/p/6915485.html

题外话

无语了，没办法发长一点的文章，只能拆开来放出来了。
写的比较粗浅，也不是很专业。看到错误可以找我纠正。估计很多人都懂这些了，更多的只是把这两年学习的复习和整理。