onPageFinished अधिक से अधिक 2 मिनट लगते हैं जब URL सीधे

Question

कुछ वेबसाइटों पर पहुँचा, मैंने देखा है कि अगर मैं एक आंतरिक पृष्ठ का उपयोग सीधे (यानी न ही वेबसाइट पर एक अलग पेज से एक लिंक को स्पर्श करके), onPageFinished() हमेशा के लिए ले जाता है (यानी 2 मिनट और अधिक!) आने के लिए।

यदि मैं उसी वेबसाइट पर किसी पृष्ठ पर किसी लिंक को छूकर उसी पृष्ठ को लोड करता हूं, तो onPageFinished() हमेशा 1-2 सेकंड (उसी इंटरनेट कनेक्शन, समान सटीक स्थितियों) के भीतर आता है।

सभी मामलों में केवल एक onPageStarted() और केवल एक onPageFinished() है। यही है, कोई रीडायरेक्ट शामिल नहीं हैं।

इसके अलावा, प्रत्यक्ष (धीमी) और भीतर से साइट (तेज़) पहुंच दोनों में, पूरे पृष्ठ पूर्ण (दृश्यमान) के रूप में दिखाई देते हैं। यह केवल onPageStarted() है जो किसी कारण से (सीधे पहुंच में) आने से इंकार कर देता है।

बेहतर, समस्या को समझने के लिए मैं ऐसे पेज का एक उदाहरण प्रदान कर रहा हूँ:

http://mobile.nytimes.com/2013/07/19/world/middleeast/touring-refugee-camp-kerry-sees-mounting-syrian-suffering.html?from=homepage

आप उदाहरण के लिए वेबसाइट के मुख्यपृष्ठ से इस पृष्ठ तक पहुंचते हैं तो, onPageFinished() बहुत तेजी से आता है।

(मुखपृष्ठ ही है, जब सीधे पहुँचा, 1-2 सेकंड के भीतर onPageFinished() करता है!)

क्या इस व्यवहार समझा सकता है?

इस तरह की समस्या का निवारण कैसे करें?

अद्यतन 1: LogCat उत्पादन को देखते हुए मैंने देखा है कि धीमी गति से (प्रत्यक्ष) मामलों तुरंत onPageStarted() के बाद dalvikvm जीसी संचालन के बर्स्ट की विशेषता है:

07-18 21:22:33.876: D/dalvikvm(6298): GC_FOR_MALLOC freed 10371 objects/495744 bytes in 54ms 
07-18 21:22:34.016: D/dalvikvm(6298): GC_FOR_MALLOC freed 808 objects/50824 bytes in 51ms 
07-18 21:22:34.586: D/dalvikvm(6298): GC_FOR_MALLOC freed 1092 objects/297328 bytes in 72ms 
07-18 21:22:34.646: D/dalvikvm(6298): GC_EXTERNAL_ALLOC freed 49 objects/2296 bytes in 59ms 
07-18 21:22:36.526: I/global(6298): Default buffer size used in BufferedInputStream constructor. It would be better to be explicit if an 8k buffer is required. 
07-18 21:22:36.626: D/dalvikvm(6298): GC_FOR_MALLOC freed 4687 objects/513240 bytes in 86ms 
07-18 21:22:36.626: I/dalvikvm-heap(6298): Grow heap (frag case) to 3.304MB for 131088-byte allocation 
07-18 21:22:36.706: D/dalvikvm(6298): GC_FOR_MALLOC freed 928 objects/53008 bytes in 69ms 
07-18 21:22:36.766: D/dalvikvm(6298): GC_FOR_MALLOC freed 9 objects/264 bytes in 61ms 
07-18 21:22:36.766: I/dalvikvm-heap(6298): Grow heap (frag case) to 3.378MB for 131088-byte allocation 
07-18 21:22:36.836: D/dalvikvm(6298): GC_FOR_MALLOC freed 0 objects/0 bytes in 69ms 
07-18 21:22:37.286: D/dalvikvm(6298): GC_FOR_MALLOC freed 547 objects/98160 bytes in 73ms 
07-18 21:22:37.286: I/dalvikvm-heap(6298): Grow heap (frag case) to 3.617MB for 262480-byte allocation 
07-18 21:22:37.336: D/dalvikvm(6298): GC_FOR_MALLOC freed 175 objects/8384 bytes in 46ms 
07-18 21:22:37.706: D/dalvikvm(6298): GC_FOR_MALLOC freed 340 objects/183688 bytes in 78ms 
07-18 21:22:37.706: I/dalvikvm-heap(6298): Grow heap (frag case) to 3.994MB for 527244-byte allocation 
07-18 21:22:37.776: D/dalvikvm(6298): GC_FOR_MALLOC freed 104 objects/4560 bytes in 69ms 
07-18 21:22:38.006: D/dalvikvm(164): GC_EXPLICIT freed 21550 objects/1176488 bytes in 137ms 
07-18 21:22:38.286: D/dalvikvm(6298): GC_FOR_MALLOC freed 227 objects/299888 bytes in 50ms 
07-18 21:22:38.286: I/dalvikvm-heap(6298): Grow heap (frag case) to 4.135MB for 444555-byte allocation 
07-18 21:22:38.326: D/dalvikvm(6298): GC_FOR_MALLOC freed 1 objects/16 bytes in 41ms 
07-18 21:22:38.376: D/dalvikvm(6298): GC_FOR_MALLOC freed 352 objects/687432 bytes in 36ms 
07-18 21:22:38.376: I/dalvikvm-heap(6298): Grow heap (frag case) to 4.330MB for 592732-byte allocation 
07-18 21:22:38.416: D/dalvikvm(6298): GC_FOR_MALLOC freed 2 objects/104 bytes in 44ms 
07-18 21:22:38.456: D/dalvikvm(6298): GC_FOR_MALLOC freed 4 objects/96 bytes in 33ms 
07-18 21:22:38.456: I/dalvikvm-heap(6298): Grow heap (frag case) to 4.612MB for 296374-byte allocation 
07-18 21:22:38.496: D/dalvikvm(6298): GC_FOR_MALLOC freed 0 objects/0 bytes in 41ms 
07-18 21:22:38.536: D/dalvikvm(6298): GC_FOR_MALLOC freed 162 objects/599848 bytes in 29ms 
07-18 21:22:38.536: I/dalvikvm-heap(6298): Grow heap (frag case) to 5.170MB for 1185448-byte allocation 
07-18 21:22:38.576: D/dalvikvm(6298): GC_FOR_MALLOC freed 0 objects/0 bytes in 40ms 
07-18 21:22:38.626: D/dalvikvm(6298): GC_FOR_MALLOC freed 7 objects/1185616 bytes in 35ms 
07-18 21:22:38.626: I/dalvikvm-heap(6298): Grow heap (frag case) to 5.443MB for 878616-byte allocation 
07-18 21:22:38.676: D/dalvikvm(6298): GC_FOR_MALLOC freed 0 objects/0 bytes in 42ms 

इसका क्या मतलब है? क्या यह वेबसाइट में एक समस्या है? या मेरे कोड में?

अद्यतन 2: यह केवल onPageFinished() नहीं है जो सीधे यूआरएल पहुंच पर देरी हो जाती है, यह WebChromClient.onProgressChanged() भी है! यह हमेशा 89% अंक पर जम जाता है, फिर onPageFinished() प्राप्त होने के बाद 100% तक छोड़ देता है। कुछ अजीब चल रहा है। क्यूं कर?

क्या यह वेबसाइट का जानबूझकर व्यवहार हो सकता है?

यदि आप "हाँ" का उत्तर देने का लुत्फ उठा रहे हैं, तो यह एक अलग ब्राउज़र (जैसे फ़ायरफ़ॉक्स या क्रोम) का उपयोग करके उसी पृष्ठ तक पहुंचने पर ऐसा क्यों नहीं करता है?

यदि यह उस विशिष्ट वेबसाइट (यानी मेरे कोड में बग) का जानबूझकर व्यवहार नहीं है, तो यह अन्य वेबसाइटों के साथ क्यों नहीं होता है?

Answer 1

ऐसा इसलिए होना चाहिए क्योंकि वेबसाइट को आंतरिक पृष्ठों में बहुत अधिक संसाधन लोड करना होगा।

लिंक के माध्यम से पहुंचते समय यह तेज़ लोड क्यों होता है, अधिकांश वेबपृष्ठ संसाधन साझा किए जाते हैं और ब्राउज़ नेविगेशन के माध्यम से वेबव्यू द्वारा कैश किए जाते।