曲靖市网站建设_网站建设公司_定制开发_seo优化

从零开始 React Native 环境搭建：Expo 和 CLI 到底怎么选？

你是不是也经历过这样的场景？
刚决定用 React Native 做一个跨平台 App，兴致勃勃打开文档，结果被一堆术语砸晕：npx create-react-native-app、react-native init、Expo Go、Metro、EAS Build、Bare Workflow……更别提还要配 Android SDK、Xcode、CocoaPods。

环境没搭好，代码一行都没写，信心先没了大半。

这太常见了。
React Native 的强大在于“一套代码跑双端”，但它的第一道坎——环境搭建——却让很多新手止步。而更大的困惑是：我到底该用 Expo 还是 React Native CLI？

答案不是非黑即白。关键在于：你想以多快的速度启动项目？又能接受多大的限制？

今天我们就来彻底拆解这两条路径，不讲虚的，只聊实战中踩过的坑、绕不开的配置和真实的选择逻辑。

一、Expo：让前端开发者也能5分钟跑起原生App

它到底解决了什么问题？

如果你是个纯前端出身，没碰过 Java、Kotlin 或 Objective-C，也不想装个几GB的 Android Studio 来跑个Hello World——那Expo 就是为你量身定做的。

它把 React Native 中最复杂的部分——原生构建链——全部封装起来。你可以完全用 JavaScript/TypeScript 写代码，通过扫码就能在手机上看到效果，连模拟器都不需要。

“在我机器上能跑”？不存在的。Expo 的标准化环境大大减少了团队协作时的“玄学问题”。

核心机制：你在开发，云端在编译

Expo 的工作方式有点像“远程执行”：

1. 你本地运行npx expo start
2. Metro 打包你的 JS 代码
3. 生成一个二维码
4. 手机上的Expo Go应用扫码，下载并运行你的应用

整个过程你不需要任何原生工具链。iOS 开发？不用 Mac 也能预览（当然最终发布还得 Mac）。Android 构建？Gradle 那些破事交给 Expo 的云服务去处理。

等到要发版了怎么办？用EAS Build（Expo Application Services），一条命令提交到云端，自动帮你打出 APK 和 IPA。

eas build -p android --profile preview

是的，你甚至可以不用自己签名。

关键优势：快、稳、省心

但它也有“天花板”

Expo 最大的限制是什么？不能随便写原生代码。

比如你想接入公司私有的蓝牙硬件 SDK，或者用某个只有.aar包的第三方库——默认情况下，Expo 不允许你修改原生工程。

解决办法有两个：
-使用自定义开发客户端（Dev Client）：你可以“脱离”Expo Go，打包一个包含你原生代码的定制客户端。
-彻底 eject（脱管）：把项目转成裸露的原生结构，从此进入 CLI 模式。

但一旦 eject，你就失去了“零配置”的便利性。

实战流程：三步启动一个项目

# 1. 创建项目（推荐 TypeScript） npx create-react-native-app MyExpoApp --template typescript # 2. 进入目录 cd MyExpoApp # 3. 启动开发服务器 npx expo start

然后拿出手机，安装Expo Go，扫码，搞定。

你会发现项目里没有ios/和android/文件夹——因为它们被 Expo 托管了。

所有配置都集中在app.json或app.config.js中：

{ "expo": { "name": "MyApp", "slug": "myapp", "version": "1.0.0", "orientation": "portrait", "icon": "./assets/icon.png", "splash": { "image": "./assets/splash.png", "resizeMode": "contain" }, "ios": { "supportsTablet": true }, "android": { "adaptiveIcon": { "foregroundImage": "./assets/adaptive-icon.png" } } } }

改个图标、换张启动图，全靠改 JSON，不用碰一行原生代码。

二、React Native CLI：掌控一切，代价是复杂度

它适合谁？

如果你有以下任一情况，CLI 是更合适的选择：
- 项目需要深度集成原生功能
- 团队中有 iOS/Android 工程师
- 对性能要求极高（如音视频处理）
- 必须本地构建，不能走云端（安全合规需求）

CLI 的哲学很简单：给你全部控制权，但也让你承担全部责任。

项目结构一览：原生世界赤裸相见

执行这条命令：

npx react-native init MyRNApp

你会看到熟悉的目录结构：

MyRNApp/ ├── android/ │ ├── app/ │ ├── build.gradle │ └── settings.gradle ├── ios/ │ ├── MyApp.xcworkspace │ └── Podfile ├── src/ ├── App.tsx └── metro.config.js

android/和ios/完整存在，你可以像开发原生项目一样打开 Android Studio 或 Xcode 进行调试。

这意味着你能做几乎所有事：
- 修改启动页动画
- 添加后台任务
- 自定义权限请求流程
- 嵌入 WebView 并与原生通信
- 接入任意.so、.framework或.aar库

构建流程：全流程本地掌控

开发时你需要分别启动：

# 启动 Metro 打包服务 npx react-native start # 在另一个终端运行 npx react-native run-android # 或 npx react-native run-ios

run-android会触发 Gradle 构建，自动安装到设备；run-ios则依赖 CocoaPods 安装依赖并编译。

