|
Shopify 研发原生移动应用数年之后，咱们决定完全转向 React Native 来构建所有新的移动应用。做出这个决定并非易事，下面我会做详细解释。
无论是哪个季度，大都数消费者都是在移动设备上下单的（去年第三季度，咱们有 71％的顾客经过移动设备下单）。黑色星期五（Black Friday）和电商星期一（Cyber Monday）（两者以下合叫作 BFCM）是 Shopify 平台商家一年中最繁忙的日子，这时期消费活动最为活跃。在今年的 BFCM 中，Shopify 商家在移动设备上的购买量又增多了 3％，平均占营销额的 69％。
那样为何要切换到 React Native？为何此刻切换？这一变化是怎样融入咱们的原生移动研发流程的？答案很繁杂，我在回答这些问题之前需要先交代有些背景状况。
Shopify 在 2019 年之前的移动研发状况
Shopify 的工程文化之一，是押注某些初期技术来帮忙咱们快速发展。
总体而言，咱们更爱好选取少许技术打造工程基本。这为咱们供给了非常多好处： 咱们在少许几种深度技术中创立了非常明显的专业能力（咱们经常作为核心贡献者）；每种技术选取都有其怪癖，但咱们都能深度认识这些怪癖；非初期团队成员亦能贡献、传递和守护他人编写的代码；新人上手更快。与此同期，新技术层出不穷，为咱们供给了逐步提高生产力或能力的机会。咱们做了非常多尝试，找机会得到大幅度的改进——但到头来，咱们在核心工程中很少采用这些改进。
当咱们采用这些处在初期周期的语言或框架时，咱们便是在下经过计算的赌注。咱们无逃避危害，而是按照自己的一系列要求来精心科研、探索和评定此类危害。新技术的危害常常是隐匿其中的，与此类似，许多未研发的机遇亦需要咱们去探索。咱们思虑的是该怎样减轻这些危害的威胁： 倘若某项技术再也不被其核心团队支持怎么办？倘若遇到没法修复的错误该怎么办？倘若制品的发展方向与咱们的利益冲突怎么办？当 Tobi（咱们的首席执行官）于 2004 年作为 Ruby on Rails 的核心贡献者时，Ruby on Rails 还是一个青年且难用的框架。过去非常多年，Ruby on Rails 都被视为一种不足严肃且性能不良的语言。尽管它不是一种主流的技术选取，但初期周期投下的赌注使 Shopify 持有了超越竞争对手的能量。选取 Ruby on Rails 后，团队就能够运用比传统编程语言和框架更现代、更抽象的工具来更快地构建软件，并吸引众多区别行业的人才。Paul Graham 亦谈到了他决定运用 Lisp 构建 Viaweb 的决策，这一决策产生了类似的效果；另一，当今 10 家最有价值的 Y Combinator 孵化企业中有 6 家都在运用 Ruby on Rails （不外要再说一遍，它还是很不受欢迎）。相比之下，前十大最有价值的 Y Combinator 孵化企业中没有一家在运用 Java，而 Java 被广泛认为是久经沙场的企业级语言。
两年前 Shopify 又做出了类似的选取，决定转向 Google Cloud。针对在 2019 年美国排行第三大的电子商务零售网站来讲，这又是一项令人恐惧的提案——从咱们自己的数据中心迁移到云已然是艰难的决定，而选取一家处在早期周期的云供给商则一样危险。当时咱们看到了产业价值链中的技术发展趋势，因此起始专注自己所善于的工作——亦便是发扬企业家精神来改进业务，而让其他人（在这儿指的是 Google Cloud）负责守护理学硬件、电力、安全性和操作系统更新等同质化的繁重劳动。
React Native 是什么？
2015 年，Facebook 发布并开源了 React Native，当时它已然在 FB 内部被用于移动工程了。React Native 是运用 React 构建原生移动应用程序的框架。这寓意着你能够运用一流的 JavaScript 库（React）来构建自己的原生移动用户界面。
在 Shopify，这个想法在当时（并且此刻仍然）面临许多质疑，然则许多人看到了它的前景。在机构的下一个 Hackday 中，全机构都抽时间来科研 React Native。尽管初期团队看到了这个框架的非常多好处，但她们判断咱们在 2015 年没法运用 React Native 制作出足以让咱们自豪的应用来。这重点是由于性能表现不良和缺少一流的 Android 支持。而咱们当时认识到的事实是，咱们的确爱好响应式编程模型和 GraphQL。另一，起始运用 React Native 之后咱们为 iOS 构建并开源了一个函数式渲染器。在 2015 年，咱们将这些技术加入了自己的原生移动研发技术栈，但无将 React Native 用在完整的移动研发工作中。《环球邮报》在介绍咱们初代移动应用的深度报告中说到了咱们的愿景。
到日前为止，Shopify 上所有移动研发的标准都是原生移动研发。咱们创立了分别专注于 iOS 和 Android 的移动工具链和基本团队，以加快咱们的研发工作。尽管这些团队和产出的应用程序都取得了成功，但亦有人认为倘若咱们能够做到下列事项，那样团队效率可能会加强： 将 JavaScript 和 Web 的力量带入移动研发行业；在所有客户端应用程序中采用响应式编程模型；将咱们的 iOS 和 Android 研发工作整合到一个技术栈中。React Native 的工作机制
React Native 供给了一种运用 JavaScript 构建原生跨平台移动应用程序的办法。React Native 与 React 类似，它准许研发人员在 JavaScript 中创建声明式用户界面，为此它在内部创建一个 UI 元素的层次结构树，用 React 术语来讲便是创建一个虚拟 DOM。尽管 ReactJS 的输出以浏览器为目的，但 React Native 运用平台原生绑定将虚拟 DOM 转换为移动原生视图，这些平台原生绑定运用 JavaScript 对接应用程序规律。就咱们的需要而言，目的平台仅有 Android 和 iOS，然则 RN 社区已奋斗将 React Native 引入了其他平台，例如 Windows、macOS 和 Apple tvOS 等。
ReactJS 的目的是浏览器，而 React Native 的目的能够是移动 API。
在什么状况下咱们不会选取 React Native？
在某些状况下，React Native 并不是 Shopify 构建移动应用的默认选项。例如说倘若咱们有以下需要： 在较旧的硬件（CPU <1.5GHz）上安排繁杂的处理过程超高性能许多后台线程提醒一句：包含许多开源 SDK 在内的底层库还会是纯原生的。需要接近硬件层时，咱们都能够创建自己的原生模块。
为何此刻转向 React Native？
这三大原因决定了此刻是做出这一决策的好机会： 咱们在 2018 年收购了 Tictail（一家移动优先的机构，完全专注于 React Native），从中认识到了 React Native 的发展状况，并在 2019 年进行了 3 项深度制品投资；Shopify 在 Web 端广泛运用 React，此刻这一部分的知识就能够在移动端利用上了；咱们看到性能曲线是向上弯曲的（想想此刻 Google Docs 和桌面端 Microsoft Office 中的能力对比），并且咱们能够像在 Ruby、Rails、Kubernetes 和 Rich Media 中那样对 React Native 进行长时间投资。2019 年 Shopify 的移动研发状况
Shopify 持有许多移动平台，供买卖双方经过 Web 和咱们的移动应用进行交互。去年，咱们花了有些时间由三支独立的团队在三款应用上针对 React Native 进行了实验：这三款应用分别是 Arrive、Point of Sale 和 Compass。
从这些实验中咱们认识到： 在 React Native 中重写 Arrive 应用时，团队认为自己的生产力是运用原生研发时的两倍——即使仅在一个移动平台上对比亦是如此；在 Android 硬件的低功耗配置上测试 Point of Sale 应用时，咱们设置的 CPU 阈值比之前想象的还要低（1.5GHz 对 2GHz）；咱们之前估计 iOS 和 Android 之间大概 80％的代码能够共享，结果实践中的超高水平震撼了咱们——95％（Arrive）和 99％（Compass）；顺便说一句，即使咱们决定运用 React Native 来构建所有新应用，这并不寓意着咱们会自动起始在 React Native 中重写哪些旧应用。
Arrive
在 2018 年底，咱们决定用 React Native 重新编写咱们最受欢迎的消费类应用之一， Arrive 。Arrive 是一款评估颇高、表现出色的应用，在 iOS 上持有数百万的下载量。它是很好的候选者，由于它之前无 Android 版本。这一奋斗将帮忙咱们满足所有巴望得到 Arrive 的 Android 用户的期待。此刻，iOS 和 Android 上的 Arrive 都是基于 React Native 研发的，并且共享 95％的代码。咱们将在以后的博客文案中深入探讨 Arrive。
到日前为止，这次重写带来了以下结果： 与原生 iOS 应用相比，新版本在 iOS 上的崩溃次数更少；推出了 Android 版本；由移动 + 非移动研发人员构成的团队。团队还想出了一种很酷的办法来立即测试进行中的拉取请求。你只需从手机上扫描一条自动 Github 注释中的 QR 码，JavaScript 包就会更新到你的应用中，此刻你运行的便是从这个拉取请求中得到的最新代码。咱们的首席技术官 JML 近期在 Twitter 上分享了这一过程。
Point of Sale
在 2019 年初，咱们在自己的旗舰级 Point of Sale（POS）应用上展开了为期 6 周的实验，想要晓得它是不是适合用 React Native 重写。咱们学到了非常多东西，其中包含咱们的零售商家期望的 POS 响应能力几乎是之前的两倍，由于运用这款应用时会养成肌肉记忆，需要边操作应用边同顾客交流。
为了给咱们的零售商供给最好的服务，并在实体零售环境中认识 React Native 的能力，咱们决定在 iOS 上原生构建新版 POS，并在 Android 上运用 React Native。
咱们选取由两支团队并行推进，重点出于以下原由： 咱们已然有了一支具备 iOS 专业知识的团队，其中有许多成员参与构建了原始 POS 应用；咱们期盼能与原生 iOS 这一黄金标准对比，对 React Native 的工程速度以及应用性能进行基准测试；为了满足商家的高性能需要，咱们觉得应该在项目起步前等待 Facebook 对 React Native 做完所有架构更新（事实证明，这些更新对咱们的性能场景而言并不重要）。在两个平台上持有两支团队，降低了咱们起步项目时面临的危害。咱们在 Unite 2019 上宣布了起始对 POS 做全面重构。预计原生 iOS 和 React Native Android 应用都将在 2020 年发布！
Compass
Shopify Start 团队的任务是帮忙创业新人。在机构做出全面决策，准备在 React Native 中编写所有移动应用之前，这支团队深入科研了原生、Flutter 和 React Native 这些可能的技术选项。她们最后选取了 React Native，并在应用商店中上线了 iOS 和 Android 应用（测试版）。
Compass 的第1批版本（iOS 和 Android）只用了不到 3 个月就发布了，iOS 和 Android 版本之间共享约 99％的代码。
Shopify 在 2020 年之后的移动研发规划
咱们在 2020 年有非常多计划。
咱们会重写哪些原生应用吗？不，这是需要由每一个应用团队独立做出的决定。
咱们会继续雇用原生研发工程师吗？是的，需要非常多！
咱们期盼为 React Native 内核做出贡献，构建平台特定的组件，并继续认识每一个平台的精妙之处。这需要深厚的原生专业知识。
合作与开源
咱们认为构建软件是一项团队运动。咱们认同开放 Web、开放源码和开放标准。
咱们正在赞助 Software Mansion 和 Krzysztof Magiera（Android 版 React Native 的一起创始人），支持她们围绕 React Native 进行开源工作。
咱们正在与 William Candillon（Can It Be Done in React Native 的主持人）合作进行架构审查和性能改进。
咱们将与 Facebook 的 React Native 团队紧密合作，科研自动化、第三方库以及经过 Lean Core 管理某些模块主题。
咱们正在与 Discord 合作，以加快 FastList for React Native （一个仅渲染视口中列表项的库）的开源进程，并针对 Android 进行优化。
React Native 的研发工具链和基本
当你下注一项技术并深入科研它时，你期盼从这一选取中得到最大的效用。为了使咱们快速构建并得到最大效用，咱们设置了两种类型的团队来帮忙 Shopify 的其他团队快速构建。第1个类型是工具链团队，能够帮忙他人进行工程设置、集成和安排。第二个类型是基本团队，专注于 SDK、代码重用和开源。进入 2020 年，咱们已然起始让这两支队伍都转变方向，专注于 React Native。
Shopify Ping 应用仅在 iOS 平台上就处理了数十万次客户对话。2020 年，咱们将在旧金山办公室运用 React Native 构建它的 Android 版本，日前正在为此招聘人员）。
在 2019 年，Twitter 运用叫作为 React Native Web 的东西发布了她们的桌面和移动 Web 应用。虽然这项技术有点令人困惑，不外它准许你为 Web 应用运用相同的 React Native 技术栈。Facebook 为该项目聘请了首席工程师 Nicolas Gallager。在 Shopify，咱们将在 2020 年进行有些 React Native Web 的实验。
作者介绍：
Farhan Thawar 是 Shopify 的途径和移动业务副总裁。
原文链接：
https://engineering.shopify.com/blogs/engineering/react-native-future-mobile-shopify
| 
发表于