dumpsys

dumpsys é uma ferramenta que é executada em dispositivos Android e fornece informações sobre serviços do sistema. Você pode chamar dumpsys na linha de comando usando o Android Debug Bridge (ADB) para ter uma saída de diagnóstico para todos os serviços do sistema em execução em um dispositivo conectado. Normalmente, essa saída é mais detalhada que o necessário. Portanto, use as opções de linha de comando descritas abaixo para ver apenas as informações dos serviços do sistema em que você tem interesse. Esta página também descreve como usar o dumpsys para realizar tarefas comuns, como inspeção de entrada, diagnóstico de RAM, bateria ou rede.

Sintaxe

A sintaxe geral para usar dumpsys é a seguinte:

 adb shell dumpsys [-t timeout] [--help | -l | --skip services | service [arguments] | -c | -h]

Para ter uma saída de diagnóstico para todos os serviços do sistema do dispositivo conectado, basta executar o adb shell dumpsys. No entanto, isso gera muito mais informações do que normalmente desejado. Para ter uma saída mais gerenciável, especifique o serviço que você quer examinar incluindo-o no comando. Por exemplo, o comando abaixo fornece dados do sistema para componentes de entrada, como touchscreens ou teclados integrados:

adb shell dumpsys input

Para ver uma lista completa dos serviços do sistema que podem ser usados com dumpsys, use o seguinte comando:

adb shell dumpsys -l

Opções de linha de comando

A tabela a seguir lista as opções disponíveis ao usar o dumpsys.

adb shell dumpsys procstats -h
    

Inspecionar diagnósticos de entrada

Especificar o serviço de input, como mostrado abaixo, despeja o estado dos dispositivos de entrada do sistema, como teclados e touchscreens, e o processamento de eventos de entrada.

adb shell dumpsys input

A saída pode variar de acordo com a versão do Android executada no dispositivo conectado. As seções abaixo descrevem o tipo de informação que é vista normalmente.

Estado do hub de eventos

Veja a seguir uma amostra do que pode ser encontrado ao inspecionar o estado do hub de eventos dos diagnósticos de entrada:

INPUT MANAGER (dumpsys input)

Event Hub State:
  BuiltInKeyboardId: -2
  Devices:
    -1: Virtual
      Classes: 0x40000023
      Path: 
      Descriptor: a718a782d34bc767f4689c232d64d527998ea7fd
      Location:
      ControllerNumber: 0
      UniqueId: 
      Identifier: bus=0x0000, vendor=0x0000, product=0x0000, version=0x0000
      KeyLayoutFile: /system/usr/keylayout/Generic.kl
      KeyCharacterMapFile: /system/usr/keychars/Virtual.kcm
      ConfigurationFile:
      HaveKeyboardLayoutOverlay: false
    1: msm8974-taiko-mtp-snd-card Headset Jack
      Classes: 0x00000080
      Path: /dev/input/event5
      Descriptor: c8e3782483b4837ead6602e20483c46ff801112c
      Location: ALSA
      ControllerNumber: 0
      UniqueId:
      Identifier: bus=0x0000, vendor=0x0000, product=0x0000, version=0x0000
      KeyLayoutFile:
      KeyCharacterMapFile:
      ConfigurationFile:
      HaveKeyboardLayoutOverlay: false
    2: msm8974-taiko-mtp-snd-card Button Jack
      Classes: 0x00000001
      Path: /dev/input/event4
      Descriptor: 96fe62b244c555351ec576b282232e787fb42bab
      Location: ALSA
      ControllerNumber: 0
      UniqueId:
      Identifier: bus=0x0000, vendor=0x0000, product=0x0000, version=0x0000
      KeyLayoutFile: /system/usr/keylayout/msm8974-taiko-mtp-snd-card_Button_Jack.kl
      KeyCharacterMapFile: /system/usr/keychars/msm8974-taiko-mtp-snd-card_Button_Jack.kcm
      ConfigurationFile:
      HaveKeyboardLayoutOverlay: false
    3: hs_detect
      Classes: 0x00000081
      Path: /dev/input/event3
      Descriptor: 485d69228e24f5e46da1598745890b214130dbc4
      Location:
      ControllerNumber: 0
      UniqueId:
      Identifier: bus=0x0000, vendor=0x0001, product=0x0001, version=0x0001
      KeyLayoutFile: /system/usr/keylayout/hs_detect.kl
      KeyCharacterMapFile: /system/usr/keychars/hs_detect.kcm
      ConfigurationFile:
      HaveKeyboardLayoutOverlay: false
...

Estado do leitor de entrada

O InputReader é responsável pela decodificação de eventos de entrada do kernel. O despejo de estado dele mostra informações sobre como cada dispositivo de entrada está configurado e mudanças de estado que ocorreram recentemente, como teclas pressionadas ou toques no touchscreen.

Na amostra a seguir, há uma saída de uma tela sensível ao toque. Observe as informações sobre a resolução do dispositivo e os parâmetros de calibração que foram usados.

