返回

repo sync 太慢？AOSP Gingerbread 分支下载优化技巧

Linux

AOSP repo sync 太慢？ Gingerbread 分支下载优化指南

一、直击痛点：repo sync 龟速还乱下东西？

不少朋友在学习嵌入式 Android，或者想研究某个特定 AOSP 老版本（比如经典的 Gingerbread）时，都会碰到一个头疼的问题。按照官方文档或者书籍的指引，执行了类似下面的命令：

repo init -u https://android.googlesource.com/platform/manifest.git -b gingerbread
repo sync

然后，漫长的等待就开始了… 更让人困惑的是，看着终端输出，里面似乎在下载 android-5.x 甚至更新版本的东西？我明明指定的是 gingerbread 分支啊！是不是它下载了多余的代码，才导致这么慢的？

没错，你的直觉是对的。这确实是 repo sync 默认行为的一部分，也是导致同步时间过长的主要原因之一。

二、为啥 repo sync 会这么慢，还会下其他分支？

理解这个问题，得从 repo 工具和 Git 的工作方式说起。

1. Repo 的“贪婪”本性

当你用 repo init -b <branch_name> 指定了一个分支后，repo 会下载对应的 manifest 文件。这个文件定义了该 AOSP 版本包含哪些 Git 项目 (project) 以及每个项目应该检出 (checkout) 哪个分支或 Commit ID。

但是，repo sync 在处理每个 Git 项目时，默认的行为是：

  • 获取这个项目的 完整 Git 历史记录，包括所有的分支和标签 (tags)。
  • 它只是在下载完之后，帮你把工作区切换到 manifest 文件里指定的分支 (gingerbread) 而已。

也就是说，即使你只要 gingerbread 分支的代码，它也会把这个项目从诞生到最新的所有分支信息、提交记录都先尝试拉下来。AOSP 里面上百个项目都这么来一遍，数据量自然小不了。你看到的 android-5... 之类的输出，就是它在同步某个项目时，发现了这些属于其他分支的更新。

2. 项目的历史包袱

gingerbread 是个相当早期的版本 (Android 2.3)。虽然你指定了这个老分支，但它依赖的很多底层项目（比如 kernel, bionic, art 等等）在后续的 Android 版本中持续开发，积累了大量的提交历史。即使这些项目在 gingerbread 时期代码量不大，但它们完整的 Git 仓库可能已经非常臃肿了。

3. 网络，永远的痛

访问 googlesource.com 的网络延迟和带宽限制是个老生常谈的问题，尤其在国内环境下，连接不稳定、速度慢是家常便饭。下载 AOSP 这种体量的代码库，对网络的考验极大。

4. 多仓库管理的开销

AOSP 由数百个独立的 Git 仓库组成。repo 工具需要逐一处理这些仓库，检查状态、拉取更新、解决冲突（虽然下载时冲突少见），这个管理过程本身也有一定的开销，特别是在项目数量极多的时候。

三、给 repo sync 提速的几种实用方法

了解了原因，我们就可以对症下药了。下面是几种常用的加速 repo sync，特别是针对特定分支下载的优化方法：

方法一：只拉取当前分支 (-c 或 --current-branch)

这是解决“看到下载其他分支日志”问题的最直接方法。

  • 原理： 这个参数告诉 repo，在同步每个 Git 项目时，“我只要 manifest 文件里指定的那个分支，别的分支我完全不关心！” 这样 repo 在和远程仓库通信时，只会请求和下载与当前所需分支相关的引用 (refs)，大大减少了需要检查和下载的数据量。
  • 操作： 
    repo sync -c
  • 效果： 能显著减少同步过程中的网络流量和时间，尤其是对于那些历史包袱重的项目。同时也让你眼不见心不烦，看不到其他无关分支的下载信息了。
  • 注意： 使用 -c 参数后，本地的 Git 仓库就只包含 manifest 指定的分支信息。如果你之后想在这个项目里切换到其他本地尚未同步过的分支（比如 master 或其他 android-x.x 分支），会失败。你需要重新执行 repo sync (可能不带 -c) 来获取其他分支信息。但对于目标明确，只想编译特定版本（比如 gingerbread）的场景，这个参数非常合适。

方法二：浅克隆，不要历史 (--depth=1)

如果你的目的仅仅是获取 gingerbread 分支的最新代码用于编译或查看，完全不关心这个分支之前的修改历史，那么浅克隆是极佳的选择。

  • 原理： 这个参数传递给底层的 git clone 和 git fetch 命令，让 Git 只下载每个项目指定分支的 最后一次提交 (commit) 以及相关的文件内容，完全抛弃之前的历史记录。想象一下，每个项目只下载薄薄一层代码快照，而不是整本厚厚的历史书。
  • 操作： 
    repo sync --depth=1
  • 效果： 这是最大幅度减少下载数据量的方法，效果立竿见影！对于网络条件不好，或者磁盘空间有限的情况，简直是救星。
  • 强强联合： 它可以和 -c 参数一起使用，效果更佳： 
    repo sync -c --depth=1
    这样既只关心当前分支，又只下载该分支的最新 commit。
  • 安全/注意：
    • 没有历史： 你将彻底丢失所有代码的修改历史。git log 只能看到一个 commit，无法追溯代码变更。这对于需要调试历史 bug、理解代码演进的开发者来说是不可接受的。
    • 切换分支困难： 和 -c 类似，基于浅克隆仓库进行分支切换、代码合并等操作会遇到很多限制。
    • 场景： 非常适合 CI/CD 构建、快速获取特定版本源码编译等场景。

方法三：加大并发数 (-j <N>)

充分利用你的网络带宽和 CPU 资源。

  • 原理： repo sync 同步 AOSP 涉及几百个项目。默认情况下，它可能只同时下载少数几个项目。-j 参数允许你指定并行下载的任务数量。
  • 操作： 
    repo sync -j8
    这里的数字 8 表示同时最多下载 8 个项目。你可以根据你的 CPU 核心数和网络带宽来调整这个数值。通常建议设置为 CPU 核心数的 1 到 2 倍（比如 4 核 CPU 可以尝试 -j4 或 -j8）。
  • 效果： 在网络带宽允许的情况下，能大幅缩短总体同步时间。多个项目同时下载，总比一个一个排队快得多。
  • 进阶技巧 - 处理网络中断：
    • 网络不稳定时，某个项目下载失败可能导致整个 repo sync 停止。如果想让它更“顽强”一点，遇到错误时跳过并继续尝试其他项目，可以去掉默认的（或者显式指定的）--fail-fast 参数 (或者让 repo sync 失败后再次执行，它会尝试继续未完成的任务)。
    • 如果你希望任何一个项目下载失败就立刻停下来，方便排查问题，可以加上 --fail-fast 参数 (在某些 repo 版本中可能是默认行为)。
    # 示例：并发下载，遇到错误继续尝试其他
# (具体行为可能依赖repo版本，默认可能不是fail-fast)
repo sync -j8

# 示例：并发下载，遇到任何错误立即停止
repo sync -j8 --fail-fast
  • 注意：
    • -j 值不是越大越好。设置过高可能会耗尽本地 CPU 或内存资源，或者把网络连接撑爆（尤其是小水管用户），甚至可能被服务器视为攻击而临时限速。需要根据自己的机器和网络情况 expérimentation 找到最佳值。
    • 可以和其他参数组合使用，比如 repo sync -c -j8 --depth=1。

方法四：换个快的镜像源 (国内用户福音)

