Android到底是不是Linux？一文解清你的所有疑惑

0.1 Linux 只是内核#

在最严格的定义下，Linux 根本不是一个完整的操作系统，它仅仅是一个内核

1991 年，芬兰大学生 Linus Torvalds 写下第一行代码时，他编写的只是一个内核程序

内核的作用是什么？ 它负责管理 CPU 调度、内存分配、网络通信以及驱动底层硬件（比如让主板认出你的网卡和键盘），他仅仅只是一个发动机，你没办法只靠一台发动机给他开上高速

Android 确实使用了 Linux 内核，在这个极为狭义的层面上，你可以说 Android 包含了 Linux

0.2 GNU/Linux 是什么#

既然 Linux 只是内核，那我们平时用的 Arch、Debian、CentOS 甚至国产的 Deepin，那些带桌面、带命令行、能装软件的完整系统，到底是什么？

这就不得不提下 Richard Stallman 和他发起的 GNU 计划
1983 年，斯托曼决定打造一个完全自由、开源的操作系统。他的团队耗费多年，开发出了操作系统所需的几乎所有上层组件：

• C 语言标准库 glibc： 所有软件运行的基础底座
• 编译器： 把代码变成可执行程序的机器
• 命令行工具集： 比如你敲进去的 ls、cd、cp、rm
• Shell 环境： 比如大名鼎鼎的 Bash

而到 90 年代初，GNU 团队万事俱备，造好了精美的汽车底盘、方向盘和外壳，唯独缺一台好用的发动机（他们的自研内核 Hurd 难产了）。而另一边，Linus 刚好造出了一台极好的发动机（Linux 内核），但没有外壳

于是，两者一拍即合。Linux 内核 + GNU 工具链 = 完整好用的操作系统

因此，今天我们在服务器和个人电脑上使用的传统 Linux 发行版，它们最准确的学术名称应该叫 GNU/Linux。我们平时常说的「我用的是 Linux 系统」，其实是 「GNU/Linux 系统」的简称

0.3 Android 是什么#

理解了上述历史，Android 本质就非常清晰了

当 Google 决定开发一款智能手机操作系统时，他们看中了 Linux 这台超级发动机，但是，Google 并不想要 GNU 造的车体

为了适应移动设备的特性，以及避开 GNU 背后严苛的开源协议（这在后续章节会详细讲），Google 把 Linux 这台发动机拆了下来，围绕它重新打造了一整套全新的跑车

1.1 GPL#

传统 GNU/Linux 系统（如 Ubuntu）中，从 Linux 内核到上层的 GNU 核心组件（C 标准库、命令行工具等），绝大多数都使用的是 GPL 协议

GPL 协议的初衷是极其伟大且纯粹的：捍卫软件的绝对自由。它规定：你可以免费使用我的代码，也可以随意修改，但是，任何使用了 GPL 代码、或者链接了 GPL 库的衍生软件，都必须同样以 GPL 协议开源其全部源代码

在我们视角里这叫自由的接力棒。但在商业公司的法务部眼里，这被称为病毒式协议

这对手机硬件厂商意味着什么？ 假设高通砸了十亿 USD 研发了一款拥有顶级图形性能的 GPU，或者三星开发了极其先进的相机算法。为了让这些硬件在手机上工作，他们必须编写硬件驱动程序

如果 Android 原封不动地照搬 GNU/Linux 的架构，高通和三星在编写驱动时，就不可避免地要调用底层那些受 GPL 保护的代码库。一旦调用（哪怕只是链接了一个 .so 动态库），根据 GPL 的传染性，高通和三星就必须把他们耗费巨资研发的 GPU 和相机驱动源代码公之于众

这等同于让他们把商业机密白白送给竞争对手。如果 Google 当年对硬件厂商说：「用我的 Android 系统吧，代价是公开你们的所有核心技术代码」，那么毫无疑问，Android 会在诞生之初就暴毙，任何 OEM 厂商都会让他门外竖着

1.2 Apache#

Google 不是傻子，他们清楚地知道，想要打造一个垄断全球的手机操作系统，最好的办法是建立一个庞大的商业联盟

要吸引三星、HTC、高通、联发科等巨头入局，Google 必须给他们吃下一颗定心丸：用我的系统，且允许你们闭源

为了实现这个承诺，Google 做出了一个极其重大的架构决策：在用户空间封杀 GPL 协议，全面右转 Apache 2.0

Apache 2.0（以及类似的 BSD、MIT 协议）被称为对商业极度友好的协议。你可以免费使用我的代码，随便你爆改，也可以选择闭源拿去捞钱

这完美契合了硬件厂商和闭源商业软件开发者的胃口

1.3 架构指导思想#

然而现实是，Linux 内核本身就是 GPL，How to do?