Input Reader State
...
  Device 6: Melfas MMSxxx Touchscreen
      IsExternal: false
      Sources: 0x00001002
      KeyboardType: 0
      Motion Ranges:
        X: source=0x00001002, min=0.000, max=719.001, flat=0.000, fuzz=0.999
        Y: source=0x00001002, min=0.000, max=1279.001, flat=0.000, fuzz=0.999
        PRESSURE: source=0x00001002, min=0.000, max=1.000, flat=0.000, fuzz=0.000
        SIZE: source=0x00001002, min=0.000, max=1.000, flat=0.000, fuzz=0.000
        TOUCH_MAJOR: source=0x00001002, min=0.000, max=1468.605, flat=0.000, fuzz=0.000
        TOUCH_MINOR: source=0x00001002, min=0.000, max=1468.605, flat=0.000, fuzz=0.000
        TOOL_MAJOR: source=0x00001002, min=0.000, max=1468.605, flat=0.000, fuzz=0.000
        TOOL_MINOR: source=0x00001002, min=0.000, max=1468.605, flat=0.000, fuzz=0.000
      Touch Input Mapper:
        Parameters:
          GestureMode: spots
          DeviceType: touchScreen
          AssociatedDisplay: id=0, isExternal=false
          OrientationAware: true
        Raw Touch Axes:
          X: min=0, max=720, flat=0, fuzz=0, resolution=0
          Y: min=0, max=1280, flat=0, fuzz=0, resolution=0
          Pressure: min=0, max=255, flat=0, fuzz=0, resolution=0
          TouchMajor: min=0, max=30, flat=0, fuzz=0, resolution=0
          TouchMinor: unknown range
          ToolMajor: unknown range
          ToolMinor: unknown range
          Orientation: unknown range
          Distance: unknown range
          TiltX: unknown range
          TiltY: unknown range
          TrackingId: min=0, max=65535, flat=0, fuzz=0, resolution=0
          Slot: min=0, max=9, flat=0, fuzz=0, resolution=0
        Calibration:
          touch.size.calibration: diameter
          touch.size.scale: 10.000
          touch.size.bias: 0.000
          touch.size.isSummed: false
          touch.pressure.calibration: amplitude
          touch.pressure.scale: 0.005
          touch.orientation.calibration: none
          touch.distance.calibration: none
        SurfaceWidth: 720px
        SurfaceHeight: 1280px
        SurfaceOrientation: 0
        Translation and Scaling Factors:
          XScale: 0.999
          YScale: 0.999
          XPrecision: 1.001
          YPrecision: 1.001
          GeometricScale: 0.999
          PressureScale: 0.005
          SizeScale: 0.033
          OrientationCenter: 0.000
          OrientationScale: 0.000
          DistanceScale: 0.000
          HaveTilt: false
          TiltXCenter: 0.000
          TiltXScale: 0.000
          TiltYCenter: 0.000
          TiltYScale: 0.000
        Last Button State: 0x00000000
        Last Raw Touch: pointerCount=0
        Last Cooked Touch: pointerCount=0

No final do despejo de estado do leitor de entrada, há algumas informações sobre os parâmetros de configuração global, como o intervalo de toque.

Configuration:
  ExcludedDeviceNames: []
  VirtualKeyQuietTime: 0.0ms
  PointerVelocityControlParameters: scale=1.000, lowThreshold=500.000, highThreshold=3000.000, acceleration=3.000
  WheelVelocityControlParameters: scale=1.000, lowThreshold=15.000, highThreshold=50.000, acceleration=4.000
  PointerGesture:
    Enabled: true
    QuietInterval: 100.0ms
    DragMinSwitchSpeed: 50.0px/s
    TapInterval: 150.0ms
    TapDragInterval: 300.0ms
    TapSlop: 20.0px
    MultitouchSettleInterval: 100.0ms
    MultitouchMinDistance: 15.0px
    SwipeTransitionAngleCosine: 0.3
    SwipeMaxWidthRatio: 0.2
    MovementSpeedRatio: 0.8
    ZoomSpeedRatio: 0.3

Estado do expedidor de entrada

O InputDispatcher é responsável por enviar eventos de entrada para aplicativos. Na amostra de saída abaixo, é possível ver que o despejo de estado apresenta informações sobre qual janela está sendo tocada, o estado da fila de entrada, se um ANR está em andamento e assim por diante.

