Szacowanie dostępnego miejsca

tl;dr

Chrome 61 wraz z kolejnymi przeglądarkami pokazuje teraz, miejsca na dane wykorzystywanego przez aplikację internetową oraz jego ilości:

if ('storage' in navigator && 'estimate' in navigator.storage) {
  navigator.storage.estimate().then(({usage, quota}) => {
    console.log(`Using ${usage} out of ${quota} bytes.`);
  });
}

Nowoczesne aplikacje internetowe i miejsce na dane

Myśląc o zapotrzebowaniu na miejsce na dane w nowoczesnej aplikacji internetowej, warto wziąć pod uwagę podziel co zapisywanych, na 2 kategorie: podstawowe dane potrzebne do wczytywania. aplikacji internetowej i danych potrzebnych do jednorazowej interakcji aplikacja została wczytana.

Pierwszy typ danych, niezbędny do załadowania aplikacji internetowej, składa się z HTML, JavaScript i CSS a może też obrazy. Skrypty Service Worker – wraz z interfejs Cache Storage API, zapewnić infrastrukturę niezbędną do zapisania tych podstawowych zasobów, a następnie aby szybko załadować aplikację internetową, najlepiej całkowicie omijając sieć. (narzędzia, które integrują się z procesem kompilacji aplikacji internetowej, Biblioteki robocze lub starsze sw-precache, mogą w pełni zautomatyzować proces przechowywania, aktualizowania i używania tego typu data.)

A co z drugim rodzajem danych? To zasoby, które nie są potrzebne do wczytują aplikację internetową, ale mogą mieć kluczowe znaczenie dla ogólnego i uzyskiwanie dodatkowych informacji. Jeśli tworzysz na przykład aplikację internetową do edytowania obrazów, chcą zapisać co najmniej jedną lokalną kopię obrazu, co pozwala użytkownikom przełączać między zmianami i cofnąć swoją pracę. Lub jeśli tworzysz media offline łatwość odtwarzania, zapisywanie lokalnie plików audio i wideo funkcji. Każda spersonalizowana aplikacja internetowa musi zapisać rodzaj informacji o stanach. Jak sprawdzić, ile miejsca jest dostępne na ten typ pamięci środowiska wykonawczego? i co się stanie, gdy skończy Ci się miejsce?

Przeszłość: window.webkitStorageInfo i navigator.webkitTemporaryStorage

Przeglądarki dotychczas obsługiwały ten typ introspekcji za pomocą prefiksu interfejsów, takich jak bardzo stary (i wycofany) window.webkitStorageInfo i niezwykła, ale i niestandardowa navigator.webkitTemporaryStorage Interfejsy te dostarczają przydatnych informacji, ale nie zapewniają będzie w przyszłości standardem.

Dlatego warto stosować standard COWG Storage pojawi się na zdjęciu.

Przyszłość: navigator.storage

W ramach prac nad Storage Living Standard wprowadziliśmy kilka przydatnych interfejsów API, do StorageManager. który jest widoczny dla przeglądarek jako navigator.storage Podobnie jak wiele innych nowszych interfejsów API, usługa navigator.storage jest dostępna tylko w bezpiecznych (udostępniane przez HTTPS lub localhost).

W zeszłym roku wprowadziliśmy navigator.storage.persist(). która pozwala aplikacji internetowej zażądać, aby jej miejsce na dane są zwolnione z automatycznego czyszczenia.

Jest ona połączona metodą navigator.storage.estimate(), która służy jako nowoczesny zamiennik urządzenia navigator.webkitTemporaryStorage.queryUsageAndQuota(). Funkcja estimate() zwraca podobne informacje, ale ujawnia błąd interfejsu promise-based (obietnicę), co jest zgodne z innymi nowoczesnymi asynchronicznymi interfejsami API. Obietnica, Funkcja estimate() zwraca wartość obiektu zawierającego dwie właściwości: usage, oznacza liczbę obecnie używanych bajtów oraz quota, który reprezentuje maksymalna liczba bajtów, które może zapisać bieżąca origin. Tak jak w przypadku wszystkich innych kwestii związanych z miejscem na dane, limit jest stosowany do całej origin.)

Jeśli aplikacja internetowa próbuje zapisać dane, na przykład przy użyciu metody IndexedDB lub Cache Storage API – dane wystarczająco duże, by przenieść dany punkt początkowy dostępnego limitu, żądanie zakończy się niepowodzeniem z QuotaExceededError wyjątek.

Oszacowanie ilości miejsca na dane w praktyce

To, jak użyjesz estimate(), zależy od typu danych, których potrzebuje aplikacja sklepu. Można na przykład zaktualizować w interfejsie element sterujący, który umożliwia użytkownikom aby sprawdzać ilość miejsca zajętego po zakończeniu każdej operacji przechowywania. Najlepiej udostępnić interfejs, który pozwoli użytkownikom ręcznie wyczyścić dane które nie są już potrzebne. Możesz napisać kod w tych wierszach:

// 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;
  }
}

Jak dokładne są te dane?

Trudno umknąć fakt, że dane uzyskiwane dzięki funkcji to oszacowanie przestrzeni używanej przez punkt początkowy. Jest on dostępny w funkcji imię! Ani wartości usage, ani quota nie powinny być stabilne, więc warto wziąć pod uwagę te kwestie:

  • usage pokazuje, ile bajtów efektywnie dane źródło wykorzystuje na potrzeby same-origin na które mogą wpływać wewnętrzne techniki kompresji, bloki przydzielania o stałym rozmiarze, które mogą uwzględniać nieużywane miejsce, z „tombstone” rekordy które mogą zostać tymczasowo utworzone po usunięciu treści. Aby zapobiec wyciekom o dokładnych informacjach o rozmiarze, między domenami nieprzejrzyste zasoby zapisane lokalnie mogą powodować dodatkowe bajty dopełnienia w ogólnym rozmiarze usage .
  • quota odzwierciedla ilość miejsca obecnie zarezerwowanego dla źródła. zależy od pewnych stałych czynników, takich jak ogólny rozmiar miejsca na dane, liczbę potencjalnie zmiennych czynników, w tym ilość dostępnego miejsca która nie jest obecnie używana. Tak jak inne aplikacje na urządzeniu zapisują lub usuwają ilość miejsca, którą przeglądarka może przeznaczyć na witrynę źródło aplikacji prawdopodobnie się zmieni.

Czas teraźniejszy: wykrywanie cech i wartości zastępcze

Od wersji Chrome 61 interfejs estimate() jest domyślnie włączony. Firefox jest eksperymentuje z narzędziem navigator.storage, ale od sierpnia 2017 r. nie został włączony domyślnie włączone. Czynności, które musisz wykonać włącz preferencję dom.storageManager.enabled aby ją przetestować.

Podczas pracy z funkcjami, które nie są jeszcze obsługiwane we wszystkich przeglądarkach, wykrywanie cech charakterystycznych jest konieczne. Wykrywanie cech możesz połączyć z kod oparty na obietnicach nałożony na starszą wersję navigator.webkitTemporaryStorage aby uzyskać spójny interfejs w następujący sposób:

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});
}