🚴🏼 👩🏻‍🤝‍👨🏿 🕙 क्लाइंट पर छवियों का पूर्वावलोकन करना: लसदार ब्राउज़रों से लड़ना 👨🏼‍⚕️ ⛹🏾 😍

सभी को नमस्कार! आज हमारे पास निम्नलिखित कार्य हैं: छवियों को डाउनलोड करने के लिए एक इंटरफ़ेस बनाना आवश्यक है, जो डाउनलोड करने से पहले छोटे प्रारूप के थंबनेल उत्पन्न करेगा। फिलहाल, HTML5 ग्रह के चारों ओर पूरे जोरों पर है, और ऐसा लगता है कि इसे कैसे लागू किया जाए, यह बेहद स्पष्ट होना चाहिए। इस विषय पर कई रूसी-भाषा के लेख हैं (उदाहरण के लिए)। लेकिन एक बात है लेकिन वहां पर दिए गए दृष्टिकोण में, ब्राउज़र की मेमोरी खपत पर कोई ध्यान नहीं दिया गया था। और खपत विशाल अनुपात तक पहुंच सकती है। बेशक, यदि आप एक ही समय में अपलोड करते हैं तो एक छोटे प्रारूप के 5-10 से अधिक चित्र नहीं हैं, फिर भी सब कुछ सामान्य सीमा के भीतर रहता है; लेकिन हमारा इंटरफ़ेस आपको प्रारूप की कई छवियों को एक बार में डाउनलोड करने की अनुमति दे सकता है जो आधुनिक कैमरों, साबुन व्यंजनों से कम नहीं हैं। और फिर मुफ्त की याद हमारी आँखों के सामने पिघलने लगती है।

शुरू करने के लिए, समस्या के पैमाने का आकलन करने के लिए, हम इस विषय पर सभी लेखों में बदलाव के बिना लगभग वर्णित दृष्टिकोण को लागू करते हैं, और स्मृति के उपयोग का पता लगाने का प्रयास करते हैं। मैंने पूर्वावलोकन के निर्माण को प्रदर्शित करने के लिए उदाहरण कोड को यथासंभव सरल बनाने की कोशिश की। ड्रैग एंड ड्रॉप को कैसे लागू किया जाए और लोडिंग को मेरे पिछले लेख में भी देखा जा सकता है ।

कोड

