L'utilisation de l'application Android cpu saut à 50-100% et trace seulement JDWP

Question

Mon application a commencé à ralentir le téléphone après qu'il a couru en arrière-plan pendant un moment. Après avoir enregistré l'utilisation du processeur, le fichier de trace me montre que JDWP prend 99% de l'utilisation du processeur sur le thread JDWP qui est le seul thread que je peux voir dans le fichier de trace.

Est-il possible que le JDWP (que Google dit est Java Debug Wire Protocol) prend autant de CPU ou ai-je un problème avec le fichier de trace? Le téléphone commence à travailler plus lentement et à se réchauffer après le saut d'utilisation du processeur, donc je suis sûr que les données d'utilisation sont correctes.

Voici 2 fichiers de trace qui ne montrent que jdwp:
https://drive.google.com/file/d/0B9MtungcpihwZnl0RFIwanktMEk/view?usp=sharing

Voici un album avant, au milieu et après l'enregistrement de la trace:
http://imgur.com/a/rOZ4g

La sortie du commande adb shell top -m 5 est ici:
http://pastebin.com/2FJNVvZA

Answer 1

Le thread JDWP ne devrait pas fonctionner beaucoup; C'est le thread qui gère les commandes du débogueur, y compris certaines choses que votre IDE fait automatiquement.

Je ne me souviens pas d'avoir vu cela prendre beaucoup de temps CPU, mais je suppose que cela pourrait arriver si vous (ou, plus probablement, certains outils) exécutiez beaucoup de commandes.

Sinon, vous avez peut-être trouvé un bogue dans la machine virtuelle (ART) ou dans l'EDI/les outils.

Si vous souhaitez partager le fichier de trace, cela ne me dérangerait pas d'y jeter un coup d'œil.

MISE À JOUR 1: J'ai jeté un coup d'oeil aux fichiers. En effet, il n'y a pas d'autres threads que le thread JDWP. Cependant, il n'utilise pas beaucoup de CPU - passez votre curseur sur le haut "JDWP". bloquer et vérifier le temps de l'horloge murale (4.344s) par rapport au temps CPU (0.006s). Vous pouvez également passer à la vue "Thread time" au lieu de "Wall Clock time" dans la liste déroulante en haut.

est ici la partie lisible par l'homme de l'un des fichiers de trace:

