ब्राउज़र सहायता
-
अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है
-
अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है
-
अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है
-
अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है
आज के दौर में आज-कल के मॉडर्न ब्राउज़र कभी-कभी पेजों को निलंबित कर देते हैं या फिर उन्हें मैन्युअल तरीके से खारिज कर देते हैं सिस्टम के संसाधन सीमित हैं. आने वाले समय में, ब्राउज़र ऐसा करना चाहेंगे ताकि वे कम ऊर्जा और मेमोरी की खपत कर सकें. Page Lifecycle API लाइफ़साइकल हुक उपलब्ध कराता है, ताकि आपके पेज इन ब्राउज़र को सुरक्षित तरीके से हैंडल कर सकें उपयोगकर्ता अनुभव को प्रभावित किए बिना हस्तक्षेप करते हैं. एपीआई को देखें, देखें कि आपको अपने ऐप्लिकेशन में ये सुविधाएं लागू करनी चाहिए या नहीं.
बैकग्राउंड
ऐप्लिकेशन लाइफ़साइकल, आधुनिक ऑपरेटिंग सिस्टम को मैनेज करने का मुख्य तरीका है संसाधन. Android, iOS, और Windows के हाल ही के वर्शन पर, ऐप्लिकेशन इस्तेमाल किए जा सकते हैं और को ओएस से किसी भी समय रोका जा सकता है. इससे इन प्लैटफ़ॉर्म को इस्तेमाल करने के दौरान, ऐसे संसाधनों को फिर से बांट सकते हैं जहां वे उपयोगकर्ता को सबसे ज़्यादा फ़ायदा पहुंचा सकें.
वेब पर, पहले ऐसी कोई लाइफ़साइकल नहीं रही है. साथ ही, ऐप्लिकेशन को बनाए रखने अनिश्चित काल तक रहने दें. बड़ी संख्या में वेब पेजों के साथ, एक अहम सिस्टम इसके लिए, मेमोरी, सीपीयू, बैटरी, और नेटवर्क जैसे संसाधनों की सदस्यता ली जा सकती है, इससे असली उपयोगकर्ता को खराब अनुभव मिलता है.
हालांकि, वेब प्लैटफ़ॉर्म पर लंबे समय से ऐसे इवेंट चल रहे हैं जो लाइफ़साइकल स्टेट से जुड़े हैं
— जैसे कि load
,
unload
, और
visibilitychange
— इन इवेंट से सिर्फ़ डेवलपर को
उपयोगकर्ता की ओर से शुरू की गई लाइफ़साइकल की स्थिति में होने वाले बदलावों के जवाब के लिए. वेब के काम करने के लिए
वे कम क्षमता वाले डिवाइसों पर भरोसा करते हैं (और संसाधनों को लेकर सामान्य तौर पर इन
सभी प्लैटफ़ॉर्म) ब्राउज़र को, सिस्टम पर फिर से दावा करने और उसे फिर से असाइन करने के लिए एक तरीका चाहिए होता है
संसाधन.
इतना ही नहीं, आज-कल ब्राउज़र भी संसाधनों को बचाने के लिए कदम उठा रहे हैं और कई ब्राउज़र (खास तौर पर Chrome) को खोजने के लिए, उनका ज़्यादा से ज़्यादा इस्तेमाल करना — उनके कुल रिसॉर्स फ़ुटप्रिंट को कम करना.
समस्या यह है कि डेवलपर के पास इस तरह की टेक्नोलॉजी के लिए तैयारी करने का कोई तरीका नहीं है करते हैं या आपको पता होता है कि वे किए जा रहे हैं. इसका मतलब है ब्राउज़र ऐसे होने चाहिए जो कंज़र्वेटिव या जोखिम भरे वेब पेज न हों.
Page Lifecycle API इस समस्या को हल करने की कोशिश करता है:
- वेब पर लाइफ़साइकल स्थितियों के सिद्धांत को पेश किया गया है और उनके लिए स्टैंडर्ड तय किया गया है.
- सिस्टम से शुरू की गई ऐसी नई स्थितियां तय करना जो ब्राउज़र को ऐसे संसाधन जिन्हें छिपे हुए या इनऐक्टिव टैब में इस्तेमाल किया जा सकता है.
- ऐसे नए एपीआई और इवेंट बनाना जो वेब डेवलपर को जवाब देने की अनुमति देते हों इन नए सिस्टम से शुरू किए गए राज्यों में और वहां से ट्रांज़िशन करता है.
यह समाधान, अनुमान लगाने की वह सुविधा देता है जिसकी ज़रूरत वेब डेवलपर को बनाना पड़ता है ऐप्लिकेशन, सिस्टम इंटरवेंशन के हिसाब से काम करते हैं. साथ ही, इससे ब्राउज़र को हम सिस्टम के संसाधनों को अच्छे से ऑप्टिमाइज़ करते हैं. इससे सभी वेब उपयोगकर्ताओं को फ़ायदा मिलता है.
इस पोस्ट के बाकी हिस्से में, पेज लाइफ़साइकल की नई सुविधाओं के बारे में बताया गया है और यह पता लगाने के लिए कि वे सभी मौजूदा वेब प्लैटफ़ॉर्म राज्यों से कैसे जुड़े हैं और इवेंट शामिल हैं. इसके अलावा, इससे टाइप किए गए प्रॉडक्ट या सेवाओं से जुड़े सुझाव और सबसे सही तरीके भी मिलेंगे काम डेवलपर को हर राज्य में करना चाहिए (और नहीं भी करना चाहिए).
पेज लाइफ़साइकल की स्थितियों और इवेंट की खास जानकारी
पेज की लाइफ़साइकल की सभी स्थितियां अलग-अलग होती हैं और ये अलग-अलग होती हैं. इसका मतलब है कि पेज एक ही होता है एक समय में सिर्फ़ एक स्थिति में हो सकता है. साथ ही, किसी पेज के लाइफ़साइकल की स्थिति में हुए ज़्यादातर बदलाव आम तौर पर, डीओएम इवेंट की मदद से निगरानी की जा सकती हैं (अपवादों के लिए हर राज्य के लिए डेवलपर के सुझाव देखें).
यह पेज लाइफ़साइकल के बारे में बताने और इसे समझने का सबसे आसान तरीका हो सकता है उनके बीच ट्रांज़िशन दिखाने वाले इवेंट — इस डायग्राम के ज़रिए दिखाए जा रहे हैं:
राज्य
इस टेबल में, हर राज्य के बारे में पूरी जानकारी दी गई है. इसमें संभावित रूप से इस्तेमाल करने से पहले और बाद में आने वाले राज्यों के साथ-साथ इवेंट भी आ सकते हैं. का इस्तेमाल बदलावों को मॉनिटर करने के लिए किया जाता है.
स्थिति | ब्यौरा |
---|---|
ऐक्टिव |
कोई पेज चालू स्थिति में है, अगर वह दिख रहा है और उसमें इनपुट फ़ोकस.
पिछली संभावित स्थितियां: |
काम नहीं कर रहा |
अगर कोई पेज पैसिव स्टेटस में है, तो हो सकता है कि वह दिख रहा हो और ऐसा करता हो इनपुट फ़ोकस नहीं है.
पिछली संभावित स्थितियां:
अगली संभावित स्थितियां: |
छिपे हुए |
अगर कोई पेज छिपाया गया है, तो उसे फ़्रीज़ किया गया हो, खारिज किया गया हो या खत्म कर दिया गया हो).
पिछली संभावित स्थितियां:
अगली संभावित स्थितियां: |
फ़्रोज़न |
फ़्रीज़ की गई स्थिति में ब्राउज़र,
फ़्रीज़ेबल
टास्क
टास्क सूची को तब तक जारी रखें, जब तक पेज को फ़्रीज़ नहीं किया जाता. इसका मतलब है कि
JavaScript टाइमर और फ़ेच कॉलबैक की सुविधा काम नहीं करती. पहले से चल रहा है
टास्क पूरे हो सकते हैं (सबसे ज़रूरी बात यह है कि
सीपीयू/बैटरी/डेटा खर्च को सुरक्षित रखने के लिए ब्राउज़र पेजों को फ़्रीज़ करते हैं; वे तेज़ी से चालू करने के लिए भी किया जा सकता है बैक/फ़ॉरवर्ड नेविगेशन — पूरा पेज बनाने की ज़रूरत नहीं होती फिर से लोड करें.
पिछली संभावित स्थितियां:
अगली संभावित स्थितियां: |
खत्म किया गया |
किसी पेज के शुरू होने के बाद, उसे बंद की स्थिति में रखा जाता है अनलोड हो गया और ब्राउज़र से मेमोरी से मिटा दिया गया. नहीं नए टास्क इस स्थिति में शुरू हो सकते हैं. साथ ही, जारी टास्क उन्हें मार दिया जाता है.
पिछली संभावित स्थितियां:
अगली संभावित स्थितियां: |
खारिज किया गया |
कोई पेज डिसकार्ड की स्थिति में होता है, जब उसे ब्राउज़र करने की ज़रूरत नहीं होती. कोई टास्क, इवेंट कॉलबैक या इस स्थिति में JavaScript को किसी भी तरह का चलाया जा सकता है. आम तौर पर, इसे खारिज कर दिया जाता है संसाधन पाबंदियों के तहत होता है, जहां नई प्रक्रिया शुरू करना करना संभव नहीं है. हटाई गई स्थिति में, टैब अपने-आप सेट हो जाता है (इसमें टैब टाइटल और फ़ेविकॉन शामिल हैं) आम तौर पर उपयोगकर्ता को दिखते हैं भले ही पेज हटा दिया गया हो.
पिछली संभावित स्थितियां:
अगली संभावित स्थितियां: |
इवेंट
ब्राउज़र बहुत सारे इवेंट भेजते हैं, लेकिन उनमें से सिर्फ़ एक छोटा हिस्सा ही पेज लाइफ़साइकल स्थिति में संभावित बदलाव. नीचे दी गई टेबल में सभी इवेंट की जानकारी दी गई है जो लाइफ़साइकल से जुड़ी होती हैं. साथ ही, इसमें यह भी बताया जाता है कि वे किन स्थितियों में पहुंच सकते हैं और किन स्थितियों में पहुंच सकते हैं.
नाम | ब्यौरा |
---|---|
focus
|
एक DOM एलिमेंट पर फ़ोकस किया गया है.
ध्यान दें:
पिछली संभावित स्थितियां:
संभावित मौजूदा स्थितियां: |
blur
|
एक DOM एलिमेंट ने फ़ोकस खो दिया है.
ध्यान दें:
पिछली संभावित स्थितियां:
संभावित मौजूदा स्थितियां: |
visibilitychange
|
दस्तावेज़ का
पिछली संभावित स्थितियां:
संभावित मौजूदा स्थितियां: |
freeze
*
|
पेज को अभी-अभी फ़्रीज़ किया गया है. कोई भी पेज की टास्क सूचियों में, फ़्रीज़ किए जा सकने वाले टास्क शुरू नहीं होंगे.
पिछली संभावित स्थितियां:
संभावित मौजूदा स्थितियां: |
resume
*
|
ब्राउज़र ने फ़्रीज़ किए गए पेज को फिर से शुरू कर दिया है.
पिछली संभावित स्थितियां:
संभावित मौजूदा स्थितियां: |
pageshow
|
सेशन के इतिहास की एंट्री ट्रैक की जा रही है. यह या तो बिलकुल नया पेज लोड हो सकता है या फिर
बैक/फ़ॉरवर्ड कैश मेमोरी. अगर पेज
इवेंट को बैक/फ़ॉरवर्ड कैश मेमोरी से लिया गया था,
पिछली संभावित स्थितियां:
संभावित मौजूदा स्थितियां: |
pagehide
|
किसी सेशन के इतिहास की एंट्री को ट्रैज किया जा रहा है. अगर उपयोगकर्ता किसी दूसरे पेज पर जा रहा है और ब्राउज़र,
मौजूदा पेज को बैक/फ़ॉरवर्ड करने के लिए
कैश मेमोरी को बाद में फिर से इस्तेमाल करने के लिए, इवेंट की
पिछली संभावित स्थितियां:
संभावित मौजूदा स्थितियां: |
beforeunload
|
विंडो, दस्तावेज़, और इसके संसाधन अनलोड होने वाले हैं. दस्तावेज़ अब भी दिख रहा है. साथ ही, इवेंट को अब भी रद्द किया जा सकता है अंक.
अहम जानकारी:
पिछली संभावित स्थितियां:
संभावित मौजूदा स्थितियां: |
unload
|
पेज को अनलोड किया जा रहा है.
चेतावनी:
हम
पिछली संभावित स्थितियां:
संभावित मौजूदा स्थितियां: |
* यह पेज लाइफ़साइकल एपीआई के ज़रिए तय किए गए नए इवेंट के बारे में बताता है
Chrome 68 में जोड़ी गई नई सुविधाएं
पिछले चार्ट में दो स्थितियां दिखाई गई हैं, जो उपयोगकर्ता की ओर से शुरू किया गया: फ़्रीज़ किया गया और खारिज किया गया. जैसा कि पहले बताया गया था, आज-कल ब्राउज़र कभी-कभी फ़्रीज़ और खारिज कर देते हैं के आधार पर छिपा दिए जाते हैं, लेकिन डेवलपर को यह नहीं पता होता कि वे होता है.
Chrome 68 में, अब डेवलपर यह देख सकते हैं कि छिपा हुआ टैब कब फ़्रीज़ किया गया है और
freeze
को सुनकर, ऐप्लिकेशन को अनफ़्रीज़ करें
और document
को resume
इवेंट.
document.addEventListener('freeze', (event) => {
// The page is now frozen.
});
document.addEventListener('resume', (event) => {
// The page has been unfrozen.
});
Chrome 68 के document
ऑब्जेक्ट में अब
wasDiscarded
प्रॉपर्टी को डेस्कटॉप Chrome पर अपडेट करें (इस समस्या में Android सहायता को ट्रैक किया जा रहा है). यह पता लगाने के लिए कि किसी पेज को छिपाए जाने पर खारिज किया गया था या नहीं
टैब से, पेज लोड होने के दौरान इस प्रॉपर्टी की वैल्यू की जांच की जा सकती है (ध्यान दें:
खारिज किए गए पेजों को दोबारा इस्तेमाल करने के लिए, उन्हें फिर से लोड करना होगा).
if (document.wasDiscarded) {
// Page was previously discarded by the browser while in a hidden tab.
}
यह जानने के लिए कि freeze
और resume
में क्या-क्या करना ज़रूरी है
इवेंट देखने और खारिज किए जाने वाले पेजों को मैनेज करने का तरीका जानने के लिए, देखें कि
हर राज्य के लिए डेवलपर के सुझाव.
अगले कुछ सेक्शन में, इन नई सुविधाओं के इस्तेमाल से जुड़ी खास जानकारी दी गई है मौजूदा वेब प्लैटफ़ॉर्म की स्थिति और इवेंट.
कोड में पेज लाइफ़साइकल की स्थितियों को देखने का तरीका
ऐक्टिव, पैसिव, और छिपी हुई विंडो में कहा जाता है, तो JavaScript कोड को चलाया जा सकता है, जो वर्तमान मौजूदा वेब प्लैटफ़ॉर्म एपीआई से पेज की लाइफ़साइकल की स्थिति.
const getState = () => {
if (document.visibilityState === 'hidden') {
return 'hidden';
}
if (document.hasFocus()) {
return 'active';
}
return 'passive';
};
फ़्रीज़ की गई और बंद की गई स्थितियां
दूसरी तरफ़, सिर्फ़ इवेंट लिसनर में ही उनका पता लगाया जा सकता है
(freeze
और pagehide
) ऐसा राज्य है
बदल रहा है.
स्थिति में होने वाले बदलावों को देखने का तरीका
पहले तय किए गए getState()
फ़ंक्शन के आधार पर, सभी पेजों को देखा जा सकता है
लाइफ़साइकल की स्थिति नीचे दिए गए कोड से बदल जाती है.
// Stores the initial state using the `getState()` function (defined above).
let state = getState();
// Accepts a next state and, if there's been a state change, logs the
// change to the console. It also updates the `state` value defined above.
const logStateChange = (nextState) => {
const prevState = state;
if (nextState !== prevState) {
console.log(`State change: ${prevState} >>> ${nextState}`);
state = nextState;
}
};
// Options used for all event listeners.
const opts = {capture: true};
// These lifecycle events can all use the same listener to observe state
// changes (they call the `getState()` function to determine the next state).
['pageshow', 'focus', 'blur', 'visibilitychange', 'resume'].forEach((type) => {
window.addEventListener(type, () => logStateChange(getState()), opts);
});
// The next two listeners, on the other hand, can determine the next
// state from the event itself.
window.addEventListener('freeze', () => {
// In the freeze event, the next state is always frozen.
logStateChange('frozen');
}, opts);
window.addEventListener('pagehide', (event) => {
// If the event's persisted property is `true` the page is about
// to enter the back/forward cache, which is also in the frozen state.
// If the event's persisted property is not `true` the page is
// about to be unloaded.
logStateChange(event.persisted ? 'frozen' : 'terminated');
}, opts);
यह कोड तीन काम करता है:
getState()
फ़ंक्शन का इस्तेमाल करके शुरुआती स्थिति सेट करता है.- इस नीति से एक ऐसे फ़ंक्शन के बारे में पता चलता है जो अगली स्थिति को स्वीकार करता है. साथ ही, अगर कोई बदलाव होता है, तो कंसोल में स्थिति में होने वाले बदलावों को लॉग करता है.
- जोड़ें
कैप्चर करना
सभी ज़रूरी लाइफ़साइकल इवेंट के लिए इवेंट लिसनर, जिनसे कॉल किया जाता है
logStateChange()
, अगली स्थिति में पास हो रहा है.
कोड के बारे में ध्यान रखने वाली एक बात यह है कि सभी इवेंट लिसनर जोड़े जाते हैं
window
को और वे सभी पास हो जाएंगे
{capture: true}
.
ऐसा होने की कुछ वजहें होती हैं:
- सभी पेज लाइफ़साइकल इवेंट का टारगेट एक जैसा नहीं होता.
pagehide
, औरpageshow
,window
को सक्रिय हुए;visibilitychange
,freeze
, औरresume
कोdocument
को सक्रिय किया गया है औरfocus
औरblur
को उनके संबंधित DOM एलिमेंट. - इनमें से ज़्यादातर इवेंट बबल नहीं होते. इसका मतलब है कि इन्हें जोड़ा नहीं जा सकता नॉन-कैप्चर करने वाले इवेंट लिसनर को एक कॉमन एंसेस्टर एलिमेंट पर देखते हैं और उन सभी को मॉनिटर करते हैं विकल्प मिलते हैं.
- कैप्चर फ़ेज़, टारगेट या बबल फ़ेज़ से पहले लागू होता है. इसलिए, लिसनर यह पक्का करने में मदद करते हैं कि अन्य कोड के रद्द होने से पहले ही वे चलें.
हर राज्य के लिए डेवलपर के सुझाव
डेवलपर के तौर पर, यह ज़रूरी है कि पेज लाइफ़साइकल की स्थितियों को समझा जाए और उन्हें कोड में ट्रैक करने का तरीका पता है, क्योंकि आपको किस तरह का काम करना चाहिए नहीं) करना काफ़ी हद तक इस बात पर निर्भर करता है कि आपका पेज किस स्थिति में है.
उदाहरण के लिए, कुछ समय के लिए दिखने वाली सूचना दिखाने का कोई फ़ायदा नहीं है अगर पेज छिपा है, तो उपयोगकर्ता को दिखाया जाएगा. यह उदाहरण काफ़ी साफ़ तौर पर, कुछ ऐसे सुझाव भी हैं जो बहुत साफ़ तौर पर नहीं दिए जाते गिना जा रहा है.
स्थिति | डेवलपर के लिए सुझाव |
---|---|
Active |
ऐक्टिव स्थिति उपयोगकर्ता के लिए सबसे अहम समय होती है. इसलिए, यह स्थिति उपयोगकर्ता के लिए सबसे अहम समय होती है. इसलिए आपके पेज के लिए सबसे अहम समय होता है, जो उपयोगकर्ता के इनपुट के हिसाब से सही नहीं होते. यूज़र इंटरफ़ेस (यूआई) के अलावा, मुख्य थ्रेड को ब्लॉक करने वाले किसी भी काम को प्राथमिकता नहीं देनी चाहिए को कुछ समय तक इस्तेमाल में न रहने की अवधि या लोड किया गया. |
Passive |
पैसिव स्थिति में, उपयोगकर्ता पेज के साथ इंटरैक्ट नहीं कर रहा है, लेकिन वे उसे फिर भी देख सकते हैं. इसका मतलब है कि यूज़र इंटरफ़ेस (यूआई) अपडेट और ऐनिमेशन अब भी ऐसे होने चाहिए आसानी से अपडेट हो जाएँ, लेकिन इन अपडेट के लागू होने का समय ज़्यादा अहम नहीं होता. जब पेज चालू से पैसिव में बदल जाता है, तो ऐप्लिकेशन को सेव नहीं किए गए स्टेटस को बनाए रखने का अच्छा समय है. |
जब पेज पैसिव से छिपा हुआ में बदल जाता है, तो जब तक इसे फिर से लोड नहीं किया जाता, तब तक उपयोगकर्ता इससे दोबारा इंटरैक्ट नहीं करेगा. छिपाए गए में ट्रांज़िशन अक्सर आखिरी स्थिति में भी बदलाव होता है
जिसे डेवलपर भरोसेमंद तरीके से ट्रैक करते हैं (खास तौर पर, यह तब लागू होता है, जब
मोबाइल पर है, क्योंकि उपयोगकर्ता टैब या ब्राउज़र ऐप्लिकेशन को बंद कर सकते हैं और
इसका मतलब यह है कि आपको छिपाई गई स्थिति को संभावित तौर पर उपयोगकर्ता का सेशन. दूसरे शब्दों में, किसी भी सेव न की गई ऐप्लिकेशन स्थिति को बनाए रखें और ऐसा कोई भी डेटा भेजा जा सकता है जो नहीं भेजा गया है. आपको यूज़र इंटरफ़ेस (यूआई) अपडेट करना भी बंद कर देना चाहिए (क्योंकि अपडेट किए गए उपयोगकर्ता की ओर से), और आपको ऐसे सभी टास्क रोक देने चाहिए जिन्हें उपयोगकर्ता नहीं चाहेगा बैकग्राउंड में चल रहा है. |
|
Frozen |
फ़्रीज़ की गई स्थिति में, फ़्रीज़ किए जा सकने वाले टास्क टास्क की सूचियों को तब तक निलंबित रखा जाता है, जब तक पेज को फ़्रीज़ नहीं किया जाता — कभी नहीं होता (उदाहरण के लिए, अगर पेज खारिज कर दिया जाता है). इसका मतलब है कि जब पेज छिपा हुआ से फ़्रीज़ हो गया हो जाता है यह ज़रूरी है कि आप किसी भी टाइमर को बंद कर दें या किसी भी कनेक्शन को हटा दें, अगर फ़्रीज़ की गई है, तो एक ही ऑरिजिन में खुले हुए अन्य टैब पर असर डाल सकती है या पेज को में रखने की ब्राउज़र की क्षमता बैक/फ़ॉरवर्ड कैश मेमोरी. खास तौर पर, यह ज़रूरी है कि:
आपको किसी भी डाइनैमिक व्यू की स्थिति (जैसे, स्क्रोल पोज़िशन) को बनाए रखना चाहिए
में देखें) से
अगर पेज फ़्रीज़ किए गए से वापस छिपा हुआ हो जाता है, आपके पास बंद किए गए किसी भी कनेक्शन को फिर से चालू करने या पोल को फिर से चालू करने का विकल्प होता है पेज को फ़्रीज़ करने के दौरान रोका गया. |
Terminated |
आम तौर पर, पेज के ट्रांज़िशन होने पर आपको कोई कार्रवाई करने की ज़रूरत नहीं होती है बंद की स्थिति में होंगे. चूंकि उपयोगकर्ता की कार्रवाई से पेज अनलोड हो जाते हैं, इसलिए बंद करने से पहले छिपी हुई स्थिति से गुज़रकर स्थिति, छिपाई गई स्थिति वह जगह है जहां सेशन खत्म होने वाला लॉजिक (उदाहरण के लिए, ऐप्लिकेशन की स्थायी स्थिति और आंकड़ों की रिपोर्ट) प्रदर्शन किया. साथ ही (जैसा कि के लिए सुझावों में बताया गया है
छिपाई गई स्थिति), डेवलपर के लिए यह समझना ज़रूरी है कि
खत्म होने की स्थिति में ट्रांज़िशन भरोसेमंद तरीके से नहीं किया जा सकता
यह अलग-अलग मामलों में (खास तौर पर मोबाइल पर) होता है. इसलिए, जो डेवलपर इस पर निर्भर रहते हैं
बंद होने की घटनाओं पर आधारित है (जैसे, |
Discarded |
डेवलपर, हटा दिए गए स्टेटस की जांच नहीं करते हैं: पेज को खारिज करने का समय. ऐसा इसलिए होता है, क्योंकि आम तौर पर पेज संसाधन पाबंदियों के तहत खारिज किया जाना चाहिए. साथ ही, अनुमति देने के लिए पेज को अनफ़्रीज़ करना किसी छोड़ें इवेंट के प्रतिक्रिया में स्क्रिप्ट चलाना ज़्यादातर मामलों में. इसलिए, आपको डेटा खारिज करने की तैयारी करनी होगी
छिपाए गए से फ़्रीज़ किया गया में बदल जाता है, और फिर आप
खारिज किए गए पेज को वापस लाने पर, पेज लोड होने के दौरान प्रतिक्रिया देने के लिए
|
एक बार फिर से, क्योंकि लाइफ़साइकल इवेंट की विश्वसनीयता और क्रम, सभी ब्राउज़र पर एक ही तरह से लागू किया जाता है. सलाह का पालन करने का सबसे आसान तरीका टेबल में PageLifecycle.js.
इन लेगसी लाइफ़साइकल एपीआई से बचें
जहां भी मुमकिन हो, इन इवेंट से बचना चाहिए.
अनलोड इवेंट
कई डेवलपर, unload
इवेंट को गारंटी के साथ कॉलबैक के तौर पर देखते हैं और इसे इस तरह इस्तेमाल करते हैं
राज्य की जानकारी को सेव करने और आंकड़ों का डेटा भेजने के लिए, सेशन के खत्म होने का सिग्नल देते हैं. हालांकि, ऐसा करने से
बहुत ही भरोसेमंद है, खासकर मोबाइल पर! unload
इवेंट यह नहीं करता
अनलोड होने की कई सामान्य स्थितियों में फ़ायर होता है. इनमें, टैब से टैब बंद करना भी शामिल है
मोबाइल पर स्विच करने या ऐप्लिकेशन स्विचर से ब्राउज़र ऐप्लिकेशन बंद करने का विकल्प होता है.
इस कारण से, अपने लक्ष्य के लिए
visibilitychange
इवेंट, ताकि यह तय किया जा सके कि सेशन कब ट्रिगर होगा
खत्म हो जाता है और छिपी हुई स्थिति पर विचार करता है,
ऐप्लिकेशन और उपयोगकर्ता के डेटा को सेव करने का पिछला भरोसेमंद समय.
इसके अलावा, सिर्फ़ रजिस्टर किए गए unload
इवेंट हैंडलर की मौजूदगी (इसके ज़रिए
onunload
या addEventListener()
) ब्राउज़र को
पेजों को बैक/फ़ॉरवर्ड कैश मेमोरी में तेज़ी से सेव करने के लिए
बैक और फ़ॉरवर्ड लोड होते हैं.
सभी मॉडर्न ब्राउज़र में, यह सलाह दी जाती है कि आप हमेशा
pagehide
इवेंट, ताकि पेज के संभावित अनलोड का पता लगाया जा सके.
unload
इवेंट के बजाय खत्म स्थिति) किया था. अगर आपको
को Internet Explorer के वर्शन 10 और इससे पहले के वर्शन पर काम करना हो, तो आपको
pagehide
इवेंट का पता लगाएं और unload
का इस्तेमाल सिर्फ़ तब करें, जब ब्राउज़र काम न करे
pagehide
:
const terminationEvent = 'onpagehide' in self ? 'pagehide' : 'unload';
window.addEventListener(terminationEvent, (event) => {
// Note: if the browser is able to cache the page, `event.persisted`
// is `true`, and the state is frozen rather than terminated.
});
beforeunload इवेंट
beforeunload
इवेंट और unload
इवेंट से मिलती-जुलती एक समस्या है.
ऐतिहासिक रूप से, beforeunload
इवेंट की मौजूदगी के कारण पेजों को
बैक/फ़ॉरवर्ड कैश मेमोरी की ज़रूरी शर्तें पूरी करता हो. मॉडर्न ब्राउज़र
में यह प्रतिबंध नहीं है. हालांकि, सावधानी के तौर पर कुछ ब्राउज़र सक्रिय नहीं होंगे
किसी पेज को बैक/फ़ॉरवर्ड करने की कोशिश करते समय हुआ beforeunload
इवेंट
कैश मेमोरी का मतलब है कि इवेंट, सेशन के आखिर के सिग्नल के तौर पर भरोसेमंद नहीं है.
इसके अलावा, कुछ ब्राउज़र (जिनमें Chrome शामिल है)
beforeunload
इवेंट को अनुमति देने से पहले, पेज पर उपयोगकर्ता के इंटरैक्शन की ज़रूरत होती है
जो इसकी विश्वसनीयता को प्रभावित करते हैं.
beforeunload
और unload
के बीच एक अंतर यह है कि
beforeunload
के सही इस्तेमाल. उदाहरण के लिए, जब आप उपयोगकर्ता को चेतावनी देना चाहते हों
पेज को अनलोड करना जारी रखने पर, वे बदलाव खो देंगे.
beforeunload
का इस्तेमाल करने की मान्य वजहें हैं. इसलिए, हमारा सुझाव है कि आप
beforeunload
लिसनर को सिर्फ़ तब जोड़ा जा सकता है, जब किसी उपयोगकर्ता के बदलाव सेव नहीं किए गए हों. इसके बाद
सेव किए जाने के तुरंत बाद उन्हें हटाया जा सकता है.
दूसरे शब्दों में, ऐसा न करें (क्योंकि इससे beforeunload
लिसनर जुड़ता है
बिना शर्त:
addEventListener('beforeunload', (event) => {
// A function that returns `true` if the page has unsaved changes.
if (pageHasUnsavedChanges()) {
event.preventDefault();
// Legacy support for older browsers.
return (event.returnValue = true);
}
});
इसके बजाय ऐसा करें (क्योंकि यह beforeunload
लिसनर को सिर्फ़ तब जोड़ता है, जब यह
ज़रूरी है, और लिंक न होने पर इसे हटा देता है):
const beforeUnloadListener = (event) => {
event.preventDefault();
// Legacy support for older browsers.
return (event.returnValue = true);
};
// A function that invokes a callback when the page has unsaved changes.
onPageHasUnsavedChanges(() => {
addEventListener('beforeunload', beforeUnloadListener);
});
// A function that invokes a callback when the page's unsaved changes are resolved.
onAllChangesSaved(() => {
removeEventListener('beforeunload', beforeUnloadListener);
});
अक्सर पूछे जाने वाले सवाल
"लोड हो रहा है" पेज क्यों नहीं दिख रहा है राज्य?
Page Lifecycle API की मदद से यह तय किया जाता है कि स्थितियां अलग-अलग होती हैं और अलग-अलग होती हैं. पेज को किसी भी ऐक्टिव, पैसिव या छिपी हुई स्थिति में लोड किया जा सकता है और क्योंकि उसके लोड होने से पहले ही स्थिति बदल सकती है—या उसे खत्म भी किया जा सकता है— इस उदाहरण में, कॉन्टेंट लोड होने की अलग-अलग स्थिति का कोई मतलब नहीं है.
मेरा पेज छिपाए जाने पर अहम काम करता है. इसे फ़्रीज़ होने या खारिज होने से कैसे रोका जा सकता है?
कई मान्य वजहों से, चलते समय वेब पेजों को फ़्रीज़ नहीं किया जाना चाहिए में दिखेगा. इसका सबसे अच्छा उदाहरण संगीत चलाने वाला ऐप्लिकेशन है.
ऐसी स्थितियां भी हो सकती हैं जिनमें Chrome के लिए, किसी पेज को खारिज करना जोखिम भरा हो,
जैसे कि फ़ॉर्म में कोई ऐसा फ़ॉर्म शामिल है जिसे सबमिट नहीं किया गया है या उसमें
beforeunload
हैंडलर, जो पेज के अनलोड होने पर चेतावनी देता है.
फ़िलहाल, पेजों को खारिज करते समय Chrome कंज़र्वेटिव हो जाएगा और ऐसा सिर्फ़ तब करें, जब आपको भरोसा हो कि इसका असर उपयोगकर्ताओं पर नहीं पड़ेगा. उदाहरण के लिए, ऐसे पेज जो इनमें से किसी भी काम को करते हुए देखा गया है, जबकि छिपे हुए स्टेटस में ये काम नहीं करते को तब तक खारिज कर दें, जब तक कि बहुत ज़्यादा संसाधनों की कमी न हो:
- ऑडियो चल रहा है
- WebRTC का उपयोग करना
- टेबल का टाइटल या फ़ेविकॉन अपडेट करना
- अलर्ट दिखाए जा रहे हैं
- पुश नोटिफ़िकेशन भेजे जा रहे हैं
यह निर्धारित करने के लिए उपयोग की जाने वाली वर्तमान सूची सुविधाओं के लिए कि कोई टैब सुरक्षित रूप से हो सकता है या नहीं फ़्रीज़ या खारिज किए गए के तौर पर देखें, तो देखें: फ़्रीज़िंग और खारिज किया जा रहा है Chrome में.
को दबाकर रखें बैक/फ़ॉरवर्ड कैश मेमोरी की सुविधा क्या है?
बैक/फ़ॉरवर्ड कैश मेमोरी का इस्तेमाल कुछ ब्राउज़र लागू करते हैं, जो नेविगेशन ऑप्टिमाइज़ेशन के साथ बैक अप और दूसरे बटनों को तेज़ी से आगे बढ़ा सकते हैं.
जब कोई व्यक्ति किसी पेज से किसी दूसरे पेज पर जाता है, तो ये ब्राउज़र उस पेज के वर्शन को फ़्रीज़ कर देते हैं
पेज को इस तरह से बनाया गया है कि जब उपयोगकर्ता अपने कंप्यूटर पर वापस नेविगेट करे, तो इस पेज को तेज़ी से शुरू किया जा सके
'वापस जाएं' या 'आगे बढ़ें' बटन का इस्तेमाल करें. unload
जोड़ना याद रखें
इवेंट हैंडलर इस ऑप्टिमाइज़ेशन को संभव होने से रोकता है.
सभी कामों के लिए, यह फ़्रीज़िंग काम करने के तरीके के जैसे ही है फ़्रीज़ करने वाले ब्राउज़र सीपीयू/बैटरी बचाने के लिए काम करते हैं; इसी वजह से, इसे इसे फ़्रीज़ की गई लाइफ़साइकल स्थिति का हिस्सा माना जाता है.
अगर मैं फ़्रीज़ किए गए या खत्म हो चुके स्टेटस में एसिंक्रोनस एपीआई नहीं चला पा रहा हूं, तो IndexedDB में डेटा कैसे सेव करूं?
फ़्रीज़ की गई और खत्म की गई स्थितियों में, फ़्रीज़ होने वाले टास्क किसी पेज की टास्क सूचियों में शामिल हो सकते हैं निलंबित है, जिसका मतलब है कि एसिंक्रोनस और कॉलबैक-आधारित एपीआई, जैसे कि IndexedDB का भरोसेमंद तरीके से इस्तेमाल नहीं किया जा सकता.
आने वाले समय में, हम IDBTransaction
ऑब्जेक्ट में एक commit()
तरीका जोड़ेंगे, जो
इससे डेवलपर को ऐसे लेन-देन करने में मदद मिलती है जो सिर्फ़ राइट-ओनली मोड में होते हैं
जिनके लिए कॉलबैक की ज़रूरत नहीं होती. दूसरे शब्दों में, अगर डेवलपर सिर्फ़
IndexedDB के लिए डेटा और रीड वाले जटिल लेन-देन को पूरा नहीं करना
और लिखता है, commit()
तरीका टास्क की
सूची से पहले ही पूरा हो जाएगा
निलंबित (यह मानते हुए कि IndexedDB डेटाबेस पहले से खुला है).
हालांकि, जिस कोड को आज काम करना है उसके लिए डेवलपर के पास दो विकल्प हैं:
- सेशन स्टोरेज का इस्तेमाल करें: सेशन स्टोरेज सिंक्रोनस होता है और पेज खारिज करने की प्रक्रिया में सेव रहता है.
- अपने सर्विस वर्कर से मिले IndexedDB का इस्तेमाल करना: सर्विस वर्कर, डेटा को इसमें स्टोर कर सकता है
पेज को बंद या खारिज करने के बाद, IndexedDB.
freeze
में याpagehide
इवेंट लिसनर आप इसके ज़रिए अपने सर्विस वर्कर को डेटा भेज सकते हैंpostMessage()
, और सर्विस वर्कर, डेटा को सेव कर सकता है.
अपने ऐप्लिकेशन को फ़्रीज़ और खारिज की गई स्थितियों में टेस्ट करना
यह देखने के लिए कि आपका ऐप्लिकेशन, फ़्रीज़ और खारिज की गई स्थितियों में कैसे काम करता है
अपने किसी भी आइटम को फ़्रीज़ या खारिज करने के लिए chrome://discards
खुले हुए टैब.
![Chrome, यूज़र इंटरफ़ेस (यूआई) को खारिज कर देता है](https://developer.chrome.com/static/docs/web-platform/page-lifecycle-api/image/chrome-discards-ui-4c0620d6f8619.png?authuser=9&hl=hi)
इससे आपको यह पक्का करने में मदद मिलती है कि आपका पेज, freeze
और resume
के हिसाब से सही तरीके से काम करता है
इवेंट और document.wasDiscarded
फ़्लैग का इस्तेमाल, जब पेज के बाद फिर से लोड किया जाता है, तो
एक खारिज करें.
खास जानकारी
ऐसे डेवलपर जो अपने उपयोगकर्ता के डिवाइसों के सिस्टम संसाधनों का पालन करना चाहते हैं को अपने ऐप्लिकेशन, पेज लाइफ़साइकल की स्थितियों को ध्यान में रखकर बनाए जाने चाहिए. यह ज़रूरी है कि वेब पेज ऐसी परिस्थितियों में सिस्टम के बहुत ज़्यादा संसाधनों का इस्तेमाल नहीं कर रहे हैं जहां उपयोगकर्ता की उम्मीद नहीं होगी
डेवलपर जितने ज़्यादा पेज लाइफ़साइकल एपीआई लागू करना शुरू करेंगे, यह उतना ही सुरक्षित होगा ब्राउज़र, उन पेजों को फ़्रीज़ और खारिज कर सकेंगे जिनका इस्तेमाल नहीं किया जा रहा है. यह इसका मतलब है कि ब्राउज़र कम मेमोरी, सीपीयू, बैटरी, और नेटवर्क रिसॉर्स का इस्तेमाल करेंगे. यह लोगों के लिए फ़ायदेमंद है.