React Native 月度会议仍在蓬勃发展！请务必查看本文底部关于下一次会议的说明。

Expo​

• 祝贺 Devin Abbott 和 Houssein Djirdeh 预发布了 “Full Stack React Native” 书籍！它将引导您通过构建几个小型应用程序来学习 React Native。
• 发布了 reason-react-native-scripts 的第一个（实验性）版本，以帮助人们轻松试用 ReasonML。
• Expo SDK 24 已发布！它使用 React Native 0.51，并包含大量新功能和改进：独立应用中捆绑图片（无需在首次加载时缓存！）、图片处理 API（裁剪、调整大小、旋转、翻转）、人脸检测 API、新的发布渠道功能（为给定渠道设置活动发布和回滚）、用于跟踪独立应用构建的 Web 仪表板，以及修复了 OpenGL Android 实现和 Android 多任务处理器的长期存在的错误，仅举几例。
• 从今年 1 月开始，我们将分配更多资源给 React Navigation。我们坚信，仅使用 React 组件和 Animated 和 react-native-gesture-handler 等基元构建 React Native 导航是可行且可取的，我们对我们计划进行的一些改进感到非常兴奋。如果您希望为社区做出贡献，请查看 react-native-maps 和 react-native-svg，这两个项目都需要一些帮助！

Infinite Red​

• 我们为 Chain React conf 准备了主题演讲嘉宾：Kent C. Dodds 和 Tracy Lee。我们将很快开放 CFP。
• 社区聊天 现在有 1600 人。
• React Native Newsletter 现在有 8500 名订阅者。
• 目前正在研究使 RN 具有抗崩溃性的最佳实践，报告将在稍后发布。
• 添加从 Solidarity 报告的能力。
• 发布了关于在 React Native 和 Android 上发布的 HOW-TO。

Microsoft​

• 已启动 pull request 以将核心 React Native Windows 桥迁移到 .NET Standard，使其有效地与操作系统无关。希望许多其他 .NET Core 平台可以使用自己的线程模型、JavaScript 运行时和 UIManager（例如 JavaScriptCore、Xamarin.Mac、Linux Gtk# 和 Samsung Tizen 选项）扩展该桥。

Wix​

• Detox
  • 为了使我们能够扩展 E2E 测试，我们希望最大限度地减少在 CI 上花费的时间，我们正在开发 Detox 的并行化支持。
  • 提交了一个 pull request 以启用对自定义 flavor 构建的支持，以便更好地支持 E2E 上的模拟。
• DetoxInstruments
  • DetoxInstruments 的杀手级功能被证明是一项非常具有挑战性的任务，在任何给定时间获取 JavaScript 回溯都需要自定义 JSCore 实现来支持 JS 线程挂起。在 Wix 的应用程序上内部测试分析器揭示了关于 JS 线程的有趣见解。
  • 该项目仍然不够稳定，无法供通用用途使用，但正在积极开发中，我们希望很快宣布它。
• React Native Navigation
  • V2 开发速度已大幅提高，到目前为止，我们只有一个开发人员花费 20% 的时间进行开发，而现在我们有 3 个开发人员全职进行开发！
• Android 性能
  • 用最新的版本（webkitGTK 项目的尖端，具有自定义 JIT 配置）替换 RN 中捆绑的旧 JSCore，使 JS 线程的性能提高了 40%。下一步是编译 64 位版本。这项工作基于 Android 的 JSC 构建脚本。在此处关注其当前状态 here。

下一次会议​

有人讨论过重新调整本次会议的用途，以讨论一个单一且特定的主题（例如导航、将 React Native 模块移动到单独的仓库、文档等）。这样，我们觉得我们可以为 React Native 社区做出最好的贡献。这可能会在下一次会议上进行。请随意发推文告诉我们您希望看到哪些主题被涵盖。

React Native 月度会议继续进行！让我们看看我们的团队在做什么。

Callstack​

• 我们一直在开发 React Native CI。最重要的是，我们已从 Travis 迁移到 Circle，为 React Native 留下了一条单一、统一的 CI 管道。
• 我们组织了 Hacktoberfest - React Native 版本，与与会者一起，我们尝试向开源项目提交许多 pull request。
• 我们继续开发 Haul。上个月，我们提交了两个新版本，包括 webpack 3 支持。我们计划添加 CRNA 和 Expo 支持，并致力于改进 HMR。我们的路线图在 issue 跟踪器上公开。如果您想提出改进建议或提供反馈，请告诉我们！

Expo​

• 发布了 Expo SDK 22（使用 React Native 0.49）并更新了 CRNA 以支持它。
  • 包括改进的启动画面 API、基本的 ARKit 支持、“DeviceMotion” API、iOS11 上的 SFAuthenticationSession 支持以及 更多。
• 您的 snacks 现在可以有多个 JavaScript 文件，您可以将图像和其他资源拖放到编辑器中来上传它们。
• 为 react-navigation 贡献代码，以添加对 iPhone X 的支持。
• 在我们使用 Expo 构建大型应用程序时，将注意力集中在粗糙的边缘。例如
  • 一流地支持部署到多个环境：暂存、生产和任意渠道。渠道将支持回滚和为给定渠道设置活动发布。如果您想成为早期测试人员，请在 @expo_io 上告知我们。
  • 我们还在改进我们的独立应用程序构建基础设施，并添加对在独立应用程序构建中捆绑图像和其他非代码资源的支持，同时保持通过无线方式更新资源的能力。

Facebook​