幸运的是，Linus 当年做过一个极其重要的声明：正常的系统调用（即上层软件呼叫底层内核帮忙办事的操作）不构成衍生作品，不受 GPL 传染

Google 敏锐地抓住了这根救命稻草，确立了 Android 架构设计的最高原则：隔离 GPL：

1. 把 GPL 严格锁死在内核层： 底层那个不可修改的 Linux 内核，Google 认了，依然遵守 GPL 协议
2. 上层空间全面“去 GNU 化”： 在内核之上的所有东西，绝对不允许出现任何 GPL 的影子。Google 下死手把传统 GNU/Linux 中那些带有 GPL 传染风险的核心底层库（比如 glibc、所有的核心命令工具）统统杀了，自己花钱重新写了一套的替代品
3. 驱动上移： 传统 Linux 驱动是在内核里的，为了不让硬件厂商的驱动被内核的 GPL 传染，Google 硬生生在架构中间插了一层硬件抽象层HAL，让厂商把核心驱动代码挪出内核，放到用户空间去闭源运行

2.1 开始自研#

• libC是任何基于 Linux 内核的操作系统中最重要的一块基石。它是所有上层软件（无论是 C++ 写的原生程序，还是 Java 虚拟机）与底层 Linux 内核打交道的唯一桥梁

• 传统 GNU/Linux： 使用的是大名鼎鼎的 glibc。它极其庞大、功能大而全、完全符合 POSIX 规范，且运行速度极快。但它有两个弱点：第一，它是 GPL 协议的。第二，它太占用内存了，对 08 年初生代智能手机那点可怜的 RAM 来说，太重了

于是 Google 抛弃了 glibc，基于 BSD 协议，自己重写了一个轻量级的 C 标准库，命名为 Bionic libc

• 体积小： 它的体积只有 glibc 的一小部分
• 速度快： 专门针对移动端 ARM 处理器的低频特性和低功耗进行了指令集优化

那么代价呢？它阉割了大量在手机上用不到的 POSIX 标准功能。这也是为什么很多传统的 Linux C/C++ 软件无法直接在 Android 上编译运行原因

2.3 干掉命令行工具集#

在传统 Linux 中，你敲的 ls、grep等，统统来自 GNU Coreutils 软件包

为了避嫌，Android 早期自己写了一个叫 Toolbox 的极简命令集，也是基于 BSD。后来随着系统发展，Toolbox 渐渐不够用了，于是 Google 从 Android 6.0 开始，全面转向了由 Rob Landley 发起的 Toybox 项目

Toybox 是一个极其神奇的项目，它把上百个常用的 Linux 命令打包进了一个小小的二进制文件中，并且使用的是 BSD/0-clause（极其宽松，几乎等于放弃版权要求）
所以，你在 Android 手机里敲的 ls，和你在 Arch 里敲的 ls，虽然长得一样，但它们底层完全是两码事

2.3 干掉编译器#

最初，Android 和所有 Linux 一样，使用 GNU 的 GCC 作为 C/C++ 代码的官方编译器。但 GCC 也是 GPL 协议的重灾区

随着苹果主导的开源编译器架构 LLVM/Clang（采用宽松的 Apache/UIUC 协议）走向成熟，Google 毫不犹豫地跟进。从 Android NDK r11 开始逐步推荐 Clang，到 r18 版本，Google 干脆彻底删除了 GCC。现在的 Android 系统及其原生生态，已经完完全全是由 LLVM/Clang 编译出来的了

3.1 宏内核#

Linux 是一个Monolithic Kernel操作系统。这意味着，在传统的 GNU/Linux 中，硬件的驱动程序是直接塞进 Linux 内核空间里运行的

这就产生了一个法律炸弹：

1. Linux 内核是 GPLv2 协议
2. 你的驱动代码要跑在内核里，就必须调用内核提供的各种 API
3. 根据 GPL 协议，这就构成了衍生作品
4. 你得开源

这对硬件大厂来说是绝对不可接受的。如果不用 Android，他们要自己重头写一个操作系统。如果用 Android，商业机密就要被迫公开。局面一度陷入死胡同

3.2 HAL#

为了打破这个死局，Google 的架构师们在 Linux 内核和上层 Android 框架之间，硬生生地插入了一个全新的概念：**HAL Hardware Abstraction Layer 硬件抽象层 **

既然 GPL 只限制在内核空间，那我们就把驱动程序的核心逻辑从内核空间搬出来，搬到不受 GPL 限制的用户空间去

具体做法如下：

1. 硬件厂商在 Linux 内核里只写一个极其简单的占位驱动 Stub。这个驱动只负责最基础的硬件读写指令，直接开源
2. 硬件厂商把真正的控制逻辑、图像处理算法、复杂的调度机制，写成一个闭源的动态链接库（.so 文件），放在用户空间的 HAL 层。这部分代码受 Apache 2.0 保护，完全闭源
3. 当你打开手机相机时，Android 上层应用调用 API -> 系统服务去找 HAL 层的闭源 .so 库 -> .so 库再向底层内核那个开源的空客发简单指令

