React Native 应用程序中的 Redux 非常慢，数据量很大答案

【问题标题】：Redux in React Native app is very slow with lots of dataReact Native 应用程序中的 Redux 非常慢，数据量很大
【发布时间】：2019-06-05 22:19:45
【问题描述】：

我有大量 JSON 对象存储在单个 Redux 变量中（约 8k 项，每个对象大约 1kb，总共 8mb）。这似乎使 Redux 调用速度变慢，即使对于最琐碎的操作和实际上不做任何事情的 reducer 也是如此。例如，调用此doNothing() 操作，reducer 会在设备上产生 500 毫秒的等待时间，而不会在调试器上运行：

// action
export const doNothing = () => {
  return {
    type: DO_NOTHING
  };
};

// reducer
export default (state = INITIAL_STATE, action) => {
  switch (action.type) {
    case DO_NOTHING: {
      return state;
    }
    default:
      return state;
  }
};

我最好的尝试是通过slowlog 来分析这个问题，这是我为我的 React 组件中的 Redux 调用提出 500 毫秒数字的地方。对于较小的数据集（约 500 项），我仍然需要等待，但它更接近 100 毫秒。这一切都在设备上，并且在模拟器和调试器上变得更慢。我在一个简单的视图上对此进行测试，只需一个按钮即可排除昂贵的重新选择和重新渲染带来的并发症。一个可能的复杂情况是我正在使用redux-offline，它将 Redux 存储持久化到AsyncStorage，但是当我关闭持久性时，我得到同样糟糕的性能。

理想情况下，我会直接解决瓶颈问题，但我也愿意接受变通方法。我尝试将动作调用包装在 setTimeout 中，但这似乎只是延迟了我的 React Native 应用程序的减速。

提前感谢您的任何建议！

【问题讨论】：

我没有这方面的经验，但我很好奇所有变量的调用速度都很慢，还是只有 8mb 变量？
这在开发和生产方面是否同样缓慢？我还在模拟器上看到了性能问题（不到 500 毫秒，但仍然很明显），但在生产中一切都很好。另一件事：我注意到在动画期间调度动作也会降低性能。
我们使用了一个类似的库：redux-persist.. 我们看到我们的应用程序出现了类似的缓慢，但数据要小得多。 redux-persist 的问题在于它读取了新的传入状态（即使它相同），进行了比较并将更新的状态（即使没有任何变化）写入异步存储。我们的解决方案是将大数据标准化为单独的 reducer 状态。此外，如果此状态是静态的并且不需要共享，我会将其存储到 JSON 文件中以避免写入减速器状态。
我有类似的情况 - 我目前正在实现离线模式，所以我将所有内容都保存在设备上。我不认为这是一个不合理的数额。我有一个包含 2500 个小对象的数组，根据响应标头为 0.2mb。奇怪的是它在调试版本中运行良好，而发布版本需要 15 秒才能对任何按钮按下做出反应！！！而且我知道这是我测试过的数据，除了在传递给 redux 之前过滤一半之外没有任何变化，它运行良好。完全以我的想法结束！

标签： reactjs performance react-native redux react-redux

【解决方案1】：

以 redux 状态存储大量数据并间接存储在 RAM 中并不是一种可靠的方法。

最佳做法是使用本地数据库，以便将数据存储在存储内存中。

对于 ReactNative，有一个流行的数据库 Watermelon DB 适合这种场景

请查看它的文档：https://nozbe.github.io/WatermelonDB/

这就是它解决的问题

对于简单的应用程序，使用带有持久性适配器的 Redux 或 MobX 是最简单的方法。但是，当您开始扩展到数千或数万条数据库记录时，您的应用现在启动速度会很慢（尤其是在速度较慢的 Android 设备上）。将完整的数据库加载到 JavaScript 中很昂贵！

西瓜通过懒惰来解决它。在请求之前不会加载任何内容。而且由于所有查询都直接在独立的本地线程上坚如磐石的 SQLite 数据库上执行，因此大多数查询会立即解决。

使用西瓜数据库存储/检索大数据

同时，使用 redux 状态只存储小数据。

希望这有帮助?

【讨论】：

【解决方案2】：

只需阅读以下文章即可了解 U 发生了什么以及如何解决该问题：

Click Here

【讨论】：

这不是一个真正的答案，你知道