• 更好的 RTL 支持
  • 我们正在引入许多方向感知样式。
    • 位置
      • (left|right) → (start|end)
    • 外边距
      • margin(Left|Right) → margin(Start|End)
    • 内边距
      • padding(Left|Right) → padding(Start|End)
    • 边框
      • borderTop(Left|Right)Radius → borderTop(Start|End)Radius
      • borderBottom(Left|Right)Radius → borderBottom(Start|End)Radius
      • border(Left|Right)Width → border(Start|End)Width
      • border(Left|Right)Color → border(Start|End)Color
  • 在 RTL 中，位置、外边距、内边距和边框样式的 “left” 和 “right” 的含义被交换了。在几个月内，我们将删除此行为，并使 “left” 始终表示 “left”，而 “right” 始终表示 “right”。破坏性更改隐藏在标志下。在您的 React Native 组件中使用 I18nManager.swapLeftAndRightInRTL(false) 来选择加入它们。
• 正在开发 Flow，为我们的内部原生模块添加类型，并使用这些类型在 Java 中生成接口，在 ObjC 中生成协议，原生实现必须实现这些接口和协议。我们希望这种代码生成最早在明年开源。

Infinite Red​

• 用于帮助 React Native 和其他项目的新 OSS 工具。更多信息请访问 此处。
• 正在改进 Ignite 以发布新的样板版本（代号：Bowser）

Shoutem​

• 改进 Shoutem 上的开发流程。我们希望简化从创建应用程序到第一个自定义屏幕的过程，并使其非常容易，从而降低新 React Native 开发人员的门槛。准备了一些研讨会来测试新功能。我们还改进了 Shoutem CLI 以支持新的流程。
• Shoutem UI 收到了一些组件改进和错误修复。我们还检查了与最新 React Native 版本的兼容性。
• Shoutem 平台收到了一些值得注意的更新，新的集成作为 开源扩展项目 的一部分提供。我们非常高兴看到其他开发人员积极开发 Shoutem 扩展。我们积极联系并提供关于他们的扩展的建议和指导。

下一次会议​

下一次会议定于 2017 年 12 月 6 日星期三举行。如果您对我们应如何改进会议的输出有任何建议，请随时在 Twitter 上 ping 我。

React Native 月度会议继续进行！以下是每个团队的笔记

Callstack​

• React Native EU 已经结束。来自 33 个国家/地区的 300 多名参与者访问了弗罗茨瓦夫。可以在 YouTube 上找到演讲视频。
• 会议结束后，我们正在慢慢回到我们的开源计划。值得一提的一件事是，我们正在开发 react-native-opentok 的下一个版本，该版本修复了大多数现有问题。

GeekyAnts​

尝试通过以下方式降低开发人员采用 React Native 的入门门槛

• 在 React Native EU 上发布了 BuilderX.io。BuilderX 是一种设计工具，可直接与 JavaScript 文件（目前仅支持 React Native）一起使用，以生成美观、可读且可编辑的代码。
• 推出了 ReactNativeSeed.com，它为您的下一个 React Native 项目提供了一组样板。它提供了多种选项，包括用于数据类型的 TypeScript 和 Flow，用于状态管理的 MobX、Redux 和 mobx-state-tree，以及作为堆栈的 CRNA 和纯 React-Native。

Expo​

• 将很快发布 SDK 21，它增加了对 react-native 0.48.3 的支持，以及 Expo SDK 中的大量错误修复/可靠性改进/新功能，包括视频录制、新的启动画面 API、对 react-native-gesture-handler 的支持以及改进的错误处理。
• 关于 react-native-gesture-handler，Software Mansion 的 Krzysztof Magiera 继续推进这项工作，我们一直在帮助他进行测试并资助他的一部分开发时间。将其集成到 SDK21 中的 Expo 将使人们可以在 Snack 中轻松使用它，因此我们很高兴看到人们提出什么。
• 关于改进的错误日志记录/处理 - 请参阅 此内部 Expo PR 的 gist 以了解有关日志记录的详细信息（特别是“问题 2”），以及 此提交 以了解处理导入 npm 标准库模块失败的尝试的更改。在这种方式下，React Native 中有很多机会可以改进上游的错误消息，我们将致力于后续的上游 PR。社区参与进来会很棒。
• native.directory 继续增长，您可以从 GitHub 仓库 添加您的项目。
• 访问北美各地的黑客马拉松，包括 PennApps、Hack The North、HackMIT，以及即将到来的 MHacks。

Facebook​

• 致力于改进 Android 上的 <Text> 和 <TextInput> 组件。（<TextInput> 的原生自动增长；深度嵌套的 <Text> 组件布局问题；更好的代码结构；性能优化）。
• 我们仍在寻找额外的贡献者，他们愿意帮助分类问题和 pull request。

Microsoft​

• 发布了 CodePush 的代码签名功能。React Native 开发人员现在能够在 CodePush 中签署他们的应用程序包。公告可以在 此处 找到
• 致力于完成 CodePush 到 Mobile Center 的集成。同时考虑测试/崩溃集成。

下一次会议​

下一次会议定于 2017 年 10 月 10 日星期三举行。由于这只是我们的第四次会议，我们想知道这些笔记如何使 React Native 社区受益。如果您对我们应如何改进会议的输出有任何建议，请随时在 Twitter 上 ping 我。

React Native 月度会议继续进行！本月的会议时间较短，因为我们的大多数团队都在忙于发布。下个月，我们将参加在波兰弗罗茨瓦夫举行的 React Native EU 会议。请务必购买门票，我们在那里与您见面！与此同时，让我们看看我们的团队在做什么。

团队​

在第三次会议上，我们有 5 个团队加入我们

• Callstack
• Expo
• Facebook
• Microsoft
• Shoutem

笔记​

以下是每个团队的笔记

Callstack​