通过这个华丽的架构魔术，Android 完美地保护了所有硬件巨头的核心利益 这也是为什么你在 Android 手机目录的 /vendor/lib/hw/ 下，能看到一堆由高通或联发科提供的、根本看不了源码的 .so 文件的原因

3.3 Project Treble#

早期，HAL 层的代码和 Android 的系统框架是绑定在一起的。这就导致每次 Google 发布新版本，厂商必须重新修改他们的 HAL 代码，这就导致了安卓手机极其臭名昭著的升级碎片化（厂商懒得改，你的手机也就永远停在老版本）

为了解决这个问题，Google 在 Android 8.0 推出了 Project Treble 他们设计了一种叫 HIDL/AIDL 的接口定义语言。相当于给 HAL 层和 Android 框架之间制定了一套标准插座

从此以后，硬件厂商的闭源驱动变成了完全独立的模块（Vendor 分区）。Google 升级 Android 系统（System 分区），只需要直接拔下旧的插上新的，底层闭源驱动连改都不用改就能直接兼容新系统

4.1 抛弃 X11 与 Wayland#

传统的 Linux 桌面系统，长期以来使用的是 X11，后来逐渐向 Wayland 过渡。X11 的设计初衷诞生于 80 年代，它支持网络透明性（你可以把远程服务器上的软件图形界面，投射到本地电脑上显示）。这种设计非常适合科研和服务器环境，但它极其臃肿，层层传递的开销极大，对于手机屏幕来说开销太大

Google 果断抛弃了 X11 和 Wayland，专门为移动设备量身定制了一套以硬件渲染为核心的显示框架，它的绝对核心组件叫 SurfaceFlinger

它的工作原理极其简单高效：在 Android 中，每一个 App（甚至每一个按钮、每一个弹窗）在底层都被抽象成一块块的图层。App 进程只负责把自己那块图层画好（通过 OpenGL ES 或 Vulkan）。然后，所有的图层都会被送到 SurfaceFlinger 手里

SurfaceFlinger 就是一个合成器，它利用手机的 GPU 和专门的硬件合成器（HWC, Hardware Composer），在极短的时间内（比如 16.6 毫秒）把这些图层像双层吉士（那很好吃了）一样叠加在一起，按 Z 轴顺序排好，一把推送到屏幕上，没有鼠标指针的概念，没有窗口拖拽重叠的复杂逻辑（早期），一切为全屏触控和极速渲染让路

4.2 音频子系统#

传统 GNU/Linux 底层使用 ALSA 驱动，上层通常使用 PulseAudio 或较新的 PipeWire 来进行音频的混音和路由

Android 底层依然保留了 ALSA 驱动（因为这是 Linux 内核的一部分），但 Google 同样把上层全部推翻，自己写了一个叫 AudioFlinger 的音频策略服务器。它专门针对手机的复杂场景进行了优化：比如你正在听歌（媒体音量），突然来了一个电话（铃声音量），它能极其精准地实现音频焦点的抢占、混音、硬件解码卸载以及极低延迟的音频处理

5.1 抛弃传统 System V IPC#

传统 Linux 提供了丰富的 IPC 机制：管道、信号、消息队列、共享内存、Socket 等（统称 System V IPC 或 POSIX IPC）

• 为什么 Android 不爱用？
  • 管道和消息队列：需要把数据从进程 A 拷贝到内核，再从内核拷贝到进程 B，拷贝两次，性能太差
  • 共享内存：性能极高（0 次拷贝），但控制极其复杂，没有安全校验机制
  • Socket：通用性强，但开销大，通常用于网络通信

5.2 Binder#

为了解决手机上成百上千个 App 频繁调用的性能和安全问题，Google 从早期的 BeOS/PalmOS 系统中汲取灵感，引入了一个全新的机制：Binder

如果没有 Binder，就没有今天的 Android

Binder 巧妙地利用了内存映射技术。进程 A 发送数据时，数据只需拷贝一次进入内核态的特定内存区域，进程 B 就能直接读取到，安全迅速。

当 App A 通过 Binder 呼叫系统服务时，Binder 驱动会在底层强制自动打上 App A 的真实身份标签（UID/PID）。系统服务看一眼标签就知道你有没有权限调

整个 Android 系统（ActivityManager、PackageManager、各种硬件服务）完全是建立在 Binder 织成的庞大通信网之上的

5.3 精简的 init vs systemd#

当我们按下手机电源键，Linux 内核启动完毕后，需要运行第一个用户空间进程（PID=1）来接管系统，把所有的服务拉起来

GNU/Linux 如今基本被 systemd 统治。它极其强大、极其复杂，负责挂载文件系统、配置网络、管理后台守护进程，甚至接管了日志系统

