移动应用
用 React Native / Expo 构建并发布跨平台移动应用，从规划到应用商店。
规划与初始化
定义范围、选择 Expo 或裸工作流，并搭建项目骨架。
为什么
移动端规划锁定了后续难以变更的约束：导航结构、状态形状、离线行为。Expo 与裸工作流是'1 周 vs 3 个月'的决策——Expo 替你处理原生模块和 OTA 更新；裸工作流给你完整原生控制，但你要自己维护 Gradle/Xcode 构建。
何时使用
在写任何界面代码之前。聚焦的 MVP 通常 1-2 周。现在就决定仅 iOS 还是双平台——它影响每个依赖选择。
如何做
1. 定义 MVP 范围
- 列出 3-5 个核心界面（如 认证、信息流、详情、设置）
- 若能缩短测试周期，先选一个平台（iOS）
2. 选择工作流
- Expo（推荐）：npx create-expo-app，开发无需 Xcode/Android Studio
- 裸工作流：npx react-native init，完整原生控制，你维护原生构建
3. 搭建导航
- expo-router（基于文件，类似 Next.js）— 新应用推荐
- 提前定义 tab/stack/modal 结构
4. 选择状态 + 数据层
- 状态：Zustand（简单）或 Redux Toolkit（结构化）
- 数据：TanStack Query 管服务端状态，AsyncStorage 管本地缓存
- 规划离线：缓存优先读，写入排队同步
5. 配置环境
- .env 放 API URL、Sentry DSN、功能开关
- EAS Build（Expo 应用服务）做云端构建，无需 Xcode
示例
脚手架：
npx create-expo-app@latest my-app --template tabs
cd my-app && npx expo install expo-router zustand @tanstack/react-query
app/（expo-router 基于文件）
_layout.tsx — 根 stack + QueryClientProvider
(tabs)/_layout.tsx — 底部 tab 导航
(tabs)/index.tsx — 信息流
(tabs)/detail/[id].tsx
login.tsx
.env.local：
EXPO_PUBLIC_API_URL=https://api.example.com
EXPO_PUBLIC_SENTRY_DSN=...
决策：Expo 托管 + EAS Build（前 3 个月无需本地 Xcode）
常见问题
- ⚠过早选裸工作流——你花数周在 Gradle/Xcode 而非功能上
- ⚠无离线规划——弱网下应用白屏，用户认为它坏了
- ⚠深链和导航结构临时决定，加界面时被迫重构
最佳实践
- ✓从 Expo 托管开始——仅在需要 Expo 不支持的原生模块时才 eject
- ✓用 expo-router 提前把导航设计成树；文件路径即路由
- ✓服务端状态与本地状态分开——TanStack Query + Zustand，而非一个巨型 Redux store
开发与测试
构建界面，配备快速刷新、真机测试和每次提交的 CI。
为什么
移动端 bug 比网页更难复现——设备碎片、系统版本、网络条件放大边界情况。第一周就启用快速刷新和真机测试，能发现模拟器漏掉的布局和手势问题。没有 CI，原生依赖的回归会悄悄破坏构建。
何时使用
初始化后。先做风险最高的界面（认证或核心流程）以尽早验证导航 + 数据层。
如何做
1. 用快速刷新开发
- npx expo start — 真机扫 QR（Expo Go）
- 按 'j' 网页预览，'i' iOS 模拟器，'a' Android 模拟器
2. 增量构建界面
- 一个界面一个 PR，PR < 400 行便于审查
- 用 React Native Paper / Tamagui 保持组件一致
- 尽早用 react-native-gesture-handler 测试手势
3. 处理平台差异
- Platform.OS 判断分歧代码
- Platform.select({ ios: ..., android: ... })
- SafeAreaView 处理刘海；react-native-safe-area-context
4. 搭建测试
- Jest + React Native Testing Library 做组件/单元测试
- Detox 或 Maestro 做 E2E（Maestro 更简单，YAML 流程）
- 每个 PR 在 CI 跑测试（GitHub Actions + EAS）
5. 加可观测性
- Sentry React Native（崩溃、面包屑、性能）
- LogRocket / Embrace 做会话回放（移动端专用）
示例
组件测试（Jest + RNTL）：
test('feed renders items', () => {
const { getByText } = render(<Feed items={[{id:1,title:'Hi'}]} />);
expect(getByText('Hi')).toBeTruthy();
});
E2E（Maestro flow.yml）：
appId: com.example.app
- launchApp
- tapOn: { id: 'login-button' }
- assertVisible: 'Welcome'
CI（.github/workflows/ci.yml）：
- npm ci && npx expo prebuild
- npm test -- --coverage
- npx maestro test flows/
常见问题
- ⚠只在模拟器测试——手势和键盘 bug 只在真机出现
- ⚠iOS 开发时忽视 Android——提交时小屏 Android 布局崩坏
- ⚠上线后才加崩溃上报——第一台坏设备就是 1 星评价
最佳实践
- ✓第一天就在真机测试——用手机扫 Expo QR，而非只看模拟器
- ✓CI 里 iOS 和 Android 都跑 Maestro E2E——平台 bug 是非对称的
- ✓首次 TestFlight 前就装 Sentry——你需要在评审遇到崩溃前就有数据
部署与 OTA 更新
用 EAS 构建生产包，并通过 OTA 推送 JS 更新而无需商店审核。
为什么
EAS Build 在云端生成签名包，无需与 Xcode 签名搏斗。OTA 更新（expo-updates）让你几分钟推送纯 JS 修复，而非等 1-7 天商店审核——对崩溃修复至关重要，但只有结构正确才安全。
何时使用
核心流程在真机测试通过后。首次 TestFlight 前就建好 EAS 和 expo-updates，这样需要时更新通道已就绪。
如何做
1. 配置 EAS
- eas.json：development、preview、production 三个 profile
- eas build --platform ios --profile production
- 凭证：EAS 自动管理签名（需 Apple Developer 账号）
2. 搭建 OTA 更新
- npx expo install expo-updates
- eas update --branch production --message "修复登录崩溃"
- 纯 JS 变更即时推送；原生变更需新包
3. 分阶段发布
- 先更新 staging 通道，冒烟测试
- 24 小时无问题后提升到 production 通道
- expo-updates rollback 回滚坏更新
4. 首次提交包到商店
- iOS：eas submit --platform ios（用 App Store Connect API）
- Android：eas submit --platform android（Google Play 服务账号）
- 首次需人工审核；更新可分阶段
5. 部署后监控
- Sentry release health：无崩溃用户 %、每版本新问题数
- 无崩溃率低于 99.5% 时用 OTA 回滚
示例
eas.json（production profile）：
{
"build": {
"production": {
"distribution": "store",
"ios": { "applicationArchivePath": "build/*.ipa" }
}
}
}
推送纯 JS 热修复：
eas update --branch production --message "fix: 冷启动 null user"
# 用户下次打开即生效，无需商店审核
推送原生变更（新权限）：
eas build --platform ios --profile production
eas submit --platform ios # 需完整商店审核
常见问题
- ⚠OTA 更新用了新原生 API——旧包设备崩溃
- ⚠无 staging 通道——每次更新直达所有用户，无法发现回归
- ⚠崩溃修复等商店审核，而本可用 OTA 即时推送
最佳实践
- ✓只 OTA 推送纯 JS 变更；任何原生变更都需新包 + 商店审核
- ✓始终先更新 staging 通道，等 24 小时再提升到 production
- ✓把 expo-updates rollback 写进事件手册——它是最快的回滚
商店提交与增长
上架 App Store 和 Google Play，配备素材、ASO 和基于评价的迭代。
为什么
商店素材质量直接驱动安装转化——截图和描述前三行决定搜索用户是否安装。ASO（应用商店优化）是移动端的 SEO：做一次，终身复利。评价回复是你的公开支持渠道。
何时使用
首个生产包构建并测试通过后。别赶素材——一套好截图能让安装转化翻倍。
如何做
1. 准备商店素材
- 图标：1024x1024，无 alpha，无圆角（商店会加）
- 截图：6.7" iPhone + 5.5" 覆盖最广；展示真实 UI，非营销话术
- 描述：前三行是钩子（不展开即可见）
2. 写 ASO 优化元数据
- 标题：品牌 + 1 个关键词短语（iOS 30 字，Android 50 字）
- 关键词：iOS 100 字，用 AppFollow / Sensor Tower 调研
- 副标题：讲收益而非功能（"30 秒追踪习惯" 而非 "习惯追踪器"）
3. 提交审核
- iOS：eas submit --platform ios（1-3 天审核，首次后更快）
- Android：eas submit --platform android（通常 < 24 小时）
- 如实填写隐私政策 URL 和数据使用问卷
4. 上线并监控评价
- 24 小时内回复每条评价——这是公开支持
- 在 App Store Connect / Play Console 追踪安装转化
- 关注提及特定设备/系统的 1 星评价
5. 用 ASO 迭代
- A/B 测试图标和截图（Play Console 实验）
- 每季度根据搜索词报告更新关键词
- 每次更新都是重新进入"新品"区的机会
示例
App Store Connect 上架信息：
名称："FocusFlow — 习惯追踪"（关键词：习惯追踪）
副标题："每天 30 秒养成习惯"
关键词：习惯,追踪,日常,连续,目标,打卡,养成
截图：6.7" iPhone，首图=核心流程，末图=设置
评价回复模板：
"{name} 你好，抱歉带来不便。v1.2 已修复——
去 App Store 更新即可。退款请邮件 [email protected]。"
Play Console 实验：
测试图标 A（抽象）vs B（应用 UI）14 天
-> B 安装转化 +18%，上线 B
常见问题
- ⚠营销风截图掩盖真实 UI——用户不信任，不安装
- ⚠标题堆砌关键词——商店惩罚，排名下降
- ⚠忽视 1 星评价——每条未回复的差评约损失 10 次安装
最佳实践
- ✓首图展示核心操作，而非启动页——它是安装转化的第一驱动
- ✓24 小时内回复每条评价；礼貌回复常在更新后把 1 星变 4 星
- ✓持续跑 Play Console 图标/截图 A/B 测试——小胜在应用生命周期中复利