• 最近开源了 react-native-material-palette。它从图像中提取突出的颜色，以帮助您创建具有视觉吸引力的应用程序。目前仅适用于 Android，但我们正在研究将来添加对 iOS 的支持。
• 我们已将 HMR 支持添加到 haul 以及许多其他很棒的东西！查看最新版本。
• React Native EU 2017 即将到来！下个月的主题是 React Native 和波兰！请务必在此处购买最后剩余的门票 here。

Expo​

• 发布了在 Snack 上安装 npm 包的支持。通常的 Expo 限制适用 - 包不能依赖于 Expo 中尚未包含的自定义原生 API。我们还在开发在 Snack 中支持多个文件和上传资源的功能。Satyajit 将在 React Native Europe 上谈论 Snack。
• 发布了 SDK20，其中包含摄像头、支付、安全存储、磁力计、暂停/恢复 fs 下载以及改进的启动/加载屏幕。
• 继续与 Krzysztof 合作开发 react-native-gesture-handler。请尝试一下，重建一些您以前使用 PanResponder 或原生手势识别器构建的手势，并告知我们您遇到的问题。
• 正在试验 JSC 调试协议，并在 Canny 上处理大量功能请求。

Facebook​

• 上个月我们讨论了 GitHub issue 跟踪器的管理，我们将尝试进行改进以解决项目的可维护性问题。
• 目前，未解决 issue 的数量稳定在 600 个左右，并且似乎可能会在一段时间内保持这种状态。在过去一个月中，由于缺少活动（定义为过去 60 天内没有评论），我们关闭了 690 个 issue。在这些 690 个 issue 中，有 58 个因各种原因重新打开（维护人员承诺提供修复，或者贡献者提出了保持 issue 打开的充分理由）。
• 我们计划在可预见的未来继续自动关闭过时的 issue。我们希望达到这样一种状态：跟踪器中打开的每个有影响力的 issue 都能得到处理，但我们尚未达到这种状态。我们需要维护人员提供所有可能的帮助来分类 issue，并确保我们不会错过引入回归或引入破坏性更改的 issue，尤其是那些影响新创建项目的问题。有兴趣提供帮助的人员可以使用 Facebook GitHub Bot 来分类 issue 和 pull request。新的维护人员指南包含有关分类和 GitHub Bot 使用的更多信息。请将自己添加到 issue 任务组，并鼓励其他活跃的社区成员也这样做！

Microsoft​

• 新的 Skype 应用程序基于 React Native 构建，以便于在平台之间尽可能多地共享代码。基于 React Native 的 Skype 应用程序目前在 Android 和 iOS 应用商店中可用。
• 在基于 React Native 构建 Skype 应用程序时，我们会向 React Native 发送 pull request，以解决我们遇到的错误和缺少的功能。到目前为止，我们已经合并了大约 70 个 pull request。
• React Native 使我们能够从同一代码库为 Android 和 iOS Skype 应用程序提供支持。我们也希望使用该代码库为 Skype Web 应用程序提供支持。为了帮助我们实现这一目标，我们在 React/React Native 之上构建并开源了一个薄层，称为 ReactXP。ReactXP 提供了一组跨平台组件，当以 iOS/Android 为目标时，这些组件会映射到 React Native，而当以 Web 为目标时，则会映射到 react-dom。ReactXP 的目标与另一个名为 React Native for Web 的开源库类似。在 ReactXP FAQ 中简要描述了这些库的方法有何不同。

Shoutem​

• 我们正在继续努力改进和简化使用 Shoutem 构建应用程序时的开发人员体验。
• 开始将我们所有的应用程序迁移到 react-navigation，但是我们最终将其推迟到更稳定的版本发布，或者其中一种原生导航解决方案变得稳定为止。
• 将我们所有的 扩展 和我们的大多数开源库（animation、theme、ui）更新到 React Native 0.47.1。

下一次会议​

下一次会议定于 2017 年 9 月 13 日星期三举行。由于这只是我们的第三次会议，我们想知道这些笔记如何使 React Native 社区受益。如果您对我们应如何改进会议的输出有任何建议，请随时在 Twitter 上 ping 我。

React Native 在 Facebook 系列的多个应用程序中的多个位置使用，包括主 Facebook 应用程序中的顶级选项卡。我们这篇文章的重点是一个非常引人注目的产品，Marketplace。它在十几个左右的国家/地区可用，使用户可以发现其他用户提供的产品和服务。

在 2017 年上半年，通过 Relay 团队、Marketplace 团队、Mobile JS Platform 团队和 React Native 团队的共同努力，我们将 Android Year Class 2010-11 设备 的 Marketplace 交互时间 (TTI) 缩短了一半。Facebook 历来将这些设备视为低端 Android 设备，并且它们在任何平台或设备类型上都具有最慢的 TTI。

典型的 React Native 启动看起来像这样

免责声明：比例不具代表性，并且会因 React Native 的配置和使用方式而异。

我们首先初始化 React Native 核心（也称为 “Bridge”），然后再运行产品特定的 JavaScript，该 JavaScript 确定 React Native 将在原生处理时间中呈现哪些原生视图。

不同的方法​

我们早期犯下的错误之一是让 Systrace 和 CTScan 驱动我们的性能工作。这些工具帮助我们在 2016 年找到了许多唾手可得的成果，但我们发现 Systrace 和 CTScan 都不能代表生产场景，也无法模拟野外发生的事情。分解中花费的时间比率通常是不正确的，有时甚至会严重偏离。在极端情况下，我们期望花费几毫秒的事情实际上花费了数百或数千毫秒。尽管如此，CTScan 仍然很有用，我们发现它可以捕获三分之一的回归，然后它们才会影响生产。

