React Native 的目标是为您提供最佳的开发者体验。其中很大一部分是您保存文件到看到更改之间所需的时间。我们的目标是使这个反馈循环保持在 1 秒以内，即使您的应用不断增长。

我们通过三个主要功能接近了这个理想

• 使用 JavaScript 作为语言，它没有漫长的编译周期时间。
• 实现一个名为 Packager 的工具，将 es6/flow/jsx 文件转换为 VM 可以理解的普通 JavaScript。它被设计为服务器，将中间状态保存在内存中以实现快速增量更改，并使用多核。
• 构建一个名为 Live Reload 的功能，在保存时重新加载应用。

此时，开发人员的瓶颈不再是重新加载应用所需的时间，而是丢失应用的状态。一个常见的场景是开发一个距离启动屏幕多个屏幕的功能。每次重新加载时，您都必须一次又一次地点击相同的路径才能回到您的功能，使周期变为几秒钟。

热重载​

热重载背后的想法是保持应用运行，并在运行时注入您编辑的文件的新版本。这样，您就不会丢失任何状态，这在您调整 UI 时尤其有用。

一图胜千言。查看 Live Reload（当前）和 Hot Reload（新）之间的区别。

如果您仔细观察，您会注意到可以从红色错误框中恢复，并且您还可以开始导入以前不存在的模块，而无需进行完全重新加载。

警告：由于 JavaScript 是一种非常有状态的语言，因此热重载无法完美实现。在实践中，我们发现当前的设置在大量常用用例中运行良好，并且在出现问题时始终可以使用完全重新加载。

热重载从 0.22 版本开始可用，您可以启用它

• 打开开发者菜单
• 点击“启用热重载”

简而言之的实现​

现在我们已经了解了我们为什么需要它以及如何使用它，有趣的部分开始了：它实际上是如何工作的。

热重载构建在 热模块替换 或 HMR 功能之上。它最初由 webpack 引入，我们在 React Native Packager 内部实现了它。HMR 使 Packager 监视文件更改并将 HMR 更新发送到应用中包含的精简 HMR 运行时。

简而言之，HMR 更新包含已更改的 JS 模块的新代码。当运行时接收到它们时，它会将旧模块的代码替换为新代码

HMR 更新包含的内容不仅仅是我们想要更改的模块的代码，因为仅仅替换它不足以让运行时接收更改。问题是模块系统可能已经缓存了我们想要更新的模块的导出。例如，假设您的应用由以下两个模块组成

// log.js
function log(message) {
  const time = require('./time');
  console.log(`[${time()}] ${message}`);
}

module.exports = log;

// time.js
function time() {
  return new Date().getTime();
}

module.exports = time;

模块 log 打印出提供的消息，包括模块 time 提供的当前日期。

当应用被捆绑时，React Native 使用 __d 函数在模块系统上注册每个模块。对于这个应用，在许多 __d 定义中，将有一个用于 log

__d('log', function() {
  ... // module's code
});

此调用将每个模块的代码包装到一个匿名函数中，我们通常将其称为工厂函数。模块系统运行时跟踪每个模块的工厂函数，无论它是否已被执行，以及执行结果（导出）。当需要模块时，模块系统要么提供已经缓存的导出，要么首次执行模块的工厂函数并保存结果。

假设您启动您的应用并 require log。此时，log 和 time 的工厂函数都尚未执行，因此没有缓存任何导出。然后，用户修改 time 以 MM/DD 格式返回日期

// time.js
function bar() {
  const date = new Date();
  return `${date.getMonth() + 1}/${date.getDate()}`;
}

module.exports = bar;

Packager 会将 time 的新代码发送到运行时（步骤 1），当最终需要 log 时，导出的函数将被执行，它将使用 time 的更改来执行（步骤 2）

现在假设 log 的代码在顶层 require time

const time = require('./time'); // top level require

// log.js
function log(message) {
  console.log(`[${time()}] ${message}`);
}

module.exports = log;

当 require log 时，运行时将缓存其导出和 time 的导出。（步骤 1）。然后，当 time 被修改时，HMR 进程不能简单地在替换 time 的代码后结束。如果它这样做，当执行 log 时，它将使用 time 的缓存副本（旧代码）执行。