Input Dispatcher State:
  DispatchEnabled: 1
  DispatchFrozen: 0
  FocusedApplication: <null>
  FocusedWindow: name='Window{3fb06dc3 u0 StatusBar}'
  TouchStates: <no displays touched>
  Windows:
    0: name='Window{357bbbfe u0 SearchPanel}', displayId=0, paused=false, hasFocus=false, hasWallpaper=false, visible=false, canReceiveKeys=false, flags=0x01820100, type=0x000007e8, layer=211000, frame=[0,0][1080,1920], scale=1.000000, touchableRegion=[0,0][1080,1920], inputFeatures=0x00000000, ownerPid=22674, ownerUid=10020, dispatchingTimeout=5000.000ms
    1: name='Window{3b14c0ca u0 NavigationBar}', displayId=0, paused=false, hasFocus=false, hasWallpaper=false, visible=false, canReceiveKeys=false, flags=0x01840068, type=0x000007e3, layer=201000, frame=[0,1776][1080,1920], scale=1.000000, touchableRegion=[0,1776][1080,1920], inputFeatures=0x00000000, ownerPid=22674, ownerUid=10020, dispatchingTimeout=5000.000ms
    2: name='Window{2c7e849c u0 com.vito.lux}', displayId=0, paused=false, hasFocus=false, hasWallpaper=false, visible=true, canReceiveKeys=false, flags=0x0089031a, type=0x000007d6, layer=191000, frame=[-495,-147][1575,1923], scale=1.000000, touchableRegion=[-495,-147][1575,1923], inputFeatures=0x00000000, ownerPid=4697, ownerUid=10084, dispatchingTimeout=5000.000ms
    ...
  MonitoringChannels:
    0: 'WindowManager (server)'
  RecentQueue: length=10
    MotionEvent(deviceId=4, source=0x00001002, action=2, flags=0x00000000, metaState=0x00000000, buttonState=0x00000000, edgeFlags=0x00000000, xPrecision=1.0, yPrecision=1.0, displayId=0, pointers=[0: (335.0, 1465.0)]), policyFlags=0x62000000, age=217264.0ms
    MotionEvent(deviceId=4, source=0x00001002, action=1, flags=0x00000000, metaState=0x00000000, buttonState=0x00000000, edgeFlags=0x00000000, xPrecision=1.0, yPrecision=1.0, displayId=0, pointers=[0: (335.0, 1465.0)]), policyFlags=0x62000000, age=217255.7ms
    MotionEvent(deviceId=4, source=0x00001002, action=0, flags=0x00000000, metaState=0x00000000, buttonState=0x00000000, edgeFlags=0x00000000, xPrecision=1.0, yPrecision=1.0, displayId=0, pointers=[0: (330.0, 1283.0)]), policyFlags=0x62000000, age=216805.0ms
    ...
  PendingEvent: <none>
  InboundQueue: <empty>
  ReplacedKeys: <empty>
  Connections:
    0: channelName='WindowManager (server)', windowName='monitor', status=NORMAL, monitor=true, inputPublisherBlocked=false
      OutboundQueue: <empty>
      WaitQueue: <empty>
    1: channelName='278c1d65 KeyguardScrim (server)', windowName='Window{278c1d65 u0 KeyguardScrim}', status=NORMAL, monitor=false, inputPublisherBlocked=false
      OutboundQueue: <empty>
      WaitQueue: <empty>
    2: channelName='357bbbfe SearchPanel (server)', windowName='Window{357bbbfe u0 SearchPanel}', status=NORMAL, monitor=false, inputPublisherBlocked=false
      OutboundQueue: <empty>
      WaitQueue: <empty>
    ...
  AppSwitch: not pending
    7: channelName='2280455f com.google.android.gm/com.google.android.gm.ConversationListActivityGmail (server)', windowName='Window{2280455f u0 com.google.android.gm/com.google.android.gm.ConversationListActivityGmail}', status=NORMAL, monitor=false, inputPublisherBlocked=false
      OutboundQueue: <empty>
      WaitQueue: <empty>
    8: channelName='1a7be08a com.android.systemui/com.android.systemui.recents.RecentsActivity (server)', windowName='Window{1a7be08a u0 com.android.systemui/com.android.systemui.recents.RecentsActivity EXITING}', status=NORMAL, monitor=false, inputPublisherBlocked=false
      OutboundQueue: <empty>
      WaitQueue: <empty>
    9: channelName='3b14c0ca NavigationBar (server)', windowName='Window{3b14c0ca u0 NavigationBar}', status=NORMAL, monitor=false, inputPublisherBlocked=false
      OutboundQueue: <empty>
      WaitQueue: <empty>
    ...
  Configuration:
    KeyRepeatDelay: 50.0ms
    KeyRepeatTimeout: 500.0ms

Itens a serem verificados

Veja a seguir uma lista de itens a serem considerados ao inspecionar as diversas saídas do serviço de input:

Estado do hub de eventos:

• Todos os dispositivos de entrada que você espera encontrar estão presentes.
• Cada dispositivo de entrada tem um arquivo apropriado de layout de teclas, um arquivo de mapeamento de caracteres de teclas e um arquivo de configuração do dispositivo de entrada. Se houver arquivos faltando ou com erros de sintaxe, eles não serão carregados.
• Cada dispositivo de entrada está classificado corretamente. Os bits no campo Classes correspondem às sinalizações em EventHub.h, como INPUT_DEVICE_CLASS_TOUCH_MT.
• O BuiltInKeyboardId está correto. Se o dispositivo não tiver um teclado integrado, o id precisará ser -2. Caso contrário, ele precisará ser o id do teclado integrado.
• Se você observar que o BuiltInKeyboardId não é -2, mas deveria ser, um arquivo de mapeamento de caracteres de teclas para um teclado de função especial está faltando em algum lugar. Dispositivos de teclado de função especial precisam ter arquivos de mapeamento de caracteres de teclas que contenham apenas a linha type SPECIAL_FUNCTION (presente no arquivo tuna-gpio-keykad.kcm mencionado acima).