在 Android 上，我们将这些工具的缺点归因于以下事实：1) React Native 是一个多线程框架，2) Marketplace 与大量复杂视图（例如 Newsfeed 和其他顶级选项卡）位于同一位置，以及 3) 计算时间差异很大。因此，在这半年中，我们让生产测量和分解驱动了我们几乎所有的决策和优先级排序。

生产工具化的道路​

表面上看，生产工具化可能听起来很简单，但事实证明这是一个非常复杂的过程。它花费了多个迭代周期，每个周期为 2-3 周；由于在 master 中提交代码、将应用程序推送到 Play 商店以及收集足够的生产样本以对我们的工作充满信心都存在延迟。每个迭代周期都涉及发现我们的分解是否准确、是否具有正确的粒度级别以及它们是否正确地加起来构成整个时间跨度。我们无法依赖 alpha 和 beta 版本，因为它们不能代表普通人群。从本质上讲，我们非常乏味地构建了一个非常准确的生产跟踪，该跟踪基于数百万个样本的聚合。

我们一丝不苟地验证了每次崩溃的每毫秒都正确地累加到其父指标中，原因之一是我们很早就意识到我们的工具存在差距。事实证明，我们最初的崩溃分析没有考虑到线程跳转造成的停顿。线程跳转本身并不昂贵，但是跳转到已经在工作的繁忙线程则非常昂贵。我们最终通过在正确的时刻加入 Thread.sleep() 调用在本地重现了这些阻塞，并通过以下方式成功修复了它们：

1. 移除我们对 AsyncTask 的依赖，
2. 撤销在 UI 线程上强制初始化 ReactContext 和 NativeModules，以及
3. 移除在初始化时测量 ReactRootView 的依赖。

总而言之，移除这些线程阻塞问题将启动时间缩短了 25% 以上。

生产指标也挑战了我们之前的一些假设。例如，我们过去常常在启动路径上预加载许多 JavaScript 模块，认为将模块共置在一个捆绑包中会降低它们的初始化成本。然而，预加载和共置这些模块的成本远远超过了收益。通过重新配置我们的内联 require 黑名单并从启动路径中移除 JavaScript 模块，我们能够避免加载不必要的模块，例如 Relay Classic（而实际上只需要 Relay Modern）。如今，我们的 RUN_JS_BUNDLE 分解速度提高了 75% 以上。

我们还通过调查特定于产品的原生模块发现了优势。例如，通过延迟注入原生模块的依赖项，我们将该原生模块的成本降低了 98%。通过消除 Marketplace 启动与其他产品的竞争，我们将启动时间缩短了相同的间隔。

最棒的是，这些改进中的许多都广泛适用于使用 React Native 构建的所有屏幕。

结论​

人们认为 React Native 启动性能问题是由 JavaScript 速度慢或网络时间过高引起的。虽然加速 JavaScript 等方面会使 TTI 降低相当大的幅度，但与之前认为的相比，这些因素对 TTI 的贡献百分比要小得多。

到目前为止的教训是：测量，测量，再测量！ 一些改进来自于将运行时成本转移到构建时，例如 Relay Modern 和 Lazy NativeModules。另一些改进来自于通过更智能地并行化代码或移除死代码来避免工作。还有一些改进来自于 React Native 的大型架构变更，例如清理线程阻塞。性能没有万能的解决方案，而长期的性能提升将来自于增量式的工具和改进。不要让认知偏差影响您的决策。相反，请仔细收集和解释生产数据，以指导未来的工作。

未来计划​

从长远来看，我们希望 Marketplace TTI 能够与使用 Native 构建的类似产品相媲美，并且总体而言，React Native 的性能能够与原生性能相提并论。此外，尽管我们在上半年的工作中将桥接启动成本大幅降低了约 80%，但我们计划通过 Prepack 等项目和更多的构建时处理，将 React Native 桥接的成本降至接近于零。

React Native 每月例会继续进行！在本次会议上，我们邀请了 Infinite Red，Chain React, the React Native Conference 背后的杰出团队。由于这里的大多数人都在 Chain React 上发表演讲，我们将会议推迟了一周。会议的演讲视频已发布到网上，我鼓励您去看看。那么，让我们看看我们的团队在忙些什么。

团队​

在第二次会议上，共有 9 个团队加入我们

• Airbnb
• Callstack
• Expo
• Facebook
• GeekyAnts
• Infinite Red
• Microsoft
• Shoutem
• Wix

笔记​

以下是每个团队的笔记

Airbnb​

• 请查看 Airbnb 仓库 以了解 React Native 相关项目。

Callstack​

• Mike Grabowski 一如既往地管理着 React Native 的每月发布，包括一些已发布的 beta 版本。特别是在努力发布 v0.43.5 版本到 npm，因为它将解除 Windows 用户的障碍！
• 关于 Haul 的缓慢但持续的工作正在进行中。有一个 pull request 添加了 HMR，并且其他改进也已发布。最近，一些行业领导者开始采用它。可能计划在该领域开始全职有偿工作。
• 来自 Jest 团队的 Michał Pierzchała 本月加入了 Callstack。他将帮助维护 Haul，并可能参与 Metro Bundler 和 Jest 的工作。
• Satyajit Sahoo 现在加入了我们，太棒了！
• 我们的 OSS 部门即将推出许多很酷的东西。特别是，正在努力将 Material Palette API 引入 React Native。计划最终发布我们的原生 iOS 工具包，旨在提供与原生组件 1:1 的外观和感觉。

Expo​

