mobile-development

移动开发

一项用于构建 iOS 和 Android 应用的技能，针对原生（Swift/SwiftUI、Kotlin/Jetpack Compose）和跨平台（Flutter、React Native）技术栈提供深入的框架专属指南。四者共用一套 Agent 工作流——搭建脚手架、构建并签名、在设备和模拟器上测试，以及发布到应用商店——因此它们属于同一项技能，并按框架提供参考资料，沿用 frontend-engineering 的先例。先加载下方的共享工作流，再按需加载你实际采用的框架对应的参考资料。

框架	技术栈	参考资料（按需加载）
iOS	Swift、SwiftUI/UIKit、Xcode	references/ios.md
Android	Kotlin、Jetpack Compose、Gradle	references/android.md
Flutter	Dart、Flutter SDK	references/flutter.md
React Native	TypeScript/JavaScript、React、Metro	references/react-native.md

适用场景

任务涉及移动应用生命周期的任何环节时，都可加载此技能：

• 搭建脚手架——为 iOS、Android、Flutter 或 React Native 创建新的移动项目：选择框架、初始化项目并设置平台工具链。
• 构建并签名——编译调试版或发布版、配置代码签名（证书、配置描述文件、密钥库、应用签名），或生成可分发的产物（.ipa、APK、AAB）。
• 在设备和模拟器上测试——在 iOS 模拟器、Android 模拟器或实体设备上运行和调试，包括设备配置、连接和平台特定的运行时行为。
• 发布到应用商店——提交到 App Store（TestFlight、App Store Connect）或 Google Play（内部、封闭式、开放式测试轨道、Play Console），并判断是否已准备好通过应用商店审核。
• 移动端特有行为——应用生命周期和后台运行、离线存储与同步、推送通知、深层链接，以及移动端测试（单元、组件、UI 和设备云测试）。

不适用场景

• Web 前端——组件架构、状态管理和浏览器行为应使用 frontend-engineering；此技能涵盖运行于 iOS 和 Android 设备上的应用。
• 后端服务和 API——服务端逻辑、API 设计和服务端数据持久化应使用 backend-engineering。移动应用会调用这些 API，而不是取代它们。
• 桌面端或 Web 平台目标——面向桌面端/Web 的 Flutter 和面向 Web 的 React Native（React Native Web）在交付和测试方面各不相同；此技能仅适用于 iOS 和 Android 应用商店平台。
• 跨平台、以 Web 为先的开发——如果交付物是网站或 PWA，请改用 frontend-engineering。

移动工程师的职责范围

你负责	你不负责
移动应用架构——平台结构、应用入口、导航，以及设备上的状态管理	后端 API、数据模型和服务器端持久化——这些属于 backend-engineering
框架和工具链配置——Xcode/Gradle 项目配置、Flutter/React Native 脚手架、依赖管理	Web 前端架构和浏览器行为——这些属于 frontend-engineering
构建和签名——调试版/发布版构建、证书、配置描述文件、密钥库、应用签名、版本号和构建号	服务器软件的发布编排和推出流程——这些属于 release-engineering
设备和模拟器测试——模拟器、仿真器、实体设备、adb/xcrun 设备工作流	整个产品的测试策略、覆盖率和质量门禁——这些属于 qa-methodology
移动端特有事项——生命周期/后台运行、离线和同步、推送、深度链接、移动端性能	用户旅程、线框图和交互设计——这些属于 product-design-and-ux
应用商店提交——TestFlight、App Store Connect、Play Console、发布轨道、商店列表元数据	CI/CD 流水线基础设施——这些属于 platform-engineer

通用移动端工作流

无论使用哪种框架，每项移动端任务都遵循相同的四个步骤。框架特定的深入细节留待各框架参考文档——在相关步骤中阅读即可。

1. 搭建脚手架

生成代码前，先明确应用的基本情况：

• 平台和框架——原生 iOS、原生 Android、Flutter 或 React Native。根据团队技能、目标受众和各项功能的需求进行选择（参见 Core Principles）。
• 最低 OS 版本——你将支持的最旧 iOS 和 Android 版本；下文的所有决策（API、依赖、测试）都由此决定。
• 项目初始化——使用框架的标准工具生成项目（xcodebuild/Xcode 模板、Android Studio/Gradle、flutter create、npx @react-native-community/cli init 或 create-expo-app），并在添加应用代码前提交脚手架，以便工具链升级可供审查。
• 唯一事实来源——使用跨平台框架时，以单个项目根目录构建两个平台，确保能够从代码仓库复现构建产物。

2. 构建和签名

只能在你的机器上运行的构建，不算真正的构建：

• 在 CI 中构建一次——发布构建必须能在干净的机器或 CI 运行器上复现，而不只是能在 IDE 中构建。固定工具链版本（Xcode、JDK/Gradle、Flutter SDK、Node）。
• 签名与构建分开——将签名资产（证书、配置描述文件、密钥库）保存在代码仓库之外；通过环境变量或安全的密钥存储来引用。各平台要求的存放位置，请参阅各框架的参考文档。
• 可区分的构建产物——每次发布都必须递增版本号和构建号，以便测试人员和崩溃报告能够识别构建版本。
• 了解构建产物格式——iOS 使用 .ipa，Android 使用 APK 和 AAB，此外还有框架特定的中间产物。应用商店提交有严格的格式要求（例如，Google Play 要求新应用使用 AAB）。

3. 在设备和模拟器上测试

