3、开发环境准备：硬件要求、操作系统选择（Ubuntu/macOS）、磁盘分区与网络配置

AOSP（Android Open Source Project）的源码体量巨大、构建链路复杂，其开发环境的准备质量直接决定了后续编译效率与排障成本。本章围绕硬件配置基线、操作系统选型、磁盘分区策略与网络加速方案四个核心维度展开，帮助你在动手下载源码之前，先构建一个稳定、高效、可复现的工程化环境。需要特别强调的是，AOSP 编译并非“能跑就行”，而是需要从 CPU 核数、内存带宽、磁盘 IOPS 到网络出口带宽进行系统性匹配，任何单一环节的短板都可能成为编译瓶颈。

AOSP 开发环境四维决策模型 硬件要求 • CPU ≥ 8核16线程 • 内存 ≥ 32GB DDR4 • 磁盘 ≥ 500GB NVMe SSD • 网络 ≥ 100Mbps 稳定带宽 • 散热：塔式/机架式优先 操作系统选择 • Ubuntu 20.04/22.04 LTS • macOS 12+ (Intel/Apple Silicon) • 不推荐 Windows 直接编译 • 虚拟机仅用于轻量验证 • Docker 适合 CI 构建 磁盘分区策略 • / 根分区 ≥ 100GB • /home 或 /data ≥ 400GB • 独立 /ccache 分区 100GB • 文件系统 ext4 / APFS • 预留 20% 冗余空间 网络配置 • 代理：HTTP/HTTPS/SOCKS5 • 镜像：TUNA / 华为云 • git 协议：https 优先 • DNS：8.8.8.8 / 223.5.5.5 • 限速：repo 并发调优 环境准备决策入口 输出：可编译的 AOSP 环境 源码同步 → 环境校验 → 编译验证 → 产物输出 → 迭代开发 图 3-1 AOSP 开发环境四维决策模型：硬件、系统、磁盘、网络协同规划

3.1 硬件要求：从“能编译”到“高效编译”的量化标准

AOSP 的构建系统（Soong/Ninja）会将源码拆分为数万个编译单元并行处理，硬件配置直接决定了单次全量编译的时间成本。以 Android 13 的 aosp_arm64 目标为例，在 8 核 16 线程、32GB 内存、NVMe SSD 的典型配置下，全量编译约需 40-60 分钟；若降至 4 核 8 线程，时间将延长至 2 小时以上，且内存不足会触发 OOM 导致构建中断。因此，硬件规划应遵循“木桶效应”原则，优先补齐最短短板。

硬件项最低要求推荐配置专业建议
CPU4 核 8 线程8 核 16 线程及以上AMD Ryzen 9 / Intel i7-12700K 以上，支持 AVX2 指令集
内存16GB32GB DDR4 3200MHz64GB 可显著提升 ccache 命中率与并行任务数
磁盘250GB HDD500GB NVMe SSD建议 1TB 以上，预留 AOSP 多版本分支空间
网络50Mbps200Mbps 光纤首次 repo sync 约需下载 30-60GB 数据
散热/电源普通风冷塔式散热 + 650W 电源长时间满载编译需关注 CPU 温度不超过 85°C

在判断硬件是否满足需求时，建议使用 nproc、free -h、df -h 命令快速核查。对于笔记本用户，务必注意散热能力——编译时 CPU 会持续满载 30 分钟以上，轻薄本容易触发温度墙导致降频，实际编译速度可能仅为台式机的 60%。若条件允许，优先使用台式机或服务器，并外接 USB 3.2 Gen2 固态硬盘作为源码存储盘。

经验提醒：不要忽略 swap 空间。即使内存达到 32GB，建议额外配置 16GB swap（放在 SSD 上），用于应对内存峰值。但 swap 仅作为兜底，若频繁使用 swap 说明内存确实不足，应升级硬件而非依赖 swap。

3.2 操作系统选择：Ubuntu 与 macOS 的工程化对比

Google 官方支持 Ubuntu LTS 和 macOS 作为 AOSP 构建主机。Ubuntu 是主流，因为其包管理工具 apt 能快速安装 OpenJDK、Python、Git 等依赖，且社区资料丰富。macOS 在 Apple Silicon 芯片上表现优异，但需注意部分 AOSP 模块（如某些内核驱动）对 macOS 支持不完整。Windows 系统无法直接编译 AOSP，只能通过 WSL2 或虚拟机间接实现，但性能损耗明显且文件系统兼容性问题频发，不建议作为主力环境。

选择操作系统时，应遵循以下判断流程：

  1. 团队协作一致性：若团队统一使用 Ubuntu，则个人环境应保持一致，避免因系统差异导致构建产物行为不一致。
  2. 硬件架构匹配：Apple Silicon（M1/M2/M3）使用 arm64 架构，编译 arm64 目标时无需交叉编译，速度更快；但 x86_64 目标需要模拟，性能下降约 30%。
  3. 工具链兼容性：Ubuntu 20.04 对应 OpenJDK 11，Ubuntu 22.04 对应 OpenJDK 17，需根据 AOSP 版本选择。macOS 需安装 Xcode Command Line Tools，且部分 AOSP 历史版本不兼容最新 macOS。

对于 Ubuntu 版本，推荐 20.04 LTS 或 22.04 LTS。20.04 更稳定，适合 Android 12 及以下版本；22.04 对 Android 13+ 支持更好。安装完成后，需执行以下基础配置：

# 更新软件源
sudo apt update && sudo apt upgrade -y

