您的当前位置:首页正文

React Native 这一年

来源:华拓网

这是一个史诗般的旅程——但是,我们才刚刚开始。让我们回顾一下 React Native 自开源一年以来的成长和演化,我们遇到的挑战,以及我们对未来的期望。

开端:React Native 起源

在我们有了一个可工作的原型之后,我们预期这个项目会赋予 Facebook 很大的潜能。几年前我们把工作重心转向原生移动开发。但是,重新编译代码往往很慢,而且构建 iOS 和 Android 需要不同的技巧。所有这一切意味着低效的产品开发。而 React Native 的思想意味着,我们可以把 Web 开发中喜欢的所有东西引入到移动开发——比如快速迭代,并且只需要一支团队去开发整个产品。这意味着我们能够前进得更快。

结果,我们决定开始对这个项目投入时间和精力——我们知道,证明这项新技术能够真正工作的唯一方法就是把它丢到一个有难度的项目中去。我们选择了信息流原型,这是早期使用 React Native 构建的项目之一,当时我们还在同时开发 React Native 的基础设施。它的代码后来实际变成了独立 Facebook Groups 应用的基础。

直到 2014 年 7 月,仍然只有少数人在跟进这个项目,这时 React Native 有幸得到了一个大项目:Ads Manager 项目组想开发独立的 iOS应用。但是,他们没有开发 iOS 的经验。这太合适了。接下来是 Ads Manager 产品团队与 React Native 团队几个月的紧密合作。产品工程师们不断打破平台的分界线。目标是第一个完全由 React Native 开发的应用在用户体验上不逊于用 Objective-C 开发的应用。

我们对这项任务的可能行充满自信,随即决定把 React Native 做成跨平台,并在伦敦组建了 Android 团队。其中的三人在 2014 的后半年里编写了大部分核心 Android 运行环境和最初的组件库。我们的目标是在 Android 上运行 Ads Manager 的 iOS 代码,到 2014 年底我们已经跑通了一个基础的版本。虽然它缺少很多视图并且在低端设备上性能表现欠佳,但是你可以看到广告列表了,甚至可以创建一个广告。我们有信心能解决这些问题,于是进一步推进了性能与功能的平衡。

2015年1月,Facebook Ads Manager 的 iOS 基础代码运行在 Android 上。

随即,Ads Manager 的产品工程师与伦敦的 Android 团队紧密配合,开始把他们的 JavaScript 代码向 Android 移植。在开发 Ads Manager 的 iOS 版时,我们的目标不是平台间的代码共享,而是期望这能对使用 React Native 有积极影响。然而当 Andriod 版 Ads Manager 准备发布时,我发现两个应用之间复用了 85% 的代码。

与 iOS 发布类似,我们想尽快得到 Android 版的反馈。为此,我们只开发了核心运行环境和少数视图与模块(Text, Image, ScrollView, Network, AsyncStorage等等)。9月14日,我们在 GitHub 和 npm 上发布了核心的 Android 运行环境和初始 Android 模块集。React Native 0.11 也成为了第一个支持 Android 的版本。自开源起,我们已经添加了与 iOS 对应的如下 Android 模块:Alert, AppState, CameraRoll, Clipboard, Date 与 time pickers, Geolocation, Intent, Modal, NetInfo, Pull to refresh view, Picker, Slider, View Pager, WebView。

不必多言,被 Facebook 以外的团队采用让 React Native 团队的所有人都异常激动。

React Native 从开始到 Android 版发布的里程碑。

快速接纳:一年的学习与成长

React Native 被接纳的程度以及开发者社区成长的速度比我们想象的快得多。

超过 650 人向 React Native 代码库提交了代码。在5800余次的提交中,30% 的贡献者不在 Facebook 工作。2016年2月,外部贡献者的提交首次超过了 50%。大量社区人民对 React Native 贡献代码,我们看到的是平均每月266次的PR(pull request)(每天多达10个)。其中很多是高质量的,并且实现了广泛使用的功能。

React Native 在 GitHub 上每月开放状态 PR 的数量。

起初,PR 的数量使快速和高效的审查变得很困难。寻找每个 PR 的审查者意味着每天大量的人肉工作。为了解决这个问题,我们使用了两个 GitHub 机器人来尽量使每件事自动化。

第一个是提及机器人(mention bot),它负责为每个 PR 寻找正确的审查者。

提及机器人根据责任信息找到每个 PR 的最佳审查者。