在代码实际运行的环境中测试，而不是在方便的地方测试：

• 模拟器提速，真机验证 — 模拟器速度快且易于编写脚本，但真机才能反映真实的网络、电池、内存和传感器表现。两者都要覆盖。
• 全新安装 — 测试全新安装（而不只是覆盖旧版本重新构建），以发现首次启动、存储和迁移问题。
• 设备矩阵 — 覆盖已纳入范围的操作系统版本和屏幕尺寸，以及低内存和低存储空间的情况。当矩阵超出本地硬件能力时，使用设备云（Firebase Test Lab、BrowserStack、Xcode Cloud）。
• 调试版与发布版保持一致 — 调试版和发布版是不同的程序（proguard/代码缩减、剥离、优化）。提交应用商店前，先对签名后的发布包进行冒烟测试。

4. 提交到应用商店

提交应按清单逐项检查，而不是事后才考虑：

• 先进入测试轨道 — 正式发布前，先分发到 TestFlight（iOS）和 Android 内部或封闭测试轨道；应用商店不应成为你首次获取真实设备反馈的途径。
• 做好商店发布准备 — 元数据、截图、隐私政策、数据收集声明和隐私营养标签必须与应用的实际行为一致。审核要求会有变化；请在临近提交时重新确认。
• 了解审核预期 — 两家应用商店都会因缺少隐私披露、元数据具有误导性、启动时崩溃，以及登录或应用内购买流程故障而拒绝应用。上传前，按平台的审核清单检查应用。
• 分阶段发布 — 优先采用分阶段发布（Play 上的分阶段发布、App Store Connect 上的渐进式发布），这样回归问题只会影响少数用户，而不会立即影响所有人。

移动端特有问题

以下问题体现了移动端工程与 Web 和桌面端工作的不同之处。

应用生命周期与后台运行

移动操作系统会积极终止和挂起应用；生命周期管理不可忽视：

• 生命周期状态 — iOS（前台/后台/非活跃状态、基于场景的生命周期）和 Android（Activity/Fragment 状态、进程终止）。未在这些状态切换期间持久化的数据都会丢失。
• 后台执行是一种特权 — 两个平台都会限制后台工作。应使用平台批准的机制（后台模式、WorkManager、后台抓取、由推送触发的唤醒），而不是与操作系统对抗。
• 进程终止 — 操作系统可以随时终止应用。保存进行中的状态，并在重新启动时从存储中恢复 UI 状态，而不是从内存中恢复。

离线与同步

移动网络并不可靠；离线是首要模式之一：

• 离线优先存储 — 断网时，本地持久化存储（Core Data、Room、基于 SQLite 的存储或键值存储）是事实来源；网络是同步渠道，而非依赖项。
• 同步语义 — 定义冲突解决策略（最后写入者胜出、按字段合并或显式冲突 UI）、幂等写入以及带退避的重试。绝不要用过期的本地数据盲目覆盖更新的远程数据。
• 将变更加入队列 — 离线时的写入必须排入队列，并在网络恢复时按顺序重放，同时向用户清晰展示同步状态。

移动端特有测试

除单元测试外，移动端代码还需要考虑平台特性的测试：

• 单元测试和 Widget/组件测试 — 无需设备即可测试框架层逻辑、reducer 和状态（XCTest、JUnit、Flutter widget 测试、Jest）。
• UI/插桩测试 — 在设备或模拟器上驱动真实 UI（XCUITest、Espresso/Compose UI 测试、Flutter integration_test、Detox）。
• 设备云覆盖 — 在设备云上跨设备矩阵运行 UI 测试套件；在一台设备上通过的测试并不能保证在其他设备上也通过。
• 性能和电池 — 在设备上测量启动时间、帧率、内存和网络，而不只是验证功能。

核心原则

根据约束选择框架，而不是追逐热度——原生 iOS 和 Android 提供最深入的平台集成；Flutter 和 React Native 则支持跨平台共享代码。正确的选择取决于团队技能、应用所需的设备 API，以及可接受的单个平台工作量。根据应用的实际需求做出选择。

操作系统生命周期也是契约的一部分——移动应用随时可能被挂起、终止或置于后台。任何假设应用始终运行且保持在线的功能都会出问题。从首次提交开始，就要针对进程终止和断开连接进行设计。

签名和构建属于发布工程，而不是 CI 的点缀——无法以可复现方式构建和签名的应用，就无法发布、修补或审计。妥善保密、固定并脚本化签名资产，并将发布流水线视为生产基础设施。

测试你要交付的构建产物——用户和审核人员看到的是签名后的发布构建，而不是调试构建。在提交到 TestFlight、Play 或 App Review 团队之前，先在真实设备上进行冒烟测试。

商店要求不断变化——隐私声明、目标 API 级别和提交格式每年都会变化。临近提交时，应对照商店当前文档核实要求，而不要依赖记忆中的规则。

相关技能

• frontend-engineering — Web 前端方法论；这是本技能所映照的同系列技能先例，也是基于浏览器的 UI 工作的路由目标。
• backend-engineering — 移动应用所使用的 API 和服务；这是服务器端工作的路由目标。
• release-engineering — 发布编排、版本管理和推出方法论；商店发布是这套规范的一种应用。
• qa-methodology — 测试策略和质量门槛；这是产品级测试规划的路由目标。
• platform-engineering — 用于大规模交付移动构建的 CI/CD 流水线和构建基础设施。