Estado do leitor de entrada:

• Todos os dispositivos de entrada esperados se encontram presentes.
• Cada dispositivo de entrada está configurado corretamente. Em especial, verifique se os eixos do joystick e do touchscreen estão corretos.

Estado do expedidor de entrada:

• Todos os eventos de entrada são processados conforme o esperado.
• Depois de tocar no touchscreen e executar dumpsys ao mesmo tempo, a linha TouchStates identifica corretamente a janela que está sendo tocada.

Testar desempenho da IU

A especificação do serviço gfxinfo fornece informações de desempenho relacionadas aos frames de animação que estão ocorrendo durante a fase de gravação. O comando a seguir usa gfxinfo para reunir dados de desempenho da IU para um nome de pacote especificado:

adb shell dumpsys gfxinfo package-name

Você também pode incluir a opção framestats para fornecer informações ainda mais detalhadas de tempo até a renderização de frames recentes. Assim, será possível rastrear e depurar problemas com mais precisão, conforme mostrado abaixo:

adb shell dumpsys gfxinfo package-name framestats

Se quiser saber mais sobre como usar gfxinfo e framestats para integrar a medição de performance da IU às suas práticas de teste, consulte Como criar uma Macrobenchmark.

Inspecionar diagnósticos de rede

A especificação do serviço netstats fornece estatísticas de uso de rede coletadas desde que o dispositivo anterior foi inicializado. Para gerar outras saídas, como informações detalhadas do ID de usuário único (UID, na sigla em inglês), inclua a opção detail, da seguinte maneira:

adb shell dumpsys netstats detail

A saída pode variar de acordo com a versão do Android executada no dispositivo conectado. As seções abaixo descrevem o tipo de informação que é vista normalmente.

Interfaces ativas e interfaces UID ativas

A amostra de saída a seguir lista as interfaces ativas e as interfaces UID ativas do dispositivo conectado. Na maioria dos casos, as informações sobre interfaces ativas e interfaces UID ativas são as mesmas.

Active interfaces:
  iface=wlan0 ident=[{type=WIFI, subType=COMBINED, networkId="Guest"}]
Active UID interfaces:
  iface=wlan0 ident=[{type=WIFI, subType=COMBINED, networkId="Guest"}]

Estatísticas "Dev" e "Xt"

Veja esta amostra de saída para a seção de estatísticas Dev:

Dev stats:
  Pending bytes: 1798112
  History since boot:
  ident=[{type=WIFI, subType=COMBINED, networkId="Guest", metered=false}] uid=-1 set=ALL tag=0x0
    NetworkStatsHistory: bucketDuration=3600
      st=1497891600 rb=1220280 rp=1573 tb=309870 tp=1271 op=0
      st=1497895200 rb=29733 rp=145 tb=85354 tp=185 op=0
      st=1497898800 rb=46784 rp=162 tb=42531 tp=192 op=0
      st=1497902400 rb=27570 rp=111 tb=35990 tp=121 op=0
Xt stats:
  Pending bytes: 1771782
  History since boot:
  ident=[{type=WIFI, subType=COMBINED, networkId="Guest", metered=false}] uid=-1 set=ALL tag=0x0
    NetworkStatsHistory: bucketDuration=3600
      st=1497891600 rb=1219598 rp=1557 tb=291628 tp=1255 op=0
      st=1497895200 rb=29623 rp=142 tb=82699 tp=182 op=0
      st=1497898800 rb=46684 rp=160 tb=39756 tp=191 op=0
      st=1497902400 rb=27528 rp=110 tb=34266 tp=120 op=0

Estatísticas de UID

Veja esta amostra de estatísticas detalhadas de cada UID.

UID stats:
  Pending bytes: 744
  Complete history:
  ident=[[type=MOBILE_SUPL, subType=COMBINED, subscriberId=311111...], [type=MOBILE, subType=COMBINED, subscriberId=311111...]] uid=10007  set=DEFAULT tag=0x0
    NetworkStatsHistory: bucketDuration=7200000
      bucketStart=1406167200000 activeTime=7200000 rxBytes=4666 rxPackets=7 txBytes=1597 txPackets=10 operations=0
  ident=[[type=WIFI, subType=COMBINED, networkId="MySSID"]] uid=10007  set=DEFAULT tag=0x0
    NetworkStatsHistory: bucketDuration=7200000
      bucketStart=1406138400000 activeTime=7200000 rxBytes=17086802 rxPackets=15387 txBytes=1214969 txPackets=8036 operations=28
      bucketStart=1406145600000 activeTime=7200000 rxBytes=2396424 rxPackets=2946 txBytes=464372 txPackets=2609 operations=70
      bucketStart=1406152800000 activeTime=7200000 rxBytes=200907 rxPackets=606 txBytes=187418 txPackets=739 operations=0
      bucketStart=1406160000000 activeTime=7200000 rxBytes=826017 rxPackets=1126 txBytes=267342 txPackets=1175 operations=35