• 最近推出了 Native Directory，以帮助发现和评估 React Native 生态系统中的库。问题：库太多，难以测试，需要手动应用启发式方法，并且无法立即清楚哪些是您应该使用的最佳库。也很难知道某些东西是否与 CRNA/Expo 兼容。因此，Native Directory 试图解决这些问题。快去看看并添加您的库到其中。库列表在这里。这只是我们的第一次尝试，我们希望它由社区拥有和运营，而不仅仅是 Expo 团队。因此，如果您认为这有价值并想让它变得更好，请加入进来！
• 在 Snack 中为 Expo SDK 19 添加了安装 npm 包的初始支持。如果您在使用过程中遇到任何问题，请告诉我们，我们仍在解决一些错误。与 Native Directory 一起，这应该可以轻松测试仅具有 JS 依赖项或包含在 Expo SDK 中的依赖项的库。试试看
  • react-native-modal
  • react-native-animatable
  • react-native-calendars
• 发布了 Expo SDK19，在各个方面都进行了一系列改进，并且我们现在正在使用更新后的 Android JSC。
• 正在与 Alexander Kotliarskyi 一起编写文档中的指南，其中包含有关如何改善您的应用程序用户体验的技巧列表。请加入并添加到列表中或帮助撰写其中一些内容！
  • 问题：#14979
  • 初始 pull request：#14993
• 继续致力于：音频/视频、相机、手势（与 Software Mansion 合作，react-native-gesture-handler）、GL 相机集成，并希望在 SDK20（8 月）中首次实现其中一些功能，并在那时对其他功能进行重大改进。我们才刚刚开始在 Expo 客户端中构建用于后台工作的基础设施（地理定位、音频、处理通知等）。
• Adam Miskiewicz 在模仿 UINavigationController 在 react-navigation 中的过渡效果方面取得了一些不错的进展。请查看 他的推文 中早期版本的演示 - 即将发布。另请查看他 上游 的 MaskedViewIOS。如果您有技能和意愿为 Android 实现 MaskedView，那将非常棒！

Facebook​

• Facebook 内部正在探索在 React Native 中嵌入原生 ComponentKit 和 Litho 组件的可能性。
• 非常欢迎为 React Native 做出贡献！如果您想知道如何贡献，“如何贡献”指南 介绍了我们的开发流程，并列出了发送您的第一个 pull request 的步骤。还有其他无需编写代码的贡献方式，例如通过分类问题或更新文档。
  • 在撰写本文时，React Native 有 635 个 未解决的问题 和 249 个 未解决的 pull request。这对我们的维护者来说压力巨大，并且当内部修复问题时，很难确保相关任务得到更新。
  • 我们不确定在保持社区满意度的同时，处理这种情况的最佳方法是什么。一些（但不是全部！）选项包括关闭过时的问题、给予更多人管理问题的权限以及自动关闭不遵循问题模板的问题。我们编写了“维护者期望”指南以设定期望并避免意外。如果您对如何改善维护者的体验以及确保提出问题和 pull request 的人感到被倾听和重视有任何想法，请告诉我们！

GeekyAnts​

• 我们在 Chain React 上演示了 Designer Tool，它可以与 React Native 文件一起使用。许多与会者注册了等候名单。
• 我们还在研究其他跨平台解决方案，例如 Google Flutter（即将进行重大比较）、Kotlin Native 和 Apache Weex，以了解架构差异，以及我们可以从中学习什么来提高 React Native 的整体性能。
• 我们的大多数应用程序都切换到 react-navigation，这提高了整体性能。
• 此外，还发布了 NativeBase Market - 一个面向 React Native 组件和应用程序的市场（面向开发者和由开发者运营）。

Infinite Red​

• 我们想介绍一下 Reactotron。请观看介绍视频。我们很快将添加更多功能！
• 组织了 Chain React 会议。会议非常棒，感谢大家的到来！视频现已上线！

Microsoft​

• CodePush 现已集成到 Mobile Center 中。现有用户的工作流程不会发生任何变化。
  • 有些人报告了一个应用程序重复的问题 - 他们已经在 Mobile Center 上有一个应用程序。我们正在努力解决这些问题，但如果您有两个应用程序，请告知我们，我们可以为您合并它们。
• Mobile Center 现在支持 CodePush 的推送通知。我们还展示了如何将通知和 CodePush 结合使用来进行 A/B 测试应用程序 - 这是 ReactNative 架构独有的功能。
• VS Code 在 ReactNative 中存在一个已知的调试问题 - 几天后发布的扩展程序的下一个版本将修复该问题。
• 由于 Microsoft 内部还有许多其他团队也在从事 React Native 的工作，我们将努力在下次会议上获得所有小组的更好代表。

Shoutem​

• 完成了在 Shoutem 上简化 React Native 开发的过程。在 Shoutem 上开发应用程序时，您可以使用所有标准的 react-native 命令。
• 我们做了很多工作，试图找出在 React Native 上进行性能分析的最佳方法。大部分 文档 已过时，我们将尽最大努力在官方文档上创建 pull request，或者至少在博客文章中写下我们的一些结论。
• 将我们的导航解决方案切换到 react-navigation，因此我们可能很快会收到一些反馈。
• 我们在我们的工具包中发布了 一个新的 HTML 组件，该组件将原始 HTML 转换为 React Native 组件树。

Wix​

• 我们开始致力于向 Metro Bundler 提交 pull request，其中包含 react-native-repackager 功能。我们更新了 react-native-repackager 以支持 RN 44（我们在生产中使用）。我们将其用于 detox 的模拟基础设施。
• 在过去的三个星期里，我们一直在 detox 测试中覆盖 Wix 应用程序。这是关于如何在如此大规模的应用程序（超过 40 名工程师）中减少手动 QA 的惊人学习体验。我们因此解决了 detox 的几个问题，刚刚发布了一个新版本。我很高兴地报告，我们正在履行“零不稳定策略”，并且到目前为止，测试一直稳定通过。
• Detox for Android 正在顺利推进。我们得到了社区的大力帮助。我们预计在两周左右的时间内推出初始版本。
• DetoxInstruments，我们的性能测试工具，正在变得比我们最初预期的要大一些。我们现在计划将其转变为一个独立的工具，它不会与 detox 紧密耦合。它将允许调查 iOS 应用程序的总体性能。它还将与 detox 集成，以便我们可以对性能指标运行自动化测试。

