Android13编译内存不足？手把手教你用Swap分区解决Ninja报错137
Android 13编译内存不足？Swap分区实战指南解决Ninja报错137
编译Android 13时遇到Ninja报错137，往往是系统内存不足导致的OOM（Out of Memory）杀手在作祟。这个问题尤其容易出现在资源有限的开发环境中，即使物理内存看似充足，复杂的编译任务仍可能耗尽所有可用资源。本文将深入解析这一问题的根源，并提供一套完整的Swap分区解决方案，帮助开发者在不升级硬件的情况下顺利完成编译。
1. 理解Ninja报错137的本质
当你在终端看到"ninja failed with: exit status 137"这样的错误信息时，这实际上是Linux系统的一种保护机制在起作用。错误代码137并非Ninja工具本身的错误，而是Linux内核在内存耗尽时强制终止进程的结果。
具体来说，137这个数字是128（表示进程被信号终止）加上9（SIGKILL信号编号）的结果。当系统内存严重不足时，内核的OOM-killer会选择一个"最合适"的进程发送SIGKILL信号，而Ninja编译进程往往成为牺牲品。
关键诊断步骤：
- 检查系统日志确认OOM事件：
grep -i "oom" /var/log/syslog - 监控实时内存使用情况：
watch -n 1 free -h - 查看Ninja日志中的内存峰值：
grep "maxrss" out/soong.log
2. Swap分区：低成本的内存扩展方案
Swap空间本质上是硬盘上的一块特殊区域，当物理内存(RAM)不足时，系统可以将部分不常用的内存数据暂时交换到这块磁盘空间上。虽然Swap的读写速度远低于物理内存（通常相差100倍以上），但它能有效防止系统因内存耗尽而崩溃。
Swap与物理内存的典型配置比例：
| 物理内存大小 | 推荐Swap大小 |
|---|---|
| ≤ 2GB | 2倍内存大小 |
| 2GB-8GB | 等于内存大小 |
| 8GB-64GB | 0.5倍内存大小 |
| >64GB | 4GB(工作负载依赖) |
对于Android编译这种内存密集型任务，建议至少配置8GB以上的Swap空间，特别是当物理内存小于32GB时。
3. 实战：在Ubuntu上创建和优化Swap分区
3.1 检查现有Swap配置
首先确认当前系统的Swap状态：
sudo swapon --show free -h如果已有Swap分区但容量不足，需要先禁用：
sudo swapoff -a3.2 创建新的Swap文件
使用dd命令创建Swap文件（这里以8GB为例）：
sudo dd if=/dev/zero of=/swapfile bs=1G count=8 status=progress注意：确保存储Swap文件的分区有足够空间，建议放在SSD上以获得更好的性能
设置正确的文件权限：
sudo chmod 600 /swapfile sudo mkswap /swapfile3.3 激活并优化Swap
启用Swap文件：
sudo swapon /swapfile为了使配置永久生效，编辑/etc/fstab文件：
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab关键优化参数：
# 调整swappiness（默认值60，建议设为10-30） echo 'vm.swappiness=20' | sudo tee -a /etc/sysctl.conf sudo sysctl -p # 提高缓存压力（减少文件缓存占用内存） echo 'vm.vfs_cache_pressure=50' | sudo tee -a /etc/sysctl.conf sudo sysctl -p4. 编译环境调优与替代方案
4.1 并行任务控制
调整Ninja的并行编译任务数可以显著影响内存使用：
# 保守设置（适合内存紧张环境） make -j4 # 根据CPU核心数动态设置（平衡性能与内存） make -j$(nproc --all)4.2 选择性编译
对于大型项目，考虑分模块编译：
# 只编译特定模块 make framework make services # 跳过某些耗内存的步骤 make SKIP_ABI_CHECKS=true4.3 内存监控技巧
使用工具实时监控内存状态：
# 综合监控 htop # 专查内存 watch -n 1 "free -h; echo; grep -E 'Swap|Mem' /proc/meminfo" # 进程级监控 sudo apt install smem smem -s swap -r4.4 临时解决方案对比表
| 方法 | 效果 | 实施难度 | 适用场景 |
|---|---|---|---|
| 增加Swap | 较好，但可能影响性能 | 低 | 长期解决方案 |
| 减少-j参数 | 明显，但编译时间大幅增加 | 极低 | 临时测试 |
| 关闭其他应用 | 有限 | 低 | 轻度内存不足 |
| 使用ccache | 中等，减少部分编译量 | 中 | 重复编译场景 |
| 分模块编译 | 好，但需手动管理 | 高 | 大型项目模块化程度高时 |
5. 高级技巧：Zswap与Zram
对于较新的Linux内核（4.x+），可以考虑更现代的内存压缩技术：
Zswap配置：
# 编辑grub配置 sudo nano /etc/default/grub # 找到GRUB_CMDLINE_LINUX_DEFAULT行，添加： zswap.enabled=1 zswap.compressor=lz4 zswap.max_pool_percent=20 # 更新grub sudo update-grub sudo rebootZram设置：
sudo apt install zram-config # 调整配置（通常位于/etc/init.d/zram-config）这些技术通过在内存中压缩数据，可以在不增加Swap文件的情况下有效扩展可用内存空间，特别适合SSD速度较慢的系统。
6. 长期解决方案评估
虽然Swap分区能解决眼前的问题，但从长远来看，开发者应该考虑：
- 硬件升级：32GB内存已成为Android开发的基准线，AOSP官方推荐64GB以上
- 构建服务器：配置专门的构建机器，通过SSH远程编译
- 云编译：利用Google Cloud Build等云服务
- 增量编译：善用ccache和ninja的增量构建特性
在最近的Android 13编译实践中，一个中等规模的AOSP构建可能需要：
- 200GB以上磁盘空间
- 16-32GB物理内存（无Swap时）
- 8-16个CPU核心
- 2-4小时完整编译时间