*version 
3 
data-file-overflow=false 
clock=dual 
elapsed-time-usec=4345915 
num-method-calls=410 
clock-call-overhead-nsec=3808 
vm=dalvik 
*threads 
1  main 
14  Thread-7700 
13  Thread-7699 
12  Thread-7698 
11  FileObserver 
10  Binder_2 
9  Binder_1 
8  FinalizerWatchdogDaemon 
7  FinalizerDaemon 
6  ReferenceQueueDaemon 
5  Compiler 
4  JDWP 
3  Signal Catcher 
2  GC 
*methods 
0x6da675c0  android/ddm/DdmHandleProfiling handleChunk  (Lorg/apache/harmony/dalvik/ddmc/Chunk;)Lorg/apache/harmony/dalvik/ddmc/Chunk; DdmHandleProfiling.java -1 
0x6da673c0  android/ddm/DdmHandleProfiling handleMPRQ  (Lorg/apache/harmony/dalvik/ddmc/Chunk;)Lorg/apache/harmony/dalvik/ddmc/Chunk; DdmHandleProfiling.java -1 
0x6da67430  android/ddm/DdmHandleProfiling handleMPSE  (Lorg/apache/harmony/dalvik/ddmc/Chunk;)Lorg/apache/harmony/dalvik/ddmc/Chunk; DdmHandleProfiling.java -1 
0x6da67468  android/ddm/DdmHandleProfiling handleMPSS  (Lorg/apache/harmony/dalvik/ddmc/Chunk;)Lorg/apache/harmony/dalvik/ddmc/Chunk; DdmHandleProfiling.java -1 
0x6d8b4ca0  java/nio/ByteBuffer  order (Ljava/nio/ByteOrder;)Ljava/nio/ByteBuffer;  ByteBuffer.java 635 
0x6d8b4410  java/nio/ByteBuffer  <init> (ILjava/nio/MemoryBlock;)V  ByteBuffer.java 116 
0x6d8b44f0  java/nio/ByteBuffer  wrap ([BII)Ljava/nio/ByteBuffer;  ByteBuffer.java 108 
0x6d8dd658  java/util/HashMap  get  (Ljava/lang/Object;)Ljava/lang/Object; HashMap.java -1 
0x6d918008  java/util/Arrays  checkOffsetAndCount  (III)V Arrays.java  1731 
0x6d9913a8  org/apache/harmony/dalvik/ddmc/ChunkHandler  wrapChunk  (Lorg/apache/harmony/dalvik/ddmc/Chunk;)Ljava/nio/ByteBuffer; ChunkHandler.java  80 
0x6d9807d0  android/os/Debug  getMethodTracingMode ()I  Debug.java  -1 
0x6d981100  android/os/Debug  startMethodTracingDdms (IIZI)V Debug.java  -1 
0x6d9811a8  android/os/Debug  stopMethodTracing  ()V  Debug.java  -1 
0x6da67040  android/ddm/DdmHandleHeap  handleChunk  (Lorg/apache/harmony/dalvik/ddmc/Chunk;)Lorg/apache/harmony/dalvik/ddmc/Chunk; DdmHandleHeap.java  -1 
0x6da66e78  android/ddm/DdmHandleHeap  handleHPIF  (Lorg/apache/harmony/dalvik/ddmc/Chunk;)Lorg/apache/harmony/dalvik/ddmc/Chunk; DdmHandleHeap.java  -1 
0x6d8be8d0  java/lang/Integer  equals (Ljava/lang/Object;)Z Integer.java 208 
0x6d8be940  java/lang/Integer  hashCode  ()I  Integer.java 302 
0x6d8be190  java/lang/Integer  <init> (I)V Integer.java 88 
0x6d8be740  java/lang/Integer  valueOf (I)Ljava/lang/Integer; Integer.java 706 
0x6d8b5240  java/nio/Buffer <init> (IILjava/nio/MemoryBlock;)V  Buffer.java  97 
0x6dc2d778  org/apache/harmony/dalvik/ddmc/DdmVmInternal heapInfoNotify (I)Z DdmVmInternal.java  -2 
0x6d8b5ec8  org/apache/harmony/dalvik/ddmc/Chunk <init> (I[BII)V  Chunk.java  45 
0x6d9d22a8  java/nio/ByteArrayBuffer  get ()B  ByteArrayBuffer.java 151 
0x6d9d2000  java/nio/ByteArrayBuffer  <init> (I[BIZ)V  ByteArrayBuffer.java 41 
0x6d9d2038  java/nio/ByteArrayBuffer  <init> ([B)V ByteArrayBuffer.java -1 
0x6d8b5fe0  org/apache/harmony/dalvik/ddmc/DdmServer  dispatch  (I[BII)Lorg/apache/harmony/dalvik/ddmc/Chunk; DdmServer.java 143 
0x6d8b7128  dalvik/system/VMDebug getMethodTracingMode ()I  VMDebug.java -2 
0x6d8b7550  dalvik/system/VMDebug startMethodTracingDdms (IIZI)V VMDebug.java 182 
0x6d8b76d8  dalvik/system/VMDebug stopMethodTracing  ()V  VMDebug.java -2 
0x6d8ba1b8  java/lang/Number  <init> ()V  Number.java  33 
*end 

Comme vous pouvez le voir, les autres fils sont au moins présents dans l'en-tête.

L'en-tête ne contient aucune référence à des méthodes non-système.

Je ne dirais pas qu'il est impossible que vous ayez trouvé un bogue bizarre - mais je pense qu'il est plus probable que votre application soit complètement inactive à ce stade, sauf pour le travail mineur de réponse aux commandes de trace sur JDWP, et la trace JDWP-only a réussi à vous embrouiller un peu.

Votre titre mentionne "l'utilisation cpu 50-100%", mais, ce qui suggère que quelque chose est en cours d'exécution. Je ne sais pas d'où vous avez ces chiffres - peut-être qu'ils comprennent tout, pas seulement votre application? Essayez d'exécuter adb shell top -m 5 pour connaître les principaux consommateurs de CPU de votre système.