使用 React Native 时，我有哪些存储数据的选项?(iOS 和安卓) [英] What are my options for storing data when using React Native? (iOS and Android)

问题描述

我还是 React Native 世界的新手，通常在移动/原生世界也是如此，我发现文档在数据持久性方面有点缺乏.

I am still new in the React Native world, and generally in the mobile/native world as well, and I am finding the documentation a bit lacking when it comes to data persistence.

在 React Native 中存储数据有哪些选择以及每种类型的含义?例如，我看到有本地存储和异步存储，但后来我也看到了 Realm 之类的东西，我很困惑所有这些如何与外部数据库一起工作.

What are my options for storing data in React Native and the implications of each type? For instance, I see that there is local storage and async storage, but then I also see things like Realm, and I'm confused how all of this would work with an outside database.

我特别想知道:

• 数据持久化有哪些不同的选项?
• 对于每个，持久性的限制是什么(即，数据何时不再可用)?例如:关闭应用程序时，重启手机等.
• 对于每个，在 iOS 和 Android 中实现之间是否存在差异(除了一般设置)?
• 与离线访问数据的选项相比如何?(或者通常如何处理离线访问?)
• 还有什么我应该记住的注意事项吗?

感谢您的帮助！

推荐答案

这是我在确定推进我当前的几个应用项目的最佳方式时学到的东西.

Here's what I've learned as I determine the best way to move forward with a couple of my current app projects.

