FirefoxOS的内存映射等效项 [英] Memory mapped equivalent for FirefoxOS

查看:208
本文介绍了FirefoxOS的内存映射等效项的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

您如何在FirefoxOS,Tizen或任何其他移动纯JS解决方案中模拟内存映射文件?

How would you emulate a memory mapped file in FirefoxOS, Tizen or any other mobile pure-JS solution?

用例适用于移动浏览器,您需要大量的数据不适合RAM,或者你不想浪费RAM而宁愿懒得加载它。

The use case is for a mobile browser and you need lots of data which does not fit in the RAM or you don't want to waste RAM for it yet and prefer to lazy load it.

我发现的唯一的东西是 IndexedDB 或我该怎么办?有没有更好的技巧或API?

The only thing I found is IndexedDB or what can I do about it? Any better tricks or APIs?

看起来像 Web SQL Database 也可以是Android,Tizen或iOS上的解决方案。但Firefox不支持它(?)

Hmmh it looks like Web SQL Database could be also a solution on Android, Tizen or iOS. But Firefox does not support it (?)

更新:我问的是因为一些实验

推荐答案

首先,Web SQL不会像规范,因此只应考虑基于WebKit / Blink的浏览器。

First thing first, Web SQL won't be ever standardised as explained in the specification, so it should be considered only for WebKit/Blink-based browsers.

有一个此问题,即使在该问题中考虑了地图图块,我认为它仍与您的用例相关。

There is an awesome overview of offline storage options in this queston, even though the map tiles are considered in that question, I think it is still relevant to your use case.

我相信您使用IndexedDB处于正确的轨道上图表数据。在高层次上它是一个键值异步对象存储(参见基本概念文档)。对于您的用例,您可以在对象存储区

I believe you are on the right track with IndexedDB for the graph data. On a high level it is a key-value asynchronous object store (see the Basic Concepts document). For your use case, you could index graph nodes in an object store. There is, for example, LevelGraph library which stores graph data in IndexedDB, though it is built for Semantic Web triples. HeliosJS is also worth mentioning, though it is an in-memory graph database.

编辑: IndexedDB的当前API是异步的。规范中草拟了同步API ,只能在网络工作者中使用。不幸的是,目前没有引擎实现此功能有一个 Gecko待定补丁,但我没有找到任何计划Blink或WebKit,因此它现在不是一个有意义的选项。

Current API for IndexedDB is asynchronous. There is synchronous API drafted in the spec, which could be used only in web workers. Unfortunately no engine currently implements this feature. There is a pending patch for Gecko, but I did not find any plans for Blink or WebKit, so it is not a meaningful option now.

可以通过Web API访问原始文件。您可以使用 XHR2 将(本地)文件作为二进制文件加载< a href =https://developer.mozilla.org/en-US/docs/Web/API/Blob =nofollow noreferrer> Blob 。不幸的是,XHR2主要是为流文件而不是随机访问而设计的,尽管你可以将数据分成多个文件并按需请求它们,但这可能很慢。
目前对文件的直接访问非常有限, FileList和createObjectURL 主要用于直接文件用户输入(通过拖放或文件输入字段),FileSystem API是最近被杀了,以及 DeviceStorage 是非标准和特权(Firefox OS特定)。您还可以在IndexedDB中存储文件,该文件描述了 FileHandle API 。但是,一旦您设法访问原始File对象,就可以使用 Blob.slice 方法加载文件的块 - 有一个通过上传表单阅读文件块的好例子
您可能还想查看 jDataView 库&朋友,通过更高效的 ArrayBuffer 。

It is possible to access raw files through Web APIs. You could use XHR2 to load a (local) file as a binary Blob. Unfortunately XHR2 is mostly designed for streaming files and not for a random access, though you could split-up the data into multiple files and request them on demand, but that may be slow. The direct access to files is currently quite limited, FileList and createObjectURL are primarily used for direct file user input (through Drag and Drop or file input field), FileSystem API was recently killed, and the DeviceStorage is non-standard and privileged (Firefox OS-specific). You can also store files in IndexedDB, which is described for FileHandle API. However, once you manage to get access to the raw File object, you can use the Blob.slice method to load chunks of the file – there is a great example of reading file chunks via upload form. You may also want to look at jDataView library & friends, which eases handling of binary data through the more efficient ArrayBuffer.

编辑:至于同步API, localStorage (aka DOM Storage)也可以考虑。它也是一个键值存储,但比IndexedDB简单得多且更有限:

As for the synchronous API, localStorage (aka DOM Storage) could be considered too. It is also a key-value storage, but much much simpler and more limited than IndexedDB:


  • 存储空间的大小有限,通常为5 MB

  • 每个域/应用程序只有一个localStorage(您可以有多个名为IndexedDB中的对象存储。)

  • 只能存储字符串。

一般情况下,localStorage是有用的cookie更换,但它对存储大型离线数据并不是很有用。

In general, localStorage is useful cookies replacement, but it is not really useful for storing large offline data.

总结起来:


  • IndexedDB是最容易和最广泛使用的选项,尽管它可能很慢,效率低或内存限制很大,数据非常大;此外,目前只能使用异步API。

  • 如果没有用户交互且API不稳定且不标准,很难获得原始文件访问。

最后,你可以结合两种方法,考虑两个选项:

In the end, you can combine both approaches, two options come in mind:


  • 使用XHR2以块的形式解析大文件并将已解析的节点存储到IndexedDB中

  • 将大文件存储到IndexedDB(通过XHR),使用 FileHandle.getFile 加载File对象和 Blob.slice 阅读其内容。

  • Use XHR2 to parse the large file in chunks and store the parsed nodes into IndexedDB
  • Store the large file into IndexedDB (via XHR), use FileHandle.getFile to load the File object and Blob.slice to read its content.

在所有情况下,您都可以(应该)使用 Web Workers 在后台处理数据操作和计算。

In all cases, you can (should) use Web Workers to handle data manipulation and calculations in the background.

无论如何,GraphHopper看起来很棒,我们真的缺乏适用于Firefox OS的非平凡的离线应用程序,祝你好运!

Anyway, GraphHopper looks great, we really lack such non-trivial offline applications for Firefox OS, so good luck!

这篇关于FirefoxOS的内存映射等效项的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