迁移背景:AI 改变技术权衡
Shop App 作为全球增长最快的移动应用之一,自 2020 年推出以来一直采用 React Native 框架,服务于数亿顾客和数百万商家。这一早期决策曾为应用带来显著优势,但随着 编程代理(Coding Agents)能力的提升,维护共享代码库的成本效益比发生了根本性变化。尽管为 iOS 和 Android 分别构建原生应用仍存在成本,但 AI 代理的出现使得重新评估这一决策变得合理。Shop App 决定转向完全原生开发,使用 Swift(iOS)和 Kotlin(Android),以利用 AI 辅助开发的潜力。
"That decision has served Shop app well, but our increasing ability to develop with coding agents has allowed Shop to go fully native."
在做出全面迁移决定前,Shop App 正面临下一个重大 React Native 投资:采用新架构(New Architecture)。这一工作涉及重新审视原生模块集成、渲染机制以及共享代码与平台特定代码之间的边界。在承诺这一投资之前,团队测试了编程代理是否能够帮助直接在 SwiftUI 和 Jetpack Compose中构建应用,同时保持跨平台的产品行为一致性。这一测试成为迁移决策的关键转折点。
概念验证:一周内的可行性探索
为了评估全量迁移的可行性,团队进行了一项小规模的概念验证(Proof of Concept)。一名工程师利用编程代理在一周内尝试将现有的 React Native 应用尽可能多地迁移至基于 SwiftUI 的原生 iOS 应用中。结果令人信服:以现有的 React Native 应用为参考,团队能够快速重建屏幕、交互和应用流程。虽然一周后的结果尚未达到生产就绪状态,但它证明了逐功能迁移的可行性,并增强了团队推进全量迁移的信心。
"The result wasn’t production-ready after just one week, but it demonstrated that a close, feature-for-feature migration was achievable."
编程代理在拥有现有实现作为参考时表现尤为出色。它们成功完成了定义功能的移植、屏幕脚手架搭建、数据连接、动画实现以及基于视觉反馈的布局优化。这一阶段的关键在于验证 AI 代理能否准确理解并转换复杂的 UI/UX 逻辑,而不仅仅是生成基础代码。这次验证为后续大规模迁移奠定了技术信心。
实施过程:核心构建与功能对齐
全量迁移由一个六人的核心团队启动,负责搭建原生基础架构和应用的主要用户旅程。在迁移中途,功能团队加入以验证各自领域并覆盖边缘情况。首要任务是保留已移植功能的原始行为以及下游系统所依赖的分析事件。迁移过程需确保对现有用户无感:保持登录状态、持续接收推送通知,并确保交互事件能向下游系统(如推荐引擎)发送预期的上下文信息。
"Our priority was preserving both the behavior of the features we ported over and the analytics events that downstream systems depended on."
在保持连续性的同时,团队利用迁移机会简化应用架构。他们刻意废弃了一些屏幕并精简了其他部分,旨在通过原生重构提升代码质量和可维护性。这一阶段不仅涉及功能移植,更是一次应用架构的重塑过程,确保原生版本在行为逻辑上与原 React Native 版本完全一致。
性能基准测试:关键指标对比分析
迁移完成后,团队对原生应用与 React Native 前身进行了全面性能对比。以下是基于原文明确给出的数据进行的基准测试汇总:
| 指标 | Android 原生 vs React Native | iOS 原生 vs React Native |
|---|---|---|
| 启动时间 | 原生应用冷启动速度更快(从点击图标到首页内容可见) | 原生应用冷启动速度更快 |
| 会话稳定性 | 提升至 99.95%+,崩溃率降低约 10 倍 | 提升至 99.95%+,崩溃率降低约 10 倍 |
| 应用体积 | 构建版本缩小了 109 MB | 构建版本增加了约 1 MB |
| 构建时间 | 发布版构建时间减少约 75% | 发布版构建时间与之前基本持平 |
| 运行时性能 | Android 原生应用在 Pixel 设备上滚动 Feed 时达到 120 FPS(未经过多优化) | 未提供具体帧数数据,但强调渲染性能提升 |
"Our historical stability was at 99.5%+ but with the release of the native version, our session stability has climbed to 99.95%+ — a 10x reduction in sessions that crash."
数据表明,Android 平台在应用体积和构建效率上获益显著,而 iOS 平台则在稳定性提升和应用包大小控制上表现均衡。Android 原生应用在未进行深度优化的情况下即达到 120 FPS,凸显了原生渲染在流畅度上的先天优势。
AI 开发工作流:代理协作与调试工具
Agentic(基于智能体)的开发工作流与传统模式截然不同。团队不再依赖单一开发者修改、运行和迭代,而是并行运行多个代理会话在不同的工作树(worktrees)中。为此,团队构建了可复用的迁移工作流程作为 Pi 编程代理的扩展。专门的子代理负责检查 React Native 源代码、记录其行为、准备平台计划、实现功能并审查一致性。
"Agents were particularly effective when they had an existing implementation to work from."
为确保代码质量,团队引入了严格的审查机制。源审查涵盖 UI、状态管理、导航、分析、无障碍性和数据行为。计划的接受与内容哈希值绑定:任何计划内容的变更都会使之前的批准失效,确保审批始终关联到实际审查过的实现方案。此外,团队开发了名为 Tardis 的调试工具,为代理提供对原生应用事件、日志和状态的结构性访问权限,并允许向应用发送命令。这使得代理能够通过结构化反馈调查问题、检查导航和分析事件,从而减少手动 UI 检查的需求。
一致性验证与原生专家的角色
为了支持功能对齐审查,Tardis 工具增加了截图和事件窗口捕获功能。在命名检查点处,系统同时记录 React Native 和原生应用的状态。通过启用原始事件捕获,代理可以比较事件名称、数量和有效载荷字段。对比指令考虑了运行中自然不同的值(如时间戳和页面 UUID),同时检查事件与其页面或实体上下文之间的关系。这为工程师提供了一种可重复的方法来调查流程中的差异。
"Generated code could satisfy feature requirements while still introducing duplication, architectural drift, or performance problems."
尽管 AI 代理提高了效率,但原生专业知识仍然至关重要。生成的代码可能满足功能需求,但也可能引入重复、架构漂移或性能问题。团队通过仓库指南、Linting 检查、测试、静态分析、性能检查和代码审查来弥补这一差距。学习曲线比预期更平缓,因为声明式 UI 概念(如 SwiftUI 和 Jetpack Compose)与 React Native 工程师熟悉的模式相似,平台知识则指导了架构决策和审查过程。
结论
Shop App 从 React Native 迁移至原生开发的成功,核心在于编程代理技术改变了维护共享代码库的成本效益权衡。通过概念验证证明可行性后,团队利用 AI 代理加速了迁移过程,同时保留了关键的功能行为和分析数据。性能数据显示,原生应用在稳定性(崩溃率降低 10 倍)、Android 构建效率(提升 75%)和运行时性能方面显著优于 React Native。尽管 AI 代理极大提升了开发效率,但原生专家在架构审查、性能优化和质量控制中仍扮演不可或缺的角色。未来,团队将继续保持 Android 和 iOS 的功能对齐,并将此次迁移视为性能提升的新基线。