异步存储(以前内置"到 React Native，现在独立移动)

Async Storage (formerly "built-in" to React Native, now moved on its own)

我将 AsyncStorage 用于生产中的应用程序.存储保持在设备本地，未加密(如另一个答案中所述)，如果您删除应用程序就会消失，但应作为设备备份的一部分保存并在升级期间保持不变(本机升级 ala TestFlight 和通过 CodePush 的代码升级).

I use AsyncStorage for an in-production app. Storage stays local to the device, is unencrypted (as mentioned in another answer), goes away if you delete the app, but should be saved as part of your device's backups and persists during upgrades (both native upgrades ala TestFlight and code upgrades via CodePush).

结论:本地存储；您提供自己的同步/备份解决方案.

Conclusion: Local storage; you provide your own sync/backup solution.

SQLite

我参与的其他项目使用 sqlite3 进行应用程序存储.这为您提供了类似 SQL 的体验，可压缩的数据库也可以在设备之间传输.我没有将它们同步到后端的任何经验，但我认为存在各种库.有用于连接到 SQLite 的 RN 库.

Other projects I have worked on have used sqlite3 for app storage. This gives you an SQL-like experience, with compressible databases that can also be transmitted to and from the device. I have not had any experience with syncing them to a back end, but I imagine various libraries exist. There are RN libraries for connecting to SQLite.

数据以您的传统数据库格式存储，数据库、表、键、索引等均以二进制格式保存到磁盘.可以通过命令行或具有 SQLite 驱动程序的应用程序直接访问数据.

Data is stored in your traditional database format with databases, tables, keys, indices, etc. all saved to disk in a binary format. Direct access to the data is available via command line or apps that have SQLite drivers.

结论:本地存储；您提供同步和备份.

Conclusion: Local storage; you supply the sync and backup.

Firebase

Firebase 提供实时 noSQL 数据库以及用于保持 1 到 n 个客户端同步的 JSON 文档存储(如 MongoDB)等.文档讨论了离线持久性，但仅适用于本机代码(Swift/Obj-C、Java).React Native 使用的 Google 自己的 JavaScript 选项(Web")不提供缓存存储选项(请参阅下面的 2/18 更新).该库是在假设 Web 浏览器将要连接的情况下编写的，因此将存在半持久连接.您可能可以编写一个本地缓存机制来补充 Firebase 存储调用，或者您可以编写本机库和 React Native 之间的桥梁.

Firebase offers, among other things, a real time noSQL database along with a JSON document store (like MongoDB) meant for keeping from 1 to n number of clients synchronized. The docs talk about offline persistence, but only for native code (Swift/Obj-C, Java). Google's own JavaScript option ("Web") which is used by React Native does not provide a cached storage option (see 2/18 update below). The library is written with the assumption that a web browser is going to be connecting, and so there will be a semi-persistent connection. You could probably write a local caching mechanism to supplement the Firebase storage calls, or you could write a bridge between the native libraries and React Native.

2018 年 2 月更新从那以后，我发现了 React Native Firebase，它为原生 iOS 和 Android 库提供了一个兼容的 JavaScript 接口(做 Google 可能会做的事情/应该完成)，为您提供本机库的所有优点以及 React Native 支持.随着 Google 在实时数据库旁边引入 JSON 文档存储，我对 Firebase 重新审视了我计划构建的一些实时应用.

Update 2/2018 I have since found React Native Firebase which provides a compatible JavaScript interface to the native iOS and Android libraries (doing what Google probably could/should have done), giving you all the goodies of the native libraries with the bonus of React Native support. With Google's introduction of a JSON document store beside the real-time database, I'm giving Firebase a good second look for some real-time apps I plan to build.

实时数据库以类似 JSON 的树形式存储，您可以在网站上对其进行编辑并非常简单地导入/导出.

The real-time database is stored as a JSON-like tree that you can edit on the website and import/export pretty simply.

结论:使用 react-native-firebase，RN 获得与 Swift 和 Java 相同的好处.[/update] 适用于联网设备.低利用率的低成本.与其他 Google 云产品完美结合.数据可以从他们的界面轻松查看和编辑.

Conclusion: With react-native-firebase, RN gets same benefits as Swift and Java. [/update] Scales well for network-connected devices. Low cost for low utilization. Combines nicely with other Google cloud offerings. Data readily visible and editable from their interface.

领域

2020 年 4 月更新MongoDB 已收购 Realm 并计划将其与 MongoDB Stitch(下文讨论)合并.这看起来非常令人兴奋.

2020 年 9 月更新使用过 Realm 与 Stitch:Stitch API 本质上允许 JS 应用(React Native 或 Web)直接与 Mongo 数据库对话，而不是通过您自己构建的 API 服务器.

Update 9/2020 Having used Realm vs. Stitch: Stitch API's essentially allowed a JS app (React Native or web) to talk directly to the Mongo database instead of going through an API server you build yourself.

Realm 旨在在发生更改时同步数据库的各个部分.

Realm was meant to synchronize portions of the database whenever changes were made.

两者的结合有点令人困惑.以前称为 Stitch API 的工作方式仍然像传统的 Mongo 查询和更新调用一样，而较新的 Realm 内容附加到代码中的对象并全部自行处理同步……主要是.我仍在研究在一个使用 SwiftUI 的项目中以正确的方式做事，所以它有点跑题了.但仍然很有前途和整洁.

The combination of the two gets a little confusing. The formerly-known-as-Stitch API's still work like your traditional Mongo query and update calls, whereas the newer Realm stuff attaches to objects in code and handles synchronization all by itself... mostly. I'm still working through the right way to do things in one project, which is using SwiftUI, so it's a bit off-topic. But promising and neat nonetheless.

也是具有自动网络同步功能的实时对象存储.他们自诩为设备至上".演示视频展示了设备如何处理零星或有损网络连接.

Also a real time object store with automagic network synchronization. They tout themselves as "device first" and the demo video shows how the devices handle sporadic or lossy network connectivity.

他们提供免费版本的对象存储，您可以将其托管在自己的服务器上或 AWS 或 Azure 等云解决方案中.您还可以创建不与设备保持同步的内存中存储、不与服务器同步的仅设备存储、只读服务器存储以及用于跨一台或多台设备同步的完整读写选项.他们有专业和企业选项，每月预付费用比 Firebase 高.

They offer a free version of the object store that you host on your own servers or in a cloud solution like AWS or Azure. You can also create in-memory stores that do not persist with the device, device-only stores that do not sync up with the server, read-only server stores, and the full read-write option for synchronization across one or more devices. They have professional and enterprise options that cost more up front per month than Firebase.

与 Firebase 不同，React Native 和 Xamarin 支持所有 Realm 功能，就像它们在 Swift/ObjC/Java(原生)应用中一样.

Unlike Firebase, all Realm capabilities are supported in React Native and Xamarin, just as they are in Swift/ObjC/Java (native) apps.

您的数据与代码中的对象相关联.因为它们是定义的对象，所以您确实有一个架构，并且版本控制是代码完整性的必要条件.通过 Realm 提供的 GUI 工具可以直接访问.设备端数据文件跨平台兼容.

Your data is tied to objects in your code. Because they are defined objects, you do have a schema, and version control is a must for code sanity. Direct access is available via GUI tools Realm provides. On-device data files are cross-platform compatible.

结论:设备优先，可选择与免费和付费计划同步.React Native 支持的所有功能.横向扩展比 Firebase 更昂贵.

Conclusion: Device first, optional synchronization with free and paid plans. All features supported in React Native. Horizontal scaling more expensive than Firebase.

iCloud

老实说，我还没有玩过很多游戏，但在不久的将来会这样做.

I honestly haven't done a lot of playing with this one, but will be doing so in the near future.

如果您有一个使用 CloudKit 的本机应用程序，您可以使用 CloudKit JS 从网络应用程序(或在我们的示例中为 React Native)连接到您应用程序的容器.在这种情况下，您可能有一个原生 iOS 应用和一个 React Native Android 应用.

If you have a native app that uses CloudKit, you can use CloudKit JS to connect to your app's containers from a web app (or, in our case, React Native). In this scenario, you would probably have a native iOS app and a React Native Android app.

与 Realm 一样，它在本地存储数据并在可能的情况下将其同步到 iCloud.您的应用程序有公共商店，每个客户都有私人商店.客户甚至可以选择与其他用户共享他们的一些商店或物品.

Like Realm, this stores data locally and syncs it to iCloud when possible. There are public stores for your app and private stores for each customer. Customers can even chose to share some of their stores or objects with other users.

我不知道访问原始数据有多容易；可以在 Apple 的网站上设置架构.

I do not know how easy it is to access the raw data; the schemas can be set up on Apple's site.

结论:非常适合面向 Apple 的应用.

Conclusion: Great for Apple-targeted apps.

沙发床

大牌，背后有很多大公司.有标准支持费用的社区版和企业版.

Big name, lots of big companies behind it. There's a Community Edition and Enterprise Edition with the standard support costs.

他们的网站上有一个教程，用于将事物连接到 React Native.我也没有在这个上花太多时间，但就功能而言，它看起来是 Realm 的可行替代品.我不知道在您的应用或您构建的任何 API 之外获取数据有多容易.

They've got a tutorial on their site for hooking things up to React Native. I also haven't spent much time on this one, but it looks to be a viable alternative to Realm in terms of functionality. I don't know how easy it is to get to your data outside of your app or any APIs you build.

结论:看起来与 Realm 具有相似的功能.可以仅限设备或同步.我需要尝试一下.

Conclusion: Looks to have similar capabilities as Realm. Can be device-only or synced. I need to try it out.

MongoDB

2020 年 4 月更新

Mongo 收购了 Realm，并且计划将 MongoDB Stitch(下文讨论)与 Realm(上文讨论)结合起来).

Mongo acquired Realm and plans to combine MongoDB Stitch (discussed below) with Realm (discussed above).

我将此服务器端用于本地使用 AsyncStorage 的应用程序.我喜欢一切都存储为 JSON 对象，这使得到客户端设备的传输非常简单.在我的用例中，它用作电视指南数据的上游提供商和我的客户端设备之间的缓存.

I'm using this server side for a piece of the app that uses AsyncStorage locally. I like that everything is stored as JSON objects, making transmission to the client devices very straightforward. In my use case, it's used as a cache between an upstream provider of TV guide data and my client devices.

数据没有硬结构，如模式，因此每个对象都存储为文档"；易于搜索、过滤等.类似的 JSON 对象可以具有附加(但不同)的属性或子对象，从而为您构建对象/数据的方式提供很大的灵活性.

There is no hard structure to the data, like a schema, so every object is stored as a "document" that is easily searchable, filterable, etc. Similar JSON objects could have additional (but different) attributes or child objects, allowing for a lot of flexibility in how you structure your objects/data.

我没有尝试任何客户端到服务器同步功能，也没有使用它嵌入.MongoDB 的 React Native 代码确实存在.

I have not tried any client to server synchronization features, nor have I used it embedded. React Native code for MongoDB does exist.

结论:仅限本地的 NoSQL 解决方案，没有像 Realm 或 Firebase 那样明显的同步选项.

Conclusion: Local only NoSQL solution, no obvious sync option like Realm or Firebase.

2/2019 更新

MongoDB 有一个产品"(或服务)称为缝合.由于客户端(在 Web 浏览器和电话的意义上)不应该直接与 MongoDB 对话(这是由服务器上的代码完成的)，因此他们创建了一个无服务器前端，您的应用程序可以与之交互，如果您选择使用他们的托管解决方案 (Atlas).他们的文档表明有一个可能的同步选项.

MongoDB has a "product" (or service) called Stitch. Since clients (in the sense of web browsers and phones) shouldn't be talking to MongoDB directly (that's done by code on your server), they created a serverless front-end that your apps can interface with, should you choose to use their hosted solution (Atlas). Their documentation makes it appear that there is a possible sync option.

