उपलब्ध स्टोरेज के लिए बची जगह का अनुमान लगाना

Jeff Posnick

बहुत ज़्यादा शब्द

अन्य ब्राउज़र के साथ आने वाले Chrome 61 वर्शन के साथ अब यह भी पता चलता है कि वेब ऐप्लिकेशन कितनी मेमोरी का इस्तेमाल कर रहा है और कितनी मेमोरी इनके ज़रिए उपलब्ध है:

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

मॉडर्न वेब ऐप्लिकेशन और डेटा सेव करने की सुविधा

जब आप किसी मॉडर्न वेब ऐप्लिकेशन के लिए, स्टोरेज की ज़रूरतों के बारे में सोचते हैं, तो इससे आपको क्या सेव किया जा रहा है, इसे दो कैटगरी में बांट दें: लोड करने के लिए ज़रूरी मुख्य डेटा वेब ऐप्लिकेशन और उपयोगकर्ता के काम के इंटरैक्शन के लिए ज़रूरी डेटा एक बार ऐप्लिकेशन लोड हो जाता है.

डेटा का पहला टाइप, जो आपके वेब ऐप्लिकेशन को लोड करने के लिए ज़रूरी होता है उसमें एचटीएमएल शामिल है, JavaScript, CSS, और शायद कुछ इमेज. सर्विस वर्कर. कैश मेमोरी एपीआई, इन मुख्य संसाधनों को बचाने और इनका इस्तेमाल करने के लिए ज़रूरी इंफ़्रास्ट्रक्चर उपलब्ध कराना आपके वेब ऐप्लिकेशन को तेज़ी से लोड करने के लिए उन्हें बाद में लोड करते हैं. खास तौर पर, नेटवर्क को बायपास करते हुए. (ऐसे टूल जो आपके वेब ऐप्लिकेशन की बिल्ड प्रोसेस के साथ इंटिग्रेट हो जाते हैं, जैसे कि नए वर्शन Workbox लाइब्रेरी या पुरानी किताबों sw-precache, पूरी तरह से अपने-आप होने वाली प्रोसेस को पूरी तरह से अपने-आप स्टोर करने, अपडेट करने, और इस्तेमाल करने का काम कर सकता है data.)

हालांकि, दूसरी तरह के डेटा का क्या होगा? इन संसाधनों की ज़रूरत नहीं है लोड करने में मदद करने के लिए बनाया गया है. अनुभव. उदाहरण के लिए, यदि आप चित्र संपादन वाला कोई वेब ऐप्लिकेशन लिख रहे हैं, तो आप किसी इमेज की एक या उससे ज़्यादा लोकल कॉपी सेव करना चाहते हैं. इससे उपयोगकर्ता इन पर स्विच कर सकते हैं और उनके काम को पहले जैसा करें. या अगर आप एक ऑफ़लाइन मीडिया डेवलप कर रहे हैं, कॉन्टेंट चलाने और ऑडियो या वीडियो फ़ाइलों को स्थानीय तौर पर सेव करने की अहमियत सुविधा. मनमुताबिक बनाए जा सकने वाले हर वेब ऐप्लिकेशन के लिए कुछ मेमोरी की ज़रूरत होती है राज्य की जानकारी को क्रम में लगा सकता है. यह कैसे पता चलेगा कि इस तरह के रनटाइम स्टोरेज के लिए कितना स्टोरेज उपलब्ध है, और कमरा खत्म हो जाने पर क्या होता है?

पिछली यादें: window.webkitStorageInfo और navigator.webkitTemporaryStorage

ब्राउज़र अब भी इस तरह की जांच करने की सुविधा देता है. इसके लिए, ब्राउज़र प्रीफ़िक्स का इस्तेमाल करता है इंटरफ़ेस, जैसे कि बहुत पुराने (और बहिष्कृत) window.webkitStorageInfo और आम तौर पर पुराना न होने के बावजूद, सामान्य navigator.webkitTemporaryStorage. इन इंटरफ़ेस से आपको काम की जानकारी मिलती है, लेकिन आने वाले समय में लागू होगी.

यही वह जगह है जहां WhatWG Storage Standard चित्र के अंदर प्रवेश करता है.

आने वाले समय की जानकारी: navigator.storage

स्टोरेज लिविंग स्टैंडर्ड पर काम चल रहा है. इसके तहत, काम के कुछ एपीआई उपलब्ध कराए गए हैं CANNOT TRANSLATE StorageManager इंटरफ़ेस, जो ब्राउज़र में navigator.storage. कई नए वेब एपीआई की तरह, navigator.storage भी सिर्फ़ सुरक्षित प्लैटफ़ॉर्म पर उपलब्ध है (एचटीटीपीएस या लोकलहोस्ट के ज़रिए उपलब्ध कराया गया) ऑरिजिन.

पिछले साल, हमने navigator.storage.persist() तरीका है, जो आपके वेब ऐप्लिकेशन को यह अनुरोध करने की अनुमति देता है कि अपने-आप क्लीनअप करने की सुविधा से छूट दी गई है.

