移动开发中的构建服务器 — 它是什么、任务和原理

什么是 Build Server

Build Server（构建服务器） — 是一个专用的计算系统，用于自动执行与代码编译和版本发布准备相关的任务。与开发人员本地计算机上的编译不同，服务器使用仓库副本工作，采用干净环境和固定版本的依赖。

构建服务器是 Continuous Integration 实践的关键组件。它确保每个提交无论是谁完成的，都经过相同的验证流程。这消除了“在我的机器上可以跑”的问题，并确保统一的质量标准。

根据 Google DORA, 2025 的数据，使用专用构建服务器的团队将变更确认时间从小时缩短到分钟。这直接影响了功能和修复快速提供给终端用户的速度。

为什么移动开发需要构建服务器

移动应用编译需要大量资源：Kotlin 或 Swift 的编译可能需要 5 到 40 分钟。如果在开发人员的 本地计算机上运行编译，在完成之前他无法高效工作。构建服务器解决了这个问题，让开发人员能够做其他任务。

构建服务器和 CI 服务器的区别

在实践中，这两个术语常被当作同义词使用，但它们之间有区别：CI 服务器（Jenkins、CircleCI） — 是管理管道的系统，而构建服务器是运行这些管道的物理或虚拟主机。一个 CI 服务器可以管理多个构建代理（build slaves）。

构建服务器架构

典型的构建服务器由多个组件组成，每个组件负责过程的 特定阶段。了解架构有助于在团队负荷下正确扩展基础设施。

主要组件

内核（executor） — 运行构建任务。可以以 Docker 容器、虚拟机或直接在主机上运行。任务队列 管理并行构建的优先级。产物存储 保存结果（APK、IPA、AAB）供后续发布。

构建代理网络（build farm）

为了加快工作速度，构建服务器可以管理代理池。每个代理是一台独立的计算机或容器，能够执行构建。随着负荷增加，自动扩展（auto-scaling）在云中添加新的代理。例如，Jenkins 配合 Kubernetes 插件可以为每个构建动态创建 pod。

pipeline {
    agent {
        kubernetes {
            yaml """
apiVersion: v1
kind: Pod
spec:
  containers:
  - name: android-sdk
    image: openjdk:17-jdk
    command: ['sleep','infinity']
"""
        }
    }
    stages {
        stage('Build') {
            steps {
                sh './gradlew assembleDebug'
            }
        }
    }
}

构建服务器类型

构建服务器按部署方式和 目标技术栈分为几大类。具体解决方案的选择取决于团队规模、预算和安全要求。

Self-hosted 构建服务器

Jenkins、TeamCity、Bamboo、GitLab Runner（self-hosted）— 安装在自己的服务器或 VPS 上。优点：完全控制配置，可使用任何软件，数据不离开公司基础设施。缺点：管理、更新和扩展成本。

云管理解决方案

GitHub Actions、CircleCI、Bitrise、Codemagic、GitLab SaaS — 无需管理服务器。按构建分钟或订阅付费。对于小团队来说，这是 最佳起步。对于构建量大的大型项目，成本可能超过 self-hosted 解决方案。

针对 iOS 开发的构建服务器

iOS 的特点是编译只能在 macOS 上进行。选项：机架中的 Mac mini、MacStadium（租用 Mac）、带 macOS runner 的 GitHub Actions、自带 Mac 代理的 Bitrise。Self-hosted Mac 构建服务器需要购买昂贵的设备并维护它。

如何设置构建服务器

让我们逐步查看为含有 Android 和 iOS 构建的移动项目设置构建服务器。作为基础，我们使用 GitHub Actions， iOS 用 self-hosted runner，Android 用云 runner。

步骤 1：安装和配置 CI 服务器

选择管理平台（Jenkins、GitLab、GitHub Actions）。安装主节点，通过 SSH 或 personal access token 配置对 仓库的访问。配置 webhook 以在推送到仓库时自动启动构建。

步骤 2：添加构建代理

将一台或多台计算机注册为代理（slaves/runners）。对于 Android 构建，代理可以在安装了 JDK、Android SDK、Gradle 的 Linux 或 Windows 上运行。对于 iOS — 在安装了 Xcode Command Line Tools 和 CocoaPods 的 macOS 上。

步骤 3：配置管道

定义阶段：clone、安装依赖、编译、测试、发布产物。为了加快速度，使用依赖的 缓存（Gradle cache、CocoaPods cache、Docker image layers）。

name: Android Build
on:
  push:
    branches: [main, develop]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          distribution: 'temurin'
          java-version: '17'
      - name: Cache Gradle
        uses: actions/cache@v4
        with:
          path: ~/.gradle/caches
          key: ${{ runner.os }}-gradle-${{ hashFiles('**/*.gradle*') }}
      - name: Build Release APK
        run: ./gradlew assembleRelease
      - name: Upload Artifact
        uses: actions/upload-artifact@v4
        with:
          name: app-release.apk
          path: app/build/outputs/apk/release/app-release.apk

构建服务器成本对比

在 self-hosted 和云构建服务器之间的选择不仅是技术决定，还是 财务决定。成本因构建量、所需执行时间和 iOS 是否需要 macOS 而差异很大。

CAPEX 与 OPEX 对比

Self-hosted 服务器需要资本支出（CAPEX）：购买设备（Mac mini 从 $699 起、服务器机架、网络设备）、配置和维护。云解决方案 — 运营成本（OPEX）：按构建分钟付费。对于小团队，OPEX 更划算；对于每天有数百次构建的大型项目，CAPEX 在 6–12 个月内收回成本。

隐性成本

在计算预算时，考虑 隐性成本：软件更新时间、故障排除、配置备份、产物网络存储。对于 self-hosted 解决方案，在基确维护成本上添加 20–30%。对于云解决方案，确保分钟限额覆盖峰值负荷，尤其是在发布前。

成本优化

降低构建服务器成本的方法有多种：在云中使用 spot 实例（便宜达 70%）、在构建之间缓存依赖、限制失败管道的执行时间以及配置在工作时间外自动关闭闲置的 self-hosted 代理。

构建服务器最佳实践

构建服务器的高效工作需要遵循一系列原则。优化构建速度 和基础设施稳定性直接影响开发团队的生产力。

缓存和递增构建

Gradle Build Cache、针对 C/C++ 的 CCache、针对 Kotlin 和 Swift 的递增编译器 — 启用所有可用的缓存机制。配置远程构建缓存（通过 HTTP 或 S3），以便不同的开发人员和代理共享编译结果。

环境隔离

每次构建应在干净的环境中运行。使用 Docker 容器 或临时虚拟机来排除之前构建对当前构建的影响。这消除了“污染状态”（state pollution）的问题。

• 使用 Docker 对构建环境进行容器化 — 这保证了构建的可重复性
• 设置监控 构建服务器 — CPU、内存、磁盘、构建时间、错误频率
• 自动清理 旧产物，以免填满磁盘空间

构建服务器安全

构建服务器可以访问源代码、签名密钥和机密。最小化 攻击面：为不同项目使用隔离的代理，限制对主节点的访问，使用签名提交并检查依赖的漏洞。