Android中的Realm VS Room [关闭]答案

【问题标题】：Realm VS Room in Android [closed]Android中的Realm VS Room [关闭]
【发布时间】：2018-04-23 11:23:39
【问题描述】：

我正在构建一个应用程序，我需要在其中使用一个数据库。我正在考虑使用 Room，因为它现在很新而且很热。但我也听说过很多关于 Realm 的好消息。有人可以指出使用每种方法的可能优势吗？

我进行了研究并阅读了文档，但我自己没有理解它的经验

编辑：

已经有一段时间了，我可以指出另一个使用 Room 的原因。虽然您可以使用 Realm 和 Transformations 来与 LiveData 绑定，但使用 Room 您可以直接为 DB 返回 LiveData（以及使用插件的 RXJava 类型），这将为您节省一些样板代码和头痛。

编辑 2：

除了第一次编辑之外，Room 现在在 Kotlin 中对协程提供了一流的支持，所以如果你打算使用它们，那将是一个不错的选择 -> https://medium.com/androiddevelopers/room-coroutines-422b786dc4c5

【问题讨论】：

看看reddit.com/r/androiddev/comments/6dj652/realm_vs_room
@AesSedai101 感谢您的链接，阅读起来很有用。唯一的问题是讨论发生在 5 个月前，随着越来越多的人开始使用 Room，一些观点可能会改变
关于这个问题被关闭 - 我不同意这个问题是基于意见的。这个问题是在两种方法/库之间进行选择时询问架构方向和关键考虑因素。有些答案可能是基于意见的，但如果问题得到很好的回答，它将为开发人员提供客观的决策标准。

标签： android realm android-room

【解决方案1】：

我们推动使用数据库库的主要原因是它让我们能够对对象进行建模并使 CRUD 更容易，我对 Realm 有很好的体验，它真的很容易设置和工作，它是快速灵活，但库的大小是个问题，可以通过在构建目标 ABI 上拆分 APK 来减小 APK 大小，但我更喜欢使用 GreenDao，因为它基于 SQLite，尽管我认为它像其他任何东西一样有一些缺点图书馆，但它对我来说是最好的选择。

老实说，我还没有尝试过 Room，但是通过简要查看文档，您会发现它对开发人员更加灵活和友好，作为 Google 粉丝，我更喜欢使用 Google 家伙的库！正如我之前所说，相比全新的数据库库，我更喜欢层而不是原生 SQLite。

我将在我的下一个项目中尝试 Room，并在稍后的更新中分享我的经验，希望对您有所帮助。

【讨论】：

在房间里试验后，我发现了一个非常关心的问题，处理来自数据库操作的异常。目前我认为没有办法处理数据库异常。数据库回调也没有办法，例如插入、更新等上的行 id 回调。

【解决方案2】：

领域

一个比较快速方便的库，所有的链接都是简单实现的，和数据库的面向对象有关。优秀的文档。也许是目前在移动设备上存储数据的最佳选择之一，减号只能是 apk 文件的大小增加 2.5 MB。

房间

Google I/O 2017 上提出的一个有趣的解决方案是在 Android 操作系统上使用数据库的最佳解决方案。尽管有必要使用显式 sql-requests，但事实证明该库非常方便，我个人喜欢它。在性能上处于领先地位，所以我建议你选择这个特定的库。这样做的一大优势是基于内置的 SQLite 数据库。由于此解决方案由 Google 提交，因此很快就会流行起来，因此，为随之出现的问题寻找解决方案不会有任何问题。

Realm 使用更多 RAM 并增加 apk 大小和构建时间。所以我更喜欢房间。

有比较：https://github.com/AlexeyZatsepin/Android-ORM-benchmark

【讨论】：

我从未使用过它，但我认为它会像 Realm 一样有同样的问题和好处。
@AlexeyZatsepin 如果您根据架构拆分 apk，则不会占用 2.5 mb 空间。它会根据架构而减少。
我在一个演示应用程序中尝试过，还不错（易于使用），但文档还不够好。此外，似乎还有一堆问题需要他们先解决（例如，我已经等了 2 个月，他们的 rxjava 适配器才能正常工作）。我遇到的最大问题之一是自动迁移。这在纸上听起来很棒，但它也有可能使事情变得不可预测和无法追踪，而且不完全好的文档意味着我最终会弄乱数据库一两次。（续）
我最终搬到了同一应用程序的生产版本的房间，以便在易用性和稳定性之间取得更好的平衡（房间仍然是新的，但至少 sqlite 不是而且它不是太难寻找可以提供帮助的资源或人员）
对于领域，您的基准比较是不公平的。它基于一个非常旧的领域版本，但更重要的是你使用了低效的代码来实现，这使得它看起来比正确使用时要慢