下一次会议​

下次会议定于 2017 年 8 月 16 日举行。由于这只是我们的第二次会议，我们想知道这些笔记对 React Native 社区有何好处。如果您对我们应该如何改进会议的输出有任何建议，请随时在 Twitter 上 ping 我。

在 Shoutem，我们很幸运能够从 React Native 的最初阶段就开始与其合作。我们从一开始就决定成为这个令人惊叹的社区的一份子。很快，我们意识到几乎不可能跟上社区发展和改进的步伐。这就是为什么我们决定组织一次每月例会，让所有主要的 React Native 贡献者可以简要介绍他们的工作和计划。

每月例会​

我们在 2017 年 6 月 14 日举行了第一次每月例会。React Native Monthly 的使命简单而直接：改进 React Native 社区。展示团队的工作有助于促进团队之间的线下协作。

团队​

在第一次会议上，共有 8 个团队加入我们

• Airbnb
• Callstack
• Expo
• Facebook
• GeekyAnts
• Microsoft
• Shoutem
• Wix

我们希望有更多核心贡献者加入即将到来的会议！

笔记​

由于团队的计划可能对更广泛的受众感兴趣，我们将在这里，在 React Native 博客上分享它们。所以，它们来了

Airbnb​

• 计划向 View 和 AccessibilityInfo 原生模块添加一些 A11y（辅助功能）API。
• 将调查在 Android 上的原生模块中添加一些 API，以允许为它们指定运行线程。
• 一直在调查潜在的初始化性能改进。
• 一直在调查一些更复杂的捆绑策略，以在“unbundle”之上使用。

Callstack​

• 正在研究通过使用 Detox 进行 E2E 测试来改进发布流程。Pull request 应该很快就会提交。
• 他们一直在处理的 Blob pull request 已被合并，后续的 pull request 即将到来。
• 在内部项目中增加 Haul 的采用率，以了解其与 Metro Bundler 相比的性能。正在与 webpack 团队合作开发更好的多线程性能。
• 在内部，他们已经实施了更好的基础设施来管理开源项目。计划在未来几周内发布更多内容。
• React Native Europe 会议即将到来，目前还没有什么有趣的消息，但欢迎大家参加！
• 暂时退出了 react-navigation 一段时间，以调查替代方案（尤其是原生导航）。

Expo​

• 正在努力使在 Snack 中安装 npm 模块成为可能，这将有助于库作者在文档中添加示例。
• 正在与 Krzysztof 和 Software Mansion 的其他人合作，进行 Android 上的 JSC 更新和手势处理库的开发。
• Adam Miskiewicz 正在将其重心转向 react-navigation。
• Create React Native App 已在文档的入门指南中。Expo 希望鼓励库作者清楚地说明他们的库是否与 CRNA 兼容，如果兼容，请说明如何设置它。

Facebook​

• React Native 的打包器现在是 Metro Bundler，在一个独立的仓库中。伦敦的 Metro Bundler 团队很高兴能够满足社区的需求，提高模块化以适应 React Native 之外的其他用例，并提高对问题和 PR 的响应速度。
• 在未来几个月内，React Native 团队将致力于改进原始组件的 API。预计在布局怪癖、辅助功能和 Flow 类型方面会有所改进。
• React Native 团队还计划在今年提高核心模块化，通过重构以完全支持 Windows 和 macOS 等第三方平台。

GeekyAnts​

• 该团队正在开发一个 UI/UX 设计应用程序（代号：Builder），该应用程序直接与 .js 文件一起工作。目前，它仅支持 React Native。它类似于 Adobe XD 和 Sketch。
• 该团队正在努力使您可以在编辑器中加载现有的 React Native 应用程序，进行更改（可视化地，作为设计师），并将更改直接保存到 JS 文件中。
• 人们正在努力弥合设计师和开发者之间的差距，并将他们放在同一个仓库中。
• 此外，NativeBase 最近达到了 5,000 个 GitHub star。

Microsoft​

• CodePush 现已集成到 Mobile Center 中。这是提供与分发、分析和其他服务更集成体验的第一步。请参阅他们的公告 此处。
• VS Code 在调试方面存在一个 bug，他们正在努力修复该 bug，并将发布新的构建版本。
• 正在调查 Detox 用于集成测试，正在查看 JSC Context 以获取崩溃报告旁边的变量。

Shoutem​

• 使使用 React Native 社区的工具在 Shoutem 应用程序上工作变得更容易。您将能够使用所有 React Native 命令来运行在 Shoutem 上创建的应用程序。
• 正在调查 React Native 的性能分析工具。他们在设置方面遇到了很多问题，他们将写下他们在此过程中发现的一些见解。
• Shoutem 正在努力使 React Native 更容易与现有的原生应用程序集成。他们将记录他们在公司内部开发的概念，以便获得社区的反馈。

Wix​

