在 Android 原生开发中，工程化的终局通常是围绕 Gradle 展开的。我们编写复杂的 build.gradle 脚本管理变体 (Flavors)，配置签名密钥 (Keystore)，并通过 Jenkins 或 GitHub Actions 配合 Google Play Publisher API 实现自动化发布。
当你来到 React Native 的跨平台世界时，工程化的复杂度不仅没有降低，反而翻倍了：你需要同时处理 Android (Gradle, Keystore, Play Store) 和 iOS (Xcode, Provisioning Profiles, Certificates, App Store)。
为了解决这个痛点，EAS (Expo Application Services) 和 Fastlane 成为了 RN / Expo 开发者的“工程化银弹”。
1. 原生 CI/CD vs 跨平台 CI/CD 痛点
作为一个 Android 开发者，你可能觉得打包很简单：./gradlew assembleRelease。
但在 RN 中，如果你不使用云构建工具，你需要面对：
- 本地环境地狱：打包 iOS 必须要有 Mac。团队里如果没有 Mac 设备，就无法出 iOS 包。
- 证书管理噩梦：iOS 的证书和描述文件极其繁琐（CSR, p12, mobileprovision），一旦过期或换电脑就会让人抓狂。
- 多端发布繁琐：同时向 Google Play Console 和 App Store Connect 提交包，并填写各自的更新日志。
2. EAS (Expo Application Services)：云端构建的降维打击
EAS 是 Expo 团队提供的一套深度整合了 React Native / Expo 体系的云端服务。即便你的项目是 "Bare React Native" (没有使用 Expo 框架)，你依然可以配置使用 EAS。
它完美对应并超越了我们熟知的原生工作流。
EAS Build (云端打包)
- Android 对比：相当于你把项目推送到一台配置好最新 JDK、Android SDK 和 NDK 的云服务器上执行
./gradlew bundleRelease。 - 核心优势：
- 无需本地 Mac 即可打 iOS 包。云端提供了各种版本的 macOS 和 Xcode 镜像。
- 自动管理证书：对于 iOS，EAS 可以自动连接你的 Apple ID，为你生成、管理并托管生产环境的签名证书。再也不用手动导
.p12了。对于 Android，它同样支持云端托管 Keystore。
# EAS 打包体验：只需一行命令
eas build --platform all --profile production
EAS Submit (云端发布)
- Android 对比：类似于配置了
gradle-play-publisher插件，或者在 GitHub Actions 中使用upload-artifact和相应的 Play Store Action。 - 核心优势：在 EAS Build 完成后，EAS Submit 可以自动将
.aab投递到 Google Play，将.ipa投递到 TestFlight/App Store。
EAS Update (热更新 OTA - Android 开发者的新武器)
- Android 对比：原生 Android 如果要实现热修复 (Hotfix)，通常需要接入如 Tinker, Sophix 等复杂的框架，且面临系统兼容性问题。
- 降维打击：因为 RN 的业务逻辑都打包在一个
index.android.bundle(本质是 JS 文件) 中。EAS Update 允许你绕过应用商店的审核（只要不修改原生 Java/Kotlin/C++ 代码），直接将新的 JS 产物推送到用户的手机上！这对于紧急修复线上 Bug 简直是神兵利器。
3. Fastlane：多端自动化的一体化方案
如果你更倾向于自建 CI/CD (比如部署在公司的 GitLab Runner 上)，或者你需要更精细地控制发布流程，Fastlane 是行业标准。
作为一个 Android 开发者，你可能听说过或用过 Fastlane 的 supply 工具来上传 APK，但在 RN 领域，Fastlane 的作用被放大到了极致。
Fastlane Match (证书管理)
对于 iOS 的证书噩梦，fastlane match 创造性地提出了“通过 Git 仓库来共享和同步证书”的方案。团队所有成员只需运行一个命令，就能拉取并安装解密后的证书，确保团队开发环境和 CI 服务器环境绝对一致。
Fastlane 核心概念对比
| 概念 | Fastlane 术语 | Android Gradle 术语 / 原生对应物 |
|---|---|---|
| 执行任务集合 | lane | Gradle Task (e.g., task deployStore { ... }) |
| Android 打包 | gradle(task: "bundle", build_type: "Release") | ./gradlew bundleRelease |
| iOS 打包 | gym / build_app | xcodebuild -workspace ... |
| Android 发布 | upload_to_play_store (内部是 supply) | Google Play Publisher API |
| iOS 发布 | upload_to_testflight / upload_to_app_store | Transporter / altool |
RN 项目中的 Fastlane 实战示例 (Fastfile)
通常，RN 项目的根目录下会分别有 android/fastlane/Fastfile 和 ios/fastlane/Fastfile。
android/fastlane/Fastfile 示例：
default_platform(:android)
platform :android do
desc "打包并发布到 Google Play 内部测试"
lane :beta do
# 相当于跑了 ./gradlew clean
gradle(task: "clean")
# 相当于跑了 ./gradlew bundleRelease
gradle(
task: "bundle",
build_type: "Release"
)
# 自动上传 AAB 到 Play Console
upload_to_play_store(
track: 'internal',
aab: 'app/build/outputs/bundle/release/app-release.aab'
)
end
end
4. 总结与建议
对于 Android 开发者转型 RN，在工程化发布阶段，建议路径如下：
- 首选 EAS：如果公司没有严格限制代码必须在内网构建，强烈推荐拥抱 EAS。它把 iOS 繁琐的证书管理和本地环境依赖抽象到了云端，让你能以近乎纯开发者的视角完成跨平台分发，同时 EAS Update 提供的热修复能力是原生开发很难轻易体验到的。
- 次选 Fastlane + 自建 CI：如果出于安全或成本考虑必须自建 CI（例如通过 GitHub Actions 配合内网 Runner），使用 Fastlane。对于 Android 侧，它只是你熟悉的 Gradle 命令的包装；对于 iOS 侧，引入
fastlane match来管理团队证书是保证你头发数量的关键。