Para encontrar o UID do seu aplicativo, execute este comando: adb shell dumpsys package your-package-name. Em seguida, procure a linha marcada como userId.

Por exemplo, para encontrar o uso de rede do app "com.example.myapp", execute o seguinte comando:

adb shell dumpsys package com.example.myapp | grep userId

A saída será semelhante a esta:

    userId=10007 gids=[3003, 1028, 1015]

Usando o despejo da amostra acima, procure linhas que contenham uid=10007. Existem duas dessas linhas: a primeira indica uma conexão móvel, e a segunda indica uma conexão Wi-Fi. Abaixo de cada linha, é possível ver as seguintes informações para cada intervalo de duas horas (que bucketDuration especifica em milissegundos):

• set=DEFAULT indica o uso da rede em primeiro plano, ao passo que set=BACKGROUND indica o uso em segundo plano. set=ALL implica ambos.
• tag=0x0 indica a tag de soquete associada ao tráfego.
• rxBytes e rxPackets representam os bytes e os pacotes recebidos no intervalo de tempo correspondente.
• txBytes e txPackets representam bytes e pacotes enviados (transmitidos) no intervalo de tempo correspondente.

Inspecionar o diagnóstico da bateria

A especificação do serviço batterystats gera dados estatísticos interessantes sobre o uso da bateria de um dispositivo, organizados pelo ID de usuário único (UID, na sigla em inglês). Para saber como usar o dumpsys para testar as opções "Soneca" e "App em espera" no aplicativo, acesse Testes com os recursos Soneca e App em espera.

O comando para batterystats é o seguinte:

adb shell dumpsys batterystats options

Para ver uma lista de outras opções disponíveis para batterystats, inclua a opção -h. O exemplo abaixo mostra as estatísticas de uso da bateria para um pacote de apps especificado desde a última vez que o dispositivo foi carregado:

adb shell dumpsys batterystats --charged package-name

A saída normalmente inclui o seguinte:

• Histórico de eventos relacionados ao uso da bateria
• Estatísticas gerais do dispositivo
• Uso aproximado da bateria por UID e componentes do sistema
• Milissegundos por dispositivo móvel por pacote
• Estatísticas agregadas do UID do sistema
• Estatísticas agregadas do UID do app

Para saber mais sobre como usar batterystats e gerar uma visualização HTML da saída, o que facilita o entendimento e o diagnóstico de problemas relacionados à bateria, leia Gerar perfil do uso da bateria com Batterystats e Battery Historian.

Inspecionar saída adequada para a máquina

É possível gerar a saída do batterystats no formato CSV legível por máquina usando o seguinte comando:

adb shell dumpsys batterystats --checkin

A seguir, há um exemplo da saída que será gerada:

9,0,i,vers,11,116,K,L
9,0,i,uid,1000,android
9,0,i,uid,1000,com.android.providers.settings
9,0,i,uid,1000,com.android.inputdevices
9,0,i,uid,1000,com.android.server.telecom
...
9,0,i,dsd,1820451,97,s-,p-
9,0,i,dsd,3517481,98,s-,p-
9,0,l,bt,0,8548446,1000983,8566645,1019182,1418672206045,8541652,994188
9,0,l,gn,0,0,666932,495312,0,0,2104,1444
9,0,l,m,6794,0,8548446,8548446,0,0,0,666932,495312,0,697728,0,0,0,5797,0,0
...

As observações de uso da bateria podem ser por UID ou no nível do sistema. Os dados são selecionados para inclusão com base na utilidade deles ao analisar o desempenho da bateria. Cada linha representa uma observação com os seguintes elementos:

• Um número inteiro de marcador
• O ID do usuário associado à observação
• O modo de agregação:
  • "i" para informações não vinculadas ao status de carga/descarga.
  • "l" para carregado (uso desde a última carga).
  • "u" para desconectado (uso desde a última vez em que foi desconectado). Suspenso no Android 5.1.1.
• Identificador de seção que determina como interpretar valores subsequentes na linha.

A tabela abaixo descreve os diversos identificadores de seção que podem ser vistos:

Observação: antes do Android 6.0, o uso de energia para o rádio Bluetooth, rádio celular e Wi-Fi eram monitorados na categoria de seção m (Misc). No Android 6.0 e versões mais recentes, o uso de energia para esses componentes é monitorado na seção pwi (item de uso de energia) com etiquetas individuais (wifi, blue, cell) para cada componente.

Ver alocações de memória

É possível inspecionar o uso de memória do seu app de duas maneiras: durante um período, usando procstats ou em um snapshot específico, usando meminfo. As seções abaixo demonstram como usar um dos métodos.

procstats

procstats possibilita ver como seu app está se comportando ao longo do tempo, incluindo por quanto tempo ele é executado em segundo plano e quanto de memória é usado durante esse período. Ele ajuda você a encontrar rapidamente ineficiências e erros de comportamento no seu app, como vazamentos de memória que podem afetar o desempenho, especialmente quando executados em dispositivos com pouca memória. O estado do despejo mostra estatísticas sobre o tempo de execução de cada aplicativo, tamanho de conjunto proporcional, tamanho de conjunto exclusivo (USS) e tamanho de conjunto de residentes (RSS) (siglas em inglês).