如果你在国内，访问官方的 googlesource.com 速度很可能不理想。使用国内的镜像服务器可以显著改善体验。

  • 原理： 国内的一些高校和机构（如清华大学 TUNA、中国科学技术大学 LUG）提供了 AOSP 的镜像。从这些地理位置更近、带宽通常更友好的服务器下载，速度会快很多。

  • 操作：

    1. 在 repo init 时指定镜像源： 这是最推荐的方式。

      • 清华 TUNA 源: 
        repo init -u https://mirrors.tuna.tsinghua.edu.cn/git/AOSP/platform/manifest -b gingerbread
      • 中科大 LUG 源: (注意协议可能是 git:// 或 https://，请参考镜像站说明) 
        repo init -u git://mirrors.ustc.edu.cn/aosp/platform/manifest -b gingerbread
        或者 
        repo init -u https://mirrors.ustc.edu.cn/aosp/platform/manifest.git -b gingerbread
      • 顺便把 repo 工具本身也换成镜像： (可选但推荐) 
        # 以清华为例
repo init -u https://mirrors.tuna.tsinghua.edu.cn/git/AOSP/platform/manifest -b gingerbread --repo-url=https://mirrors.tuna.tsinghua.edu.cn/git/git-repo

    2. 如果已经 init 过官方源：

      • 方法一 (推荐): 删除 .repo 目录，然后用上面的镜像源地址重新 repo init。这是最干净的方式。 
        rm -rf .repo
repo init -u <镜像源 manifest 地址> -b gingerbread [--repo-url=<镜像 repo 地址>]
repo sync ...
      • 方法二 (修改配置): 编辑项目根目录下的 .repo/manifests/default.xml (或者你 init 时使用的 .xml 文件名)，找到 <remote> 标签，将其中的 fetch 属性的值从 https://android.googlesource.com/ 改为镜像源的地址（例如 https://mirrors.tuna.tsinghua.edu.cn/git/AOSP/ 或 git://mirrors.ustc.edu.cn/aosp/）。保存后再执行 repo sync。有时可能还需要修改 .repo/manifest.xml 中 repo 工具自身的远程地址。这种方法稍微复杂，不如重新 init 来得直接。

  • 效果： 对于国内用户，网络速度提升通常非常明显，是解决下载慢最有效的手段之一。

  • 注意：

    • 同步延迟： 镜像源与 Google 官方源之间存在一定的同步延迟，可能从几小时到一天不等。如果你需要获取绝对最新的代码，镜像可能不适合。但对于 gingerbread 这种早已不再更新的稳定分支，同步延迟完全不是问题。
    • 镜像站状态： 使用前最好访问一下镜像站点的帮助页面，确认 AOSP 镜像的当前状态和推荐的 URL 格式。

四、组合拳出击，效果更佳

通常，将上述多个方法组合起来使用，能达到最佳的加速效果。

推荐的组合策略 (针对国内用户，同步 Gingerbread 分支)：

  1. 使用国内镜像源重新 init (如果还没开始或者可以重来)：

    # 使用清华源，指定 gingerbread 分支，同时使用浅克隆，并将 repo 工具本身也指向镜像
repo init -u https://mirrors.tuna.tsinghua.edu.cn/git/AOSP/platform/manifest -b gingerbread --depth=1 --repo-url=https://mirrors.tuna.tsinghua.edu.cn/git/git-repo

  2. 执行 sync 命令，结合 -c 和 -j：

    # 只拉取当前分支，使用 8 个并发下载，失败时快速停止（方便定位）
repo sync -c -j8 --fail-fast

    (并发数 8 请根据你的实际情况调整)

如果你已经用官方源 init 并且不想删除 .repo 重来：

可以直接在现有的基础上执行带优化参数的 sync 命令：

repo sync -c -j8 --depth=1

这样虽然没有享受到镜像源的网络加速，但 -c 和 --depth=1 仍然能帮你大幅减少需要下载的数据量。

通过应用这些方法，尤其是结合使用 -c, --depth=1, -j 和镜像源，应该能显著改善 AOSP repo sync 过慢的问题，让你更快地获取到 gingerbread 或其他目标分支的代码。