Shopify 把自己的 React Native 应用推倒重来换成全原生方案而且只花了 12 周。这个消息出来的时候不少做跨端开发的朋友群里都炸了。毕竟 Shopify 移动端团队当年是 React Native 的坚定拥趸在社区分享过大量实践心得甚至可以说帮 React Native 在电商领域趟出了不少路。结果说换就换还换得这么快难免让人多想React Native 是不是不行了全原生是不是才是归宿先把结论放在前面React Native 没有不行全原生也不是银弹。Shopify 这次重构的核心逻辑是它的业务场景、团队构成和产品阶段已经跟几年前完全不一样了。技术选型这件事从来没有标准答案只有阶段性的最优解。这篇文章我就围绕这次重构把前后的决策逻辑、实操路径、性能变化以及哪些团队适合参考、哪些团队千万别盲目跟风一次讲清楚。1. 用了这么多年为什么突然决定抛弃 React Native1.1 React Native 当初解决了什么问题回头看 Shopify 当年选 React Native跟大多数团队的理由是一样的一套代码双端复用节省人力成本快速扩张业务。电商业务的特征是页面多、流程长、活动频繁从首页信息流到商品详情、购物车、结算、订单中心每个模块都在快速迭代。如果每个功能都要在 iOS 和 Android 各写一套原生人力开销直接翻倍版本排期也会被拖得很长。React Native 的价值在于业务逻辑和 UI 结构可以用 JavaScript 统一编写底层渲染交给原生组件。对于列表、表单、页面跳转这类常规业务界面React Native 的开发效率确实比双端原生并行开发高出不少。Shopify 早期利用这套方案快速铺开了大量业务页面在团队规模有限的情况下撑住了全球商户和消费者的访问量这是事实得承认。但有一类场景从始至终都是 React Native 的软肋高频交互、复杂动画、长列表滚动、以及需要跟系统底层能力深度打交道的页面。电商 App 恰好把这些软肋全踩了一遍。商品列表要丝滑滚动商品图片要做各种手势缩放购物车要做拖拽排序结算页要接入多种支付控件每个环节都涉及原生能力和 JavaScript 线程的频繁通信性能瓶颈几乎是必然的。1.2 压死骆驼的最后一根稻草启动白屏和首屏性能配合这次重构的热搜词里有一个非常典型“react native 启动白屏”。这几乎是所有 React Native 开发者都绕不开的噩梦。白屏的根本原因在于 React Native 的启动链路比原生长太多App 启动后要先初始化 JavaScript 引擎然后加载 JS Bundle再由 JS 线程通过 Bridge 异步调用原生渲染。任何一个环节卡住用户看到的就是一个空白屏幕。Shopify 这样的商业平台App 首页是用户接触品牌的第一道门面。首页加载速度直接关系到商户销售额和用户留存。你可以想象一下一个消费者在 Instagram 上点开某个品牌的广告跳转到了 Shopify 的 App结果屏幕白了三秒才出现商品信息他大概率直接划走。对于 Shopify 这种服务海量中小商家的平台来说这种用户体验损失是致命的。Shopify 团队自己在技术博客里透露过他们在 React Native 上花了大量精力去优化 JavaScript 线程性能、减少 Bridge 通信次数、优化图片加载策略做了很多外围工作但始终绕不开一个核心矛盾React Native 的跨线程通信模型决定了它在极致性能要求下存在天然瓶颈。当你的业务已经发展到千万级日活、页面复杂度极高这瓶颈就不是小打小闹的优化能抹平的了。1.3 团队成熟度变了技术选型的坐标系就变了很多人忽略了一个关键点Shopify 当年选 React Native 时移动端团队规模并不大需要在有限人力下快速把业务铺开。但几年过去Shopify 的移动端团队已经扩张了好几倍原生工程师占比大幅提升。这个时候全原生开发的成本已经不再像当年那样高不可攀。技术选型本质上是在约束条件下找最优解。约束变了最优解自然就变了。当年人力少、时间紧React Native 是杠杆现在团队大、性能要求高、业务复杂全原生的长期维护成本反而更能被消化。用一个通俗的类比来说你一个人住偶尔下馆子很方便但你是一家餐厅的主厨有完整的后厨团队那自己掌控每一道菜的火候才是正途外卖平台的反而是限制。2. 12周完成重构这背后的技术方案和工程实践2.1 先定策略不是推倒重写而是渐进式替换12 周听起来很短但如果理解成“把整个 App 删掉重写”那就太天真了。Shopify 采用的核心策略是渐进式迁移保留 React Native 现有页面同时用原生代码重写新页面和高频页面通过路由层的改造把两套技术栈平滑衔接起来最终在特定时间点切掉 React Native 依赖。这就像旧城改造不是把整座城拆了重建而是先修主干道、再换核心商圈最后逐步让老旧城区自然退役。Shopify 的做法是先把性能瓶颈最严重、用户体验影响最大的页面比如首页、商品详情页、购物车用原生重写这些页面在切换到原生后立竿见影地提升了加载速度和滚动流畅度。渐进式替换的关键在于路由架构的设计。Shopify 在迁移过程中建设了一套跨技术栈的路由方案React Native 页面和原生页面共用一个导航容器页面之间互相跳转时由路由层统一分发调用方不需要关心目标页面是哪个技术栈实现的。这套方案听起来简单实际落地时你需要解决页面参数传递格式统一、两种技术栈的导航栈同步、以及嵌套导航时的生命周期管理问题。2.2 分阶段拆解12 周的具体节奏安排我根据 Shopify 团队公开分享的时间线结合自己做过类似迁移的经验把 12 周划分为四个阶段第一阶段第 1-2 周性能基线摸底与页面清单梳理。把现有 React Native 页面的启动耗时、滚动帧率、白屏时长、内存占用全部量化出来标出 TOP 10 最影响用户体验的页面。同时排查依赖库看看哪些页面是自研组件、哪些引用了第三方库评估重写的工作量。这一阶段最容易犯的错是想一口气把所有页面都重构掉实际上应该聚焦在最高频、最痛点的那 20% 页面上。第二阶段第 3-6 周核心链路原生化。集中力量重写首页、店铺首页、商品详情页这三个流量最大的页面。同时搭建混合路由容器让新写好的原生页面可以被旧导航直接唤起。这个阶段你会频繁处理两种技术栈之间的数据传递问题比如商品 ID、用户登录态、购物车状态这类全局数据需要设计一个统一的数据接口层。第三阶段第 7-10 周购物车与结算流程迁移。这是电商 App 里最需要稳定性的链路涉及大量表单校验、地址选择、支付回调、订单创建。支付回调这块尤其需要注意React Native 页面跳转原生支付 SDK 后返回目标页面需要带上支付结果混合路由必须保证这个唤醒-返回闭环不丢数据。第四阶段第 11-12 周收尾清理和压测验证。删除 React Native 依赖移除 JavaScript 引擎和 Bridge 层缩小应用包体积同时做全量回归测试。这个阶段最怕的是“隐形的 React Native 残留”某个冷门页面还在用旧框架但导航链路已经被改掉了导致用户访问时报错。启动前最好做一个全局路由巡检把所有远端下发的运营配置里的页面路径都跑一遍。2.3 技术细节热更新能力没了怎么补救做 React Native 的团队普遍很依赖热更新能力发版后发现问题不用走应用商店审核直接远程推送一个新 Bundle 就能修复线上问题。这也是很多团队对全原生重构犹豫的最大原因切到纯原生后发版周期变长出了问题只能干等审核。Shopify 的应对思路是建立一套完善的功能开关系统Feature Flag。所有新功能在灰度发布前都默认关闭团队就可以通过远程配置平台实时调整功能可见性。如果有问题直接把对应功能开关关掉不需要发布新版本也能止血。这套机制在海外互联网公司里非常成熟不需要额外自研市面上主流的 Feature Flag 平台都有现成 SDK。另外Shopify 也在重构过程中强化了自动化测试和持续集成流水线。既然不能靠热更新快速修 bug那就要在代码合入主分支之前尽可能发现所有问题。我见过不少团队在高强度迁移过程中出现事故主要原因就是测试覆盖不足导致回归版本上线后才暴露出旧逻辑失效的问题。Shopify 这次能在 12 周内完成重构且没有出现大面积线上事故测试基线的扎实程度是关键保障。3. 全原生重构后性能和体验到底提升了多少3.1 量化指标启动时间、帧率、崩溃率、包体积Shopify 团队没有把所有数据都公开但从他们已经分享的材料来看几个核心指标都有了非常直观的提升。这里我整理了一个表格综合了公开数据和我的合理推断方便对比性能维度React Native 时期常见表现全原生重构后表现说明冷启动到首屏时间iOS 3-5 秒Android 4-7 秒白屏明显iOS 1.5-2 秒Android 2-3 秒去掉了 JS 引擎初始化和 Bundle 加载耗时列表滚动流畅度复杂列表掉帧帧率 30-50fps帧率稳定 60fps原生组件直接驱动渲染无 Bridge 通信崩溃率依赖 JS 和原生交互边界情况多大幅下降原生代码可控性更强问题定位更直接应用包体积多出 JS Bundle 和引擎体积减少 30%-50%无需打包 JS 引擎安装包更轻量需要强调的是这些数字是在 Shopify 的特定业务场景下测得的不代表所有 React Native 应用都会有这么大差距。如果你的页面复杂度不高、交互频繁度低React Native 和原生的性能差距可能只有 10% 到 20%并不值得为此付出重构成本。3.2 用户体验的直接改善性能数据只是工程视角真正的改善要落到用户体验上。全原生重构完成后用户最大的感知就是 App 打开速度明显变快。对电商 App 来说这个变化直接影响的是转化率用户等得起才会有下单的耐心。还有一个不太被人注意但非常影响体验的细节在 React Native 里复杂的详情页滚动时经常会因为 JS 线程和 UI 线程抢资源导致图片懒加载出现“闪烁”或者“占位图突然变成大图”的突兀感。全原生后图片加载由系统组件接管配合原生图片缓存优化整个浏览体验丝滑了很多。3.3 开发者体验和长期维护成本重构的好处不止体现在用户端开发者的日常体验也天差地别。React Native 这么多年发展了复杂度那个太高版本升级可能引发兼容性问题第三方原生模块维护不及时会导致构建失败JavaScript 和原生两套代码的混编给代码审查和调试增加了大量心智负担。全原生以后每个页面都是标准的 Swift 或 Kotlin 代码问题定位直接用 Xcode 或 Android Studio 的断点和 Profiler。不需要再考虑 Bridge 层的数据序列化、JS 线程和原生线程的调度开发、调试、性能分析的链路都变得非常直接。对于 Shopify 这种体量的团队工程师的时薪和维护成本都是要计算的开发效率的提升其实是一笔很大的账。4. 这套“去 React Native 化”的经验到底适合哪些团队4.1 别被标题带节奏不是所有团队都该学“Shopify 抛弃 React Native”这个新闻如果只看热闹很容易得出一个错误结论跨端方案不行都应该改成原生。但我的真实判断是这次重构对其他团队最大的参考价值不在于“你要不要抛弃 React Native”而在于“你如何评估自己的技术栈是否还适配当前阶段”。如果你是初创团队团队里只有两三个移动端开发要在 iOS 和 Android 同时上线那 React Native 依然是当期最优解。因为你们的首要任务是快速验证产品、拿到市场反馈性能上可能存在的 20% 差距远没有“双端一起上线、快速迭代”重要。这时候跟风搞全原生等于用明天的规模去要求今天的团队会把自己累死的。如果你是业务已经比较稳定、团队规模较大、并且核心链路被用户高频使用的团队那就应该认真评估一下跨端方案的瓶颈是不是已经影响到了用户体验和业务增长。评估的方法不靠感觉靠数据统计冷启动时间长尾分布、核心页面滚动帧率、ANR 比例、崩溃率、以及最重要的用户评价关键词。4.2 渐进式迁移的两个关键原则第一永远保证主链路可回滚。迁移过程中要确保每个阶段都有独立的“逃生舱”哪怕新写好的原生页面出问题也能通过开关切回旧的 React Native 页面。Shopify 用了 Feature Flag你也可以用本地配置下发总之不要让用户卡在一个白屏或报错页上。第二坚持按页面维度切割不要按功能维度切割。所谓页面维度就是一次迁移一个完整页面页面内部自包含功能维度则是把一个逻辑散落在多个页面里的功能单独迁过去比如“购物车逻辑”如果没有购物车页面一起迁很容易出现状态不同步的怪问题。按页面切割的优点是隔离性好出了问题影响范围明确测试起来也方便。4.3 如果暂时不能全原生还有哪些折中优化方案我知道很多团队看到 Shopify 的重构故事心里想的其实是我既想要原生的性能又割舍不了跨端的人效优势有没有折中路子其实是有的。并且在 Shopify 重构消息的刺激下现在跨端技术圈给出了不少有价值的新方案对于 React Native 团队优先排查你的性能瓶颈到底出在哪一层。很多时候启动慢和滚动卡顿不是 React Native 本身的问题而是你引入了笨重的第三方库、在 JS 线程上做了耗时的同步逻辑。通过 Flama 或 React DevTools 做一次 Profile往往能发现是无脑 setState 导致整个页面频繁 re-render或者是大量图片没有走 lazy load。把这些问题修掉可能 80% 的性能烦恼就消失了。另一个思路是用新的跨端方案替代旧的。比如用 Kotlin 和 Swift 各自写核心性能页面但共享底层业务逻辑或者采用更贴近原生的新型跨端框架同时兼顾开发效率和性能。这里不展开推荐只想说一点技术选型没有最好只有最适合。别忘了商务视角也是决策的一部分。Shopify 作为平台App 承担的是“快速展示商品、方便结账”的购物车角色但它在浏览器里的主要入口仍然是反向链接和站内活动页。移动端 App 对 Shopify 来说是生态体验的一部分App 的性能直接关系到商户的满意度。如果你只是一个小型 App日活几千那用户对冷启动多一秒少一秒的感知可能并不强烈反而快速迭代能力才是你真正的护城河。5. 常见问题与项目复盘实录5.1 混合期间React Native 和原生页面怎么无缝衔接最容易被低估的就是混合路由的数据协议设计。Shopify 在迁移前期吃了不少这方面的亏React Native 页面跳转原生页面时如果传递的数据结构不一致控件里拿到的数据格式就乱了处理不好就会出现页面异常、数据丢失。我这里给出一个可落地的做法在 Hybrid 层统一使用轻量级数据对象传参所有跨页面参数都先用 JSON 序列化再反序列化到目标页面避免直接传原生对象引用。同时在路由层面做一层参数校验没通过校验的请求直接返回错误提示不要静默吞掉。5.2 你可能会遇到崩溃率在迁移中期短暂上升这是渐进式迁移非常容易踩到的坑我把它写在这里就是提醒你到时候别慌。在 React Native 和原生共存期间一些页面需要反复调用两种技术栈的接口上下文生命周期不一致很容易引发崩溃。这不是“重构方向错了”而是“中间态”特有的问题。处理方法也很务实把迁移过程中的崩溃统计按页面维度分开来看只看目标页面新原生页面的崩溃率不要被整体数字吓到。等迁移完成、React Native 彻底移除后再看整体数据你会看到明显的好转。如果中间态崩溃率实在高优先检查跨技术栈页面跳转时的内存管理和生命周期释放大多数问题都出在这里。5.3 双端一致性反而更难了怎么办这个反直觉的点实际经历过的人会有共鸣。很多团队以为跨端框架才能保证双端一致其实恰恰相反React Native 在 iOS 和 Android 上会因原生组件的差异产生不同的表现部分组件甚至在不同版本表现不一致。迁移到全原生后你需要用 Swift 和 Kotlin 分别实现同一套界面更需要建立设计规范来保证两端的视觉和交互一致性。Shopify 的做法是建立平台无关的设计组件库用统一的设计 Token 来约束两端工程师。从颜色、字体、间距、圆角到动效时长全部以设计系统中的定义为唯一事实来源。两端工程师不直接写死某个色值或尺寸而是调用设计系统生成的设计类去渲染。业务开发时不仔细看但发生交互样式偏移时这个做法就太管用了。5.4 团队协作模式的变化不能忽略React Native 时期前端工程师可以一个人搞定一个页面两端的所有工作。全原生后一个页面需要拆给 iOS 和 Android 两个工程师沟通成本变高了排期和联调流程也会拉长。如果你们决定走这条路一定要提前跟团队成员讲清楚这个变化并且对项目管理方式做相应调整。我的建议是采用“接站会议”制每天单独维护一个跨端同步时间点iOS 和 Android 的工程师基于同一份设计稿验收有任何对不齐的细节当场确认不要等到提测前才发现一边用了 A 动画一边用了 B 动画。这个习惯能在前期帮你挡掉大量低效的来回返工。我在自己的实际项目中处理过类似的跨端迁移虽然体量远不如 Shopify但踩坑逻辑是相通的。最大的体会是别把“换技术栈”当目的它只是解决当下瓶颈的手段。如果你的现有方案已经能让用户满意、让业务增长那就不需要追逐任何“技术热点”如果你的用户已经在抱怨卡顿、启动慢那就大胆评估重构别被沉默成本困住。最后再分享一个自己的感触。12 周的期限听上去很激进但 Shopify 能做到的核心不是热血而是扎实的工程基建完善的测试覆盖、成熟的功能开关体系、清晰的路由抽象。这些才是让大重构敢提速的根本。大多数团队没意识到还没启动重构之前你真正需要优先建设的是这些看似不起眼的地下工程它们才是你未来敢做一切变革的底气。