首先声明一下这是一个讨论帖，我只是论述一下个人的观点，欢迎大家讲事实摆道理。

前言

大家都知道App进程是AMS通过通过Socket通信通知Zygote孵化出来的，借用gityuan的图就是图中的第2步，能否用Binder通信替换Socket通信？我们只讨论技术上实现的可能性，不讨论两者性能上的差异。

我的观点

能替换成Binder通信。

我的论据

我实在是想不出用Binder通信替换Socket通信的缺陷在哪里？

别人观点

既然我想不出，肯定网上有人持否定态度，我们看看他们说的有没有道理。

观点1：并发问题

链接：

https://blog.csdn.net/qq_39037047/article/details/88066589

观点描述：

怕父进程binder线程有锁，然后子进程的主线程一直在等其子线程(从父进程拷贝过来的子进程)的资源，但是其实父进程的子进程并没有被拷贝过来，造成死锁，所以fork不允许存在多线程。而非常巧的是Binder通讯偏偏就是多线程，所以干脆父进程（Zygote）这个时候就不使用binder线程

反驳：

我们完全可以将Zygote进程的主线程作为唯一的Binder线程，这样子也就没有这个问题了。

观点2：父子进程共享FD问题（其实这个是我以前早期的观点）

观点描述：

因为Zygote在open("dev/binder")中带有的flag是O_CLOEXEC，fork之后，在子进程执行EXEC的时候，会因为O_CLOEXEC的条件关闭这个共享FD，就会调用binder_release的代码，顺带清空父进程的FD对应file结构体中private_data对象保存的binder_proc，影响父进程的Binder通信功能。

/frameworks/native/libs/binder/ProcessState.cpp
static int open_driver(const char *driver)
{
    int fd = open(driver, O_RDWR | O_CLOEXEC);
    return fd;
}

drivers/staging/android/binder.c
static int binder_release(struct inode *nodp, struct file *filp)
{
    struct binder_proc *proc = filp->private_data;
    debugfs_remove(proc->debugfs_entry);
    binder_defer_work(proc, BINDER_DEFERRED_RELEASE);//调用到代码1.1
    return 0;
}

//1.1
binder_defer_work(struct binder_proc *proc, enum binder_deferred_state defer)
{
    mutex_lock(&binder_deferred_lock);
    proc->deferred_work |= defer;
    if (hlist_unhashed(&proc->deferred_work_node)) {
        hlist_add_head(&proc->deferred_work_node,
                &binder_deferred_list);
        //发起一个workqueue去执行binder_deferred_work，也就是代码1.2
        queue_work(binder_deferred_workqueue, &binder_deferred_work);
    }
    mutex_unlock(&binder_deferred_lock);
}

//1.2
static DECLARE_WORK(binder_deferred_work, binder_deferred_func);
static void binder_deferred_func(struct work_struct *work)
{
    ...
    do {
        ...
        if (defer & BINDER_DEFERRED_RELEASE)
            binder_deferred_release(proc); /* frees proc */ //代码1.3
                ...
    } while (proc);
}

//1.3
static void binder_deferred_release(struct binder_proc *proc)
{
    ...
    kfree(proc);//这里会释放父进程的binder_proc
}

反驳：

链接：https://blog.csdn.net/scarecrow_byr/article/details/91410131

上述的观点对O_CLOEXEC的理解有些偏差，正确的理解应该是在linux系统中，父进程打开一个文件fd可以带上O_CLOEXEC标志位，fork之后，子进程得到父进程的完整拷贝，对于父进程已经open的文件，子进程也可以得到一样的fd。内核里，子进程只是把fd对应的file指针指向父进程fd对应的struct file，并且把file的引用加1。子进程中用exec系列系统调用加载新的可执行程序之前，会关闭子进程中父进程O_CLOEXEC标志打开的fd。子进程关闭该fd时候，但是因为父进程还持有fd的引用计数，所以这个关闭的动作只会执行fops的flush回调函数，并没有真正调用fops的release回调函数。

看Binder驱动中实现的flush回调函数binder_flush，最后调用的binder_deferred_flush方法中，并没有释放binder_proc，只是唤醒一下父进程的Binder线程而已。

static void binder_deferred_flush(struct binder_proc *proc)
{
    struct rb_node *n;
    int wake_count = 0;

    for (n = rb_first(&proc->threads); n != NULL; n = rb_next(n)) {
        struct binder_thread *thread = rb_entry(n, struct binder_thread, rb_node);

        thread->looper |= BINDER_LOOPER_STATE_NEED_RETURN;
        if (thread->looper & BINDER_LOOPER_STATE_WAITING) {
            wake_up_interruptible(&thread->wait);
            wake_count++;
        }
    }
    wake_up_interruptible_all(&proc->wait);

    binder_debug(BINDER_DEBUG_OPEN_CLOSE,
             "binder_flush: %d woke %d threads\n", proc->pid,
             wake_count);
}

总结

以上就是我觉得看似合理的两个观点的反驳，如果你们有新的观点，或者觉得我的反驳中的论据有问题。

欢迎留言交流。