var listen = function(element, event, fn) { return element.addEventListener(event, fn, false); }; listen(document, 'DOMContentLoaded', function() { var fileInput = document.querySelector('#file-input'); var listView = document.querySelector('#list-view'); listen(fileInput, 'change', function(event) { var files = fileInput.files; if (files.lenght == 0) { return; } for(var i = 0; i < files.length; i++) { generatePreview(files[i]); } fileInput.value = ""; }); var generatePreview = function(file) { var reader = new FileReader(); reader.onload = function(e) { var dataUrl = e.target.result; var li = document.createElement('LI'); var image = new Image(); image.width = 100; image.onload = function() { // some action here }; image.src = dataUrl; li.appendChild(image); listView.appendChild(li); }; reader.readAsDataURL(file); }; });

परीक्षणों के लिए, मैंने 3648x2736 पिक्सेल और 4 मेगाबाइट की औसत मात्रा को मापने वाली अचूक तस्वीरों के एक फ़ोल्डर का उपयोग किया। साथ ही वर्तमान संस्करणों के ब्राउज़र का एक सेट: क्रोम (31.0), यैंडेक्स (13.12), फ़ायरफ़ॉक्स (26.0), और आईई (11.0.1)। खैर, सामान्य कार्य प्रबंधक (8.1 जीत)।

इसलिए, फ़ील्ड में 20 फ़ोटो चुनें। हम देखते हैं:

ब्राउज़र	मेमोरी खपत एमबी
क्रोम	994
Yandex	1045
फ़ायरफ़ॉक्स	1388
आईई	1080

दो बिंदु यहां ध्यान देने योग्य हैं: 1) यांडेक्स और क्रोम प्रत्येक टैब के लिए एक अलग प्रक्रिया रखते हैं, लेकिन फ़ायरफ़ॉक्स और आईई नहीं करते हैं, इसलिए पिछले दो के लिए, कुछ ओवरहेड जो सीधे हमारे परीक्षण से संबंधित नहीं हैं, माप में भी आते हैं; 2) मैंने सभी चित्रों को लोड करने के बाद लगभग 20 सेकंड के लिए माप लिया (बाद में), ब्राउज़र को गर्म खोज में स्मृति को मुक्त करने में सक्षम करने के लिए, जो वे करते हैं, भले ही बहुत कम हो - 50 एमबी के भीतर, अर्थात्। अभी भी बहुत बड़ी मात्रा में जारी है। पृष्ठ को अपडेट / बंद करने के बाद, सभी ब्राउज़र धीरे-धीरे मेमोरी को सामान्य आकारों में मुक्त करते हैं।

इसलिए, यह स्पष्ट है कि ऐसी स्थिति निर्णायक रूप से हमारे अनुकूल नहीं है। हमें लगता है कि आप ले सकते हैं ...

शेल के लिए पहला दृष्टिकोण

मेरा पहला विचार था: “क्या होगा अगर ऐसा ओवररन समानांतर में सभी चित्रों को अपलोड करने की कोशिश से आता है? हो सकता है कि इसे क्रमिक रूप से करने की कोशिश की जाए, जिससे ब्राउज़रों को अपनी सांस थोड़ी पकड़ने का मौका मिले? " खैर, हम सबसे सरल कतार को लागू करने की कोशिश कर रहे हैं।

कोड

 // ...    ... var queue = []; var isProcessing = false; listen(fileInput, 'change', function(event) { var files = fileInput.files; if (files.lenght == 0) { return; } for(var i = 0; i < files.length; i++) { queue.push(files[i]); } fileInput.value = ""; processQueue(); }); var processQueue = function() { if (isProcessing) { return; } if (queue.length == 0) { isProcessing = false; return; } isProcessing = true; file = queue.pop(); var reader = new FileReader(); reader.onload = function(e) { var dataUrl = e.target.result; var li = document.createElement('LI'); var image = new Image(); image.width = 100; image.src = dataUrl; li.appendChild(image); listView.appendChild(li); isProcessing = false; processQueue(); }; reader.readAsDataURL(file); };

परिणाम (उसी 20 फ़ोटो पर):

ब्राउज़र	मेमोरी खपत एमबी
क्रोम	979
Yandex	1119
फ़ायरफ़ॉक्स	1360
आईई	399

हम देखते हैं कि इससे केवल IE के मामले में मदद मिली। खैर, क्या करना है - हम अनुशंसा करते हैं कि सभी उपयोगकर्ता IE के अलावा किसी भी ब्राउज़र के उपयोग को छोड़ दें। एक चुटकुला। हम आगे सोचते हैं ...

दूसरा तरीका

कुछ शर्मिंदगी के एक सत्र के बाद, विचार मन में आता है: "शायद समस्या यह है कि ब्राउज़रों को अपनी स्मृति में व्यापक चित्र रखना पड़ता है, हालांकि वास्तव में हमें केवल पूर्वावलोकन के आकार में एक बार चित्र को सिकोड़ने की आवश्यकता है? क्या होगा अगर सामान्य आईएमजी के बजाय कैनवास का उपयोग करें, जहां पहले से ही सिकुड़ी हुई छवि डालनी है? " तो कर लो ।

कोड

 var queue = []; var isProcessing = false; listen(fileInput, 'change', function(event) { // ... }); var processQueue = function() { // ...       file = queue.pop(); var reader = new FileReader(); reader.onload = function(e) { var dataUrl = e.target.result; var li = document.createElement('LI'); var canvas = document.createElement('CANVAS'); var ctx = canvas.getContext('2d'); var image = new Image(); listView.appendChild(li); image.onload = function() { var newWidth = 100; var newHeight = image.height * (newWidth / image.width); ctx.drawImage(image, 0, 0, newWidth, newHeight); li.appendChild(canvas); }; image.src = dataUrl; isProcessing = false; processQueue(); }; reader.readAsDataURL(file); };

परिणाम (सभी 20 चित्र):

ब्राउज़र	मेमोरी खपत एमबी
क्रोम	188 (चरम समय पर यह ~ 800MB तक पहुंच गया, लेकिन जल्दी से इसे फेंक दिया)
Yandex	201 (चरम समय में यह ~ 1GB तक पहुंच गया, लेकिन तुरंत इसे क्रोम की तरह फेंक दिया गया)
फ़ायरफ़ॉक्स	661 (शिखर ~ 900. यह ध्यान दिया जाना चाहिए कि एक और मिनट इंतजार कर रहे हैं, 300 तक फेंक दिया गया है)
आईई	103 (शिखर ~ 260)

इस प्रक्रिया में उच्च खपत (आईई को छोड़कर सभी के लिए) के बावजूद, ब्राउज़र ने कम से कम तुरंत मेमोरी खाली करना शुरू कर दिया। यह आनंदित नहीं कर सकता है। लेकिन फिर भी अंतिम जीत का जश्न बहुत जल्दी है। हमें लगता है कि अधिक किया जा सकता है ...

तीसरा तरीका

आगे फेंकने और बहुत सफल प्रयोग न करने की प्रक्रिया में, हम याद करते हैं कि एक बार जब हम एक API जैसे ObjectURL ( निर्माण और उपयोग ) में आ गए, जो आपको ब्राउज़र के कैश में संग्रहीत किसी भी बाइनरी डेटा के लिए स्थानीय लिंक बनाने की अनुमति देता है और उनका उपयोग भी करता है। सिद्धांत रूप में, यह हमें विशाल DataURL प्रसंस्करण से बचने में मदद कर सकता है। बल्कि कोशिश करें

कोड

 // ...     var processQueue = function() { // ...     isProcessing = true; file = queue.pop(); var li = document.createElement('LI'); var canvas = document.createElement('CANVAS'); var ctx = canvas.getContext('2d'); var image = new Image(); listView.appendChild(li); image.onload = function() { var newWidth = 100; var newHeight = image.height * (newWidth / image.width); ctx.drawImage(image, 0, 0, newWidth, newHeight); URL.revokeObjectURL(image.src); li.appendChild(canvas); isProcessing = false; processQueue(); }; image.src = URL.createObjectURL(file); };

परिणाम:

ब्राउज़र	मेमोरी खपत एमबी
क्रोम	881
Yandex	927
फ़ायरफ़ॉक्स	140 (चोटी ~ 860)
आईई	36 (शिखर ~ 70)

हमें क्या मिला? ठीक है, सबसे पहले, IE में उत्कृष्ट परिणाम। एफएफ में कम या ज्यादा स्वीकार्य। लेकिन WebKit ब्राउज़रों के साथ, वे वापस उछाल के लिए लग रहे थे। निष्पक्षता में, यह ध्यान दिया जाना चाहिए कि एक ही समय में, सभी ब्राउज़रों में, चित्रों को संवेदनाओं के अनुसार शुद्ध रूप से तेजी से संसाधित किया जाना शुरू हुआ, लेकिन उसी समय IE में अल्पकालिक फ्रेजेस पैदा हुए। यह भी संभव है कि FF और IE ईमानदारी से URL.revokeObjectURL () कॉल करने के बाद तुरंत संसाधनों को मुक्त करते हैं, और वेबकिट ब्राउज़र को ऐसा करने के लिए कुछ समय चाहिए (यह संभव है कि वे कम मेमोरी की स्थिति में ऐसा करने के लिए तेज़ हो जाएं)। आप दो तरीकों से आगे जा सकते हैं: 1) दृष्टिकोणों को विभाजित करें - वेबकिट पर ब्राउज़रों में दूसरे दृष्टिकोण पर लौटें (इसके साथ सब कुछ स्पष्ट है - एक तकनीकी मामला); और 2) हर जगह तीसरे दृष्टिकोण को ध्यान में लाने की कोशिश करें। चलिए आखिरी विकल्प आजमाते हैं ...

चौथा दृष्टिकोण (और अंतिम): ऐसे और क्या होगा?

थोड़ा निचोड़, हम सुधार के एक जोड़े को निचोड़ते हैं। सबसे पहले, हम क्यू एल हैंडलर से img एलिमेंट के निर्माण को हटाते हैं: अब हम उसी पूर्व-निर्मित वस्तु का पुनः उपयोग करेंगे। आगे देखते हुए, मैं कहता हूँ कि इससे वेब ब्राउज़र और नए ब्राउज़र में मेमोरी की स्थिति में काफी सुधार हुआ है - जिसकी आवश्यकता थी। और दूसरा, यह एक लंबे समय से ज्ञात चाल है - हम प्रत्येक बाद के प्रसंस्करण को सेटटाइमआउट () के साथ थोड़ा स्थगित कर देते हैं, इससे अल्पकालिक फ्रिज़ के साथ स्थिति को बेहतर बनाने में मदद मिली। तो परिणाम है :

कोड

 //    var listen = function(element, event, fn) { return element.addEventListener(event, fn, false); }; listen(document, 'DOMContentLoaded', function() { var fileInput = document.querySelector('#file-input'); var listView = document.querySelector('#list-view'); var queue = []; var isProcessing = false; var image = new Image(); //     img var imgLoadHandler; listen(fileInput, 'change', function(event) { var files = fileInput.files; if (files.lenght == 0) { return; } for(var i = 0; i < files.length; i++) { queue.push(files[i]); } fileInput.value = ""; processQueue(); }); var processQueue = function() { if (isProcessing) { return; } if (queue.length == 0) { isProcessing = false; return; } isProcessing = true; file = queue.pop(); var li = document.createElement('LI'); var canvas = document.createElement('CANVAS'); var ctx = canvas.getContext('2d'); //      image.removeEventListener('load', imgLoadHandler, false); imgLoadHandler = function() { var newWidth = 100; var newHeight = image.height * (newWidth / image.width); ctx.drawImage(image, 0, 0, newWidth, newHeight); URL.revokeObjectURL(image.src); li.appendChild(canvas); isProcessing = false; setTimeout(processQueue, 200); //    }; listView.appendChild(li); listen(image, 'load', imgLoadHandler); image.src = URL.createObjectURL(file); }; });

परीक्षण:

ब्राउज़र	मेमोरी खपत एमबी
क्रोम	103 (शिखर ~ 150)
Yandex	113 (शिखर ~ 150, क्रोमियम की तरह)
फ़ायरफ़ॉक्स	107 (चोटी ~ 510)
आईई	40 (और यह ऊपर नहीं उठा। जैसे कि कोई काम बिल्कुल नहीं चल रहा था)

उसी समय, हम एक ही आकार के 100 चित्रों पर भी परीक्षण करेंगे:

ब्राउज़र	मेमोरी खपत एमबी
क्रोम	98 (शिखर ~ 150)
Yandex	150 (चोटी ~ 180)
फ़ायरफ़ॉक्स	104 (शिखर ~ 520)
आईई	40 (सभी समान 40 एमबी!)

हम देखते हैं कि व्यावहारिक रूप से संसाधित छवियों की संख्या में वृद्धि से खपत में वृद्धि नहीं होती है। यह, शायद, बंद हो जाएगा।

निष्कर्ष

स्वीकार करने के लिए, बहुत पहले जांच के बाद, कुछ बिंदु पर मैंने सोचा था कि वर्तमान स्थिति में अत्यधिक स्मृति के बिना इस अवसर को महसूस करना संभव नहीं होगा। फिर भी, यह उपयोगकर्ता को निलंबित करने के लिए बदसूरत है [जो एक बार में 100 चित्र अपलोड करना चाहता है] उसकी काल्पनिक नेटबुक। लेकिन यह अच्छा है कि मैं इन संदेहों को दूर करने में कामयाब रहा :)

इसलिए, हमने कुछ बिंदुओं का पता लगाने में कामयाबी हासिल की। समय की संख्या: DataURL का उपयोग केवल बहुत छोटे प्रारूप में चित्रों के साथ काम करने के लिए उपयुक्त है (बड़े लोगों के लिए, यह ObjectURL API का उपयोग करना बेहतर है, जिसमें केवल दो विधियाँ शामिल हैं)। नंबर दो: आपको बड़ी संख्या में इमेज ऑब्जेक्ट बनाते समय सावधान रहना होगा। नंबर तीन: एक बार में सभी प्रोसेसिंग न करें।

खैर, चूंकि इस छोटे से अध्ययन में बेवजह ब्राउज़रों की तुलना की गई, इसलिए आइए प्रत्येक व्यक्ति पर व्यक्तिगत रूप से विचार करें।

क्या फ़ायरफ़ॉक्स हार गया?

चोटी की खपत के बावजूद जो बाकी की तुलना में बाहर खड़ा है, मुझे लगता है कि स्थिति अभी भी काफी स्वीकार्य है। सबसे पहले (मैंने इसे ऊपर उल्लेख नहीं किया है), माप के बाद एक और 30 सेकंड, मेमोरी 60MB तक गिर गई, जो कि वेब-आधारित लोगों की तुलना में कम है; और दूसरी बात, यह संभावना है कि गंभीर कमी की स्थितियों में, फ़ायरफ़ॉक्स समय-समय पर प्रसंस्करण के दौरान मेमोरी को मिटा देगा और अंत में, यहां तक कि अपने चरम पर भी इतना नहीं खाएगा। सामान्य तौर पर, हम सेट करते हैं।

IE पर हर किसी के साथ रहो!

यह फिर से एक मजाक है :) लेकिन निष्पक्ष रूप से बोलते हुए, हमें यह स्वीकार करना चाहिए कि IE अब सामान्य ब्राउज़र डाउनलोड करने के लिए सिर्फ एक उपकरण नहीं है, बल्कि कम से कम एक और अधिक उपयुक्त ब्राउज़र है।

Yandex.Browser बड़े भाइयों से थोड़ा पीछे है?

मुझे ऐसा नहीं लगता। और यहाँ क्यों: तथ्य यह है कि मैं अब इसे मुख्य के रूप में उपयोग करता हूं, और तदनुसार प्रयोग को स्पष्ट नहीं कहा जा सकता है। प्लगइन्स, इतिहास, सिंक्रनाइज़ेशन की एक जोड़ी - यह सब इस मामूली अंतराल का कारण बन सकता है।

और ओपेरा कहां है?

मैं वास्तव में इस प्रयोग के लिए 12 वां संस्करण अलग से नहीं रखना चाहता था। इस तथ्य के बावजूद कि यह अभी भी किसी और द्वारा उपयोग किया जा रहा है, जल्द ही इस वफादार प्रशंसकों की संख्या को या तो अपग्रेड करना होगा या किसी अन्य ब्राउज़र पर माइग्रेट करना होगा। और नए, वेबकिट के बारे में - यह विश्वास करने का हर कारण है कि स्थिति यैंडेक्स और क्रोम के समान है।

UPD: 12 वीं ओपेरा में सभी की जाँच की। परिणाम निम्नानुसार हैं: 3 जी (और, तदनुसार, 4 वें) दृष्टिकोण काम नहीं करते हैं। दूसरा दृष्टिकोण 500 एमबी शिखर पर और प्रसंस्करण के बाद 300 एमबी खाता है।

लेकिन सफारी के बारे में क्या?

जीतने पर, यह एक दुर्लभ जानवर है, लेकिन खसखस पर मैंने अंतिम संस्करण (सभी 20 तस्वीरों में) का परीक्षण किया। प्रसंस्करण के दौरान, मेमोरी की खपत बिल्कुल नहीं बढ़ी।

मोबाइल ब्राउज़र के बारे में क्या?

आईफोन 5 एस पर सफारी में भी जांच की गई। एक अल्पकालिक फ्रिज़ मनाया जाता है, लेकिन एक ही समय में मुफ्त मेमोरी की मात्रा व्यावहारिक रूप से कम नहीं हुई है। मुझे तुरंत यह पता नहीं चला कि क्या यह संभव है कि किसी तरह यह देखना कि प्रत्येक प्रक्रिया विशेष रूप से अलग से आरक्षित होती है, मैं आभारी रहूंगा यदि कोई मुझे टिप्पणियों में बताएगा। Android उपकरण, दुर्भाग्य से, हाथ में नहीं थे। शायद कोई भी अपने आप को जांचने और परिणामों को साझा करने के लिए आलसी नहीं है।

आपका ध्यान देने के लिए धन्यवाद। मुझे आशा है कि कोई इसी तरह के शोध पर समय बर्बाद नहीं करने में लेख की मदद करता है। और पिछली छुट्टियों के साथ आप,% उपयोगकर्ता नाम%!

क्लाइंट पर छवियों का पूर्वावलोकन करना: लसदार ब्राउज़रों से लड़ना

शेल के लिए पहला दृष्टिकोण

दूसरा तरीका

तीसरा तरीका

चौथा दृष्टिकोण (और अंतिम): ऐसे और क्या होगा?

निष्कर्ष

क्या फ़ायरफ़ॉक्स हार गया?

IE पर हर किसी के साथ रहो!

Yandex.Browser बड़े भाइयों से थोड़ा पीछे है?

और ओपेरा कहां है?

लेकिन सफारी के बारे में क्या?

मोबाइल ब्राउज़र के बारे में क्या?

More articles: