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