再学安卓

binder_ioctl是Binder驱动中最核心的函数，没有之一，它负责通信两端IPC数据的收发以及Binder参数的设置。在IPC通信过程中，进程调用此函数执行相关命令，达成传输的目的。

在我们之前的binder探索中，已遇到过很多通过syscall调用驱动函数的情况，比如：open、ioctl、mmap等。但这些只是它们在用户空间的封装。

随着对Binder的探索逐步深入，我们总是在某处边界停下来，本篇我们就穿过这层结界，看看内核的世界。

我们对Binder通信的流程有了大致的了解，但始终有一个问题萦绕在我们心里，CountBinder需要AMS和APP建立的已有通道才能传输，那么AMS和APP之间的通道是怎么建立?

在上一篇中，SystemServer和普通APP进程的通信已经出现了binder的身影，这是Android领域的热门话题，应用工程师、Framework工程师，甚至内核工程师都在谈论它。

本篇来看看与我们息息相关的APP进程从无到有是怎么诞生的。这也是系统启动章节的最后一篇。系统绝大多数进程的诞生都是如此。

fork？分叉？系统启动流程开始发生神奇的变化，SystemServer接管繁重的管理任务，系统中最重量级的进程就此诞生。

Zygote生，万物生，从此繁花似锦，万象更新。Android的世界变得丰富多彩，越来越复杂，也越来越有趣！

本篇内容会适度发散，浅浅涉及到Kernel的源码，这对于了解Android系统的开端是有帮助的。 Kernel代码位于Google仓库中，可以直接git下载。

个人认为无论从事什么类型开发的程序员都有两部分工作内容： 阅读源码（日常积累） 解决问题（直接的工作成果） 针对这两部分需要在两种思考策略之间切换，发散和聚焦。

上一篇我们已经在WSL2+Ubuntu环境下成功编译了AOSP源码，接下来我们开始配置最终的开发环境。

本文描述从远程仓库同步代码到本地，编译准备、启动构建以及相关QA等内容。欢迎评论，收藏，订阅，转发请注明出处。

适用于个人的开发环境配置，包括软硬件要求、安装操作系统、安装WSL2。欢迎评论，收藏，订阅，转发请注明出处。