• 正在内部采用 Detox，以便将 Wix 应用程序的很大一部分转移到“零手动 QA”。因此，Detox 正在被数十名开发人员在生产环境中大量使用，并且正在迅速成熟。
• 正在努力为 Metro Bundler 添加支持，以便在构建期间覆盖任何文件扩展名。它不仅支持“ios”和“android”，还支持任何自定义扩展名，例如“e2e”或“detox”。计划将其用于 E2E 模拟。已经有一个名为 react-native-repackager 的库，现在正在开发 PR。
• 正在调查性能测试的自动化。这是一个名为 DetoxInstruments 的新仓库。您可以查看一下，它是开源开发的。
• 正在与来自 KPN 的贡献者合作开发 Detox for Android 并支持真机。
• 正在考虑将“Detox 作为平台”，以允许构建其他需要自动化模拟器/设备的工具。一个例子是 Storybook for React Native 或 Ram 关于集成测试的想法。

下一次会议​

会议将每四周举行一次。下次会议定于 2017 年 7 月 12 日举行。由于我们刚刚开始这次会议，我们想知道这些笔记对 React Native 社区有何好处。如果您对我们应该在后续会议中涵盖哪些内容，或者我们应该如何改进会议的输出有任何建议，请随时在 Twitter 上 ping 我。

在我们在社区群组中发布预告公告后，你们中的许多人已经开始试用我们的一些新列表组件，但我们今天正式宣布它们！不再有 ListView 或 DataSource、陈旧的行、被忽略的错误或过多的内存消耗 - 使用最新的 React Native 2017 年 3 月候选版本 (0.43-rc.1)，您可以从新的组件套件中选择最适合您用例的组件，开箱即用地获得出色的性能和功能集

<FlatList>​

这是用于简单、高性能列表的主力组件。提供一个数据数组和一个 renderItem 函数，您就可以开始了

<FlatList
  data={[{title: 'Title Text', key: 'item1'}, ...]}
  renderItem={({item}) => <ListItem title={item.title} />}
/>

<SectionList>​

如果您想渲染一组分为逻辑部分的数据，可能带有节标题（例如，在按字母顺序排列的地址簿中），并且可能具有异构数据和渲染（例如，包含一些按钮的个人资料视图，然后是作曲器，然后是照片网格，然后是朋友网格，最后是故事列表），那么这是最佳选择。

<SectionList
  renderItem={({item}) => <ListItem title={item.title} />}
  renderSectionHeader={({section}) => <H1 title={section.key} />}
  sections={[ // homogeneous rendering between sections
    {data: [...], key: ...},
    {data: [...], key: ...},
    {data: [...], key: ...},
  ]}
/>

<SectionList
  sections={[ // heterogeneous rendering between sections
    {data: [...], key: ..., renderItem: ...},
    {data: [...], key: ..., renderItem: ...},
    {data: [...], key: ..., renderItem: ...},
  ]}
/>

<VirtualizedList>​

幕后实现，具有更灵活的 API。如果您的数据不是纯数组（例如，不可变列表），则尤其方便。

功能​

列表在许多上下文中使用，因此我们在新组件中 packed 了大量功能，以开箱即用地处理大多数用例

• 滚动加载 (onEndReached)。
• 下拉刷新 (onRefresh / refreshing)。
• 可配置的 可见性 (VPV) 回调 (onViewableItemsChanged / viewabilityConfig)。
• 水平模式 (horizontal)。
• 智能的项目和节分隔符。
• 多列支持 (numColumns)
• scrollToEnd、scrollToIndex 和 scrollToItem
• 更好的 Flow 类型。

一些注意事项​

• 当内容滚动出渲染窗口时，项目子树的内部状态不会保留。确保您的所有数据都捕获在项目数据或外部存储（如 Flux、Redux 或 Relay）中。

• 这些组件基于 PureComponent，这意味着如果 props 保持浅相等，它们将不会重新渲染。确保您的 renderItem 函数直接依赖的所有内容都作为 prop 传递，该 prop 在更新后不是 ===，否则您的 UI 可能不会在更改时更新。这包括 data prop 和父组件状态。例如

  <FlatList
    data={this.state.data}
    renderItem={({item}) => (
      <MyItem
        item={item}
        onPress={() =>
          this.setState(oldState => ({
            selected: {
              // New instance breaks `===`
              ...oldState.selected, // copy old data
              [item.key]: !oldState.selected[item.key], // toggle
            },
          }))
        }
        selected={
          !!this.state.selected[item.key] // renderItem depends on state
        }
      />
    )}
    selected={
      // Can be any prop that doesn't collide with existing props
      this.state.selected // A change to selected should re-render FlatList
    }
  />
  

• 为了限制内存并实现平滑滚动，内容在屏幕外异步渲染。这意味着滚动速度可能快于填充速度，并且会短暂地看到空白内容。这是一种权衡，可以进行调整以适应每个应用程序的需求，我们正在幕后努力改进它。

• 默认情况下，这些新列表会在每个项目上查找 key prop，并将其用于 React 键。或者，您可以提供自定义的 keyExtractor prop。

性能​

除了简化 API 之外，新的列表组件还具有显着的性能增强，主要的一点是对于任何数量的行，内存使用量几乎恒定。这是通过“虚拟化”渲染窗口外部的元素来实现的，方法是将它们完全从组件层次结构中卸载，并回收 React 组件中的 JS 内存，以及来自阴影树和 UI 视图的本机内存。这样做有一个缺点，即内部组件状态将不会保留，因此请确保您在组件本身之外跟踪任何重要状态，例如在 Relay 或 Redux 或 Flux 存储中。

限制渲染窗口还减少了 React 和本机平台需要完成的工作量，例如来自视图遍历的工作量。即使您正在渲染一百万个元素中的最后一个，使用这些新列表也无需遍历所有这些元素即可进行渲染。您甚至可以使用 scrollToIndex 跳转到中间位置，而无需进行过多的渲染。

我们还在调度方面进行了一些改进，这应该有助于应用程序的响应能力。渲染窗口边缘的项目会以较低的优先级在任何活动手势或动画或其他交互完成后不频繁地渲染。