为了让 log 获取 time 的更改，我们需要清除其缓存的导出，因为它依赖的模块之一已被热交换（步骤 3）。最后，当再次需要 log 时，它的工厂函数将被执行，require time 并获取其新代码。

HMR API​

React Native 中的 HMR 通过引入 hot 对象扩展了模块系统。此 API 基于 webpack 的 API。hot 对象公开了一个名为 accept 的函数，允许您定义一个回调，该回调将在模块需要热交换时执行。例如，如果我们按如下方式更改 time 的代码，则每次保存 time 时，我们都会在控制台中看到“time changed”

// time.js
function time() {
  ... // new code
}

module.hot.accept(() => {
  console.log('time changed');
});

module.exports = time;

请注意，只有在极少数情况下您才需要手动使用此 API。对于最常见的用例，热重载应该开箱即用。

HMR 运行时​

正如我们之前看到的，有时仅接受 HMR 更新是不够的，因为使用正在热交换的模块的模块可能已被执行，并且其导入已被缓存。例如，假设电影应用示例的依赖树具有一个顶级的 MovieRouter，它依赖于 MovieSearch 和 MovieScreen 视图，而这些视图又依赖于先前示例中的 log 和 time 模块

如果用户访问了电影的搜索视图，但没有访问另一个视图，则除了 MovieScreen 之外的所有模块都将具有缓存的导出。如果模块 time 进行了更改，则运行时将必须清除 log 的导出，以便它获取 time 的更改。该过程不会在那里结束：运行时将递归地重复此过程，直到所有父级都被接受。因此，它将获取依赖于 log 的模块并尝试接受它们。对于 MovieScreen，它可以放弃，因为它尚未被 require。对于 MovieSearch，它将必须清除其导出并递归地处理其父级。最后，它将对 MovieRouter 执行相同的操作，并在那里结束，因为没有模块依赖于它。

为了遍历依赖树，运行时在 HMR 更新中从 Packager 接收反向依赖树。对于此示例，运行时将接收到如下所示的 JSON 对象

{
  modules: [
    {
      name: 'time',
      code: /* time's new code */
    }
  ],
  inverseDependencies: {
    MovieRouter: [],
    MovieScreen: ['MovieRouter'],
    MovieSearch: ['MovieRouter'],
    log: ['MovieScreen', 'MovieSearch'],
    time: ['log'],
  }
}

React 组件​

React 组件更难与热重载一起工作。问题是我们不能简单地用新代码替换旧代码，因为我们会丢失组件的状态。对于 React Web 应用程序，Dan Abramov 实现了 Babel 转换，该转换使用 webpack 的 HMR API 来解决此问题。简而言之，他的解决方案通过在转换时为每个 React 组件创建一个代理来工作。代理保存组件的状态并将生命周期方法委托给实际组件，而实际组件是我们热重载的组件

除了创建代理组件之外，转换还定义了 accept 函数，其中包含一段代码以强制 React 重新渲染组件。这样，我们就可以热重载渲染代码，而不会丢失任何应用状态。

React Native 附带的默认 transformer 使用 babel-preset-react-native，它被 配置 为以与在使用 webpack 的 React Web 项目中使用它的相同方式使用 react-transform。

Redux Store​

要在 Redux store 上启用热重载，您只需使用 HMR API，类似于您在 Web 项目中使用 webpack 时所做的操作

// configureStore.js
import { createStore, applyMiddleware, compose } from 'redux';
import thunk from 'redux-thunk';
import reducer from '../reducers';

export default function configureStore(initialState) {
  const store = createStore(
    reducer,
    initialState,
    applyMiddleware(thunk),
  );

  if (module.hot) {
    module.hot.accept(() => {
      const nextRootReducer = require('../reducers/index').default;
      store.replaceReducer(nextRootReducer);
    });
  }

  return store;
};

当您更改 reducer 时，用于接受该 reducer 的代码将被发送到客户端。然后客户端将意识到 reducer 不知道如何接受自身，因此它将查找引用它的所有模块并尝试接受它们。最终，流程将到达单个 store，即 configureStore 模块，它将接受 HMR 更新。

结论​

