2013-07-19 24 views
10

Su determinati siti Web, ho notato che se accedo direttamente a una pagina interna (ovvero non toccando un collegamento da una pagina diversa sullo stesso sito Web), impiega un'eternità (vale a dire 2 minuti e più!) per arrivare.onPageFinished richiede più di 2 minuti quando l'URL accede direttamente

Se carico la stessa pagina toccando un collegamento in una pagina sullo stesso sito Web, onPageFinished() arriva sempre entro 1-2 secondi (stessa connessione Internet, stesse condizioni esatte).

In tutti i casi c'è solo uno onPageStarted() e solo uno onPageFinished(). Cioè, non sono coinvolti reindirizzamenti.

Inoltre, sia nell'accesso diretto (lento) che all'interno (veloce), l'intera pagina risulta completa (visivamente). È solo il onPageStarted() che rifiuta di arrivare per qualche motivo (nell'accesso diretto).

Per capire meglio il problema, sto fornendo un esempio di tale pagina:

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

Se si accede a questa pagina dalla homepage del sito, ad esempio, onPageFinished() arriva molto più veloce.

(la home page stessa, quando vi si accede direttamente, ottiene onPageFinished() entro 1-2 secondi!)

Cosa potrebbe spiegare questo comportamento?

Come risolvere un problema come questo?

Update 1: Guardando l'uscita LogCat ho notato che le lenti casi (diretti) sono caratterizzati da una raffica di dalvikvm operazioni GC subito dopo 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 

Cosa significa? È un problema nel sito web? o nel mio codice?

Aggiornamento 2: non è solo onPageFinished() che viene ritardato in caso di accesso diretto all'URL, è anche WebChromClient.onProgressChanged()! Si blocca sempre al segno dell'89%, quindi salta al 100% dopo che è stato ricevuto. Sta succedendo qualcosa di strano. Perché?

Potrebbe essere un comportamento intenzionale del sito web?

Se si è tentati di rispondere a "sì", perché non lo fa quando accede direttamente alla stessa pagina utilizzando un browser diverso (ad esempio Firefox o Chrome)?

Se questo non è comportamento intenzionale di tale sito Web specifico (ad esempio bug nel mio codice), perché questo non accade con altri siti web?

risposta

0

Ciò dovrebbe essere dovuto al fatto che il sito Web deve caricare troppe risorse nelle pagine interne.

Motivo per il quale si carica più rapidamente quando si accede tramite i collegamenti, la maggior parte delle risorse delle pagine Web sono condivise e sarebbero state memorizzate nella cache dalla visualizzazione Web tramite la navigazione di navigazione.

+3

La tua teoria avrebbe senso se la prima pagina caricata da quel sito Web che porta a quella pagina problematica (ad esempio homepage) mostrasse la stessa lentezza. Ma non è così. Si carica in 1-2 secondi! – WebViewer