去年 Shopify 官宣把移动端主 App 从 React Native 逐步撤回 Swift/Kotlin 的时候圈子里讨论声很大。有人把这解读成“跨端已死”也有人觉得这是“大厂终于认清了现实”。但真正从头到尾跟过这类迁移的人大概率不会说得这么简单——因为从 RN 回到原生这件事本质上不是把页面换一种写法重写一遍而是把一个跑在 JavaScript 引擎上的复杂系统平稳过渡到两套完全不同的原生技术栈上。这个过程中涉及到的包体积控制、启动链路优化、双端能力对齐、基础设施重建、几百人团队的节奏协调每一环都足以把一个项目拖垮。我今天想借这个标题聊点实际的为什么 Shopify 当初会选 RN后来为什么扛不住真正回归原生时又是什么地方最容易让人误判。尤其是“有手就行”这个印象和真实情况差得不是一星半点。1. Shopify 当年为什么押注 React Native很多人在复盘的时候会忽略一个基本问题一家公司做技术选型很少会只看“技术本身好不好”更多是看“在当时的规模、团队和时间窗口下哪个方案最划算”。1.1 移动端早期的真实局面Shopify 的核心业务是电商 SaaS。它的商家后台、数据分析、订单管理、店铺装修这些功能在移动端上的形态非常重而且迭代频率极高。早期阶段Shopify 同时维护着 iOS 和 Android 两套原生应用每上一个新功能都要写两遍代码业务逻辑还经常因为两边写法不一致出现偏差。这种情况在团队很小的时候还能忍受但电商类 App 的功能链路很长——从登录、商品列表、购物车、结算到售后任何一个模块的改动都要双端同步时间成本直接翻倍。正是在这个节点上React Native 进入了 Shopify 的视野。1.2 React Native 当时解决的核心痛点RN 最明显的优势不是“性能比原生好”而是让业务团队可以共用一套 TypeScript 代码把 UI 组件和业务逻辑同时跑在 iOS 和 Android 上。对 Shopify 这种业务逻辑复杂、页面数量巨大的电商平台来说这意味着人力几乎减半而且新功能上线的时间窗口能压缩不少。电商场景还有一个特殊需求运营活动经常要快速上线和调整。虽然 App 原生也能通过热更新机制做远程配置但 RN 的 JS Bundle 机制让“不发版就能改 UI 和业务”这件事在工程上变得非常顺滑。这一点对促销活动频繁的电商平台是很加分的。1.3 早期确实跑通了不少场景根据 Shopify 自己后来公开的复盘内容来看RN 在其内部的早期应用并不是失败的。大量普通页面、表单流程、营销模块跑在 RN 上开发效率有实打实的提升。尤其是 JavaScript 生态里的状态管理、UI 组件库以及和 Web 团队共享代码的可能性让很多业务线尝到了甜头。但也正因为跑通的业务越来越多RN 在 Shopify 内部的使用范围越滚越大。从几个核心页面扩展到购物、订单、物流等关键路径再到整个 App 的第一启动屏都开始由 RN 承载。到这一步很多性能问题和工程治理问题就开始集中爆发了。2. 从“一次编写到处运行”到“到处调试”RN 在超大规模 App 扛不住的真实原因很多人对 RN 的印象还停留在“小应用跑起来挺流畅”的阶段。但 Shopify 遇到的问题远比这个复杂。当一个 App 的月活达到千万级、业务模块多达几十个、RN 页面和原生页面交错嵌套时RN 的很多短板会被无限放大。2.1 启动白屏问题链路比你想的长得多先说热词里反复出现的“react native 启动白屏”。这个问题在小型 Demo 里几乎感觉不到但在真实的大型 App 里几乎是必然出现。RN 启动链路大致是App 冷启动 → 原生容器创建 → 加载 JS Bundle → 初始化 JavaScript 引擎 → 执行业务代码 → 渲染首帧。在旧架构下这一步还涉及到 JavaScriptCore 的初始化、Bridge 的建立、Native Module 的注册任何一个环节卡住用户看到的就是白屏。我实际在低端 Android 设备上见过这个白屏能持续两三秒尤其是在首启还要同步拉远程 Bundle 或者做 Bundle 校验的时候。Shopify 的 App 里 RN 承载了启动主流程一旦 Bundle 解析慢或者引擎初始化慢用户体验掉得特别快。这也是后来他们把冷启动路径逐步原生化的直接原因之一。2.2 桥接层的心智负担高频通信是性能黑洞RN 的旧架构有一个绕不开的设计JavaScript 线程和原生线程之间所有的通信都要通过 Bridge 进行序列化和反序列化。模块之间数据量小的时候还好说但电商 App 恰恰是高交互场景——滚动列表的时候要频繁回调位置信息、图片懒加载要通知原生线程、网络请求结果要回传 JS 层。一旦这些高频调用叠加起来Bridge 就会成为瓶颈。你会在 Profile 里看到 JS 线程和 Native 线程之间大量的消息排队帧率掉到肉眼可见的程度。Shopify 的页面里大量使用长列表、图片墙这种重交互组件这个问题很难靠调优彻底解决。2.3 双端一致性陷阱你以为写一遍就够了吗RN 的口号是 Learn once, write anywhere但现实是 iOS 和 Android 上运行 JavaScript 引擎的表现并不完全一致。早期 iOS 用的是 JavaScriptCoreAndroid 在很长一段时间里也内置了 JavaScriptCore但两边的内存管理、垃圾回收时机、线程模型都不一样。更麻烦的是RN 的组件在 iOS 和 Android 上最终映射到的原生视图并不相同。同一个 padding、同一个 fontSize在两个端渲染出来可能差几个像素。遇到这类问题你还是得打开原生代码去调跨端的效率红利就打了折扣。Shopify 这种对 UI 还原度要求很高的商业 App在这上面投入了大量排查时间。2.4 原生能力深度集成时的断裂感电商 App 离不开相机扫码、Face ID/Touch ID、推送、地图、蓝牙、支付等原生能力。RN 虽然提供了丰富的第三方库但一旦系统升级、权限模型改变、或者某个交互需要深入系统底层最终还是得回到原生侧去写。问题在于当页面逻辑在 JS 层、底层能力在原生层、中间通信靠 Bridge 时一旦出现问题排查链路非常痛苦。你要分别看 JS 调用栈、Bridge 消息日志和原生崩溃日志三个层面的信息往往对不上。这种断裂感在单一技术栈的 App 里是不存在的。2.5 不是 RN 不行是你的规模到了临界点说到底我并不是想输出“RN 是坑货”这种片面结论。RN 在中小型应用里依然是一个效率极高的选择。但 Shopify 的问题在于它把 RN 用在了整个 App 的最核心路径、最复杂的交互场景同时还要面对成百上千人的协作规模。当业务多到一定程度跨端框架节省的那部分人力会被双端兼容问题、性能调优问题、 Bridge 通信问题、滚动升级问题一点点吞掉。这是一个边际成本递增的过程。很多大厂从 RN 撤退不是因为他们不会用而是因为他们规模太大跨端带来的复杂度已经盖过了收益。3. 回迁不是重写而是“器官移植”Swift/Kotlin 双线改造的真实难度很多人听到“从 RN 回到原生”的第一反应是那就把页面用 Swift 和 Kotlin 重写一遍嘛。但如果你在一个正在运行的 App 上做过大规模重构就会知道这事完全不是这样。3.1 你接手的不是一个空项目而是一个不断生长的系统RN 版本不能直接停掉——几百万用户还在用。你要做的是在保持线上版本正常运行、新功能持续迭代的同时把页面一点点替换成原生实现。这个过程没有“按个按钮整体切换”这种魔法只有一段很长的灰度迁移期。在实际操作中这种迁移就像给一架正在飞行的飞机换引擎。你不能让飞机停下来只能拆下一个旧的装上一个新的还得保证乘客全程无感。Shopify 的做法是彻底重写而非渐进式混合吗不是。他们在很长一段时间里都是让 RN 页面和原生页面共享一个 App通过路由层做分发按功能和用户群逐步灰度。真正常见的做法也是类似思路。3.2 双端并行开发设计和审核成本直接翻倍回到原生看起来是“不用写 JS 了”实际上你要同时养两支原生团队。iOS 用 SwiftAndroid 用 Kotlin两边除了业务逻辑一致其他全是独立实现。这就意味着每个 API 接口文档要对齐请求参数、错误码、响应结构要双端一致每个页面设计稿要有明确的 iOS 规范和 Android 规范导航交互、弹窗样式都不能混用每个埋点事件要双端核对否则数据一上来就是脏的每次版本发布要协调 iOS 和 Android 的发布时间窗口。这些工作在 RN 时代大部分是天然统一的回到原生之后全都要靠流程和代码规范去约束。我在实际项目中经历过类似的双端治理坦白讲这是最容易被低估的部分。3.3 网络层迁移一个 URLRequest 背后藏着一堆事热词里出现了“swift urlrequest get”可见不少人刚开始学 Swift 时都会从网络请求入手。在 Demo 里一个 URLRequest 也就是几行代码的事。但在 Shopiy 这种规模的 App 里网络层迁移是整个改造里最核心也是最枯燥的工程之一。生产环境下的网络请求要考虑什么请求头统一签名、token 自动刷新、缓存策略、超时重试、弱网降级、接口埋点、错误上报、证书校验、数据解析容错。RN 时代这些逻辑大多集中在 JavaScript 的网络库和拦截器里。回到原生你需要分别用 Swift 的 URLSession 体系和 Kotlin 的 OkHttp/Retrofit 体系各重新实现一遍还要保证行为和之前线上完全一致。这不是能不能写出来一个 get 请求的问题而是整个网络基础组件怎么设计和验证的问题。3.4 构建配置迁移Kotlin DSL 与 Groovy DSL 的“有手就行”陷阱另外一个很容易被忽视的坑是 Android 构建脚本的迁移。热词里也有“build configuration language kotlin dsl 与 groovy dsl 区别”这条我在实际迁移中深有体会。很多项目早期的 Gradle 构建脚本是用 Groovy DSL 写的。Groovy 语法松散、动态语言特性强、字符串处理方便写起来很随意。而 Kotlin DSL 是类型安全的构建脚本编译期就能发现配置错误IDE 自动补全也更好。听起来是不是“有手就行”换一下语法而已。但真实情况是一个大型 Android 工程里的 Gradle 脚本可能涉及几十个模块的依赖管理、变体配置、混淆规则、资源优化、插件扩展。Groovy 里一行pluginManagement的动态配置迁到 Kotlin DSL 里可能就要显式写类型、写 lambda 规范老项目里很多隐式约定根本没办法自动转换。我亲手做过一次代价不小的 Gradle 迁移。如果项目只有几十个依赖迁移确实低风险工程上可以很顺利地把build.gradle改成build.gradle.kts任务差异不算大很多常见插件也都有现成写法。但 Shopify 这种量级的 Android 工程模块数、插件数、定制 Task 数都远超普通项目而且内部还有自有构建框架和缓存系统牵一发而动全身。迁移后如果遇到某个民间插件的 NSIS 任务异常你连报错在哪个 DefaultTask 里都很难定位。而且构建速度在最开始往往没有提升反而因为 Kotlin DSL 编译额外的类型检查、首次运行要加载更多类构建时间会有一定程度的回退。要配合配置缓存反复微调才能回到原有构建速度甚至更快。如果只是“会写 Kotlin 代码”就上手 KTS大概率会卡在一个个配置文件连环报错里。3.5 不是“重写”是“重建基础设施”现在你应该明白了回迁原生最关键的不是页面重写而是整个 App 的基础设施重建。网络层要重写数据持久化要重写导航容器要重写日志监控要重写Feature Flag 要重写性能监控要重写推送和深链处理要重写。这些基础设施在 RN 时代被封装在跨端层里大家感受不到它们的存在。一旦切回原生你必须用两套语言同时把它们全部接起来才能让业务方在原生页面上继续正常干活。在我看来这部分工作量至少要占整个回迁项目的一半以上。4. 真正难的不是 Swift 或 Kotlin 语法而是你对架构的重新理解等到 Swift 和 Kotlin 的代码都能跑起来了另一个层面的问题才会浮出水面你究竟要构建一个什么样的原生架构4.1 SwiftUI 还是 UIKitCompose 还是 View System很多回迁团队会在这里纠结很久。以 iOS 为例SwiftUI 是当前苹果主推的声明式 UI 框架新项目用 SwiftUI 能省掉很多 UI 代码但它和 UIKit 在复杂的交互嵌套下仍然有兼容问题。Shopify 的 App 里有大量自定义视图、复杂表格、视频交互模块这些都是 SwiftUI 当前还不够顺手的地方。Android 这边也面临同样的问题Compose 的声明式 UI 效率高但在超大列表、复杂自定义绘制、辅助功能兼容上需要补的坑依然不少。别以为“回原生就是用最新的 UI 框架”大多数情况下你要做的是根据业务场景在传统 View 体系和声明式体系之间做混合制定一个完整的分层规范。我自己见过一些团队为了统一认知强行全面转向声明式 UI结果在老旧设备上碰到各种兼容问题最后不得不退回去保留一部分传统视图。这种反复内耗比一开始就老老实实做技术评估要费钱得多。4.2 职责分层不能只满足于“能跑”在 RN 时代页面逻辑、状态管理、数据处理都在 JavaScript 层分层标准相对统一。回到原生后如果没有在架构层面明确 presentation、domain、data 三层很容易变成“原生模板套路由”的混乱状态。我看到很多刚从跨端回迁的项目原生代码里 activity/fragment 里塞满了网络请求和业务判断。两三个月后页面一多、人员一流动这套代码就变成大型泥球。与其说是回到原生不如说是回到了二十年前的 MVC 大泥团。架构落地应该是这样presentation 层只负责渲染和用户交互不直接碰数据源domain 层负责核心业务规则不依赖 UIKit 和 Android frameworkdata 层封装网络、缓存、数据库实现双端各自维护 domain 层但领域模型定义尽量保持一致。这样做之后至少你从 RN 迁移过来的那部分业务逻辑可以更平滑地在双端对齐后续修改也不会因为底层实现跳来跳去而崩溃。4.3 包体积和启动时间这些指标最终会“算总账”回迁原生之后很多团队会发现一个尴尬的事实App 体积比 RN 时代更大了启动时间也只是略有改善并没有想象中那种“秒开”的效果。原因不复杂。RN 时代虽然有一个 JS 引擎和一个大 Bundle但很多原生库并没有被拆掉而回迁原生后你又把这两套原生 UI 框架、网络库、图片库全部塞了进来基础包自然更厚。真正的优化工作量在架构完成之后才开始启动链路裁剪哪些服务可以懒加载哪些组件可以不做冷启动初始化动态化包管理按功能模块拆分动态下发资源去重和裁剪移除 RN Bundle 之后多语言、图片、字体资源全部重理首屏渲染优化提前接入首帧渲染链路避免被周边初始化任务阻塞。这些动作在 RN 时代基本没法做。这是回迁后最值得发力的部分。4.4 团队能力重建才是最大的隐性成本还要提醒一句RN 团队和原生团队对应的技能栈是不同的不只是代码语言不同对性能调优、系统机制、内存管理的理解深度也不同。Shopify 在回迁原生的时候不可能直接让所有前端工程师第二天就用 SwiftUI 写页面。他们需要重建 iOS 和 Android 两个原生技术梯队长期维护双端原生架构。这件事在招聘市场上的成本远高于当初养一个 RN 团队。5. 如果你也在考虑类似的迁移这几条实际建议值得看看很多中小团队看到大厂回迁也动了“要不要也把跨端项目改成原生”的念头。这里我给几条基于实际经验的原则你可以对照自己的场景再判断。5.1 先分清你是“性能瓶颈”还是“团队规模瓶颈”如果你只是列表滚动掉帧、启动有点慢先不要急着迁移。优先做性能剖析定位瓶颈在 Bridge 通信还是在图片加载或者在接口响应。大量 RN 项目的卡顿问题其实是资源加载策略和列表复用配置不当可以通过优化解决没有必要全盘推翻。但如果你面临的问题是团队规模过大、跨端代码治理内耗高、双端兼容问题持续消耗主力人力那么回迁原生才是一个值得考虑的选项。Shopify 是属于明确触碰到了规模边界的大型 App并不是普通中小应用的参考坐标。5.2 回迁之前先把“原生基建”搭起来别先从核心页面下手。先把网络层、数据层、导航容器、埋点体系、日志体系、Feature Flag 用原生语言搭好接着在原生的容器里把线上核心路径复刻一遍再决定哪些页面第一批切换。基建没搭好的时候就分页面去写原生大概率会写出一个又一个信息孤岛。5.3 用灰度迁移代替“大爆炸”重写最理想的迁移状态是用户无感的。具体做法是服务端通过用户特征或随机分组下发新的原生页面监控切换后的崩溃率、卡顿率、页面停留时长和业务转化率发现问题立刻回滚到旧实现保证用户影响最小化等新页面稳定跑过一段时间后再扩大灰度范围。这个思路不仅适合 RN 回原生也适合任何一次大版本重构。5.4 迁移期间新功能不要停摆如果你真的在做一个长周期的回迁项目最容易犯的错是让业务方等你。一家正常运营的电商公司不可能因为你在做技术迁移就停止上新功能。这就要用到一种兼容期的双轨开发模式RN 的技术栈继续维持住线上版本的迭代同时原生团队在内部灰度版本上做替换。Shopify 在迁移期间也是这么处理的。搞不定这种双轨节奏的项目往往会因为业务压力被迫中断迁移计划最终搞成“一半 RN 一半原生”的尴尬状态。6. 关于 Shopify 这次的迁移我的真实体会说了这么多最后还是想分享一些我个人的判断。第一个体会是跨端框架没有绝对的优劣只有适配的规模范围。Shopify 放弃 RN 并不意味着 RN 不能用了反而说明 RN 的能力边界已经被划得很清楚。对绝大多数几十人团队的 App 来说RN 依然是一个效率极高的选择。真正危险的是把小项目里积累的经验直接套用到别人千万级 DAU 的 App 上然后得出“这框架不行”的结论。第二个体会是回迁原生真正的成本不是写 Swift 或 Kotlin而是你同时要重建两条原生技术线的基础设施并且要在业务不停的前提下完成平滑切换。这中间牵涉到的团队组织、工程流程、架构设计、性能监控、灰度发布没有一项是“有手就行”的。第三个体会是跨端与原生从来不是二选一的对立面。即使回迁之后大型 App 里仍然会保留很多跨端解决方案用于承载短平快的运营活动页面——成本低、上线快这件事在商业场景里永远是刚需。我个人一直很佩服能做这种大规模技术迁移的团队因为他们要对抗的不只是技术难点还有漫长的迁移期里来自各方的预期压力。用户不会因为你切了原生就自动变多业务方也不会因为你在做重构就停止提需求。能在这种环境中把项目稳扎稳打地推完靠的是扎实的架构基本功以及极强的项目管理能力。如果你也在经历类似的跨端回迁或者在考虑要不要做这件事我的建议是先别急着写代码把刚才聊的这些问题一项项想清楚尤其是你自己的“规模边界”到底在哪。想清楚了再动手也不迟。
去年 Shopify 官宣把移动端主 App 从 React Native 逐步撤回 Swift/Kotlin 的时候圈子里讨论声很大。有人把这解读成“跨端已死”也有人觉得这是“大厂终于认清了现实”。但真正从头到尾跟过这类迁移的人大概率不会说得这么简单——因为从 RN 回到原生这件事本质上不是把页面换一种写法重写一遍而是把一个跑在 JavaScript 引擎上的复杂系统平稳过渡到两套完全不同的原生技术栈上。这个过程中涉及到的包体积控制、启动链路优化、双端能力对齐、基础设施重建、几百人团队的节奏协调每一环都足以把一个项目拖垮。我今天想借这个标题聊点实际的为什么 Shopify 当初会选 RN后来为什么扛不住真正回归原生时又是什么地方最容易让人误判。尤其是“有手就行”这个印象和真实情况差得不是一星半点。1. Shopify 当年为什么押注 React Native很多人在复盘的时候会忽略一个基本问题一家公司做技术选型很少会只看“技术本身好不好”更多是看“在当时的规模、团队和时间窗口下哪个方案最划算”。1.1 移动端早期的真实局面Shopify 的核心业务是电商 SaaS。它的商家后台、数据分析、订单管理、店铺装修这些功能在移动端上的形态非常重而且迭代频率极高。早期阶段Shopify 同时维护着 iOS 和 Android 两套原生应用每上一个新功能都要写两遍代码业务逻辑还经常因为两边写法不一致出现偏差。这种情况在团队很小的时候还能忍受但电商类 App 的功能链路很长——从登录、商品列表、购物车、结算到售后任何一个模块的改动都要双端同步时间成本直接翻倍。正是在这个节点上React Native 进入了 Shopify 的视野。1.2 React Native 当时解决的核心痛点RN 最明显的优势不是“性能比原生好”而是让业务团队可以共用一套 TypeScript 代码把 UI 组件和业务逻辑同时跑在 iOS 和 Android 上。对 Shopify 这种业务逻辑复杂、页面数量巨大的电商平台来说这意味着人力几乎减半而且新功能上线的时间窗口能压缩不少。电商场景还有一个特殊需求运营活动经常要快速上线和调整。虽然 App 原生也能通过热更新机制做远程配置但 RN 的 JS Bundle 机制让“不发版就能改 UI 和业务”这件事在工程上变得非常顺滑。这一点对促销活动频繁的电商平台是很加分的。1.3 早期确实跑通了不少场景根据 Shopify 自己后来公开的复盘内容来看RN 在其内部的早期应用并不是失败的。大量普通页面、表单流程、营销模块跑在 RN 上开发效率有实打实的提升。尤其是 JavaScript 生态里的状态管理、UI 组件库以及和 Web 团队共享代码的可能性让很多业务线尝到了甜头。但也正因为跑通的业务越来越多RN 在 Shopify 内部的使用范围越滚越大。从几个核心页面扩展到购物、订单、物流等关键路径再到整个 App 的第一启动屏都开始由 RN 承载。到这一步很多性能问题和工程治理问题就开始集中爆发了。2. 从“一次编写到处运行”到“到处调试”RN 在超大规模 App 扛不住的真实原因很多人对 RN 的印象还停留在“小应用跑起来挺流畅”的阶段。但 Shopify 遇到的问题远比这个复杂。当一个 App 的月活达到千万级、业务模块多达几十个、RN 页面和原生页面交错嵌套时RN 的很多短板会被无限放大。2.1 启动白屏问题链路比你想的长得多先说热词里反复出现的“react native 启动白屏”。这个问题在小型 Demo 里几乎感觉不到但在真实的大型 App 里几乎是必然出现。RN 启动链路大致是App 冷启动 → 原生容器创建 → 加载 JS Bundle → 初始化 JavaScript 引擎 → 执行业务代码 → 渲染首帧。在旧架构下这一步还涉及到 JavaScriptCore 的初始化、Bridge 的建立、Native Module 的注册任何一个环节卡住用户看到的就是白屏。我实际在低端 Android 设备上见过这个白屏能持续两三秒尤其是在首启还要同步拉远程 Bundle 或者做 Bundle 校验的时候。Shopify 的 App 里 RN 承载了启动主流程一旦 Bundle 解析慢或者引擎初始化慢用户体验掉得特别快。这也是后来他们把冷启动路径逐步原生化的直接原因之一。2.2 桥接层的心智负担高频通信是性能黑洞RN 的旧架构有一个绕不开的设计JavaScript 线程和原生线程之间所有的通信都要通过 Bridge 进行序列化和反序列化。模块之间数据量小的时候还好说但电商 App 恰恰是高交互场景——滚动列表的时候要频繁回调位置信息、图片懒加载要通知原生线程、网络请求结果要回传 JS 层。一旦这些高频调用叠加起来Bridge 就会成为瓶颈。你会在 Profile 里看到 JS 线程和 Native 线程之间大量的消息排队帧率掉到肉眼可见的程度。Shopify 的页面里大量使用长列表、图片墙这种重交互组件这个问题很难靠调优彻底解决。2.3 双端一致性陷阱你以为写一遍就够了吗RN 的口号是 Learn once, write anywhere但现实是 iOS 和 Android 上运行 JavaScript 引擎的表现并不完全一致。早期 iOS 用的是 JavaScriptCoreAndroid 在很长一段时间里也内置了 JavaScriptCore但两边的内存管理、垃圾回收时机、线程模型都不一样。更麻烦的是RN 的组件在 iOS 和 Android 上最终映射到的原生视图并不相同。同一个 padding、同一个 fontSize在两个端渲染出来可能差几个像素。遇到这类问题你还是得打开原生代码去调跨端的效率红利就打了折扣。Shopify 这种对 UI 还原度要求很高的商业 App在这上面投入了大量排查时间。2.4 原生能力深度集成时的断裂感电商 App 离不开相机扫码、Face ID/Touch ID、推送、地图、蓝牙、支付等原生能力。RN 虽然提供了丰富的第三方库但一旦系统升级、权限模型改变、或者某个交互需要深入系统底层最终还是得回到原生侧去写。问题在于当页面逻辑在 JS 层、底层能力在原生层、中间通信靠 Bridge 时一旦出现问题排查链路非常痛苦。你要分别看 JS 调用栈、Bridge 消息日志和原生崩溃日志三个层面的信息往往对不上。这种断裂感在单一技术栈的 App 里是不存在的。2.5 不是 RN 不行是你的规模到了临界点说到底我并不是想输出“RN 是坑货”这种片面结论。RN 在中小型应用里依然是一个效率极高的选择。但 Shopify 的问题在于它把 RN 用在了整个 App 的最核心路径、最复杂的交互场景同时还要面对成百上千人的协作规模。当业务多到一定程度跨端框架节省的那部分人力会被双端兼容问题、性能调优问题、 Bridge 通信问题、滚动升级问题一点点吞掉。这是一个边际成本递增的过程。很多大厂从 RN 撤退不是因为他们不会用而是因为他们规模太大跨端带来的复杂度已经盖过了收益。3. 回迁不是重写而是“器官移植”Swift/Kotlin 双线改造的真实难度很多人听到“从 RN 回到原生”的第一反应是那就把页面用 Swift 和 Kotlin 重写一遍嘛。但如果你在一个正在运行的 App 上做过大规模重构就会知道这事完全不是这样。3.1 你接手的不是一个空项目而是一个不断生长的系统RN 版本不能直接停掉——几百万用户还在用。你要做的是在保持线上版本正常运行、新功能持续迭代的同时把页面一点点替换成原生实现。这个过程没有“按个按钮整体切换”这种魔法只有一段很长的灰度迁移期。在实际操作中这种迁移就像给一架正在飞行的飞机换引擎。你不能让飞机停下来只能拆下一个旧的装上一个新的还得保证乘客全程无感。Shopify 的做法是彻底重写而非渐进式混合吗不是。他们在很长一段时间里都是让 RN 页面和原生页面共享一个 App通过路由层做分发按功能和用户群逐步灰度。真正常见的做法也是类似思路。3.2 双端并行开发设计和审核成本直接翻倍回到原生看起来是“不用写 JS 了”实际上你要同时养两支原生团队。iOS 用 SwiftAndroid 用 Kotlin两边除了业务逻辑一致其他全是独立实现。这就意味着每个 API 接口文档要对齐请求参数、错误码、响应结构要双端一致每个页面设计稿要有明确的 iOS 规范和 Android 规范导航交互、弹窗样式都不能混用每个埋点事件要双端核对否则数据一上来就是脏的每次版本发布要协调 iOS 和 Android 的发布时间窗口。这些工作在 RN 时代大部分是天然统一的回到原生之后全都要靠流程和代码规范去约束。我在实际项目中经历过类似的双端治理坦白讲这是最容易被低估的部分。3.3 网络层迁移一个 URLRequest 背后藏着一堆事热词里出现了“swift urlrequest get”可见不少人刚开始学 Swift 时都会从网络请求入手。在 Demo 里一个 URLRequest 也就是几行代码的事。但在 Shopiy 这种规模的 App 里网络层迁移是整个改造里最核心也是最枯燥的工程之一。生产环境下的网络请求要考虑什么请求头统一签名、token 自动刷新、缓存策略、超时重试、弱网降级、接口埋点、错误上报、证书校验、数据解析容错。RN 时代这些逻辑大多集中在 JavaScript 的网络库和拦截器里。回到原生你需要分别用 Swift 的 URLSession 体系和 Kotlin 的 OkHttp/Retrofit 体系各重新实现一遍还要保证行为和之前线上完全一致。这不是能不能写出来一个 get 请求的问题而是整个网络基础组件怎么设计和验证的问题。3.4 构建配置迁移Kotlin DSL 与 Groovy DSL 的“有手就行”陷阱另外一个很容易被忽视的坑是 Android 构建脚本的迁移。热词里也有“build configuration language kotlin dsl 与 groovy dsl 区别”这条我在实际迁移中深有体会。很多项目早期的 Gradle 构建脚本是用 Groovy DSL 写的。Groovy 语法松散、动态语言特性强、字符串处理方便写起来很随意。而 Kotlin DSL 是类型安全的构建脚本编译期就能发现配置错误IDE 自动补全也更好。听起来是不是“有手就行”换一下语法而已。但真实情况是一个大型 Android 工程里的 Gradle 脚本可能涉及几十个模块的依赖管理、变体配置、混淆规则、资源优化、插件扩展。Groovy 里一行pluginManagement的动态配置迁到 Kotlin DSL 里可能就要显式写类型、写 lambda 规范老项目里很多隐式约定根本没办法自动转换。我亲手做过一次代价不小的 Gradle 迁移。如果项目只有几十个依赖迁移确实低风险工程上可以很顺利地把build.gradle改成build.gradle.kts任务差异不算大很多常见插件也都有现成写法。但 Shopify 这种量级的 Android 工程模块数、插件数、定制 Task 数都远超普通项目而且内部还有自有构建框架和缓存系统牵一发而动全身。迁移后如果遇到某个民间插件的 NSIS 任务异常你连报错在哪个 DefaultTask 里都很难定位。而且构建速度在最开始往往没有提升反而因为 Kotlin DSL 编译额外的类型检查、首次运行要加载更多类构建时间会有一定程度的回退。要配合配置缓存反复微调才能回到原有构建速度甚至更快。如果只是“会写 Kotlin 代码”就上手 KTS大概率会卡在一个个配置文件连环报错里。3.5 不是“重写”是“重建基础设施”现在你应该明白了回迁原生最关键的不是页面重写而是整个 App 的基础设施重建。网络层要重写数据持久化要重写导航容器要重写日志监控要重写Feature Flag 要重写性能监控要重写推送和深链处理要重写。这些基础设施在 RN 时代被封装在跨端层里大家感受不到它们的存在。一旦切回原生你必须用两套语言同时把它们全部接起来才能让业务方在原生页面上继续正常干活。在我看来这部分工作量至少要占整个回迁项目的一半以上。4. 真正难的不是 Swift 或 Kotlin 语法而是你对架构的重新理解等到 Swift 和 Kotlin 的代码都能跑起来了另一个层面的问题才会浮出水面你究竟要构建一个什么样的原生架构4.1 SwiftUI 还是 UIKitCompose 还是 View System很多回迁团队会在这里纠结很久。以 iOS 为例SwiftUI 是当前苹果主推的声明式 UI 框架新项目用 SwiftUI 能省掉很多 UI 代码但它和 UIKit 在复杂的交互嵌套下仍然有兼容问题。Shopify 的 App 里有大量自定义视图、复杂表格、视频交互模块这些都是 SwiftUI 当前还不够顺手的地方。Android 这边也面临同样的问题Compose 的声明式 UI 效率高但在超大列表、复杂自定义绘制、辅助功能兼容上需要补的坑依然不少。别以为“回原生就是用最新的 UI 框架”大多数情况下你要做的是根据业务场景在传统 View 体系和声明式体系之间做混合制定一个完整的分层规范。我自己见过一些团队为了统一认知强行全面转向声明式 UI结果在老旧设备上碰到各种兼容问题最后不得不退回去保留一部分传统视图。这种反复内耗比一开始就老老实实做技术评估要费钱得多。4.2 职责分层不能只满足于“能跑”在 RN 时代页面逻辑、状态管理、数据处理都在 JavaScript 层分层标准相对统一。回到原生后如果没有在架构层面明确 presentation、domain、data 三层很容易变成“原生模板套路由”的混乱状态。我看到很多刚从跨端回迁的项目原生代码里 activity/fragment 里塞满了网络请求和业务判断。两三个月后页面一多、人员一流动这套代码就变成大型泥球。与其说是回到原生不如说是回到了二十年前的 MVC 大泥团。架构落地应该是这样presentation 层只负责渲染和用户交互不直接碰数据源domain 层负责核心业务规则不依赖 UIKit 和 Android frameworkdata 层封装网络、缓存、数据库实现双端各自维护 domain 层但领域模型定义尽量保持一致。这样做之后至少你从 RN 迁移过来的那部分业务逻辑可以更平滑地在双端对齐后续修改也不会因为底层实现跳来跳去而崩溃。4.3 包体积和启动时间这些指标最终会“算总账”回迁原生之后很多团队会发现一个尴尬的事实App 体积比 RN 时代更大了启动时间也只是略有改善并没有想象中那种“秒开”的效果。原因不复杂。RN 时代虽然有一个 JS 引擎和一个大 Bundle但很多原生库并没有被拆掉而回迁原生后你又把这两套原生 UI 框架、网络库、图片库全部塞了进来基础包自然更厚。真正的优化工作量在架构完成之后才开始启动链路裁剪哪些服务可以懒加载哪些组件可以不做冷启动初始化动态化包管理按功能模块拆分动态下发资源去重和裁剪移除 RN Bundle 之后多语言、图片、字体资源全部重理首屏渲染优化提前接入首帧渲染链路避免被周边初始化任务阻塞。这些动作在 RN 时代基本没法做。这是回迁后最值得发力的部分。4.4 团队能力重建才是最大的隐性成本还要提醒一句RN 团队和原生团队对应的技能栈是不同的不只是代码语言不同对性能调优、系统机制、内存管理的理解深度也不同。Shopify 在回迁原生的时候不可能直接让所有前端工程师第二天就用 SwiftUI 写页面。他们需要重建 iOS 和 Android 两个原生技术梯队长期维护双端原生架构。这件事在招聘市场上的成本远高于当初养一个 RN 团队。5. 如果你也在考虑类似的迁移这几条实际建议值得看看很多中小团队看到大厂回迁也动了“要不要也把跨端项目改成原生”的念头。这里我给几条基于实际经验的原则你可以对照自己的场景再判断。5.1 先分清你是“性能瓶颈”还是“团队规模瓶颈”如果你只是列表滚动掉帧、启动有点慢先不要急着迁移。优先做性能剖析定位瓶颈在 Bridge 通信还是在图片加载或者在接口响应。大量 RN 项目的卡顿问题其实是资源加载策略和列表复用配置不当可以通过优化解决没有必要全盘推翻。但如果你面临的问题是团队规模过大、跨端代码治理内耗高、双端兼容问题持续消耗主力人力那么回迁原生才是一个值得考虑的选项。Shopify 是属于明确触碰到了规模边界的大型 App并不是普通中小应用的参考坐标。5.2 回迁之前先把“原生基建”搭起来别先从核心页面下手。先把网络层、数据层、导航容器、埋点体系、日志体系、Feature Flag 用原生语言搭好接着在原生的容器里把线上核心路径复刻一遍再决定哪些页面第一批切换。基建没搭好的时候就分页面去写原生大概率会写出一个又一个信息孤岛。5.3 用灰度迁移代替“大爆炸”重写最理想的迁移状态是用户无感的。具体做法是服务端通过用户特征或随机分组下发新的原生页面监控切换后的崩溃率、卡顿率、页面停留时长和业务转化率发现问题立刻回滚到旧实现保证用户影响最小化等新页面稳定跑过一段时间后再扩大灰度范围。这个思路不仅适合 RN 回原生也适合任何一次大版本重构。5.4 迁移期间新功能不要停摆如果你真的在做一个长周期的回迁项目最容易犯的错是让业务方等你。一家正常运营的电商公司不可能因为你在做技术迁移就停止上新功能。这就要用到一种兼容期的双轨开发模式RN 的技术栈继续维持住线上版本的迭代同时原生团队在内部灰度版本上做替换。Shopify 在迁移期间也是这么处理的。搞不定这种双轨节奏的项目往往会因为业务压力被迫中断迁移计划最终搞成“一半 RN 一半原生”的尴尬状态。6. 关于 Shopify 这次的迁移我的真实体会说了这么多最后还是想分享一些我个人的判断。第一个体会是跨端框架没有绝对的优劣只有适配的规模范围。Shopify 放弃 RN 并不意味着 RN 不能用了反而说明 RN 的能力边界已经被划得很清楚。对绝大多数几十人团队的 App 来说RN 依然是一个效率极高的选择。真正危险的是把小项目里积累的经验直接套用到别人千万级 DAU 的 App 上然后得出“这框架不行”的结论。第二个体会是回迁原生真正的成本不是写 Swift 或 Kotlin而是你同时要重建两条原生技术线的基础设施并且要在业务不停的前提下完成平滑切换。这中间牵涉到的团队组织、工程流程、架构设计、性能监控、灰度发布没有一项是“有手就行”的。第三个体会是跨端与原生从来不是二选一的对立面。即使回迁之后大型 App 里仍然会保留很多跨端解决方案用于承载短平快的运营活动页面——成本低、上线快这件事在商业场景里永远是刚需。我个人一直很佩服能做这种大规模技术迁移的团队因为他们要对抗的不只是技术难点还有漫长的迁移期里来自各方的预期压力。用户不会因为你切了原生就自动变多业务方也不会因为你在做重构就停止提需求。能在这种环境中把项目稳扎稳打地推完靠的是扎实的架构基本功以及极强的项目管理能力。如果你也在经历类似的跨端回迁或者在考虑要不要做这件事我的建议是先别急着写代码把刚才聊的这些问题一项项想清楚尤其是你自己的“规模边界”到底在哪。想清楚了再动手也不迟。