这篇 2018 年 12 月的文章讨论了在示例应用中使用 React Native、Stitch 和 MongoDB，文档中链接了其他示例 (https://www.mongodb.com/blog/post/building-ios-and-android-apps-with-the-mongodb-stitch-react-native-sdk).

This writeup from Dec 2018 discusses using React Native, Stitch, and MongoDB in a sample app, with other samples linked in the document (https://www.mongodb.com/blog/post/building-ios-and-android-apps-with-the-mongodb-stitch-react-native-sdk).

Twilio 同步

另一个用于同步的 NoSQL 选项是 Twilio 的 Sync.从他们的网站:同步让您可以大规模实时管理任意数量设备的状态，而无需处理任何后端基础设施."

Another NoSQL option for synchronization is Twilio's Sync. From their site: "Sync lets you manage state across any number of devices in real time at scale without having to handle any backend infrastructure."

对于上述项目之一，我认为这是 Firebase 的替代方案，尤其是在与两个团队交谈之后.我也喜欢他们的其他通信工具，并使用它们从一个简单的网络应用程序发送短信更新.

I looked at this as an alternative to Firebase for one of the aforementioned projects, especially after talking to both teams. I also like their other communications tools, and have used them for texting updates from a simple web app.

自从我最初写这篇文章以来，我已经花了一些时间在 Realm 上.我喜欢我不必编写 API 来同步应用程序和服务器之间的数据，类似于 Firebase.无服务器函数看起来对这两个函数也很有帮助，限制了我必须编写的后端代码量.

I've spent some time with Realm since I originally wrote this. I like how I don't have to write an API to sync the data between the app and the server, similar to Firebase. Serverless functions also look to be really helpful with these two, limiting the amount of backend code I have to write.

我喜欢 MongoDB 数据存储的灵活性，因此对于基于 Web 的应用程序和其他需要连接的应用程序的服务器端，它正成为我的选择.

I love the flexibility of the MongoDB data store, so that is becoming my choice for the server side of web-based and other connection-required apps.

我发现了 RESTHeart，它为 MongoDB 创建了一个非常简单、可扩展的 RESTful API.构建一个 React (Native) 组件来读取和写入 JSON 对象到 RESTHeart，然后再将它们传递给/从 MongoDB 应该不会太难.

I found RESTHeart, which creates a very simple, scalable RESTful API to MongoDB. It shouldn't be too hard to build a React (Native) component that reads and writes JSON objects to RESTHeart, which in turn passes them to/from MongoDB.

我添加了有关如何存储数据的信息.有时，如果您必须调整和测试数据，那么了解在开发和测试期间可能需要进行多少工作很重要.

I added info about how the data is stored. Sometimes it's important to know how much work you might be in for during development and testing if you've got to tweak and test the data.

Edits 2/2019 在去年(2018 年)设计高并发项目时，我尝试了其中的几个选项.他们中的一些人在他们的文档中提到了硬并发限制和软并发限制(我相信 Firebase 的硬限制是 10,000 个连接，而根据 AltConf 两个团队的讨论，Twilio 是一个可以被突破的软限制).

Edits 2/2019 I experimented with several of these options when designing a high-concurrency project this past year (2018). Some of them mention hard and soft concurrency limits in their documentation (Firebase had a hard one at 10,000 connections, I believe, while Twilio's was a soft limit that could be bumped, according to discussions with both teams at AltConf).

如果您要为数万到数十万用户设计应用，请准备好相应地扩展数据后端.

If you are designing an app for tens to hundreds of thousands of users, be prepared to scale the data backend accordingly.

这篇关于使用 React Native 时，我有哪些存储数据的选项?(iOS 和安卓)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！