अब इसे navigator.storage.estimate() तरीके से जोड़ा गया है, जो navigator.webkitTemporaryStorage.queryUsageAndQuota() की आधुनिक जगह. estimate() मिलती-जुलती जानकारी दिखाता है, लेकिन प्रॉमिस पर आधारित इंटरफ़ेस, जो अन्य मॉडर्न एसिंक्रोनस एपीआई के मुताबिक है. वह वादा estimate() फ़ंक्शन का इस्तेमाल करने पर, दो प्रॉपर्टी वाले किसी ऑब्जेक्ट का पता चलता है: usage, मौजूदा समय में इस्तेमाल की गई बाइट की संख्या दिखाता है और quota मौजूदा स्टोरेज से सेव की जा सकने वाली ज़्यादा से ज़्यादा बाइट ऑरिजिन. (स्टोरेज से जुड़ी बाकी सभी चीज़ों की तरह ही, कोटा पूरे नेटवर्क पर लागू होता है origin.)

यदि कोई वेब ऐप्लिकेशन स्टोर करने की कोशिश करता है—उदाहरण के लिए, IndexedDB या कैश मेमोरी एपीआई—ऐसा डेटा जो किसी दिए गए ऑरिजिन को उपलब्ध कोटा है, तो अनुरोध इसके साथ विफल हो जाएगा QuotaExceededError अपवाद.

स्टोरेज के अनुमान इस्तेमाल किए जा रहे हैं

आप estimate() का इस्तेमाल कैसे करते हैं, यह इस बात पर निर्भर करता है कि आपके ऐप्लिकेशन को किस तरह के डेटा की ज़रूरत है स्टोर. उदाहरण के लिए, अपने इंटरफ़ेस में किसी कंट्रोल को अपडेट करके, उपयोगकर्ताओं को जानें कि प्रत्येक मेमोरी कार्यवाही पूर्ण हो जाने के बाद कितनी जगह का उपयोग हो रहा है. इसके बाद, आपको ऐसा इंटरफ़ेस देना चाहिए जिससे उपयोगकर्ता मैन्युअल तरीके से डेटा साफ़ कर सकें अब उसकी ज़रूरत नहीं है. इन लाइनों के साथ कोड लिखा जा सकता है:

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

अनुमान कितना सटीक होता है?

यह जानना मुश्किल है कि फ़ंक्शन से वापस मिलने वाला डेटा उस स्पेस का अनुमान जिसे ऑरिजिन इस्तेमाल कर रहा है. यह फ़ंक्शन में ठीक है नाम! usage और quota, दोनों में से किसी भी वैल्यू को स्थिर नहीं किया जा सकता. इसलिए हमारा सुझाव है कि आप इन बातों का ध्यान रखें:

• usage से पता चलता है कि कोई ऑरिजिन, कितने बाइट का असरदार तरीके से इस्तेमाल कर रहा है एक ही ऑरिजिन उस पर अंदरूनी कंप्रेशन तकनीकों से असर पड़ सकता है. तय साइज़ में असाइन किए जाने वाले ऐसे ब्लॉक जिनमें इस्तेमाल न हो रही जगह और मौजूदगी "टूंबस्टोन" में से रिकॉर्ड जो कुछ समय के लिए, कुछ समय के लिए मिटाने के बाद भी बन सकती है. लीक रोकने के लिए सटीक साइज़ की जानकारी, क्रॉस-ऑरिजिन, ओपेक रिसॉर्स स्थानीय तौर पर सेव करने से, usage पर ज़्यादा पैडिंग (जगह) बाइट बढ़ सकती हैं वैल्यू.
• quota से पता चलता है कि ऑरिजिन के लिए फ़िलहाल कितना स्टोरेज बचा है. कॉन्टेंट बनाने यह वैल्यू लगातार कुछ चीज़ों पर निर्भर करती है. जैसे, कुल स्टोरेज का साइज़. स्टोरेज के लिए बची जगह समेत अन्य चीज़ों की संख्या जो फ़िलहाल इस्तेमाल में नहीं हैं. इसलिए डिवाइस पर अन्य ऐप्लिकेशन की तरह ही उन्हें लिखें या मिटाएं डेटा, वह स्थान जितना ब्राउज़र आपके वेब के लिए समर्पित है ऐप्लिकेशन का ऑरिजिन बदल सकता है.

मौजूद है: सुविधा की पहचान और फ़ॉलबैक

Chrome 61 और उसके बाद के वर्शन में, estimate() डिफ़ॉल्ट रूप से चालू होता है. Firefox यह है navigator.storage पर एक्सपेरिमेंट किया जा रहा है. हालांकि, अगस्त 2017 से इसे डिफ़ॉल्ट रूप से चालू. आपको ये काम करने होंगे dom.storageManager.enabled की सेटिंग चालू करें ताकि इसकी जांच की जा सके.

जो सुविधाएं फ़िलहाल सभी ब्राउज़र पर काम नहीं करती हैं उनके साथ काम करते समय, सुविधा का पता लगाना बहुत ज़रूरी है. आप सुविधा पहचान को पुराने navigator.webkitTemporaryStorage की स्क्रीन पर प्रॉमिस पर आधारित रैपर में एक जैसा इंटरफ़ेस उपलब्ध कराने के लिए इन तरीकों का इस्तेमाल किया गया है:

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