IndexedDB 不是本地存储的键值存储。本地存储只存储字符串,因此将对象放入本地存储通常的方法是 JSON.stringify:
myObject = {a: 1, b: 2, c: 3}; localStorage.setItem("uniq", JSON.stringify(myObject));
这对于查找关键字 uniq的对象很有用,但是从本地存储中获取 myObject 属性的唯一方法是 JSON.parse 对象并检查它:
uniq
var myStorageObject = JSON.parse(localStorage.getItem("uniq")); window.alert(myStorageObject.b);
如果在本地存储中只有一个或几个对象,那么这样做是可以的。但是假设你有一千个对象,所有对象都有一个属性 b,你想用那些 b==2的对象做一些事情。使用本地存储,您必须遍历整个存储,并在每个项目上检查 b,这是大量浪费的处理。
b
b==2
使用 IndexedDB 可以存储 除了字符串之外的东西: “这包括简单类型,如 DOMString 和 Date 以及 Object 和 Array 实例。”不仅如此,您还可以对存储在值中的对象的属性进行 创建索引操作。因此,使用 IndexedDb,您可以在其中放入相同的上千个对象,但是在 b属性上创建一个索引,并使用该索引来检索 b==2所在的对象,而不需要扫描存储中的每个对象。
至少想法是这样的,IndexedDB API 并不是很直观。
它们似乎与异步调用运行在同一个线程中。这怎么可能不会阻塞用户界面呢?
异步与多线程 JavaScript 通常不是多线程的不是一回事。如果您想尽量减少阻塞 UI,那么在 JS 中执行的任何繁重处理都会阻塞 UI,请尝试 网络工作者。
IndexedDB 允许更大的存储。为什么不增加 HTML5存储的大小?
因为,如果没有适当的索引,它会变得越来越慢,越来越大。
IndexedDB 知道“ range”,这样就可以搜索和检索所有以“ ab”开头、以“ abd”结尾的记录,从而找到“ abc”等等。
我偶然看到这篇讨论本地存储与 indexeddb 以及其他可能选项的好文章。
(以下所有值以毫秒为单位)
Https://nolanlawson.com/2015/09/29/indexeddb-websql-localstorage-what-blocks-the-dom/
从文章中总结(完全是作者的观点) ,
在 Firefox 和 Chrome 中,IndexedDB 在基本键值插入方面比 LocalStorage 慢,而且它仍然阻塞 DOM。在 Chrome 中,它也比 WebSQL 慢,后者确实阻塞了 DOM,但是速度远不及后者。只有在 Edge 和 Safari 中,IndexedDB 才能在后台运行而不中断 UI,更糟糕的是,这两种浏览器只部分实现了 IndexedDB 规范。
IndexedDB 在 web worker 中工作得很好,它以大致相同的速度运行,但没有阻塞 DOM。唯一的例外是 Safari,它不支持 worker 内部的 IndexedDB,但仍然不阻塞 UI。
如果数据简单且最小,则 localmemory 是理想的
Run the following in console of browser. It will create a separate entity in Application > Storage alongside LocalStorage and SessionStorage
const request = indexedDB.open("notes"); request.onupgradeneeded = e => { alert("upgrade"); } request.onsuccess = e => { alert("success"); } request.onerror = e => { alert("error"); }
您可以使用所有 CRUD 操作来查询这个存储,而不像其他两个存储那样具有较小的灵活性和可使用的功能。