高级用法​

与 ListView 不同，渲染窗口中的所有项目在任何 props 更改时都会重新渲染。通常这没问题，因为窗口化将项目数量减少到恒定数量，但是如果您的项目比较复杂，您应该确保遵循 React 性能最佳实践，并在您的组件中适当使用 React.PureComponent 和/或 shouldComponentUpdate 来限制递归子树的重新渲染。

如果您可以在不渲染行的情况下计算出行的高度，则可以通过提供 getItemLayout prop 来改善用户体验。这使得使用例如 scrollToIndex 滚动到特定项目时更加流畅，并且将改善滚动指示器 UI，因为可以在不渲染内容的情况下确定内容的高度。

如果您有其他数据类型（例如，不可变列表），则 <VirtualizedList> 是最佳选择。它接受一个 getItem prop，使您可以返回任何给定索引的项目数据，并具有更宽松的 flow 类型。

如果您有不常见的用例，还可以调整许多参数。例如，您可以使用 windowSize 来权衡内存使用量和用户体验，使用 maxToRenderPerBatch 来调整填充率和响应速度，使用 onEndReachedThreshold 来控制滚动加载的发生时机，以及更多。

未来工作​

• 现有表面的迁移（最终将弃用 ListView）。
• 更多功能，只要我们看到/听到需求（请告诉我们！）。
• 粘性 section header 支持。
• 更多性能优化。
• 支持带有状态的功能项组件。

在 Facebook，我们经常需要访问使用 GraphQL 获取的数据结构中深度嵌套的值。在访问这些深度嵌套值的过程中，一个或多个中间字段通常是可为空的。这些中间字段可能为空的原因有很多，从隐私检查失败到仅仅因为 null 恰好是表示非致命错误的最灵活方式。

不幸的是，访问这些深度嵌套的值目前既繁琐又冗长。

props.user &&
  props.user.friends &&
  props.user.friends[0] &&
  props.user.friends[0].friends;

有一个 ECMAScript 提案，旨在引入存在运算符，这将使这更加方便。但在该提案最终确定之前，我们希望找到一种解决方案，可以提高我们的生活质量，保持现有的语言语义，并鼓励使用 Flow 的类型安全。

我们提出了一个名为 idx 的存在函数。

idx(props, _ => _.user.friends[0].friends);

此代码片段中的调用行为类似于上面代码片段中的布尔表达式，但重复性大大降低。idx 函数正好接受两个参数

• 任何值，通常是您想要访问嵌套值的对象或数组。
• 一个函数，它接收第一个参数并访问其上的嵌套值。

理论上，idx 函数将尝试捕获由访问 null 或 undefined 上的属性而导致的错误。如果捕获到此类错误，它将返回 null 或 undefined。（您可以在 idx.js 中看到这可能是如何实现的。）

在实践中，每次嵌套属性访问都进行 try-catch 操作很慢，并且区分特定类型的 TypeError 很脆弱。为了解决这些缺点，我们创建了一个 Babel 插件，将上面的 idx 调用转换为以下表达式

props.user == null
  ? props.user
  : props.user.friends == null
    ? props.user.friends
    : props.user.friends[0] == null
      ? props.user.friends[0]
      : props.user.friends[0].friends;

最后，我们为 idx 添加了一个自定义 Flow 类型声明，允许在第二个参数中进行遍历时进行正确的类型检查，同时允许在可为空的属性上进行嵌套访问。

该函数、Babel 插件和 Flow 声明现在已在 GitHub 上提供。它们通过安装 idx 和 babel-plugin-idx npm 包，并将 “idx” 添加到您的 .babelrc 文件中的插件列表中来使用。

今天我们宣布 Create React Native App：一个使 React Native 项目入门更加容易的新工具！它深受 Create React App 设计的启发，是 Facebook 和 Expo（前身为 Exponent）合作的产物。

许多开发人员在安装和配置 React Native 当前的原生构建依赖项时遇到困难，尤其是对于 Android。使用 Create React Native App，无需使用 Xcode 或 Android Studio，您可以使用 Linux 或 Windows 为您的 iOS 设备进行开发。这是通过使用 Expo 应用程序实现的，该应用程序加载并运行用纯 JavaScript 编写的 CRNA 项目，而无需编译任何原生代码。

尝试创建一个新项目（如果您已安装 yarn，请替换为合适的 yarn 命令）

$ npm i -g create-react-native-app
$ create-react-native-app my-project
$ cd my-project
$ npm start

这将启动 React Native 打包器并打印一个二维码。在 Expo 应用程序中打开它以加载您的 JavaScript。对 console.log 的调用将转发到您的终端。您可以利用任何标准的 React Native API 以及 Expo SDK。

原生代码呢？​

许多 React Native 项目都有需要编译的 Java 或 Objective-C/Swift 依赖项。Expo 应用程序确实包含用于相机、视频、联系人等的 API，并捆绑了流行的库，如 Airbnb 的 react-native-maps，或 Facebook 身份验证。但是，如果您需要 Expo 未捆绑的原生代码依赖项，那么您可能需要拥有自己的构建配置。就像 Create React App 一样，CRNA 支持“弹出 (ejecting)”。

您可以运行 npm run eject 来获得一个与 react-native init 生成的项目非常相似的项目。那时，您将需要 Xcode 和/或 Android Studio，就像您从 react-native init 开始一样，使用 react-native link 添加库将起作用，并且您将完全控制原生代码编译过程。

有问题？反馈？​

Create React Native App 现在已经足够稳定，可以普遍使用，这意味着我们非常渴望听到您使用它的体验！您可以在 Twitter 上找到我，或者在 GitHub 存储库上打开一个 issue。非常欢迎 Pull Request！