能力
移动应用是一个长期存在的客户端，团队无法随时重新部署它。它运行在时断时续的网络上，会被操作系统不加通知地终止，旧版本还会在用户设备上停留数月。我们围绕这些事实来设计应用本身、它的 API 以及发布流水线。
移动端工程与 Web 工程有三点结构性差异。网络时断时续，因此应用在没有网络时也必须可用，并在网络恢复后与服务端重新协调一致。进程生命周期由操作系统掌控，系统会为了保护内存和电量而挂起或终止应用。发布要经过应用商店审核，之后还取决于用户是否更新，因此总有多个版本同时在用，缺陷也无法靠一次重新部署撤回。
这些约束塑造的是整个系统，而不只是客户端。API 必须与数月前发布的版本保持兼容，响应数据必须适合按流量计费的连接，认证机制必须能应对应用在后台期间令牌过期的情况。在设备上，凭证应当放在硬件支持的存储中，本地数据和任何数据库一样需要 schema 与迁移，启动时间、帧率、内存和能耗都是需要度量的属性。
我们在 iOS 上使用 Swift 与 SwiftUI，在 Android 上使用 Kotlin 与 Jetpack Compose；当共享代码库是更划算的取舍时，使用 Flutter 或 React Native。具体如何选择，依据的是产品需求和团队结构；后端契约、离线模型和发布流程则与最初的几个页面同步设计。
我们构建什么
原生开发可以第一时间用上所有平台 API，拥有最好的启动和渲染表现以及符合平台规范的行为，代价是维护两套代码库。Flutter 通过自带的引擎渲染自己的 widget，跨平台视觉一致性很高；React Native 由 JavaScript 或 TypeScript 驱动原生视图，可与 Web 团队共享技能。两者在某些集成上仍然需要编写原生代码。
在离线优先的设计中，界面读写的是本地数据库，由同步引擎在后台与服务端协调一致。本地写入以带幂等键的变更操作形式排队，在网络恢复后按顺序重放。冲突处理规则按实体分别定义，因为适合一条笔记的规则并不适合一笔支付。
机密数据存放在 iOS Keychain 和 Android Keystore 中，在设备支持的情况下，密钥生成于 Secure Enclave 或由 StrongBox 支持的安全元件内。生物识别认证把守的是硬件所持密钥的使用权：匹配成功后放行的是一次密码学操作，而不是返回一个被篡改的应用可以绕过的布尔值。登录通过系统浏览器，采用带 PKCE 的 OAuth 2.0 授权码流程。
BFF 按页面来组织响应，减少高延迟网络上的往返次数。经由 APNs 和 FCM 的推送通知只是尽力而为的投递，因此只把它当作拉取状态的信号，绝不让它承载状态本身。Universal Links 和 Android App Links 通过托管在已验证域名上的文件，把 URL 与应用绑定，从而防止其他应用冒领这些链接。
性能工作针对冷启动、帧节奏、内存和能耗。在 60 Hz 下一帧必须在约 16.7 毫秒内生成，在 120 Hz 下则是 8.3 毫秒，因此耗时工作不放在主线程上，列表采用虚拟化。崩溃和卡顿报告借助上传的 dSYM 与 R8 mapping 文件完成符号化，并按发布版本以无崩溃会话率进行跟踪。
移动端流水线在干净的机器上以可复现的方式完成构建、签名、测试和分发，签名身份保存在密钥存储中，绝不放在某台笔记本上。构建产物依次经过内部测试、TestFlight 和 Play 测试轨道，之后才在 App Store 上分阶段发布，或在 Google Play 上分阶段放量。当崩溃率或 ANR 率出现回归时，放量会被自动或手动叫停。
移动客户端经由边缘层到达后端：先是 CDN 和 Web 应用防火墙，然后是 API 网关，由它终结 TLS、校验令牌、按设备和用户限流并路由请求。在网关之后，BFF 聚合对运行在 Kubernetes 或 serverless 平台上的各领域服务的调用，返回一个为页面量身定制的响应。这样，零碎的编排调用留在数据中心内部，那里一次调用只花一毫秒；而不是发生在移动网络上，那里一次调用要花上几百毫秒。
身份通过 OpenID Connect 流转。应用打开系统浏览器，完成带 PKCE 的授权码流程，拿到一个短有效期的访问令牌和一个会轮换的刷新令牌，并保存在 Keychain 或 Keystore 中。网关验证令牌签名，把经过验证的声明传给下游；各服务依据这些声明对每个请求进行授权。还可以加入来自 App Attest 或 Play Integrity 的证明，作为调用方是未经修改的正版构建的一个信号；它对高风险操作很有用，但永远不能替代服务端授权。
源自服务端的状态变化通过三条途径到达设备。经由 APNs 和 FCM 的推送通知唤醒应用或提示用户，并触发一次拉取。应用在前台时，由 WebSocket 或 Server-Sent Events 连接承载实时更新，进入后台后则关闭连接，以遵守操作系统的限制。启动和恢复时的增量同步补上所有缺口，因此正确性从不依赖某条推送是否送达。在服务端，这些途径由驱动其他消费者的同一条事件流供给，再由通知服务把事件扇出到各个设备令牌。
架构
移动应用
边缘
BFF / 移动端 API
尽量做到每个界面一次往返
服务
数据与通知
可观测性
离线支持是一个渐进的谱系。读缓存在没有连接时展示最后一次已知的数据，成本很低。写入排队让用户可以离线操作，需要有序的发件箱、幂等的服务端端点和可见的待处理状态。完整的离线优先，即以本地数据库作为界面的事实来源并进行双向同步，能力最强也最复杂，应当在用户会长时间处于无信号环境下工作时才选择，例如现场服务、物流和巡检。
当同一条记录在两台设备上，或者在设备与服务端上，于两次同步之间各自发生变化时，冲突就会出现。按服务端时间戳的最后写入胜出很简单，但会悄无声息地丢弃其中一次编辑，这对偏好设置可以接受，对共享文档则不行。字段级合并可以保留互不重叠的编辑。CRDT 能让协作文本和列表自动收敛，代价是元数据膨胀和更难处理的数据模型。对于余额、库存和预订，服务端会依据当前状态校验每一个排队的操作，并可能拒绝它，应用必须把这次拒绝清楚地呈现给用户。
同步还需要处理几类情况：通过墓碑（tombstone）处理删除，对尚未上传的数据做 schema 迁移，以及一批操作进行到一半时的部分失败。设备时钟不可靠，因此排序使用服务端分配的版本号或逻辑时钟，绝不使用本地的墙上时钟时间。
这个决策取决于产品中有多大比例是平台特有的。以表单、列表和 API 驱动内容为主的应用很适合共享代码，一套 Flutter 或 React Native 代码库可以消除大部分重复的功能开发，并让两个平台保持同步。而围绕相机管线、蓝牙外设、后台定位、端侧机器学习、小组件、手表配套应用或最新操作系统特性构建的应用，大量精力都花在原生边界上，跨平台层在那里只增加了一层间接性，并没有省下工作量。
团队结构与技术同样重要。熟悉 TypeScript 和 React 的 Web 团队可以很快在 React Native 上产出，而 Flutter 需要改用 Dart，换来的是对渲染更精细的控制。原生团队掌握完整的工具链，新的操作系统版本发布时，不必受制于某个框架的发布节奏。Kotlin Multiplatform 是一条中间路线：共享网络、持久化和领域逻辑，界面则完全原生。
无论怎么选，都需要一定的原生开发能力。签名、推送配置、商店提交、深度链接关联、性能剖析以及许多第三方 SDK 都是平台特有的，缺乏这些知识的跨平台团队恰恰会卡在这些环节上。
我们如何构建
我们把客户端、API 和发布流程放在一起设计，因为只要旧版本还装在用户设备上，其中任何一处的决策都会一直制约另外两处。
我们确定目标操作系统版本、设备等级、离线需求、监管与应用商店政策方面的约束，以及产品所依赖的设备能力。原生还是跨平台，由这些因素决定。
与后端团队共同明确端点、分页、错误语义、幂等以及对旧版本的兼容策略。如果需要离线写入，则在编写任何存储代码之前，先定下每个实体的冲突规则。
搭建 MVVM 或 MVI 这类单向数据流、依赖注入、模块化的工程结构和本地持久化层，同时建立带签名的 CI 构建，从开发的第一周起就能把构建交到测试人员手中。
认证流程、安全存储、生物识别把关、传输安全和设备证明都作为共享基础设施来实现，并在功能开发依赖它们之前，对照 OWASP MASVS 完成评审。
单元测试和快照测试在每次提交时运行，UI 测试在覆盖较旧硬件和操作系统版本的设备矩阵上运行。网络条件模拟用于检验丢包、高延迟和请求中途断连的情况，进程终止测试用于验证状态恢复。
构建经由内部和 beta 轨道进入分阶段的正式放量，在扩大放量范围之前，把无崩溃率、ANR 率、启动时间和关键漏斗事件与上一版本逐项对比。
取舍
在确定架构之前，我们会与您的团队逐一厘清的问题。
生产就绪
令牌和密钥保存在有硬件支持的 Keychain 与 Keystore 中，访问受生物识别或设备凭证控制；任何敏感内容都不会写入日志、明文偏好设置、备份或任务切换器的截图。传输使用 TLS，并在威胁模型有此要求时启用证书锁定；发布构建经过混淆，并检查是否残留调试标志。客户端被视为不可信：每一条重要的规则都在服务端再执行一遍。
移动端的规模，意味着设备数量不断增长且分布在众多版本上，因此负载由后端来承担：CDN、网关上按设备的限流，以及分页、可缓存的响应。推送扇出由基于队列的通知服务处理，它批量发送并清理失效的令牌。代码库则通过接口明确的功能模块来扩展，在团队扩大时把构建时间和合并冲突控制在合理范围内。
崩溃、卡顿和 ANR 报告经过符号化并按发布版本分组，附带操作轨迹（breadcrumb）和设备上下文。性能监控从真实设备上记录冷启动、慢帧与冻结帧以及网络请求延迟，trace 标识符则把一次客户端请求与它在后端的 span 关联起来。分析事件遵循带版本的 schema，并遵守用户同意和平台的跟踪规则。
流水线从打了标签的提交生成带签名、带版本号的构建，上传符号文件，并自动提交到 TestFlight 和 Play 测试轨道。正式环境使用 App Store 的分阶段发布和 Google Play 的分阶段放量，两者都可以暂停。审核时间没有保证，因此发布日程要为它留出余量，紧急止损则依靠远程开关。
应用通过 OpenID Connect 与身份提供方集成，支付、地图、消息和分析类 SDK 则封装在内部接口之后，每一个都可以被替换，或在测试中用桩替代。每个第三方 SDK 都要评估其体积、启动开销、权限和数据收集情况，因为它的行为必须在 App Store 隐私标签和 Play 数据安全表单中申报。
根据工作负载和您现有的技术资产来选择。
从零到生产
想法
探索
系统架构
UX / 产品设计
应用工程
AI / 数据层
云基础设施
安全
质量保证与性能
部署
可观测性
持续演进
常见问题
这取决于产品中有多少是平台特有的，也取决于你现有的团队。内容类和流程类应用很适合用 Flutter 或 React Native 共享代码，而建立在相机、蓝牙、后台处理或新操作系统特性之上的产品，通常用 Swift 和 Kotlin 更合适。针对风险最高的那项设备集成做一次简短的技术验证（spike），比一张对比表更能可靠地回答这个问题。
应用在 iOS 上向 APNs、在 Android 上向 FCM 注册，获得一个设备令牌，并把它发送给你的后端。后端请求平台服务向该令牌投递消息，平台在设备可达时完成投递。投递只是尽力而为，可能被延迟、合并或丢弃，令牌也会变化，因此后端必须处理失效的令牌，应用也必须从 API 拉取权威状态。
审核时间并不固定，两家商店都不作保证，因此安排发布时不应假设一个固定的周转时间。常见的被拒原因包括隐私声明不完整、缺少账号删除功能、申请权限却没有说明明确用途、审核人员无法正常登录，以及支付流程与应用内购买规则相冲突。每次提交时附上测试账号和审核备注，可以避免其中的很多问题。
凭证和密钥放在带硬件级保护的 Keychain 或 Keystore 中，体量较大的敏感数据集则用保存在其中的密钥加密。生物识别校验与一个密码学密钥绑定，因此无法通过修改一处条件判断来绕过。敏感页面被排除在截屏和备份之外，服务端也从不依赖客户端已经执行过某条规则。
可以。领域服务和数据是共享的，每种客户端各有一层轻量的 BFF 来做适配：移动端的 BFF 倾向于更少、更小、能容忍版本差异的响应，Web 端的 BFF 则可以随 Web 部署同步变更。这样业务规则只保留在一处，每种客户端也可以按各自的发布节奏演进。
