indexedDB在概念上与HTML5本地存储有何不同？
Sam*_*son 67 javascript html5 indexeddb
- indexedDB和本地存储都是键值存储.拥有两个键/值存储的优势是什么？
- indexedDB是异步的,但是连接(最耗时的东西)是手动的.它们似乎与异步调用在同一个线程中运行.这怎么会阻止用户界面？
- indexedDB允许更大的商店.为什么不增加HTML5商店的大小？
- 我在挠头.indexedDB有什么意义？
rob*_*rtc 92
IndexedDB不是与本地存储相同的键值存储.本地存储只存储字符串,因此要将对象放在本地存储中,通常的方法是JSON.stringify它:
myObject = {a: 1, b: 2, c: 3};
localStorage.setItem("uniq", JSON.stringify(myObject));
这对于使用键查找对象很好uniq,但是将myObject的属性从本地存储中取出的唯一方法是JSON.parse该对象并检查它:
var myStorageObject = JSON.parse(localStorage.getItem("uniq"));
window.alert(myStorageObject.b);
如果您在本地存储中只有一个或几个对象,那么这很好.但是想象一下,你有一千个物体,所有这些物体都有一个属性b,而你想要用那些物体做些什么b==2.使用本地存储,您将需要遍历整个商店并检查b每个项目,这是一个浪费很多的处理.
使用IndexedDB,您可以在值中存储字符串以外的东西:"这包括简单类型,如DOMString和Date以及对象和数组实例." 不仅如此,您还可以在存储在值中的对象的属性上创建索引.因此,使用IndexedDb,您可以在其中放置相同的数千个对象,但在b属性上创建索引并使用它来检索对象,b==2而无需扫描存储中的每个对象的开销.
至少这是个主意.IndexedDB API不是很直观.
它们似乎与异步调用在同一个线程中运行.这怎么会阻止用户界面？
异步与多线程不同,JavaScript通常不是多线程的.如果你想最小化阻止UI尝试Web Workers,你在JS中做的任何繁重的处理都会阻止UI .
indexedDB允许更大的商店.为什么不增加HTML5商店的大小？
因为,如果没有适当的索引,它会变得越来越慢.
- 您可能还想查看以下[问题](http://stackoverflow.com/questions/14314065/are-cookie-read-write-atomic-in-browser)的答案,了解IndexedDB如何支持本地存储中的事务确实.没有交易支持可能是在Chrome和Opera等浏览器中使用多个选项卡/窗口访问本地存储的问题,每个选项卡使用一个单独的进程/线程. (2认同)
- 此外，indexeddb 是网页与其上运行的服务工作人员之间的一种通信模式。Service Worker 无法访问 localStorage。 (2认同)
Amr*_*ani 12
我看到了这篇很好的文章，讨论了 localstorage 与 indexeddb 以及其他可能的选项。
（以下所有值均以毫秒为单位）
https://nolanlawson.com/2015/09/29/indexeddb-websql-localstorage-what-blocks-the-dom/
总结文章（完全是作者的观点），
- 在 Chrome、Firefox 和 Edge 的所有三个中，LocalStorage 在您写入数据时完全阻塞 DOM 2。阻塞比在内存中更明显，因为浏览器实际上必须刷新到磁盘。
- 毫不奇怪，因为任何同步代码都是阻塞的，所以内存中的操作也会阻塞。DOM 在长时间运行的插入过程中会阻塞，但除非您处理大量数据，否则您不太可能注意到，因为内存操作非常快。
在 Firefox 和 Chrome 中，IndexedDB 在基本键值插入方面比 LocalStorage 慢，并且它仍然阻塞 DOM。在 Chrome 中，它也比阻止 DOM 的 WebSQL 慢，但几乎没有那么多。只有在 Edge 和 Safari 中，IndexedDB 才能在不中断 UI 的情况下设法在后台运行，更糟糕的是，这两个浏览器仅部分实现了 IndexedDB 规范。
IndexedDB 在 Web Worker 中运行良好，它以大致相同的速度运行，但不会阻塞 DOM。唯一的例外是 Safari，它不支持 worker 内部的 IndexedDB，但它仍然不会阻止 UI。
如果数据简单且最少，localmemory 是理想的选择