2013-07-19 14 views
10

auf bestimmte Websites zugegriffen, bemerkte ich, dass wenn ich eine innere Seite zugreifen direkt (dh nicht durch einen Link von einer anderen Seite auf der gleichen Website zu berühren), onPageFinished() ewig dauert (dh 2 Minuten und mehr!) um anzukommen.onPageFinished mehr als 2 Minuten dauert, wenn URL direkt

Wenn ich dieselbe Seite durch Berühren eines Links auf einer Seite auf derselben Website lade, kommt onPageFinished() immer innerhalb von 1-2 Sekunden an (gleiche Internetverbindung, genau die gleichen Bedingungen). In allen Fällen gibt es nur einen onPageStarted() und nur einen onPageFinished(). Das bedeutet, dass keine Weiterleitungen beteiligt sind.

Auch in den direkten (langsam) und von-innerhalb-Seite (schnell) Zugriff, die gesamte Seite zeigt sich als vollständig (visuell). Es ist nur die onPageStarted(), die aus irgendeinem Grund (im direkten Zugriff) ablehnt.

besser Um das Problem zu verstehen, ich ein Beispiel einer solchen Seite bin Bereitstellung:

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

Wenn Sie diese Seite von der Homepage der Website zugreifen, zum Beispiel kommt onPageFinished() viel schneller.

(die Homepage selbst, wenn sie direkt zugegriffen wird, bekommt onPageFinished() innerhalb von 1-2 Sekunden!)

Was dieses Verhalten erklären könnte?

So beheben Sie ein Problem wie dieses?

Update 1: Ein Blick auf die LogCat Ausgang bemerkte ich, dass die langsamen (direkt) Fälle von einem Ausbruch von dalvikvm GC Operationen unmittelbar nach onPageStarted() gekennzeichnet sind:

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 

Was bedeutet das? Ist das ein Problem in der Website? oder in meinem Code?

Update 2: Es ist nicht nur onPageFinished(), die auf direkten URL-Zugriff verzögert wird, es ist auch WebChromClient.onProgressChanged()! Es friert immer bei der 89% -Marke ein und springt dann zu 100%, nachdem onPageFinished() empfangen wurde. Etwas Seltsames geht vor sich. Warum?

Könnte dies absichtliches Verhalten der Website sein?

Wenn Sie versucht sind zu antworten "Ja", warum tut es dies nicht beim direkten Zugriff auf die gleiche Seite mit einem anderen Browser (z. B. Firefox oder Chrome)?

Wenn dies ist nicht absichtliches Verhalten dieser bestimmten Website (d. H. Fehler in meinem Code), warum passiert das nicht mit anderen Websites?

Antwort

0

Dies sollte sein, weil die Website zu viel Ressourcen auf den inneren Seiten geladen werden muss.

Der Grund, warum es beim Zugriff über Links schneller geladen wird, ist, dass die meisten Webseiten-Ressourcen freigegeben sind und durch die Webansicht über die Navigation im Browser zwischengespeichert wurden.

+3

Ihre Theorie würde Sinn machen, wenn die erste Seite, die von dieser Website geladen wird, die zu dieser problematischen Seite (z. B. Homepage) führt, die gleiche Langsamkeit zeigen würde. Aber das tut es nicht. Es lädt in 1-2 Sekunden! – WebViewer

Verwandte Themen