Kurzfassung
Weitere Browser folgen in Chrome 61. den von einer Web-App verwendeten Speicher und wie viel verfügbar ist über:
if ('storage' in navigator && 'estimate' in navigator.storage) {
navigator.storage.estimate().then(({usage, quota}) => {
console.log(`Using ${usage} out of ${quota} bytes.`);
});
}
Moderne Web-Apps und Datenspeicher
Wenn Sie an den Speicherbedarf einer modernen Webanwendung denken, ist es hilfreich, Das, was gespeichert wird, lassen sich in zwei Kategorien unterteilen: die Kerndaten, die zum Laden benötigt werden. die Webanwendung und die Daten, die für eine sinnvolle Nutzerinteraktion benötigt werden, ob die Anwendung geladen ist.
Der erste Datentyp, der zum Laden Ihrer Webanwendung benötigt wird, besteht aus HTML,
JavaScript, CSS und vielleicht einige Bilder. Service Worker sowie
die Cache Storage API,
die erforderliche Infrastruktur bereitstellen,
um diese Kernressourcen zu speichern und
um Ihre Webanwendung schnell zu laden. Idealerweise wird damit das Netzwerk vollständig umgangen.
Tools, die sich in den Erstellungsprozess Ihrer Webanwendung integrieren lassen, wie das neue
Workbox-Bibliotheken oder ältere Versionen
sw-precache
,
das Speichern, Aktualisieren und Verwenden dieser Art von
data.)
Aber was ist mit dem anderen Datentyp? Diese Ressourcen werden nicht benötigt, um Ihre Webanwendung laden, aber das kann auch eine entscheidende Rolle Nutzererfahrung. Wenn Sie zum Beispiel eine Webanwendung zur Bildbearbeitung schreiben, können Sie eine oder mehrere lokale Kopien eines Bildes speichern möchten, damit Nutzende zwischen Überarbeitungen hin und her wechseln und ihre Arbeit rückgängig machen. Wenn Sie ein Offline-Medienmedium ist das lokale Speichern von Audio- oder Videodateien . Jede Web-App, die personalisiert werden kann, muss einige eine Art von Statusinformationen. Woher wissen Sie, wie viel Speicherplatz für diese Art von Laufzeitspeicherung Und was passiert, wenn kein Platz mehr vorhanden ist?
Vergangenheit: window.webkitStorageInfo
und navigator.webkitTemporaryStorage
Browser haben diese Art der Selbstprüfung in der Vergangenheit über das Präfix
Benutzeroberflächen wie die sehr alten (und veralteten)
window.webkitStorageInfo
,
und die noch nicht ganz so alt sind, aber immer noch
navigator.webkitTemporaryStorage
Diese Oberflächen bieten zwar nützliche Informationen,
als Webstandards definieren.
Hier kommt der WHATWG-Speicherstandard ins Bild gelangt.
Die Zukunft: navigator.storage
Im Rahmen der laufenden Arbeit am Storage Living Standard wurden einige nützliche APIs entwickelt,
es an die
StorageManager
die den Browsern wie folgt angezeigt wird:
navigator.storage
Wie viele andere neuere Web-APIs ist navigator.storage
nur auf sicheren Geräten verfügbar.
(über HTTPS oder localhost bereitgestellt werden).
Letztes Jahr haben wir die Funktion
navigator.storage.persist()
, mit der Ihre Webanwendung anfordern kann,
von der automatischen Bereinigung ausgenommen.
Es wird nun durch die Methode navigator.storage.estimate()
verknüpft, die als
moderner Ersatz für navigator.webkitTemporaryStorage.queryUsageAndQuota()
.
estimate()
gibt ähnliche Informationen zurück, stellt jedoch ein
Promise-basierte Oberfläche,
was den anderen modernen asynchronen APIs entspricht. Das Versprechen,
estimate()
gibt Auflösungen mit einem Objekt zurück, das zwei Eigenschaften enthält: usage
,
steht für die Anzahl der aktuell verwendeten Byte und quota
für die
die maximale Anzahl von Byte, die von der aktuellen
origin zurück.
Wie alles andere in Bezug auf den Speicherplatz gilt auch das Kontingent für
origin.)
Wenn eine Webanwendung versucht, Daten zu speichern, z. B. mit IndexedDB oder dem
Cache Storage API: Daten, die groß genug sind, um einen bestimmten Ursprung über die
verfügbar ist, schlägt die Anfrage mit einem
QuotaExceededError
Ausnahme.
Speicherplatzschätzungen in der Praxis
Wie Sie estimate()
genau verwenden, hängt davon ab, welche Art von Daten Ihre Anwendung benötigt,
speichern. Beispielsweise können Sie ein Steuerelement in Ihrer Benutzeroberfläche aktualisieren, mit dem Nutzer
wie viel Speicherplatz nach Abschluss eines Speichervorgangs verwendet wird.
Idealerweise stellen Sie dann eine Schnittstelle zur Verfügung, über die Nutzende Daten manuell bereinigen können.
die nicht mehr benötigt werden. Sie können Code folgendermaßen schreiben:
// For a primer on async/await, see
// https://developers.google.com/web/fundamentals/getting-started/primers/async-functions
async function storeDataAndUpdateUI(dataUrl) {
// Pro-tip: The Cache Storage API is available outside of service workers!
// See https://googlechrome.github.io/samples/service-worker/window-caches/
const cache = await caches.open('data-cache');
await cache.add(dataUrl);
if ('storage' in navigator && 'estimate' in navigator.storage) {
const {usage, quota} = await navigator.storage.estimate();
const percentUsed = Math.round(usage / quota * 100);
const usageInMib = Math.round(usage / (1024 * 1024));
const quotaInMib = Math.round(quota / (1024 * 1024));
const details = `${usageInMib} out of ${quotaInMib} MiB used (${percentUsed}%)`;
// This assumes there's a <span id="storageEstimate"> or similar on the page.
document.querySelector('#storageEstimate').innerText = details;
}
}
Wie genau ist die Schätzung?
Es ist kaum zu übersehen, dass die Daten, die Sie von der Funktion erhalten,
eine Schätzung des von einem Ursprung genutzten Raums. Sie befindet sich direkt in der Funktion
Name Weder die usage
- noch die quota
-Werte sind dafür vorgesehen, stabil zu sein.
wird empfohlen, Folgendes zu berücksichtigen:
usage
gibt an, wie viele Byte ein bestimmter Ursprung effektiv für same-origin die wiederum durch interne Komprimierungstechniken beeinflusst werden können. fester Größe für Zuweisungsblöcke, die ungenutzten Platz umfassen könnten, sowie von "Tombstone" Einträge die nach dem Löschen vorübergehend erstellt werden können. Um das Auslaufen zu vermeiden von genauen Größeninformationen, ursprungsübergreifenden, Undurchsichtige Ressourcen lokal gespeicherte zusätzliche Padding-Byte zur Gesamt-usage
Wert.quota
gibt an, wie viel Platz derzeit für einen Startort reserviert ist. Die hängt von konstanten Faktoren wie der Gesamtspeichergröße ab, Anzahl potenziell flüchtiger Faktoren, einschließlich der Größe des Speicherplatzes das derzeit nicht verwendet wird. So wie andere Anwendungen auf einem Gerät Daten, also die Menge an Speicherplatz, die der Browser App-Ursprung wahrscheinlich ändern.
Jetzt neu: Funktionserkennung und Fallbacks
estimate()
ist ab Chrome 61 standardmäßig aktiviert. Firefox ist
mit navigator.storage
experimentieren. Seit August 2017 ist es jedoch noch nicht
standardmäßig aktiviert. Erforderliche Schritte
Aktivieren Sie die Einstellung dom.storageManager.enabled
.
um sie zu testen.
Wenn Sie mit Funktionen arbeiten, die noch nicht in allen Browsern unterstützt werden,
Funktionserkennung ist ein Muss. Sie können die Funktionserkennung mit einer
Promise-basierter Wrapper auf dem älteren navigator.webkitTemporaryStorage
, um eine einheitliche Schnittstelle wie folgt bereitzustellen:
function storageEstimateWrapper() {
if ('storage' in navigator && 'estimate' in navigator.storage) {
// We've got the real thing! Return its response.
return navigator.storage.estimate();
}
if ('webkitTemporaryStorage' in navigator &&
'queryUsageAndQuota' in navigator.webkitTemporaryStorage) {
// Return a promise-based wrapper that will follow the expected interface.
return new Promise(function(resolve, reject) {
navigator.webkitTemporaryStorage.queryUsageAndQuota(
function(usage, quota) {resolve({usage: usage, quota: quota})},
reject
);
});
}
// If we can't estimate the values, return a Promise that resolves with NaN.
return Promise.resolve({usage: NaN, quota: NaN});
}