Come eseguire il debug di tempo tra $ ionicView.beforeEnter e $ ionicView.enter

Question

Io uso ionic e ci vogliono più di 1 secondo tra $ionicView.beforeEnter e $ionicView.enter.

Come posso trovare quale parte del mio codice impiega così tanto tempo? Batarang non mi sta aiutando molto e non riesco a capire un modo semplice per farlo ...

Answer 1

Probabilmente non molto utile, ma quando ho avuto un problema simile non sono riuscito a trovare il colpevole usando il profilo di debug di Chrome e ho dovuto commentare/escludere parti del codice nel mio controller, a cui mi passaggio, uno alla volta. Il problema era che alcuni componenti del calendario di terze parti configurati nella fase di avvio del controller rallentavano la transizione (visualizzazione della vista). Una volta commentato, tutto ha funzionato bene. Dal momento che questo non era il mio codice e non volevo incasinarlo, ho dovuto aggiungere uno strumento per il progresso nella transizione.

Answer 2

Forse puoi usare gli strumenti di debug forniti con Chrome come Timeline o Profilo: si avvia la profilazione o il record del linea temporale e verificare cosa succede tra $ ionicView.beforeEnter e $ ionicView.enter. Entrambe le funzionalità hanno un modulo di ricerca in modo da poter cercare $ionicView.beforeEnter e vedere che cosa sta prendendo tempo fino al $ionicView.enter. Probabilmente non è il modo più semplice, ma spero che ti possa aiutare.

Answer 3

Non riesco a pensare a un modo semplice per farlo. Ma estendendoci a ciò che @nico_ menziona, usando lo strumento di debug di javascript di Chrome, dovresti impostare un punto di interruzione su $ioniView.beforeEnter e un punto di interruzione su $ionicView.enter quindi passare attraverso il codice tra i punti di interruzione.

Si può leggere di più su strumenti di debug javascript di cromo e come impostare i punti di interruzione qui: https://developer.chrome.com/devtools/docs/javascript-debugging

Answer 4

Hai provato il monitoraggio del traffico nella scheda di rete in console? Il tempo in ms è un buon indicatore del quale le chiamate xhr stanno funzionando più a lungo del previsto ... esegui un speed test.

In caso contrario, se si utilizza Chrome, vorrei semplicemente rilasciare alcune istruzioni debugger attraverso il flusso dello stato di quella vista ionica.

Answer 5

Non esiste un codice "tra i punti di rottura" ... Ci sono così tanto funzioni chiamate tra i 2 eventi ...

- Tyrius

Si dovrebbe cercare di identificare le funzioni che impiegano troppo tempo per correre.

Nota: Suppongo che la tua app non sia rallentata dai download, puoi controllare il tempo di download in Chrome Dev Tools (se TTFB è troppo alto, potresti avere una lentezza sul lato server).

Se si sa quali funzioni sono chiamati, avete due possibilità:

• Quando v'è un paio di funzioni e non chiamati troppe volte:

  function ExampleFunction() { 
      console.time("ExampleFunction"); 
      // ExampleFunction code 
      // ... 
      console.timeEnd("ExampleFunction"); 
      // output in console time between time() call and timeEnd() call 
  } 
  

• Se c'è un sacco di funzioni chiamate più volte:

Ti suggerisco di utilizzare il mio piccolo strumento JS chiamato MonitorJS per aiutare a identificare i blocchi di codice che prendono troppo tempo per eseguire:

function ExampleFunction() { 
    let mId = Monitor.Start("ExampleFunction"); 
    // ExampleFunction code 
    // ... 
    Monitor.Stop(mId); 
} 

e quando quello di vedere quale funzione sta prendendo troppo tempo, chiama questa funzione:

function ShowMonitorRecords() { 
    // get all records sorted by total_time desc 
    let records = Monitor.GetAll().sort((a,b)=>{ return b.total_time - a.total_time; }); 
    // print every records 
    for (let record of records) { 
     let avg = record.total_time/record.call_count; 
     console.log(record.name + ": " + record.total_time.toFixed(2) 
      + "ms - called " + record.call_count 
      + " time(s) - average time : "+ avg.toFixed(2) +"ms"); 
    } 
} 

// will output something like : 
// Foo: 7234.33ms - called 2 time(s) - average time : 3617.16ms 
// Bar: 6104.25ms - called 3 time(s) - average time : 2034.75ms 

Una volta che sai che la funzione impiega troppo tempo, puoi ridurre l'ambito di Start/Stop per identificare il blocco esatto del codice rallentando la tua app e refactoring.

Spero che questo aiuti!