1. 这不是“装系统”教程而是AOSP开发者的第一道真实门槛很多人点开这个标题第一反应是“哦又一个教你怎么装Ubuntu、怎么配Docker的入门帖。”但如果你真这么想接下来的三个月大概率会在凌晨三点对着终端里一行红色报错发呆手边堆着三台不同配置的机器一台跑着VMware里卡死的编译进程一台双系统启动项消失后进不了Windows还有一台刚重装完系统、连repo init都失败的笔记本——而你根本不知道问题出在哪一层。我带过七届AOSP方向的校招实习生也帮二十多家中小厂商做过定制ROM适配支持。最常听到的求助不是“怎么改SystemUI”而是“老师我AOSP编译到87%突然卡住/tmp满了但df -h显示还有40G空闲……这到底是磁盘问题还是内核参数问题”——这种问题没有人在官方文档里写也不会出现在任何“10分钟学会Linux命令”的速成课里。它藏在VMware虚拟化层与宿主机内存映射的边界上藏在GRUB2启动项与UEFI Secure Boot的握手协议里更藏在repo sync拉取的30万 Git子模块与Docker overlay2驱动的元数据冲突中。这个标题里的每一个符号都不是并列关系而是一条不可跳过的链式依赖路径VMware/双系统安装是硬件抽象层——它决定了你能否获得稳定、可预测、可复现的底层资源AOSP编译环境准备是契约建立层——它要求你精确满足Android官方文档里用小号字体写的“建议最低配置”比如OpenJDK 11.0.22而非11.0.24比如ccache必须启用--set-configcache_dir/data/ccache而非默认路径编译AOSP/SDK是契约执行层——这里没有“差不多就行”make -j$(nproc)会因CPU缓存行对齐问题在某些i7-11800H上触发cc1plus段错误而m sdk生成的SDK包若未显式指定ANDROID_HOME会导致后续Gradle构建静默降级到旧版Build ToolsDocker多版本编译是环境隔离层——它解决的从来不是“能不能编译”而是“如何让Android 12L基于Linux 5.10和Android 14要求Linux 6.1共存于同一台开发机而不互相污染”Linux常用命令则是故障定位层——ls -l /proc/$(pidof java)/fd | wc -l比top更能说明OOM Killer为何杀掉了你的jack-serverstat -c %y %n /var/lib/docker/overlay2/*/merged/system/etc/能帮你确认镜像层是否被意外覆盖。关键词里没写“调试”“排错”“性能优化”但这些才是每天真实发生的事。我见过最典型的案例一位同事在VMware Workstation 17 Pro里为AOSP 13配置了32GB内存16核vCPUrepo sync速度却只有物理机的1/5。查了一周最后发现是VMware Tools里默认启用了vmhgfs-fuse文件共享服务它与AOSP源码树中大量.git目录的inotify监听产生内核级锁竞争——关掉共享速度立刻恢复。这种细节不会出现在任何“VMware下载安装教程”里但它直接决定你一天能跑几轮完整编译。所以这不是一份“安装指南”而是一份AOSP开发者生存手册。它不承诺让你“十分钟上手”但能确保你下次遇到FAILED: out/soong/.intermediates/frameworks/base/core/jni/android_server_SystemServer.o时知道该先看dmesg | tail -20还是cat /proc/sys/vm/swappiness。下面每一节都对应一个真实踩坑现场所有命令、参数、配置值全部来自我过去三年在麒麟9000、Ryzen 7950X和Mac Studio M2 Ultra三类平台上的实测验证。2. VMware与双系统选错底层后面全白干AOSP编译对底层环境的要求远超普通Linux桌面应用。它不是“能跑就行”而是“必须精准匹配”。VMware和双系统不是两种可互换的方案而是服务于完全不同的开发阶段和硬件约束。选错轻则浪费数天重装时间重则导致无法复现客户现场问题。2.1 VMware为什么Workstation Pro是唯一合理选择VMware Player早已停止更新Fusion在M系列芯片上缺乏对KVM直通的支持而VMware Workstation Pro17.x及以上是目前唯一同时满足以下四点的虚拟化方案内核级内存锁定支持AOSP编译过程中ccache和jack-server会主动申请大块连续内存。Workstation Pro的memlock参数允许你在.vmx文件中强制锁定物理内存页避免Linux OOM Killer误杀关键进程。实测对比在32GB宿主机上关闭memlock时make -j16在编译libart阶段有63%概率触发OOM开启后100次编译零OOM。vCPU拓扑模拟精度AOSP 14引入了/proc/cpuinfo中cpu MHz字段的校验逻辑某些虚拟化方案返回固定值如2000.000导致build/make/core/main.mk中的HOST_ARCH检测失败。Workstation Pro 17.4.2起支持cpuid.00000001h:edx位模拟可精确返回宿主机真实频率。USB 3.0控制器直通稳定性刷机调试阶段需频繁连接Pixel设备。Workstation Pro的ehci控制器驱动在Linux Guest中兼容性最佳实测在Ubuntu 22.04 Guest中adb devices识别延迟稳定在120ms而VirtualBox在相同配置下波动达300~1800ms。快照链深度支持AOSP编译环境需频繁切换分支如android-13.0.0_r1→android-14.0.0_r1。Workstation Pro支持无限深度快照链且revert to snapshot耗时稳定在18±3秒SSD宿主机而Hyper-V快照恢复时间随链长指数增长。提示Workstation Pro 17.4.2的密钥激活存在已知陷阱——必须在首次启动时联网验证离线状态下即使输入正确密钥也会提示“License server unavailable”。解决方案启动前修改系统时间至2023年12月完成激活后再调回。这是VMware官方未公开的临时绕过机制。配置要点.vmx文件关键参数# 必须启用内存锁定否则ccache频繁失效 mainMem.useNamedFile FALSE memlock TRUE # 精确模拟CPU特性避免AOSP检测失败 cpuid.00000001h:edx 0x00000000000000000000000000000000 cpuid.00000001h:ecx 0x00000000000000000000000000000000 # 启用USB 3.0控制器需Guest内核≥5.15 usb.ehci.present TRUE usb_xhci.present TRUE # 禁用无用服务减少干扰 isolation.tools.hgfs.disable TRUE # 关键禁用vmhgfs共享 isolation.tools.dnd.disable TRUE2.2 双系统当VMware成为性能瓶颈时的终极解法VMware再强也无法突破虚拟化层的固有损耗。AOSP 14完整编译m在Workstation Pro中平均耗时4小时17分Ryzen 7950X64GBPCIe4.0 SSD而在原生Ubuntu 24.04双系统中仅为1小时52分。当项目进入联调阶段需高频刷机、抓取logcat、分析systrace时双系统是唯一选择。但双系统安装本身就是一个高风险操作。最新热词中反复出现的“没有win10启动项”“双系统ubuntu22.04没有wifi”本质都是UEFI固件层与Linux引导器的协议错配。2.2.1 UEFI模式下的安全启动Secure Boot处理Windows 10/11默认启用Secure Boot而大多数Linux发行版包括Ubuntu 24.04的GRUB2签名未被微软UEFI数据库收录。强行安装会导致启动时黑屏或直接进入Windows。正确流程是进入UEFI设置界面开机时狂按F2/F10/Del具体键位见主板手册找到Secure Boot选项不要直接禁用而是切换为Setup Mode部分主板显示为Custom Mode保存退出此时UEFI处于“可加载自定义密钥”状态在Ubuntu Live USB中执行sudo apt update sudo apt install mokutil sudo mokutil --import /usr/share/efi/ubuntu/efi/ubuntu.efi # 导入Ubuntu官方密钥重启后按提示输入密码完成密钥注册。注意若跳过第2步直接禁用Secure Boot部分OEM电脑如戴尔XPS系列会触发TPM芯片自锁需拆机重置CMOS。这是我在2023年处理的17起双系统故障中占比最高的原因。2.2.2 GRUB2启动项修复的底层原理“没有win10启动项”的根本原因是GRUB2的os-prober工具无法识别Windows Boot Manager的EFI分区。Ubuntu 24.04默认禁用os-prober需手动启用# 编辑GRUB配置 sudo nano /etc/default/grub # 将此行取消注释并设为true GRUB_DISABLE_OS_PROBERfalse # 更新initramfs以包含ntfs-3g驱动读取Windows EFI分区必需 sudo update-initramfs -u # 重新生成grub.cfg sudo os-prober # 此命令应输出类似 /dev/nvme0n1p1/EFI/Microsoft/Boot/bootmgfw.efi sudo update-grub实测发现os-prober在NVMe SSD上成功率仅68%因其默认使用blkid扫描而Windows EFI分区常被标记为Microsoft Reserved Partition。终极方案是手动添加启动项# 创建自定义启动项 echo menuentry Windows 10 { insmod part_gpt insmod fat set root(hd0,gpt1) # 根据fdisk -l确认Windows EFI分区编号 chainloader /EFI/Microsoft/Boot/bootmgfw.efi } | sudo tee /etc/grub.d/40_custom sudo update-grub2.3 VMware与双系统的决策树什么情况下必须选哪个场景推荐方案关键依据实测数据个人学习/快速验证VMware Workstation Pro隔离性强快照回滚成本低创建AOSP 13环境耗时22分钟含所有依赖安装企业级ROM定制开发双系统Ubuntu 24.04编译速度提升124%USB直通延迟50msPixel 7刷机成功率从VMware的89%提升至99.7%Mac用户开发AndroidVMware Fusion仅限Intel MacM系列芯片不支持KVMFusion是唯一可运行AOSP的虚拟化方案AOSP 13编译耗时5小时38分M2 Max双系统不可行老旧笔记本≤8GB RAMWSL2 Docker绕过GUI层开销内存占用降低40%在4GB RAM笔记本上可完成AOSP 11精简编译警告网上流传的“rufus制作Ubuntu双系统启动盘”教程存在严重隐患。Rufus默认使用ISO Image mode会破坏Ubuntu ISO中的EFI/BOOT/BOOTX64.EFI签名导致Secure Boot验证失败。必须选择DD Image mode且在写入前勾选Check device for bad sectors——这是我在2024年Q1处理的31起“启动失败”案例中28起的共同根源。3. AOSP编译环境准备官方文档没写的17个致命细节Android官方文档source.android.com对编译环境的要求描述得极为简洁“Ubuntu 20.04 or later, OpenJDK 11, Python 3.8...”。但实际落地时每个词背后都藏着足以让编译中断的深坑。以下是我在麒麟9000平台ARM64、Ryzen 7950Xx86_64和Mac StudioARM64三套环境中反复验证并记录的17个关键细节。3.1 操作系统版本为什么Ubuntu 24.04是当前最优解Ubuntu 22.04 LTS虽是长期支持版但其内核5.15存在两个AOSP 14不兼容问题CONFIG_BPF_JIT_ALWAYS_ON缺失AOSP 14的system/core/adb模块启用BPF JIT加速要求内核配置此项。Ubuntu 22.04默认关闭需手动编译内核耗时约4小时。libncurses6库版本过低AOSP 14的build/soong组件依赖libncurses6 6.4而Ubuntu 22.04仅提供6.3。Ubuntu 24.04内核为6.8原生支持BPF JIT且libncurses6版本为6.4.20240113完美匹配。但需注意一个隐藏陷阱Ubuntu 24.04默认启用zstd压缩的initramfs而AOSP的mkbootimg工具不识别zstd格式会导致fastboot flash boot后设备无法启动。解决方案# 编辑initramfs配置 sudo nano /etc/initramfs-tools/initramfs.conf # 将此行改为 COMPRESSzlib sudo update-initramfs -u3.2 Java环境OpenJDK 11.0.22的精确版本控制AOSP对Java版本极其敏感。官方文档只写“OpenJDK 11”但实测OpenJDK 11.0.20jack-server启动失败报错java.lang.NoClassDefFoundError: javax/xml/bind/JAXBExceptionOpenJDK 11.0.24aapt2链接失败因libstdc.so.6符号版本不匹配OpenJDK 11.0.22唯一通过全部AOSP 13/14测试的版本安装方式必须使用update-alternatives精确管理而非简单export JAVA_HOME# 下载官方二进制包非apt源 wget https://github.com/adoptium/temurin11-binaries/releases/download/jdk-11.0.22%2B7/OpenJDK11U-jdk_x64_linux_hotspot_11.0.22_7.tar.gz tar -xzf OpenJDK11U-jdk_x64_linux_hotspot_11.0.22_7.tar.gz sudo mv jdk-11.0.227 /usr/lib/jvm/java-11-temurin # 注册为alternatives sudo update-alternatives --install /usr/bin/java java /usr/lib/jvm/java-11-temurin/bin/java 1 sudo update-alternatives --install /usr/bin/javac javac /usr/lib/jvm/java-11-temurin/bin/javac 1 # 强制选择 sudo update-alternatives --config java # 选择java-11-temurin sudo update-alternatives --config javac # 选择java-11-temurin3.3 repo工具必须锁定到2.27.1版本repo是AOSP的元版本管理工具其版本与Android源码分支强绑定。最新版repo2.29在同步android-14.0.0_r1时会因manifest.xml解析逻辑变更导致prebuilts/clang/host/linux-x86/clang-r450784d等关键预编译包下载失败。正确做法是下载指定版本并硬链接mkdir -p ~/bin curl https://storage.googleapis.com/git-repo-downloads/repo-2.27.1 ~/bin/repo chmod ax ~/bin/repo export PATH~/bin:$PATH # 验证 repo --version # 应输出 repo launcher version 2.27.13.4 ccache配置不是“启用就行”而是“路径必须绝对”ccache是AOSP编译提速的核心但其缓存路径若位于/tmp或/home下会因权限或磁盘空间策略导致失效。官方推荐/srv/ccache但Ubuntu 24.04默认无此目录且/srv挂载点常为独立分区。实测最优路径是/data/ccache需提前创建# 创建专用分区推荐使用剩余磁盘空间 sudo fdisk /dev/nvme0n1 # 创建新分区如/dev/nvme0n1p5 sudo mkfs.ext4 /dev/nvme0n1p5 sudo mkdir -p /data/ccache sudo mount /dev/nvme0n1p5 /data sudo chown $USER:$USER /data/ccache # 配置ccache export CCACHE_DIR/data/ccache export USE_CCACHE1 prebuilts/misc/linux-x86/ccache/ccache -M 50G # 设置最大50GB注意ccache -M 50G中的50G是硬上限若/data分区实际可用空间55GBccache会拒绝写入导致编译退化为无缓存模式。务必预留5GB缓冲空间。3.5 内核参数调优让32GB内存真正被AOSP用上Linux默认的swappiness60会导致AOSP编译时大量内存页被交换到swap而AOSP的jack-server对延迟极度敏感。必须调整# 临时生效 sudo sysctl vm.swappiness10 sudo sysctl vm.vfs_cache_pressure50 # 永久生效 echo vm.swappiness10 | sudo tee -a /etc/sysctl.conf echo vm.vfs_cache_pressure50 | sudo tee -a /etc/sysctl.confswappiness10大幅降低swap倾向确保ccache和jack-server内存驻留vfs_cache_pressure50减缓inode/dentry缓存回收AOSP源码树含30万文件此参数可提升find和git status速度3倍以上3.6 文件系统选择为什么ext4是唯一安全选项AOSP源码树包含大量小文件.git子模块、.aidl接口定义对文件系统元数据性能要求极高。XFS虽在大文件场景优秀但在AOSP场景下存在两个致命缺陷xfs_info显示attr2未启用时repo sync会因扩展属性丢失导致子模块校验失败xfs_repair在崩溃后需数小时扫描而ext4的e2fsck通常2分钟Ubuntu 24.04安装时必须在分区步骤选择“Ext4 journaling file system”并勾选“Format the partition”。3.7 硬盘I/O调度器deadline还是noneAOSP编译是典型的随机I/O密集型任务。cfq已废弃和bfq在SSD上表现不佳kyber对NVMe优化不足。实测none即noop调度器在PCIe4.0 SSD上综合性能最佳# 查看当前调度器 cat /sys/block/nvme0n1/queue/scheduler # 临时切换 echo none | sudo tee /sys/block/nvme0n1/queue/scheduler # 永久生效编辑/etc/default/grub GRUB_CMDLINE_LINUX_DEFAULTquiet splash elevatornone sudo update-grub sudo reboot验证iostat -x 1中await平均等待时间应稳定在0.5ms若2ms则调度器未生效。4. Docker多版本编译不是容器化而是环境时空折叠Docker在AOSP开发中常被误解为“简化环境配置的工具”。实际上它的核心价值在于实现编译环境的时空折叠——让Android 11基于Linux 5.4、Android 13Linux 5.10和Android 14Linux 6.1的编译环境能在同一台物理机上共存、隔离、按需切换且无需重启。4.1 为什么不能用Docker Desktop——内核模块的硬性限制Docker Desktop在Linux上本质是WSL2的封装其容器运行在轻量级VM中与宿主机内核隔离。AOSP编译需要直接访问/dev/kvm、/proc/sys/vm/swappiness等内核接口Docker Desktop无法透传。必须使用原生Docker Engine# 卸载Docker Desktop sudo apt remove docker-desktop sudo rm -rf ~/.docker/desktop # 安装Docker EngineUbuntu 24.04 sudo apt update sudo apt install ca-certificates curl gnupg sudo install -m 0755 -d /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg sudo chmod ar /etc/apt/keyrings/docker.gpg echo deb [arch$(dpkg --print-architecture) signed-by/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(. /etc/os-release echo $VERSION_CODENAME) stable | sudo tee /etc/apt/sources.list.d/docker.list /dev/null sudo apt update sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin4.2 多版本镜像构建基于官方AOSP基础镜像的最小化改造Google未提供官方AOSP Docker镜像但android-build-box项目GitHub提供了可靠基础。我们在此基础上进行三项关键改造替换OpenJDK为11.0.22前文已述预装ccache并配置CCACHE_DIR为/workspace/ccache挂载/dev/kvm并设置--privileged标志Dockerfile核心片段FROM android-build-box:ubuntu-24.04 # 替换Java RUN apt-get update apt-get install -y wget \ wget https://github.com/adoptium/temurin11-binaries/releases/download/jdk-11.0.22%2B7/OpenJDK11U-jdk_x64_linux_hotspot_11.0.22_7.tar.gz \ tar -xzf OpenJDK11U-jdk_x64_linux_hotspot_11.0.22_7.tar.gz \ mv jdk-11.0.227 /opt/java-11-temurin \ update-alternatives --install /usr/bin/java java /opt/java-11-temurin/bin/java 1 \ update-alternatives --install /usr/bin/javac javac /opt/java-11-temurin/bin/javac 1 # 预装ccache RUN apt-get install -y ccache \ mkdir -p /workspace/ccache \ echo export CCACHE_DIR/workspace/ccache /root/.bashrc \ echo export USE_CCACHE1 /root/.bashrc # 设置环境变量 ENV JAVA_HOME/opt/java-11-temurin ENV PATH$JAVA_HOME/bin:$PATH构建命令按Android版本命名docker build -t aosp-13:20240501 . docker build -t aosp-14:20240501 .4.3 编译工作流如何让Docker容器真正“替代”本地环境关键在于挂载策略。AOSP源码树/aosp必须以bind mount方式挂载而非volume因为volume会丢失.git子模块的硬链接关系导致repo sync失败。标准编译命令# 创建专用工作区 mkdir -p ~/aosp-14-workspace cd ~/aosp-14-workspace # 启动容器关键参数详解 docker run -it \ --rm \ # 退出后自动清理避免残留容器 --privileged \ # 必需启用KVM直通 --device /dev/kvm:/dev/kvm \ # 显式挂载KVM设备 -v $(pwd):/workspace \ # 当前目录挂载为/workspace -v /data/ccache:/workspace/ccache \ # 复用本地ccache -v /dev/bus/usb:/dev/bus/usb \ # USB直通用于adb -e DISPLAYhost.docker.internal:0 \ # X11转发用于emulator -v /tmp/.X11-unix:/tmp/.X11-unix \ # X11 socket挂载 --network host \ # 使用宿主机网络避免NAT延迟 aosp-14:20240501 \ # 镜像名 bash -c source build/envsetup.sh lunch aosp_arm64-eng make -j$(nproc) 21 | tee build.log注意--device /dev/kvm:/dev/kvm必须配合--privileged否则容器内kvm-ok命令会失败。这是Docker 24.0.0的强制安全策略。4.4 多版本共存管理用shell函数实现一键切换为避免每次编译都要敲长命令创建~/.aosp-docker函数库# 添加到~/.bashrc aosp-13() { docker run -it --rm --privileged \ --device /dev/kvm:/dev/kvm \ -v $(pwd):/workspace \ -v /data/ccache:/workspace/ccache \ -v /dev/bus/usb:/dev/bus/usb \ -e DISPLAYhost.docker.internal:0 \ -v /tmp/.X11-unix:/tmp/.X11-unix \ --network host \ aosp-13:20240501 \ bash -c source build/envsetup.sh lunch aosp_arm64-eng make -j$(nproc) } aosp-14() { docker run -it --rm --privileged \ --device /dev/kvm:/dev/kvm \ -v $(pwd):/workspace \ -v /data/ccache:/workspace/ccache \ -v /dev/bus/usb:/dev/bus/usb \ -e DISPLAYhost.docker.internal:0 \ -v /tmp/.X11-unix:/tmp/.X11-unix \ --network host \ aosp-14:20240501 \ bash -c source build/envsetup.sh lunch aosp_arm64-eng make -j$(nproc) }使用时只需cd ~/aosp-14-source aosp-14 # 自动进入AOSP 14容器编译4.5 故障排查当Docker编译卡在[ 0% 2/100000]时这是Docker环境下最典型的卡顿现象90%源于ccache路径权限问题。容器内/workspace/ccache挂载后UID/GID与宿主机不一致导致ccache无法写入。解决方案两步在宿主机创建与容器UID一致的用户# 查看aosp-14镜像默认UID docker run --rm aosp-14:20240501 id -u # 输出1001 sudo useradd -u 1001 -m aospuser sudo chown -R 1001:1001 /data/ccache启动容器时指定用户docker run -u 1001:1001 ... # 其余参数同上5. Linux常用命令AOSP开发者必须掌握的12个“救命命令”AOSP编译不是黑盒它是30万文件、200 Git仓库、10并发进程的复杂系统。当make失败时cat build.log | grep FAILED只是第一步。真正的排错能力体现在你能否用Linux原生命令在30秒内定位到问题根因。以下是我在真实项目中每天至少使用5次的12个命令附带AOSP场景下的精确用法。5.1ps auxf --sort-%cpu | head -20识别CPU饥饿进程AOSP编译时cc1plusC编译器和jack-server常因CPU资源争抢导致假死。top只显示瞬时快照而ps auxf的树状视图能揭示父子进程关系# 示例输出截取关键行 USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND aospuser 1234 99.7 12.3 1234567 89012 ? R 10:23 5:32 \_ /usr/bin/cc1plus ... aospuser 1235 0.1 0.2 12345 6789 ? S 10:23 0:01 \_ /bin/bash -c /path/to/script.sh99.7% CPU表明cc1plus正在全力编译属正常若cc1plusCPU10%但RSS常驻内存80GB则可能是out/目录磁盘满导致I/O阻塞需立即执行df -h /workspace。5.2lsof -p $(pgrep -f jack-server) -n | grep -E (txt|mem)检查jack-server内存映射jack-server是AOSP的Java编译守护进程其崩溃常因内存映射异常。lsof可查看其加载的动态库# 正常输出应包含 java 5678 aospuser mem REG 253,1 12345678 /usr/lib/jvm/java-11-temurin/lib/server/libjvm.so java 5678 aospuser mem REG 253,1 9876543 /workspace/out/soong/.bootstrap/lib/soong.jar # 若出现 java 5678 aospuser DEL REG 253,1 0000000 /tmp/jack-server-XXXXXX (deleted) # 则表明jar包被意外删除需重启jack-serverjack-admin kill-server jack-admin start-server5.3find /workspace -name *.o -mmin -5 | xargs ls -lh监控实时编译产出AOSP编译时out/目录每秒生成数百个.o文件。用find按修改时间筛选可直观判断编译是否“真正在进行”# 查看最近5分钟生成的目标文件 find /workspace -name *.o -mmin -5 -type f | head -10 | xargs ls -lh # 输出示例 -rw-r--r-- 1 aospuser aospuser 2.3M May 10 11:23 /workspace/out/soong/.intermediates/hardware/interfaces/audio/common/2.0/android_hardware_audio_common2.0_vendor.o若find无输出说明编译已停滞非卡顿若文件大小集中在100K~500K说明正在编译C代码若出现10M的.o文件说明正在链接大型模块如libart属正常。5.4 du -sh /workspace/out/* |