onPageFinished trwa dłużej niż 2 minuty, gdy adres URL dostępne bezpośrednio

Question

Na niektórych stronach internetowych, zauważyłem, że jeśli dostęp do wewnętrznej strony bezpośrednio (czyli nie dotykając link z innej strony na tej samej stronie), onPageFinished() trwa wiecznie (tj. 2 minuty i więcej!), aby dotrzeć.

Jeśli załaduję tę samą stronę, klikając link na stronie w tej samej witrynie, onPageFinished() zawsze pojawia się w ciągu 1-2 sekund (to samo połączenie internetowe, takie same dokładne warunki).

We wszystkich przypadkach jest tylko jeden onPageStarted() i tylko jeden onPageFinished(). Oznacza to, że nie są zaangażowane żadne przekierowania.

Ponadto, zarówno w bezpośrednim (powolnym) jak i od wewnątrz (szybkim) dostępie, wszystkie strony są wyświetlane jako kompletne (wizualnie). To tylko onPageStarted(), który odmawia przybycia z jakiegoś powodu (w bezpośrednim dostępie).

Aby lepiej zrozumieć problem, przytaczam przykład takiej strony:

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

Jeśli masz dostęp do tej strony ze strony głównej witryny, na przykład, onPageFinished() przybywa znacznie szybciej.

(sama strona, gdy dostępne bezpośrednio, dostaje onPageFinished() ciągu 1-2 sekund!)

Co może wyjaśnić to zachowanie?

Jak rozwiązać problem podobny do tego?

Aktualizacja 1: Patrząc na wyjściu logcat Zauważyłem, że powolne (Direct) przypadki charakteryzują przypływie dalvikvm operacji GC natychmiast po onPageStarted():

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 

Co to oznacza? Czy to jest problem na stronie? lub w moim kodzie?

Aktualizacja 2: To nie tylko onPageFinished(), które jest opóźnione w bezpośrednim dostępie do adresu URL, ale także WebChromClient.onProgressChanged()! Zawsze zamiera na poziomie 89%, a następnie przeskakuje do 100% zaraz po otrzymaniu onPageFinished(). Dzieje się coś dziwnego. Czemu?

Czy może to być zamierzone zachowanie strony internetowej?

Jeśli masz ochotę odpowiedzieć na "tak", dlaczego nie robi tego podczas bezpośredniego dostępu do tej samej strony przy użyciu innej przeglądarki (np. Firefox lub Chrome)?

Jeśli to nie jest zamierzonym zachowaniem tej konkretnej witryny (np. Błąd w moim kodzie), dlaczego tak się nie dzieje z innymi witrynami?

Answer 1

Powodem tego jest fakt, że strona wewnętrzna musi ładować zbyt dużo zasobów.

Powód, dla którego ładuje się szybciej, gdy uzyskuje się dostęp za pośrednictwem linków, większość zasobów stron internetowych jest udostępniana i zostałaby zbuforowana przez przeglądarkę internetową za pomocą nawigacji przeglądania.