# 安装基础依赖（以 Ubuntu 22.04 为例）
sudo apt install -y git-core gnupg flex bison build-essential zip curl zlib1g-dev \
  libc6-dev-i386 libncurses5-dev x11proto-core-dev libx11-dev lib32z1-dev \
  libgl1-mesa-dev libxml2-utils xsltproc unzip fontconfig python3 python3-pip

# 配置 Git 用户信息
git config --global user.name "Your Name"
git config --global user.email "your.email@example.com"

macOS 用户则需安装 Homebrew 和 Xcode 命令行工具：

xcode-select --install
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
brew install git python3
风险提示：不要使用 Ubuntu 的 WSL1 模式，其 I/O 性能极差，repo sync 和编译速度会慢 5-10 倍。WSL2 虽然性能接近原生，但跨文件系统访问（/mnt/c）仍存在性能陷阱，务必把源码放在 WSL2 的 ext4 文件系统内。

3.3 磁盘分区策略：为源码、缓存与构建产物预留独立空间

AOSP 源码树在 repo sync 后约占用 30-50GB，但编译产物（out/ 目录）会额外占用 50-100GB，且 ccache 缓存建议配置 50-100GB。因此，磁盘分区不能简单地将所有空间分配给根分区，而应进行精细规划。推荐的分区方案如下：

挂载点大小文件系统用途说明
/100GBext4系统与应用程序，预留 20% 冗余
/home400GBext4存放 AOSP 源码树（~/aosp）
/ccache100GBext4编译缓存，独立分区便于清理和扩容
swap16GBswap内存溢出兜底

分区操作应在 Ubuntu 安装时完成，使用手动分区模式。若系统已安装，可通过 GParted 工具调整，但务必提前备份数据。对于 macOS，APFS 容器会自动管理空间，无需手动分区，但建议在“磁盘工具”中创建独立的 APFS 卷宗用于存放源码，便于配额管理。

文件系统的选择上，Linux 推荐 ext4，其稳定性和碎片管理能力优于 XFS。macOS 使用 APFS 即可。需要特别注意的是，不要将源码放在 NTFS/exFAT 分区，这些文件系统不支持 Linux 符号链接和权限位，会导致 repo sync 失败或编译错误。

实战场景：某团队使用 512GB 笔记本，将 AOSP 源码放在外置 NTFS 移动硬盘上，结果 repo sync 时报错“Unable to create symlink”。排查后发现 NTFS 不支持符号链接，改用 ext4 格式化的移动硬盘后问题解决。这提醒我们，磁盘分区不仅是容量问题，更是文件系统兼容性问题。

3.4 网络配置：代理、镜像与 repo 并发优化

AOSP 源码托管在 Google 的 git 服务器上，国内开发者必须配置代理或使用镜像源。网络配置的核心目标是保证 repo sync 的稳定性和速度。首先，推荐使用清华 TUNA 镜像或华为云镜像，将 repo 工具的 URL 指向镜像地址：

# 使用清华镜像初始化 repo
mkdir ~/aosp
cd ~/aosp
repo init -u https://mirrors.tuna.tsinghua.edu.cn/git/AOSP/platform/manifest -b android-13.0.0_r1

# 或使用华为云镜像
repo init -u https://mirrors.huaweicloud.com/git/AOSP/platform/manifest -b android-13.0.0_r1

若使用代理，需在环境变量中配置：

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
export no_proxy=localhost,127.0.0.1,10.0.0.0/8

repo sync 的并发数直接影响下载速度，但过高的并发会导致服务器拒绝连接。推荐使用 -j4 或 -j8 参数，同时设置 repo sync -c 仅下载当前分支的代码，避免下载全部历史标签。对于网络不稳定的场景，可添加 --fail-fast 参数快速定位失败项目，或使用 --force-sync 强制重新同步。

此外，建议配置 git 的 http 缓存以加速重复下载：

git config --global http.lowSpeedLimit 1000
git config --global http.lowSpeedTime 60
git config --global http.postBuffer 524288000
常见误区：不要直接使用 repo sync -j16 追求极限速度。过高的并发会导致部分项目下载失败，且占用大量内存。更稳妥的做法是先用 -j4 同步，若网络质量好再逐步提升并发数。同时，务必在同步前确认磁盘剩余空间大于 60GB，否则会在下载中途因磁盘写满而中断。

3.5 环境验证与常见问题复盘

环境准备完成后，应通过以下步骤验证是否满足编译要求：

  1. 检查磁盘空间：df -h /home /ccache，确保源码目录和缓存目录有足够空间。
  2. 验证编译依赖：运行 source build/envsetup.sh 和 lunch aosp_arm64-eng，确认无报错。
  3. 测试编译小模块：执行 m -j8 libandroid_runtime，验证编译链路是否通畅。
  4. 检查 ccache 配置：在 ~/.bashrc 中添加 export USE_CCACHE=1 和 export CCACHE_DIR=/ccache，并执行 ccache -M 50G 设置缓存上限。

在实际教学中，常见的问题包括：内存不足导致 ninja 进程被杀、磁盘 inode 耗尽、代理配置错误导致 repo 无法连接等。这些问题大多可以通过查看 dmesg 日志和 repo sync 的错误输出定位。建议在首次编译前，先执行一次 m -j8 nothing 空编译，验证环境配置无误后再进行全量编译。

复盘总结：环境准备的核心原则是“冗余优先”——磁盘多留 20% 空间、内存多配 8GB、网络预留备用代理。AOSP 编译是一个长时间、高负载的过程，任何环境短板都会在编译中后期暴露，导致前功尽弃。务必在开始前完成全链路验证，避免在编译中途返工。
← 上一章 📖 返回目录 下一章 →