2011年开发适用于iOS/Android的HTML5离线存储解决方案答案

【问题标题】：Developing a HTML5 offline storage solution for iOS/Android in 20112011年开发适用于iOS/Android的HTML5离线存储解决方案
【发布时间】：2011-12-05 18:28:20
【问题描述】：

问题：

我需要一个与设备无关（例如 HTML5）的解决方案，用于在手机或平板电脑类型的设备（例如 iOS/Android）上离线存储和查询 250,000 多行数据。我的想法是让人们在没有任何蜂窝数据连接的偏远地区工作，他们需要对这些数据运行查询并在离线时对其进行编辑。部分它将基于地理位置，因此如果他们所在的区域有资产（使用 GPS），那么它将显示这些资产并让它们进行编辑。当他们返回办公室时，他们可以将数据同步回办公室服务器。

我从 web 标准的角度来处理这个问题的原因基本上是通过在 HTML5 中编写一次然后跨多个平台而不是在 Objective C 和 Java 中编写两次来节省金钱和时间。此外，如果您编写的东西与平台无关，那么您就不会被锁定，也不会在每个人都转移到新的船时随船沉没。我们为 Windows Mobile 5 编写了一个类似的应用程序，现在它已经没用了，因为那个平台已经死了。

设备上的离线数据库需要是：

快速（响应时间不到 2 秒）
可能执行连接并与能够查询数据库的其他表建立关系
选择特定范围或标准内的数据，例如通过基于 GPS 读数的 x 和 y 坐标。

选项：

HTML5 本地存储：

适用于

缺点：

对于超过 10,000 行，即使在高端机器上，浏览器也会慢到爬行。
无法对数据进行复杂查询以提取所需数据，因为您必须遍历整个存储并手动搜索。
可存储的存储量限制

Web SQL 数据库：

符合要求。
在 250,000 行（1-2 秒）上快速运行查询
可以创建复杂的查询、连接等
受 Safari、Android 和 Opera 支持，因此可在 iOS 和 Android 设备上运行

缺点：

自 2010 年 11 月起已弃用
跨目录攻击的安全漏洞。不是真正的问题，因为我们不会使用共享主机

索引数据库：

键/值对象存储类似于本地存储，除了索引。

缺点：

在 200,000 行上运行查询很慢（15-18 秒）
无法运行复杂查询
无法与其他表进行联接
主要手机或平板设备不支持，例如iPad/安卓
标准不完整

这留下了实施已弃用的 Web SQL 方法的唯一选择，该方法可能只能再工作一年左右。 IndexedDB 和本地存储目前无法使用。

我不确定 Mozilla 和 Microsoft 是如何弃用 Web SQL 数据库标准的，以及为什么 W3C 允许它发生。据说他们之间拥有 77% 的桌面浏览器市场。在高级移动设备上，Mozilla 和 Microsoft 对Safari, Opera and Android have over 90% of the market share 的影响几乎为零。 Mozilla 和 Microsoft 如何规定在最有可能使用离线存储的移动市场中应该使用哪种标准没有任何意义。

comments from Mozilla 关于他们为什么要使用 IndexedDB 的原因主要是关于“开发人员美学”，他们不喜欢在 JavaScript 中运行 SQL 的想法。我不买。

目前提议的标准是劣质的，并且是一个非常基本的 NoSQL 实现，速度很慢，甚至不支持人们在数据库中需要的高级功能。有很多样板代码来建立数据库并获取数据，但他们声称人们会在其之上编写一些不错的抽象库，以提供更高级的功能。截至 2011 年 10 月，它们已无处可见。
他们已经弃用了现有的 Web SQL 标准，该标准实际上可以在主要的移动/平板浏览器中运行并实现。而他们的“新”和“更好”标准在主要的移动浏览器中不可用。
作为开发人员，我们应该在接下来的 3-5 年内使用什么，届时 IndexedDB 规范可能会逐渐标准化，拥有更多功能，在主要的移动/平板电脑浏览器中实现，并且有一些不错的图书馆让事情变得更容易？

W3C 应该让 Web SQL 数据库标准保持并行运行并解决问题。它已经支持主要的移动平台，并且运行良好。 Mozilla 和微软作为拥有最多桌面浏览器份额的两个玩家能够让这个标准废弃这一事实是相当可疑的，并且可以被视为试图阻碍移动网络平台的进展，直到他们能够赶上并提供与 iOS/Safari 和 Android 竞争的解决方案。

总之，是否有人为我的问题提供了适用于 iOS/Android 的手机/平板设备的解决方案。也许是一个很好的包装 API，它可以在后台使用多个数据库实现并具有查询功能，它允许您选择哪个数据库具有优先级。我见过像lawnchair 这样的东西，但我很确定它只允许您默认使用本地存储并回退到其他存储。我想我宁愿它使用 Web SQL（默认情况下）而不是较慢的选项。