移动设备当然不需要那么复杂的通用的管理者，它需要的是极速开机。因此，Android 用 C 语言自己手写了一个非常精简的 init

它通过解析一系列名为 init.rc 的纯文本脚本文件，严格按照设定好的顺序，启动底层核心服务（如 vold 挂载、logd 日志）、配置 SELinux 权限策略，然后拉起整个 Android 框架

6.1 Native ELF 地位边缘化#

在 Android 中，Google 极其不鼓励（甚至在早期严禁）开发者直接编写原生 C/C++ 二进制程序并作为独立进程在系统里裸奔

why？传统的 C/C++ 程序是和 CPU 架构（ARM、x86、MIPS）强绑定的。如果你写死成 ARM 指令，那用 Intel x86 芯片的手机就运行不了

对于一个致力于一统天下的商业移动系统来说，这种不兼容是致命的

6.2 Dalvik / ART 虚拟机#

为了让开发者做到一次编写，到处拉屎运行，Google 选择了 Java（后来加入了 Kotlin）作为 Android 应用层的婆罗门

你下载的 .apk ，里面装的根本不是能直接在 Linux 内核上跑的机器码，而是被编译成了专属的字节码（Dex 文件）
当你打开一个 App 时，Android 会启动一个专门的虚拟机环境来解释或编译这些字节码 * 早期（Android 4.4 之前）叫 Dalvik 虚拟机（采用 JIT 即时编译，一边运行一边翻译代码） * 现在叫 **ARTAndroid Runtime** 采用 AOT 预编译 + JIT 混合模式，在 App 安装或闲暇时直接把字节码翻译成机器码，极大提升了流畅度

6.3 组件化模型#

在传统 Linux 中，你关掉一个软件的窗口，或者用 kill 命令杀掉它，它就彻底死了 但在 Android 中，一个 App 根本没有传统的入口和出口。Google 强制所有应用必须拆分成四大组件（Activity、Service、Broadcast Receiver、Content Provider）

你的应用什么时候启动、什么时候退到后台、什么时候被杀死清理内存，完全不由你写的代码决定，而是由系统核心服务（ActivityManagerService）根据当前手机的内存状态和前台交互需求强制调度的。这种被动式的生命周期管理，在传统的 GNU/Linux 桌面端是完全不存在的

7.1 Linux 多用户机制的魔改#

在传统的 Linux 服务器中，权限隔离是基于用户的

• 比如服务器上有三个真实的人：Chongxi、xi 和 root。系统给他们分配不同的 UID。Linux 内核会在底层严格保证：Chongxi 绝对看不了 xi 文件夹里的隐私数据。 到了手机上，一部手机通常只有一个真实的主人，那 Linux 强大的多用户隔离机制不炸了吗

Google 发动鬼脑：既然没有多个人，那我就把手机里装的每一个 App，都当成一个独立的 user

这就要说到Android 沙盒机制： 当你安装 Telegram 时，系统给它分配一个 UID（比如 10045）；当你安装 b 站时，系统给它分配另一个 UID（比如 10046）

• 在底层 Linux 内核看来，微信和淘宝根本不是两个软件，而是两个互不相识的、平行的 Linux 系统用户
• 利用内核原生的 UID 隔离机制，微信天然就无法读取淘宝在私有目录下的数据，淘宝也无法干涉微信的运行，这就是 Android 沙盒。旧瓶装新酒这一块

7.2 Zygote#

既然每个 App 都在一个独立的虚拟机和沙盒里，那每次打开 App 都要重新启动一遍庞大的 Java 虚拟机环境，手机早就卡死了

为了实现极速启动和节省内存，Android 创造了一个叫 Zygote 的特殊进程

• 手机开机时，系统会先启动这个 Zygote 进程，并在里面把所有的 Java 核心库、虚拟机环境全部 ready
• 当你点击桌面微信图标时，系统只是向 Zygote 发送一个指令。Zygote 会利用 Linux 内核极其高效的 fork() 机制，瞬间克隆出一个一模一样的自己，然后在这个克隆体里运行微信的代码

所有的 App 进程都来自同一个 Zygote，它们在底层共享了大量的基础内存（利用 Copy-on-Write 技术），这使得几百兆内存的古董安卓机也能同时跑好几个 App

7.3 SELinux#

早期的 Android 经常被用户 Root，一旦拿到 su 权限，沙盒机制就形同虚设

为了堵死这个漏洞，Google 从 Android 5.0 开始，强制启用了美国国家安全局（NSA）主导开发的 SELinux（MAC）

• 在 SELinux 的规则下，即使你是 Root 用户，也不能拉屎。所有的操作（读写某个文件、调用某个硬件）都必须在系统底层的安全策略文件中有明确的白名单授权，否则即使是内核也会直接拒绝执行