正在介绍热重载

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 更新包含的内容不仅仅是我们想要更改的模块代码，因为仅仅替换它不足以让运行时获取更改。问题是模块系统可能已经缓存了我们想要更新的模块的 *exports*。例如，假设您有一个由这两个模块组成的应用程序

// 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
});

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

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

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

module.exports = bar;

Packager 会将 time 的新代码发送到运行时（步骤 1），当最终 require 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 时，运行时将缓存它的 exports 和 time 的 exports。（步骤 1）。然后，当 time 被修改时，HMR 过程不能简单地在替换 time 的代码后结束。如果那样，当 log 被执行时，它将使用 time 的缓存副本（旧代码）执行。

为了让 log 获取 time 的更改，我们需要清除其缓存的 exports，因为它依赖的模块之一已被热替换（步骤 3）。最后，当再次 require 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 之外的所有模块都将具有缓存的 exports。如果对模块 time 进行了更改，则运行时必须清除 log 的 exports，以便它可以获取 time 的更改。该过程不会在那里结束：运行时将递归地重复此过程，直到所有父模块都被接受。因此，它将获取依赖于 log 的模块并尝试接受它们。对于 MovieScreen，它可以跳过，因为它尚未被 require。对于 MovieSearch，它将必须清除其 exports 并递归地处理其父模块。最后，它将对 MovieRouter 执行相同的操作并在那里结束，因为没有模块依赖于它。

为了遍历依赖树，运行时从 Packager 接收 HMR 更新上的反向依赖树。对于此示例，运行时将接收如下 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 transform，它使用 webpack 的 HMR API 来解决这个问题。简而言之，他的解决方案通过在 *transform time* 时为每个 React 组件创建一个代理来工作。代理保存组件的状态并将生命周期方法委托给实际组件，这些组件是我们热重载的组件

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

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

Redux Stores

要在 Redux store 上启用热重载，您只需要像在使用 webpack 的 Web 项目上一样使用 HMR API

// 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，我们有机会重新思考构建应用程序的方式，使其成为一种出色的开发者体验。热重载只是拼图的一部分，我们还可以做哪些疯狂的技巧来使其更好？