首次运行pod install可能很慢，建议使用国内镜像源加速：

# Podfile 头部加入 source 'https://mirrors.tuna.tsinghua.edu.cn/git/CocoaPods/Specs.git'

原生模块注册：真正的“桥接”

当你引入一个需要 link 的库（比如react-native-camera），必须手动注册原生模块。

在 Android 中，修改MainApplication.java：

@Override protected List<ReactPackage> getPackages() { return Arrays.<ReactPackage>asList( new MainReactPackage(), new RNCameraPackage() // 注册摄像头模块 ); }

而在 iOS 中，CocoaPods 通常会自动 link，但某些库仍需手动导入。

这种“侵入式”操作是 Expo 所不允许的，但在 CLI 中却是家常便饭。

性能优化利器：Hermes 引擎

CLI 默认支持启用 Hermes —— Facebook 推出的轻量级 JS 引擎，专为移动端优化。

在android/app/build.gradle中开启：

project.ext.react = [ enableHermes: true ]

效果显著：
- 冷启动速度提升 30%+
- 内存占用下降
- 包体积缩小

Expo 也支持 Hermes，但在 CLI 中你可以更精细地控制其行为。

三、Expo vs CLI：一张表看懂本质区别

四、真实场景选择指南：别再问“哪个更好”

场景1：创业公司做 MVP，两周内要上线验证想法

👉选 Expo

理由：时间就是生命。你不需要马上处理推送、后台定位这些复杂功能。先用 Expo 把核心流程跑通，用户反馈来了再考虑扩展。

而且 OTA 更新意味着，哪怕上线后发现一个小 bug，也能立刻修复，不用等审核。

场景2：企业内部管理系统，需对接指纹识别硬件

👉选 CLI

这类私有 SDK 几乎不可能提供 Expo 兼容版本。你需要直接调用.so或.framework，甚至修改底层通信协议。

CLI 给你绝对控制权，虽然前期配置麻烦点，但后期扩展无忧。

场景3：教育机构教学生入门 React Native

👉强烈推荐 Expo

学生电脑配置参差不齐，Windows 居多。如果要求每人装 Android Studio + 配环境变量 + 解决 Gradle 各种报错……课程还没开始，一半人已经放弃了。

Expo 让他们专注在JavaScript 逻辑和 UI 构建上，这才是学习重点。

场景4：已有 Expo 项目，现在要加 AR 功能

👉升级到 Expo Dev Client

不必 eject！Expo 提供了Dev Client模式，允许你在保留 Expo 工具链的同时，添加自定义原生代码。

流程如下：
1. 安装expo-dev-client
2. 在app.json中启用 development client
3. 添加需要的原生库（如 ViroMedia）
4. 使用eas build构建包含原生代码的客户端

这样既保留了 OTA 和云构建的优势，又突破了原生限制。

五、避坑指南：那些文档不会告诉你的事

Expo 常见陷阱

• 权限配置遗漏：即使用了 Expo 提供的相机 API，发布时仍需在app.json中声明权限：

json { "ios": { "infoPlist": { "NSCameraUsageDescription": "需要访问相机用于拍照" } }, "android": { "permissions": ["CAMERA"] } }

• EAS Build 缓存问题：修改原生依赖后记得清除缓存：

bash eas build --clear-cache

• Expo Go 不支持某些库：比如 WebRTC、TensorFlow Lite 等重型原生库，必须用 Dev Client。

CLI 常见痛点

• Android SDK 版本冲突：多个项目依赖不同版本的 Gradle 或 compileSdkVersion，容易出错。建议统一使用 Android Studio 管理 SDK。
• Mac M1 芯片运行模拟器卡顿：尝试使用 Preview 版本的 Android Studio 或切换 CPU 架构为 ARM。
• iOS 首次 pod install 超时：换清华或阿里源，或科学上网。
• Hermes 启用后调试困难：Chrome DevTools 对 Hermes 支持有限，建议使用 Flipper。

六、未来趋势：两条路正在融合

你以为 Expo 和 CLI 是对立的？其实它们正越来越接近。

• Expo 现在支持Bare Workflow，本质上就是一个带 Expo 工具的 CLI 项目。
• CLI 社区也在借鉴 Expo 的自动化理念，比如 React Native New Architecture 正在推动 TurboModules 和 Fabric Renderer 的普及。
• 两者都开始支持Turbo Native Modules，让原生通信更快更安全。

换句话说：未来的理想状态是——用 Expo 的方式开发，享受 CLI 的灵活性。

最后一点建议：不要一开始就追求“完美架构”

很多开发者陷入“选择焦虑”：怕选错技术栈，怕以后重构。

但现实是：大多数项目根本活不到需要重构的那天。

所以我的建议是：

先用 Expo 快速验证产品价值，等真的需要原生能力时，再平滑迁移到 Dev Client 或 CLI。

React Native 的生态足够灵活，允许你从轻到重逐步演进。比起纠结“该用哪个”，不如先跑起来。

毕竟，完成比完美更重要。

如果你已经在用 Expo 或 CLI，欢迎在评论区分享你的实战经验。你是怎么解决环境配置难题的？有没有踩过特别深的坑？一起交流，少走弯路。