如果您有兴趣帮助改进热重载，我鼓励您阅读 Dan Abramov 关于热重载未来的帖子 并做出贡献。例如，Johny Days 将 使其与多个连接的客户端一起工作。我们依靠大家来维护和改进此功能。

借助 React Native，我们有机会重新思考构建应用的方式，以使其成为出色的开发者体验。热重载只是难题的一部分，我们还能做哪些疯狂的 hack 来使其变得更好？

随着最近在 Web 上的 React 和在移动设备上的 React Native 的发布，我们为开发者提供了一个新的前端框架来构建产品。构建强大产品的关键方面之一是确保任何人都可以使用它，包括视力丧失或其他残疾人士。React 和 React Native 的无障碍功能 API 使您能够使任何 React 驱动的体验可供可能使用辅助技术（如盲人和视障人士的屏幕阅读器）的人使用。

对于这篇文章，我们将专注于 React Native 应用。我们设计的 React Accessibility API 在外观和感觉上类似于 Android 和 iOS API。如果您之前为 Android、iOS 或 Web 开发过无障碍应用，那么您应该对 React AX API 的框架和术语感到满意。例如，您可以使 UI 元素可访问（因此暴露给辅助技术）并使用 accessibilityLabel 为元素提供字符串描述

<View accessible={true} accessibilityLabel=”This is simple view”>

让我们通过查看 Facebook 自己的 React 驱动产品之一：广告管理工具应用，来逐步了解 React AX API 的稍微复杂的应用。

这是一个摘录。阅读 Facebook 代码 上的剩余部分。

今年早些时候，我们介绍了 React Native for iOS。React Native 将开发者在 Web 上使用 React 时所习惯的功能（声明式的自包含 UI 组件和快速开发周期）带到移动平台，同时保留了原生应用的速度、保真度和感觉。今天，我们很高兴发布 React Native for Android。

在 Facebook，我们已经在生产环境中使用 React Native 一年多了。大约一年前，我们的团队开始开发 广告管理工具应用。我们的目标是创建一个新的应用，让数百万在 Facebook 上投放广告的人能够管理他们的帐户并在旅途中创建新的广告。它最终不仅成为 Facebook 的第一个完全 React Native 应用，而且也是第一个跨平台应用。在这篇文章中，我们想与您分享我们如何构建此应用，React Native 如何使我们能够更快地行动，以及我们学到的经验教训。

这是一个摘录。阅读 Facebook 代码 上的剩余部分。

两年前，我们向世界介绍了 React，从那时起，它在 Facebook 内外都取得了令人印象深刻的增长。今天，即使没有人被迫使用它，Facebook 的新 Web 项目通常以一种或另一种形式使用 React 构建，并且它正在整个行业中被广泛采用。工程师每天都在选择使用 React，因为它使他们能够将更多时间集中在他们的产品上，而将更少的时间用于与框架作斗争。然而，直到我们使用 React 构建了一段时间后，我们才开始理解是什么使它如此强大。

React 迫使我们将应用程序分解为离散的组件，每个组件代表一个单一的视图。这些组件使迭代我们的产品变得更容易，因为我们不需要将整个系统记在脑海中即可对其中的一部分进行更改。然而，更重要的是，React 使用声明式 API 包装了 DOM 的可变、命令式 API，这提高了抽象级别并简化了编程模型。我们发现，当我们使用 React 构建时，我们的代码更具可预测性。这种可预测性使我们能够更有信心地更快地迭代，并且我们的应用程序也因此更加可靠。此外，使用 React 构建应用程序不仅更容易扩展，而且我们发现扩展团队本身的规模也更容易。

结合 Web 的快速迭代周期，我们已经能够使用 React 构建一些很棒的产品，包括 Facebook.com 的许多组件。此外，我们在 React 之上构建了令人惊叹的 JavaScript 框架，例如 Relay，这使我们能够大大简化我们的大规模数据获取。当然，Web 只是故事的一部分。Facebook 还拥有广泛使用的 Android 和 iOS 应用，它们是建立在不相关的专有技术堆栈之上的。不得不在多个平台上构建我们的应用使我们的工程组织分裂，但这只是使原生移动应用开发变得困难的原因之一。

这是一个摘录。阅读 Facebook 代码 上的剩余部分。