我们称之为 fbsource 的庞大 Mercurial 仓库的简单结构。这个仓库包含了我们的移动和后台代码。

合并 PR 的过程通常包含几个人工步骤。我们通过发表一条 GitHub 上的评论简化了这一切。

@facebook-github-bot shipit:如果所有内部测试通过,代码会同时合并到 fbsource 主干和 GitHub 主干。

多亏这些工具,这个项目能够适应大量的 PR。一年里,总共关闭了 2351 个 PR。

每月关闭 PR 的数量。

管理 GitHub 问题

这个项目的流行创造了一种环境,每个人都潜移默化地想帮助我们管理庞大的处于开启状态的问题。

问题机器人能让任何人管理 GitHub 问题,不需要访问权限。

React Native 的 API 涉及面很广。它为 JavaScript 暴漏了大部分 iOS 和 Android 的构建模块,同时增加了跨平台的抽象类。对任何人来说熟悉所有 API 是一个挑战。甚至许多使用 React Native 的 Facebook 产品团队也不能总是在你之前覆盖到所有的边界条件。React Native 在为我们服务,但我们不能独自完善它。这就是为什么拥有一个熟悉底层代码的社区如此重要,不仅对我们,也对其他参与其中的广泛生态圈,他们依赖此成就他们的应用、服务和第三方模块。

社区合作者

React Native 开源合作者是一群在社区中贡献高质量补丁和乐于帮助他人的人们。我们已经为这些帮助我们推进项目的人们授予 React Native 社区合作者称号。这项殊荣附带了仓库的访问权限。

2016年2月22日,我们其中一些成员在旧金山 React.js 大会上:

图中(从左至右):Christopher Dro (React Native Playground), Brent Vatne (Exponent), Jean-Richard Lai (TaskRabbit), Eric Vlad Vicenti (React Native team), Dave Sibiski (React Native Playground), James Ide (Exponent), Martín Bigio (React Native team), Tadeu Zagallo (React Native team), Christopher Chedeau (React Native team), Ken Wheeler (Formidable), Leland Richardson (Airbnb), and Martin Konicek (React Native Team)。

今天的 React Native

React Native 每两周发布一个新版本。这样你就能在代码提交到主干后快速获取最新的属性。2016年3月代码在 npm 上被下载了 70000 次。拥有了 30000 个 star,React Native 在 GitHub 上排名第 21 位。

GitHub star 数量从 0 到 30000 只用了一年。

社区使用 React Native 做了什么

有很多高质量的应用被收录进了博客。查看案例看看我们都收录了哪些。

总之,一年之中发生了很多事情!

React Native 在 Facebook

越来越多的 Facebook 产品团队使用 React Native 来构建新的功能和应用。它被使用在独立的应用中,以及 Facebook 主要应用的 iOS 和 Android 版本。

Facebook Groups 是一个混合模式应用,其中信息流使用了 React Native。

  • 提升性能,如开启时间、响应和滚动性能。请看 和 。
  • 在 iOS 和 Android 平台上,把 UI 与 Facebook 主要应用的基础架构集成。
  • 开发性能工具,如 CPU 和 内存分析。
  • 开发 Facebook 产品团队提出的新功能。
  • 以快速回答问题和修复缺陷的方式支持产品团队。
  • 开发经验积累,比如把内部开发者工具和构建系统集成。

前瞻

在去年这个项目赚足了眼球,而我们在 Facebook 通常这么讲:我们才完成了 1%。我们会在内部持续投入这个项目。经过去年,团队数量已经翻倍。我们也会持续投入开源工具。我们希望 React Native 在 Facebook 内部和外部都是一个成功的项目。

这里有一些参与到项目中的最好方式:

  • 如果你发现了一个 bug,请发起一个修复。带有测试计划的小 PR 会最快得到审查。
  • 如果你发现文档中有不清楚的地方,请以 PR 的方式提出改进。
  • 在 提问和回答。
  • 通过 GitHub 的问题来帮助别人。
  • 如果你提出一个新功能,最好的方式是把它发布到 ,它是一个投票系统。如果你自己没有时间去实现它,它仍然可能通过足够的投票来由他人去实现。
  • 加入 Facebook 的

感谢使用 React Native 创建神奇应用,以及在它基础上构建工具和服务的每个人,你们编写了第三方模块,帮助释疑解惑,提交 PR,组织会议,撰写博客——继续加油吧!

期待明年!