React Native 的目标是为您提供尽可能最佳的开发者体验。其中很大一部分是您保存文件到能够看到更改之间所花费的时间。我们的目标是即使在您的应用不断增长的情况下，也使这个反馈循环保持在 1 秒以下。
我们通过三个主要功能接近了这个理想目标
使用 JavaScript 作为语言，它没有漫长的编译周期时间。
实现一个名为 Packager 的工具，将 es6/flow/jsx 文件转换为 VM 可以理解的普通 JavaScript。它被设计为一个服务器，将中间状态保存在内存中，以实现快速增量更改，并使用多个核心。
构建一个名为 Live Reload 的功能，在保存时重新加载应用。
此时，开发者的瓶颈不再是重新加载应用所花费的时间，而是丢失应用的状态。一个常见的场景是处理一个离启动屏幕有多个屏幕距离的功能。每次重新加载时，您都必须一遍又一遍地点击相同的路径才能回到您的功能，从而使周期长达几秒钟。
热重载
热重载背后的想法是保持应用运行，并在运行时注入您编辑的文件的新版本。这样，您就不会丢失任何状态，如果您正在调整 UI，这将特别有用。
一图胜千言。看看 Live Reload（当前）和 Hot Reload（新）之间的区别。
VIDEO
如果您仔细观察，您会注意到可以从红色错误框中恢复，并且您还可以开始导入以前不存在的模块，而无需进行完全重新加载。
警告： 由于 JavaScript 是一种非常有状态的语言，因此无法完美地实现热重载。在实践中，我们发现当前的设置在大量常见用例中运行良好，并且在出现问题时始终可以使用完全重新加载。
热重载从 0.22 版本开始可用，您可以启用它
实现简述
现在我们已经了解了为什么我们需要它以及如何使用它，有趣的部分开始了：它实际上是如何工作的。
热重载构建在 热模块替换 或 HMR 功能之上。它最初由 webpack 引入，我们在 React Native Packager 内部实现了它。HMR 使 Packager 监视文件更改，并将 HMR 更新发送到应用中包含的精简 HMR 运行时。
简而言之，HMR 更新包含已更改的 JS 模块的新代码。当运行时接收到它们时，它会将旧模块的代码替换为新代码
HMR 更新包含的内容不仅仅是我们想要更改的模块的代码，因为仅仅替换它不足以让运行时接收更改。问题在于模块系统可能已经缓存了我们想要更新的模块的导出 。例如，假设您的应用由以下两个模块组成
function log ( message ) { const time = require ( './time' ) ; console . log ( ` [ ${ time ( ) } ] ${ message } ` ) ; } module . exports = log ; function time ( ) { return new Date ( ) . getTime ( ) ; } module . exports = time ; 模块 log 打印出提供的消息，包括模块 time 提供的当前日期。
当应用被捆绑时，React Native 使用 __d 函数在模块系统上注册每个模块。对于此应用，在许多 __d 定义中，将有一个用于 log 的定义
__d ( 'log' , function ( ) { ... } ) ; 此调用将每个模块的代码包装到一个匿名函数中，我们通常将其称为工厂函数。模块系统运行时跟踪每个模块的工厂函数、它是否已被执行以及执行结果（导出）。当需要一个模块时，模块系统要么提供已缓存的导出，要么首次执行模块的工厂函数并保存结果。
假设您启动您的应用并需要 log。此时，log 和 time 的工厂函数都尚未执行，因此没有缓存任何导出。然后，用户修改 time 以 MM/DD 格式返回日期
function bar ( ) { const date = new Date ( ) ; return ` ${ date . getMonth ( ) + 1 } / ${ date . getDate ( ) } ` ; } module . exports = bar ; Packager 会将 time 的新代码发送到运行时（步骤 1），当最终需要 log 时，导出的函数会被执行，它将使用 time 的更改来执行（步骤 2）
现在假设 log 的代码在顶层需要 time
const time = require ( './time' ) ; function log ( message ) { console . log ( ` [ ${ time ( ) } ] ${ message } ` ) ; } module . exports = log ; 当需要 log 时，运行时将缓存其导出和 time 的导出。（步骤 1）。然后，当 time 被修改时，HMR 进程不能简单地在替换 time 的代码后结束。如果这样做，当执行 log 时，它将使用 time 的缓存副本（旧代码）执行。
为了让 log 接收到 time 的更改，我们需要清除其缓存的导出，因为它依赖的模块之一已被热交换（步骤 3）。最后，当再次需要 log 时，它的工厂函数将被执行，需要 time 并获取其新代码。
HMR API
React Native 中的 HMR 通过引入 hot 对象来扩展模块系统。此 API 基于 webpack 的 API。hot 对象公开了一个名为 accept 的函数，它允许您定义一个回调，该回调将在需要热交换模块时执行。例如，如果我们像下面这样更改 time 的代码，那么每次我们保存 time 时，我们都会在控制台中看到“time changed”
function time ( ) { ... } module . hot . accept ( ( ) => { console . log ( 'time changed' ) ; } ) ; module . exports = time ; 请注意，只有在极少数情况下您才需要手动使用此 API。对于最常见的用例，热重载应该开箱即用。
HMR 运行时
正如我们之前看到的，有时仅仅接受 HMR 更新是不够的，因为使用正在热交换的模块的模块可能已经被执行，并且其导入已被缓存。例如，假设电影应用示例的依赖关系树具有顶层 MovieRouter，它依赖于 MovieSearch 和 MovieScreen 视图，而这些视图又依赖于前面示例中的 log 和 time 模块
如果用户访问了电影搜索视图，但没有访问另一个视图，则除了 MovieScreen 之外的所有模块都将具有缓存的导出。如果对模块 time 进行了更改，则运行时必须清除 log 的导出，以便它接收到 time 的更改。该过程不会在那里结束：运行时将递归地重复此过程，直到所有父模块都被接受。因此，它会抓取依赖于 log 的模块并尝试接受它们。对于 MovieScreen，它可以放弃，因为它尚未被需要。对于 MovieSearch，它将必须清除其导出并递归地处理其父模块。最后，它将对 MovieRouter 执行相同的操作，并在那里结束，因为没有模块依赖于它。
为了遍历依赖关系树，运行时从 Packager 接收 HMR 更新上的反向依赖关系树。对于此示例，运行时将接收到一个类似这样的 JSON 对象
{ modules : [ { name : 'time' , code : } ] , inverseDependencies : { MovieRouter : [ ] , MovieScreen : [ 'MovieRouter' ] , MovieSearch : [ 'MovieRouter' ] , log : [ 'MovieScreen' , 'MovieSearch' ] , time : [ 'log' ] , } } React 组件
React 组件更难以与热重载一起工作。问题在于我们不能简单地用新代码替换旧代码，因为我们会丢失组件的状态。对于 React Web 应用程序，Dan Abramov 实现了 babel transform ，它使用 webpack 的 HMR API 来解决这个问题。简而言之，他的解决方案通过在转换时 为每个 React 组件创建一个代理来工作。代理保存组件的状态，并将生命周期方法委托给实际组件，而实际组件正是我们热重载的组件
除了创建代理组件外，transform 还定义了 accept 函数，其中包含一段代码来强制 React 重新渲染组件。这样，我们就可以热重载渲染代码，而不会丢失任何应用状态。
React Native 附带的默认 transformer 使用 babel-preset-react-native，它被 配置 为以与在使用 webpack 的 React Web 项目中使用它的相同方式使用 react-transform。
Redux Store
要在 Redux store 上启用热重载，您只需要使用 HMR API，类似于您在使用 webpack 的 Web 项目中所做的操作
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 来使其变得更好？