非常感谢您对解决方案的任何帮助，谢谢！

【问题讨论】：

文章写得好！这是本机应用程序赢得本机与 Web 应用程序争论的情况之一 - 但我知道您不想听到这种情况。在这种情况下，据我所知，Web SQL 是最好的选择——我还会强制用户下载与他们要去的位置相关的行，而不是整个数据库——如果你认为他们可能需要在某个地方更新一个可怕的连接，更不用说通过 1/5 大小的数据库搜索的速度提高了（不确定数据库的规模）
他们不能“只解决问题”与 WebSQL，因为标准推进到 W3C 推荐状态的要求之一是有“独立和可互操作的实现”。由于规范基本上是“做 SQLite 做的事情”，这永远不会发生。
嘿，你刚刚描述了我的期末考试项目 :) 在我看来，如果你需要离线和下降性能，有 2 个选项； 1.使用本地存储并将数据剥离到绝对基础。或 2. 构建一个原生应用程序（具有可扩展的 UI？），然后将其克隆到另一个平台（您已经在第一个平台上设置了规格，因此为其他平台再次开发它会更快。缺点是你必须保持不止一个）
因为在他们要求我们拥有的是 W3C 建议之前，没有浏览器实际实现。这三个浏览器都在使用 SQLite。没有 SQLite 规范，这就是为什么它不是标准的良好基础的原因之一。
@robertc 你是什么意思没有规范？它基于带有few minor omissions 的SQL92 标准。我找到了this page，这似乎是一个规范。此外，SQLite 网站上的all the other documentation 怎么样，这实际上是规范的一部分，不是吗？它还需要什么有效？

标签： javascript html web-sql indexeddb jaydata

【解决方案1】：

我建议查看JayData 库，它实际上具有为移动设备创建与存储无关的数据访问层的确切目的。 JayData 提供具有JavaScript Language Query (JSLQ) 和JavaScript CRUD 支持的抽象层，让您以完全相同的方式处理不同的离线和在线数据存储类型。 JayData 支持本地或远程处理复杂实体以及实体关系。

在撰写本文时，JayData 支持以下存储或协议：webSQL(sqLite)/IndexedDB/OData/YQL/FBQL。

JayData 的提供者后备功能可以轻松解决您在不同系统中提供不同存储引擎的特殊问题：它将使用它可以找到的任何存储层，同时仍为消费者代码提供相同的 API。

关于 WebSQL 将在 2012 年被弃用：在撰写本文时，WebSQL 仍然拥有 95% 的设备覆盖率，包括三星 SmartTV 和亚马逊 Kindle。 Check out kindle executing WebSQL unit tests with JayData.

【讨论】：

我同意，JavaScript 语言查询支持和提供者模型使 JayData 库成为 HTML5 离线存储解决方案的不错选择。
更新：JayData 现在也支持 HTML5 localStorage。 JayData library 执行 JSON 字符串化/解析工作并提供干净、统一的数据管理 API 和概念。
我很乐意将您的答案作为已接受的答案，因为这听起来正是需要的，但是您是否有任何大型数据库的性能基准，例如250,000 行？我很想看看它是否可以同时使用 IndexedDB 和 WebSQL 底层存储（取决于设备）来处理那么多行，然后计算执行基本“where”类型查询以根据某些条件找到其中一行所需的时间.
@zuallauz 我刚刚做了这样的基准测试。从 250K 项中获取 5-10 项在使用 Android nexus 2 的 websql 上花费了 60 毫秒，在带有 Windows Phone 的 Lumia 920 上花费了 25 毫秒。（IndexedDB 肯定更快）。
@zuallauz 你说的很对，我们会的。 IndexedDB 通常在各个方面都快得多 - 除了复杂的多字段查询。然而，在 WebSQL 上插入数据可能会很慢。为写入而打开的事务可能代价高昂（60-120 毫秒）。

【解决方案2】：

我会查看 CouchBase Lite。这是在 Android 和 iOS 上运行的 CouchDB 的一个近乎全功能的实现。

iOS

Android

如果您将您的应用程序包装在 PhoneGap 之类的东西中，您可以为这两个平台创建原生 HTML 5 应用程序，并且您只需要进行一点点 Android/iOS 特定的编程来实现 CouchDB。

优点：

用于查询多行数据的快速视图引擎。
内置了简单而强大的复制支持。

缺点：

键值存储 - 需要一些时间来适应。

【讨论】：

谢谢，听起来它可以工作，但是你need a Mac system 我相信为它开发并生产密钥等？我们没有任何 Mac。
CouchDB 非常有趣，但我不相信它的索引（“视图”）更新延迟模型（由查询或批处理触发）真的很好用。我见过的大多数应用程序都假设一旦添加了一些数据，就可以有效地查询它，而大多数其他 NoSQL 数据库将更多的工作推到写入事务中，以便读取事务更快。
@RichVel：根据我的经验，移动设备上的视图更新从来都不是问题。也就是说，使用 CouchDB 或 TouchDB 的最大原因之一是超级强大且易于使用的复制。
我开始关注 CouchDB 以复制到移动设备，但我并不想将服务器数据库暴露给移动设备，或者必须在服务器上使用 CouchDB 来获取复制。所以我现在在看一个叫做 Simperium 的数据同步云服务，见simperium.com 和simperium

【解决方案3】：

在为自己的项目寻找解决方案时，我进行了更多研究。看起来这个库很有前途：http://nparashuram.com/IndexedDBShim/

它允许在后台使用带有 WebSQL 的 IndexedDB API。

它在最近的 iPad、iPhone 5、Android 4.2.2 上通过了测试。

希望这对某人有所帮助。

【讨论】：

迟到了，但我也推荐 indexeddbshim.js。它在 Cordova/PhoneGap 环境中运行良好，可提供跨 IOS 和 Android 的单一解决方案。

【解决方案4】：

我会告诉你使用Corona。它是一个私有平台，用于支持 SQLite 的跨移动应用程序。

优点

很简单，对 SQLite 有很大的支持，不需要用 Html5 存储做奇怪的事情

缺点

如果您想在 Android Market 或 iOS Market 中使用它，则必须付费。

我把他们的评论贴在这里：

Corona 支持所有平台上的 SQLite 数据库。这是基于 iPhone 内置的 sqlite 支持，并编译 Android 上的 SQLite 版本。请注意，这会增加 Android 二进制 300K。

SQLite 可用于所有版本的 Android、iPhone 和 iPad，如以及在电晕模拟器中...

【讨论】：

【解决方案5】：

“我见过像草坪椅这样的东西，但我很确定它只允许您默认使用本地存储并回退到其他存储。我想我宁愿它使用 Web SQL（默认情况下）较慢的选项。”

这是可配置的，存储引擎的每个“适配器”都是独立的，您可以将适配器传递给 Lawnchair 构造函数，或者，通过连接 javascript 更改它回退到其他存储选项的顺序创建库时文件不同。例如对于 indexed-db 然后回退到 sqlite 然后齿轮 sqlite：

git clone https://github.com/brianleroux/lawnchair.git  
cd lawnchair  
cat src/Lawnchair.js src/adapters/indexed-db.js src/adapters/webkit-sqlite.js src/adapters/gears-sqlite.js > my_lawnchair.js

当然，正如其他答案所建议的那样，您可以使用 phonegap 等将您的 html5 包装到本机应用程序中。那么您将有很多选择，但是如果您想坚持网络标准，那么这可能是一个好方法直到我们广泛采用 IndexedDB。

【讨论】：

【解决方案6】：

为什么不用 javascript 编写一个简单的存储引擎（涵盖“基于标准”的部分）？显然你不需要任何非常花哨的东西，所以它不应该花费太多的努力来让它工作。

我会做以下事情：

以 bson 或类似的二进制格式存储所有内容。
在文件中解析和创建索引，并在启动时读取。
使用 javascript 查询并从您的（显然是离线的）网络应用程序中读取大文件。
单独存储更新的对象。

这个解决方案只有在数据库足够简单的情况下才可行。但我认为它可能会起作用——移动设备上的 javascript 支持很好。

为了灵感，here 是 javascript 中的 Btree+ 实现。

要读取本地文件，您需要file API，它可用于access local files。大多数现代浏览器都支持它，甚至是Safari 6。不过，我无法确定当前的 iPhone 浏览器是否支持此 API。

【讨论】：

手机上的 JavaScript 如何访问设备上的文件系统的读/写权限？
好点。显然 File API 并不像看起来那样，但我的回答可能有点过于乐观。 CouchBase 看起来更安全。

【解决方案7】：

值得看看我的开源库https://bitbucket.org/ytkyaw/ydn-db/wiki/Home

用于Indexeddb、WebDatabase (WebSQL) 和WebStorage (localStorage) 存储机制的Javascript 数据库模块，支持版本迁移、高级查询和事务。

作为 NoSQL 库，连接是手动的，但并非不可能。库中已经内置了关键的连接算法。

【讨论】：

如果在代码中我需要执行 SQL 查询来检索一些数据并对其进行排序，但我的设备正在运行 IndexedDB，您的库能否转换将从 IndexedDB 数据库中获取数据的 SQL 查询?
没有。我的库中的 SQL 支持非常基础。请看这里有什么可以dev.yathit.com/ydn-db/sql-query.html