Para ver estatísticas de uso de memória do aplicativo das últimas três horas, em formato legível, execute o comando a seguir:

adb shell dumpsys procstats --hours 3

Como visto no exemplo abaixo, o resultado exibe o percentual de tempo em que o aplicativo estava em execução e o PSS, USS e RSS como minPSS-avgPSS-maxPSS/minUSS-avgUSS-maxUSS/minRSS-avgRSS-maxRSS sobre o número de amostras.

AGGREGATED OVER LAST 3 HOURS:
  * com.android.systemui / u0a37 / v28:
           TOTAL: 100% (15MB-16MB-17MB/7.7MB-8.7MB-9.4MB/7.7MB-9.6MB-84MB over 178)
      Persistent: 100% (15MB-16MB-17MB/7.7MB-8.7MB-9.4MB/7.7MB-9.6MB-84MB over 178)
  * com.android.se / 1068 / v28:
           TOTAL: 100% (2.8MB-2.9MB-2.9MB/300KB-301KB-304KB/304KB-22MB-33MB over 3)
      Persistent: 100% (2.8MB-2.9MB-2.9MB/300KB-301KB-304KB/304KB-22MB-33MB over 3)
  * com.google.android.gms.persistent / u0a7 / v19056073:
           TOTAL: 100% (37MB-38MB-40MB/27MB-28MB-29MB/124MB-125MB-126MB over 2)
          Imp Fg: 100% (37MB-38MB-40MB/27MB-28MB-29MB/124MB-125MB-126MB over 2)
  ...
  * com.android.gallery3d / u0a62 / v40030:
           TOTAL: 0.01%
        Receiver: 0.01%
        (Cached): 54% (6.4MB-6.5MB-6.9MB/4.4MB-4.4MB-4.4MB/4.4MB-26MB-68MB over 6)
  * com.google.android.tvlauncher / u0a30 / v1010900130:
           TOTAL: 0.01%
        Receiver: 0.01%
        (Cached): 91% (5.8MB-13MB-14MB/3.5MB-10MB-12MB/12MB-33MB-78MB over 6)
  * com.android.vending:instant_app_installer / u0a16 / v81633968:
           TOTAL: 0.01%
        Receiver: 0.01%
        (Cached): 100% (14MB-15MB-16MB/3.8MB-4.2MB-5.1MB/3.8MB-30MB-95MB over 7)
  ...
Run time Stats:
  SOff/Norm: +32m52s226ms
  SOn /Norm: +2h10m8s364ms
       Mod : +17s930ms
      TOTAL: +2h43m18s520ms

Memory usage:
  Kernel : 265MB (38 samples)
  Native : 73MB (38 samples)
  Persist: 262MB (90 samples)
  Top    : 190MB (325 samples)
  ImpFg  : 204MB (569 samples)
  ImpBg  : 754KB (345 samples)
  Service: 93MB (1912 samples)
  Receivr: 227KB (1169 samples)
  Home   : 66MB (12 samples)
  LastAct: 30MB (255 samples)
  CchAct : 220MB (450 samples)
  CchCAct: 193MB (71 samples)
  CchEmty: 182MB (652 samples)
  Cached : 58MB (38 samples)
  Free   : 60MB (38 samples)
  TOTAL  : 1.9GB
  ServRst: 50KB (278 samples)

          Start time: 2015-04-08 13:44:18
  Total elapsed time: +2h43m18s521ms (partial) libart.so

meminfo

É possível gravar um snapshot de como a memória do seu app é dividida entre diferentes tipos de alocação de RAM com o comando a seguir:

adb shell dumpsys meminfo package_name|pid [-d]

A sinalização -d fornece mais informações relacionadas ao uso de memória Dalvik e ART.

A saída lista todas as alocações atuais do app, medidas em kilobytes.

Ao examinar essa informação, é necessário conhecer bem os seguintes tipos de alocação:

RAM privada (limpa e suja)

Essa é a memória usada somente pelo seu processo. Essa é a quantidade de RAM que o sistema pode resgatar quando o processo do app é destruído. Geralmente, a parte mais importante é a RAM privada e suja, que é a mais cara porque é usada apenas pelo seu processo e os componentes dela existem exclusivamente em RAM e, portanto, não podem ser paginados em armazenamento (porque o Android não usa swap). Todas as alocações de heap nativas e da Dalvik que forem feitas, serão RAM privada e suja. As alocações nativas e da Dalvik que forem compartilhadas com o processo Zigoto serão RAM compartilhada e suja.

Tamanho do conjunto proporcional (PSS)

Essa é uma medida do uso de RAM do seu app que leva em consideração páginas compartilhadas entre processos. Toda página de RAM exclusiva do seu processo contribui diretamente para o valor de PSS, ao passo que as páginas compartilhadas com outros processos contribuem para o valor de PSS apenas na proporção da quantidade compartilhada. Por exemplo, uma página compartilhada entre dois processos contribuirá com metade do próprio tamanho para o PSS de cada processo.

