2013-03-01 7 views
9

Quando uso comando TOP, ho potuto ottenere le seguenti informazioni:Come ottenere una maggiore precisione di "CPU%" rispetto a quella del comando TOP?

[email protected]:/ $ top -n 1              

User 31%, System 10%, IOW 0%, IRQ 0% 
User 346 + Nice 10 + Sys 120 + Idle 637 + IOW 6 + IRQ 0 + SIRQ 2 = 1121 

    PID PR CPU% S #THR  VSS  RSS PCY UID  Name 
    481 1 26% S 89 762832K 81688K fg system system_server 
1699 0 5% S 27 676472K 39092K fg u0_a72 wm.cs.systemmonitor 
11243 0 3% S 28 673140K 29796K bg u0_a111 com.weather.Weather 
13327 2 1% S 23 680472K 35844K bg u0_a83 com.rhmsoft.fm 
    659 0 1% S 17 663044K 33136K bg u0_a13 android.process.media 
20260 1 0% R  1 1208K 508K  shell top 

possiamo vedere il CPU% è rotonda a intero, c'è qualche modo ho potuto ottenere di CPU% con maggiore precisione un processo?

- Chiarimenti sulla bontà -Alex

La domanda si riferisce a sistema Android, e preferibilmente ad un dispositivo non radicata. Mentre Android offre tecniche di profilazione avanzate per applicazioni Java, gli strumenti per il codice nativo (C++) sono limitati. Il comando superiore su Android consente di mostrare le statistiche di tutti i thread in esecuzione nel sistema, sia i thread Java che i thread C++. Sto cercando una risposta che ti possa aiutare con la seguente ricerca:

La mia app utilizza il 2% di CPU quando è inattiva in background, mentre dovrebbe essere inferiore allo 0,1%. Se eseguotop -t, ottengo lo 0% per tutti i 15 thread che appartengono al mio processo (alcuni thread sono thread Java, ad esempio il thread Main, UI, altri sono pthread che non si collegano mai a JVM). Come posso indovinare quale thread mangia la batteria?

Sarei lieto di ottenere ulteriori dettagli su questa attività inaspettata, e Android fornisce ottimi aiutanti come TraceView per i thread Java. Qualsiasi intuizione riguardante gli strumenti per il codice nativo sarà molto apprezzata.

+2

non farebbe molta differenza .... –

+1

@MitchWheat: Sì, fa la differenza. Altrimenti, per favore aiutami a profilare l'applicazione che usa il 2% di CPU in background. Quando eseguo 'top -t', ottengo lo 0% per tutti i 15 thread che appartengono al mio processo. Come posso indovinare quale thread mangia la batteria? –

+0

Non ho detto che non avrebbe fatto alcuna differenza; Ho detto "non farebbe molta differenza" –

risposta

6

Lei non ne ha parlato nel tuo post, ma nel commento che hai detto che si ha realmente bisogno l'utilizzo della CPU per thread, non per processo.

Se non riesci a trovare uno strumento sufficientemente accurato, puoi guardare direttamente in /proc/[pid]/task/[ThreadName] come descritto in the man page for /proc. Questo dà il tempo totale della CPU consumato in "clock ticks" dall'inizio dell'esecuzione. Ottenere una risoluzione migliore di questa è probabilmente difficile o impossibile.

Modifica

Dal commento del PO, un comando che elenca le informazioni rilevanti sono:

adb shell cat /proc/${pid}/task/*/stat | awk -F\ '{print $1, $14}' 

Questo solo cat s corretti /proc file per l'host di debug, che gestisce un piccolo awk programma per stampare le colonne per pid e user time. È inoltre possibile utilizzare facilmente cut -d " " -f1,14 o qualcosa di simile in perl per ottenere le colonne se awk non è disponibile.

+0

Grazie! Questo consiglio ha davvero risolto il mio problema. –

+1

Su * alcuni * dispositivi, è anche possibile ottenere i contatori di schedstat ('/ proc//schedstat' e'/proc//task//schedstat'). I tre campi sono: tempo trascorso sulla CPU; tempo trascorso in attesa di un runqueue; # di timeslices eseguiti sulla CPU. Tuttavia, alcuni OEM non abilitano questa funzionalità nel kernel. – fadden

3

Prova questo:

ps -eo pcpu,pid,user,args | sort -r -k1 | less 

%CPU PID USER  COMMAND 
9.0 2721 user bash 
1.4 956 root  ... 
0.5 2212 user ... 

EDIT:

È possibile utilizzare adb shell e busybox (http://www.busybox.net/downloads/BusyBox.html)

adb shell busybox superiore

c:\ adb push busybox /system/bin 
c:\ adb shell 
# busybox top 

CPU: 2.3% usr 3.1% sys 3.9% nic 90.5% idle 0.0% io 0.0% irq 0.0% sirq 
Load average: 1.06 1.66 10.63 1/589 8048 
←[7m PID PPID USER  STAT VSZ %MEM CPU %CPU COMMAND←[0m 
31619 2180 10112 S  217m 67.0 0 3.8 com.mgeek.android.DolphinBrowser.B 

2232 2180 1000  S  551m169.6 0 2.6 system_server 
8038 8037 0  R  2068 0.6 0 0.8 busybox top 
2178  1 0  S 11092 3.3 0 0.6 /system/bin/drexe 
6812 2180 10104 S  199m 61.2 0 0.5 android.tether 
2291 2180 1001  S  324m 99.8 0 0.3 com.android.phone 
2308 2180 10006 S  325m100.0 0 0.1 com.sec.android.app.dialertab 
2177  1 1001  S  9624 2.8 0 0.1 /system/bin/rild 
    5  2 0  SW<  0 0.0 0 0.1 [events/0] 
30087 2180 10022 S  358m110.4 0 0.0 com.samsung.vvm 
2304 2180 10006 S  311m 96.0 0 0.0 com.sec.android.app.twlauncher 
16110 2180 10006 S  296m 91.3 0 0.0 android.process.acore 
2445 2180 10006 S  272m 83.8 0 0.0 com.sec.android.provider.logsprovi 

8064 2180 10002 S  238m 73.4 0 0.0 com.google.process.gapps 
31537 2180 10037 S  227m 69.9 0 0.0 com.google.android.gm 
2288 2180 10048 S  221m 68.1 0 0.0 com.swype.android.inputmethod 
2285 2180 10013 S  215m 66.3 0 0.0 com.tat.livewallpaper.aurora 
30664 2180 10011 S  213m 65.8 0 0.0 com.android.email 
31191 2180 10099 S  209m 64.4 0 0.0 com.sirma.mobile.bible.android 
2377 2180 10087 S  207m 63.9 0 0.0 android.tts 

(Tratto da here)

+0

Hai provato questo su Android o un Linux generico? La mia tavoletta JellyBean ignora questi parametri –

+0

Ho appena modificato la mia risposta :) –

+0

Cool. Dovrebbe aver aggiunto: "in un dispositivo senza root" –

1

Got queste informazioni da un altro thread:

3) Ottenere informazioni CPU

~ $ adb dumpsys shell cpuinfo

uscita:

carico: 0,08/0,4/0,64 Utilizzo della CPU da 42816 ms a 34683 ms: system_server: 1% = 1% utente + 0% kernel/errori: 16 minor kdebuglog.sh: 0% = 0% utente + 0% kernel/errori: 160 minore tiwlan_wq: 0% = 0% utente + 0% kernel usb_mass_storag: 0% = 0% utente + 0% kernel pvr_workqueue: 0% = 0 % utente + 0% kernel + sleep: 0% = 0% utente + 0% kernel + sleep: 0% = 0% utente + 0% kernel TOTALE: 6% = 1% utente + 3% kernel + 0% irq

EDIT:

si può anche provare questo comando: echo $(adb shell ps | grep com.android.phone | awk '{ system("adb shell cat /proc/" $2 "/stat");}' | awk '{print $14+$15;}')

anche:

01.235.164,106 mila

utilizzando top: Questo ti mostrerà la CPU stats top -b -n 1 |grep ^Cpu

usando ps: Questo ti mostrerà l'utilizzo della CPU% per ogni processo. ps -eo pcpu,pid,user,args | sort -r -k1 | less

EDIT2:

In realtion ai vostri commenti e la descrizione di taglie (Come posso indovinare quale filo mangia la batteria?) Ho trovato una pagina interessante:

http://ziyang.eecs.umich.edu/projects/powertutor/

Come indicato:

È possibile utilizzare PowerTutor t o monitorare il consumo energetico di qualsiasi applicazione .

Provalo per un'istanza e verifica se soddisfa le tue esigenze.

montaggio finale:

Controllare la documentazione Systrace sul sito developer.android.com:

http://developer.android.com/tools/debugging/systrace.html http://developer.android.com/tools/help/systrace.html

Mi dispiace se avete già provato, ma questo è un metodo concreto per misurare le prestazioni.

+0

Come ho spiegato nella descrizione di taglie, l'uso della CPU di precisione più elevata è interessante se usato insieme al parametro -t, per aiutare a trovare le thrrad che non sono abbastanza inattive. –

+0

BTW, 'ps' sui miei dispositivi non supporta' -eo'. –

+0

re: PowerTutor - non fornisce la risoluzione per-thread. Ma fornisce sicuramente molte informazioni utili, ad es. Wi-Fi o visualizza il consumo energetico per applicazione. –

-1

Usa DDMS e il metodo di profiling per ottenere un Traceview.

In sostanza:

  1. lanciare la vostra applicazione in modalità debug
  2. In DDMS, nella scheda Dispositivi, fare clic su "Start metodo di profiling"
  3. fare cose sul dispositivo per ricreare le condizioni che si desidera monitorare
  4. Fare clic su "metodo stop profiling"
  5. si otterrà un grafico abbastanza dettagliato con l'esecuzione di ogni thread che è possibile visualizzare in dettaglio

Maggiori dettagli qui: http://developer.android.com/tools/debugging/debugging-tracing.html

Disclaimer: ho fatto solo questo con un semplice applicazione di test, quindi non so quanto chilometraggio si otterrà fuori di esso. Sembra dare un po 'più di precisione rispetto a quanto descritto finora e non richiede la root.

enter image description here

+1

L'approccio che hai pubblicato qui è sicuramente utile in molti casi e dovremmo ricordare più e più volte i potenti strumenti di profilazione disponibili per Android JVM. Sfortunatamente, questo non risponde alla domanda, perché lo scoglio è l'attività dei thread nativi, che non è coperta da TraceView. –

Problemi correlati