我是AI时代的无业游民，我游荡在现实与意念之间

---

从 React Native 回退到 Swift 与 Kotlin：一次关于“跨平台税”的深度复盘

背景与痛点

移动端技术选型有一个反复出现的周期：团队为了“一套代码两端运行”拥抱跨平台框架，两三年后又在性能、招聘、原生能力对齐的压力下逐步回退。Shopify 把移动 App 从 React Native 迁回 Swift 与 Kotlin，正是这个周期里最新、也最值得拆解的一个样本。

问题的起点往往不是“React Native 跑不起来”，而是它跑得起来，但每往前一步都要付税。具体表现为三类：

第一，桥接层的隐性成本。RN 的 JS 线程与原生线程之间需要序列化通信。当业务从“展示列表”进化到“购物车实时计算 + 支付 SDK 深度集成 + 离线缓存”时，跨线程调用的频率和复杂度会指数上升。单次调用看起来只多几毫秒，但一次结算流程可能触发上百次桥接，累积延迟在低端安卓机上会被放大到肉眼可见。

第二，原生能力对齐的滞后。iOS 与 Android 每年都在更新系统级能力（新的支付 API、后台任务策略、隐私清单要求）。RN 生态的封装往往滞后于官方 SDK，团队要么等社区，要么自己写原生模块——而一旦开始写原生模块，跨平台带来的“一套代码”优势就开始瓦解。

第三，人才与调试的错配。RN 开发者需要同时理解 JS 运行时、原生渲染和两端差异。招聘时你会发现，真正能定位“JS 层看起来正常、原生层已经内存泄漏”的人非常稀缺。这不是 RN 的错，而是跨平台栈天然要求更宽的知识面。

不解决这些问题的代价是：技术债以“性能优化”的名义不断累积，而每次优化都在削弱跨平台的核心价值。

方案设计

Shopify 的选择是分阶段回退到原生，而不是一次性重写。这个决策本身比“用 Swift 还是 Kotlin”更重要。

备选方案对比：

方案	优势	代价	适用边界
继续 RN + 更多原生模块	改动小，复用现有团队	桥接成本不降反升，维护两套心智模型	业务稳定、原生需求少的工具类 App
Flutter 重写	渲染性能好，UI 一致性强	需要重学 Dart，原生集成仍需平台通道	以自绘 UI 为主、对原生控件依赖低的产品
完全原生（Swift + Kotlin）	性能上限最高，原生能力零延迟	两套代码，人力成本翻倍	核心业务链路复杂、对体验敏感的大型 App
混合：核心原生 + 边缘 RN	兼顾体验与迭代速度	架构复杂，边界难划分	有明确“核心/边缘”划分的成熟团队

Shopify 选了最后一种的变体：把高频、重交互、强依赖原生的路径（结算、支付、购物车）迁到原生，把内容展示类、变化快的页面暂时保留或逐步替换。这个取舍的关键判断是：跨平台框架适合“逻辑简单、UI 变化快、原生依赖弱”的场景；一旦进入交易链路，原生收益远大于成本。

明确放弃的替代方案是“一次性全量重写”。原因很现实：全量重写会冻结业务迭代，而电商的促销节奏不允许。分阶段迁移允许团队在每次发版中验证一个模块，回滚成本可控。

核心实现

1. 模块边界划分：按“调用密度”而非“页面”切分

很多团队按页面迁移，结果发现一个页面里既有原生组件又有 RN 组件，桥接调用反而更频繁。更稳的做法是按调用密度切分：统计每个功能模块与原生层的交互次数，优先迁移密度最高的模块。

// 以结算模块为例，原生侧定义清晰的边界协议
protocol CheckoutBridge {
    func calculateTotal(items: [CartItem]) -> Decimal
    func applyDiscount(code: String) -> Result<Discount, CheckoutError>
    func submitPayment(method: PaymentMethod) async throws -> Receipt
}

这个协议的价值在于：它把“原生能力”和“业务逻辑”解耦。即使未来再引入其他跨平台方案，边界依然清晰。

2. 状态同步：从“双向绑定”改为“单向数据流”

RN 时代常见的写法是 JS 和原生各自维护一份状态，通过事件同步。这种写法在并发场景下极易出现“两边不一致”。迁移到原生后，Shopify 采用单一数据源 + 不可变状态：

// Android 侧用 StateFlow 驱动 UI，避免多源状态
data class CartState(
    val items: List<CartItem>,
    val total: BigDecimal,
    val status: CartStatus
)

class CartViewModel(private val repo: CartRepository) : ViewModel() {
    private val _state = MutableStateFlow(CartState.empty())
    val state: StateFlow<CartState> = _state.asStateFlow()

    fun applyDiscount(code: String) {
        viewModelScope.launch {
            val result = repo.applyDiscount(code)
            _state.update { it.copy(total = result.newTotal) }
        }
    }
}

为什么不选另一种写法：如果用 LiveData 或 ObservableField 双向绑定，UI 层可能直接修改状态，导致“谁改了数据”难以追踪。单向数据流牺牲了一点便利性，换来的是可测试性和可追溯性——这在支付链路里是刚需。

3. 渐进式迁移：用 Feature Flag 控制流量

迁移不是“切代码”，而是“切流量”。Shopify 用 Feature Flag 让原生模块和 RN 模块并行运行，按用户维度灰度：

// RN 侧保留兜底，通过配置决定走原生还是 RN
const useNativeCheckout = await flags.get('native_checkout_enabled');
if (useNativeCheckout) {
  return NativeCheckout.start(cart);
}
return <LegacyCheckout cart={cart} />;

看起来能跑、线上会炸的点：如果两边状态不同步，用户可能在 RN 页面加购、跳到原生结算时发现购物车为空。解决办法是迁移期间以原生状态为准，RN 只读不写，直到该模块完全切换。

效果验证

验证迁移是否有效，不能只看“页面变快了”。Shopify 关注的指标是交易链路的端到端延迟和崩溃率：

• 启动到可结算时间：原生模块减少了桥接初始化，冷启动路径更短。可复现步骤：在低端安卓机（如 4GB 内存）上冷启动，记录从点击购物车图标到结算页可交互的时间。
• 支付成功率：原生 SDK 集成后，支付回调的异常处理更可控，失败重试逻辑不再依赖 JS 层。
• 崩溃归因：RN 崩溃往往堆栈跨层，定位困难；原生崩溃堆栈直接指向具体模块，平均修复时间下降。

如何证明它有效：在灰度期间，对比“原生结算组”和“RN 结算组”的支付完成率与平均耗时。如果原生组在统计上显著更优（而非“感觉更快”），才继续扩大流量。

边界与演进

局限：原生方案的人力成本是真实的。两套代码意味着两套测试、两套发布流程、两套招聘需求。如果团队规模小于某个阈值，跨平台框架的“一套代码”优势仍然成立。

不适用场景：内容型 App、内部工具、生命周期短的活动页，继续用 RN 或 Flutter 更划算。跨平台不是原罪，错配才是。

下一步优化：Shopify 的路径暗示了一个趋势——用原生做“重”的部分，用跨平台做“轻”的部分。未来可能演进为：核心交易链路原生，营销活动页用服务端驱动 UI（如 React Server Components 思路），进一步减少客户端发版依赖。

对中级开发者的启示是：不要问“哪个框架更好”，要问“这个模块的调用密度和原生依赖有多高”。把这个问题回答清楚，选型自然就清晰了。