Uma característica interessante da medida de PSS é que é possível adicionar o PSS a todos os processos para determinar a memória que está realmente sendo usada por todos eles. Isso significa que o PSS é uma boa medida para o peso real em RAM de um processo e para comparação com o uso de RAM de outros processos e com o total disponível.

Por exemplo, abaixo há uma amostra de saída de um processo de mapa em um dispositivo Nexus 5. Há muitas informações sobre esse assunto, mas os pontos principais foram listados abaixo.

adb shell dumpsys meminfo com.google.android.apps.maps -d

Observação: a informação exibida pode ser um pouco diferente do que é mostrado aqui, alguns detalhes de saída diferem entre versões de plataformas.

** MEMINFO in pid 18227 [com.google.android.apps.maps] **
                   Pss  Private  Private  Swapped     Heap     Heap     Heap
                 Total    Dirty    Clean    Dirty     Size    Alloc     Free
                ------   ------   ------   ------   ------   ------   ------
  Native Heap    10468    10408        0        0    20480    14462     6017
  Dalvik Heap    34340    33816        0        0    62436    53883     8553
 Dalvik Other      972      972        0        0
        Stack     1144     1144        0        0
      Gfx dev    35300    35300        0        0
    Other dev        5        0        4        0
     .so mmap     1943      504      188        0
    .apk mmap      598        0      136        0
    .ttf mmap      134        0       68        0
    .dex mmap     3908        0     3904        0
    .oat mmap     1344        0       56        0
    .art mmap     2037     1784       28        0
   Other mmap       30        4        0        0
   EGL mtrack    73072    73072        0        0
    GL mtrack    51044    51044        0        0
      Unknown      185      184        0        0
        TOTAL   216524   208232     4384        0    82916    68345    14570

 Dalvik Details
        .Heap     6568     6568        0        0
         .LOS    24771    24404        0        0
          .GC      500      500        0        0
    .JITCache      428      428        0        0
      .Zygote     1093      936        0        0
   .NonMoving     1908     1908        0        0
 .IndirectRef       44       44        0        0

 Objects
               Views:       90         ViewRootImpl:        1
         AppContexts:        4           Activities:        1
              Assets:        2        AssetManagers:        2
       Local Binders:       21        Proxy Binders:       28
       Parcel memory:       18         Parcel count:       74
    Death Recipients:        2      OpenSSL Sockets:        2

Veja um dumpsys mais antigo do app Gmail na Dalvik:

** MEMINFO in pid 9953 [com.google.android.gm] **
                 Pss     Pss  Shared Private  Shared Private    Heap    Heap    Heap
               Total   Clean   Dirty   Dirty   Clean   Clean    Size   Alloc    Free
              ------  ------  ------  ------  ------  ------  ------  ------  ------
  Native Heap      0       0       0       0       0       0    7800    7637(6)  126
  Dalvik Heap   5110(3)    0    4136    4988(3)    0       0    9168    8958(6)  210
 Dalvik Other   2850       0    2684    2772       0       0
        Stack     36       0       8      36       0       0
       Cursor    136       0       0     136       0       0
       Ashmem     12       0      28       0       0       0
    Other dev    380       0      24     376       0       4
     .so mmap   5443(5) 1996    2584    2664(5) 5788    1996(5)
    .apk mmap    235      32       0       0    1252      32
    .ttf mmap     36      12       0       0      88      12
    .dex mmap   3019(5) 2148       0       0    8936    2148(5)
   Other mmap    107       0       8       8     324      68
      Unknown   6994(4)    0     252    6992(4)    0       0
        TOTAL  24358(1) 4188    9724   17972(2)16388    4260(2)16968   16595     336

 Objects
               Views:    426         ViewRootImpl:        3(8)
         AppContexts:      6(7)        Activities:        2(7)
              Assets:      2        AssetManagers:        2
       Local Binders:     64        Proxy Binders:       34
    Death Recipients:      0
     OpenSSL Sockets:      1

 SQL
         MEMORY_USED:   1739
  PAGECACHE_OVERFLOW:   1164          MALLOC_SIZE:       62

Em geral, atenha-se às colunas Pss Total e Private Dirty. Em alguns casos, as colunas Private Clean e Heap Alloc também oferecem dados interessantes. Caso queira ver mais informações sobre as diferentes alocações de memória (as linhas), observe o seguinte:

Dalvik Heap

A RAM usada no seu app pelas alocações da Dalvik. O Pss Total inclui todas as alocações de Zigoto, medidas por compartilhamento entre processos, como descrito na definição de PSS acima. A Private Dirty é o número verdadeiro de RAM usada apenas nos heaps do seu app, composta das suas próprias alocações e de todas as páginas de alocação Zigoto que foram modificadas desde a bifurcação entre o processo do seu app e o Zigoto.

Observação: em plataformas mais recentes que têm a seção Dalvik Other, os números de Pss Total e Private Dirty para heap da Dalvik não incluem sobrecarga da Dalvik, como a compilação just-in-time (JIT) e o agendamento de GC, enquanto versões mais antigas listam todos combinados em Dalvik.

O Heap Alloc é a quantidade de memória que os alocadores de heap nativo e da Dalvik controlam para seu aplicativo. Esse valor é maior do que Pss Total e Private Dirty porque seu processo foi separado do Zigoto e inclui alocações compartilhadas pelo seu processo com todos os outros.

.so mmap e .dex mmap

A RAM usada para código .so (nativo) e .dex (Dalvik ou ART) mapeados. O número de Pss Total inclui código da plataforma compartilhado entre apps. A Private Clean é o código do próprio app. Geralmente, o tamanho mapeado real é muito maior. A RAM aqui é só o que é necessário estar em RAM no momento para o código executado pelo app. No entanto, o .so mmap tem uma RAM privada e suja maior devido às correções do código nativo quando ele foi carregado no endereço final.

.oat mmap

Essa é a quantidade de RAM usada pela imagem do código que é baseada nas classes pré-carregadas normalmente usadas por diversos apps. Essa imagem é compartilhada por todos os apps e não é afetada por nenhum app em especial.

.art mmap

Essa é a quantidade de RAM usada pela imagem de heap que se baseia nas classes pré-carregadas normalmente usadas por diversos apps. Essa imagem é compartilhada por todos os apps e não é afetada por nenhum app em especial. Embora a imagem da ART contenha instâncias de Object, ela não é considerada para o tamanho do heap.

.Heap (somente com a sinalização -d)

Esta é a quantidade de memória de heap para seu aplicativo. Isso exclui objetos na imagem e espaços de objetos grandes, mas inclui o espaço do zigoto e o espaço fixo.

.LOS (somente com a sinalização -d)

Essa é a quantidade de RAM usada pelo espaço de objetos grandes da ART. Inclui objetos grandes do zigoto. Objetos grandes são alocações de matriz primitiva maiores do que 12 KB.

.GC (somente com a sinalização -d)

Esse é o custo indireto para a coleta de lixo. Não há uma forma de reduzir essa sobrecarga.

.JITCache (somente com a sinalização -d)

Essa é a quantidade de memória usada pelos caches de código e dados JIT. Normalmente, esse valor é zero, já que todos os apps serão compilados assim que instalados.

.Zygote (somente com a sinalização -d)

Essa é a quantidade de memória usada pelo espaço do zigoto. O espaço do zigoto é criado durante a inicialização do dispositivo e nunca há alocações dentro dele.

.NonMoving (somente com a sinalização -d)

Essa é a quantidade de RAM usada pelo espaço fixo da ART. O espaço fixo contém objetos não móveis especiais, como campos e métodos. É possível reduzir essa parte usando menos campos e métodos no seu app.

.IndirectRef (somente com a sinalização -d)

Essa é a quantidade de RAM usada pelas tabelas de referência indireta da ART. Normalmente, esse é um valor pequeno, mas se estiver muito alto, talvez seja possível reduzi-lo ao diminuir o número de referências a JNI locais e globais usadas.

Unknown

Todas as páginas da RAM que o sistema não conseguiu classificar em um dos outros itens mais específicos. Atualmente, aqui ficam muitas das alocações nativas que não podem ser identificadas pela ferramenta durante a coleta desses dados em virtude da Ordem aleatória do layout do espaço de endereço (ASLR, na sigla em inglês). Como o heap da Dalvik, o Pss Total para Desconhecidos considera o compartilhamento com o Zigoto, e a Private Dirty é uma RAM desconhecida dedicada apenas ao seu app.

TOTAL

O total de RAM do Tamanho do conjunto proporcional (PSS) usado pelo seu processo. Essa é a soma de todos os campos de PSS acima dele. Indica o peso geral do seu processo na memória, que pode ser comparado diretamente com outros processos e com a RAM total disponível.

Private Dirty e Private Clean são o total de alocações dentro do processo que não são compartilhadas com outros processos. Juntas (especialmente a Private Dirty), elas formam a quantidade de RAM que será devolvida ao sistema quando o processo for destruído. A RAM suja são páginas que foram modificadas e, portanto, continuam alocadas à RAM (porque não há swap). Já a RAM limpa são páginas que foram mapeadas de um arquivo persistente (como código em execução) e, por isso, podem ser despaginadas se ficarem ociosas por algum tempo.

ViewRootImpl

O número de visualizações raiz ativas no processo. Cada visualização raiz está associada a uma janela, o que ajuda a identificar vazamentos de memória relacionados a caixas de diálogo ou outras janelas.

AppContexts e Activities

O número de objetos Context e Activity do aplicativo que atualmente estão ativos no processo. Isso pode ajudar você a identificar rapidamente objetos Activity com vazamentos que não podem ser coletados como lixo por terem referências estáticas, o que é comum. Muitas vezes, esses objetos têm muitas outras alocações associadas a eles, o que os torna uma boa maneira de controlar grandes vazamentos de memória.

Observação: um objeto View ou Drawable também contém uma referência à Activity de origem. Portanto, manter um objeto View ou Drawable também pode levar seu app ao vazamento de uma Activity.