dumpsys

dumpsys é uma ferramenta que é executada em dispositivos Android e fornece informações sobre serviços do sistema. Chame dumpsys na linha de comando usando o Android Debug Bridge (adb) e tenha uma saída de diagnóstico para todos os serviços do sistema em execução no dispositivo conectado.

Normalmente, essa saída é mais detalhada do que você quer. Portanto, use as opções da linha de comando nesta página para conferir a saída somente dos serviços do sistema que quiser. Esta página também descreve como usar o dumpsys para realizar tarefas comuns, como inspeção de diagnósticos de entrada, RAM, bateria ou rede.

Sintaxe

A sintaxe geral para usar dumpsys é esta:

 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, execute 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 uma lista completa dos serviços do sistema que podem ser usados com dumpsys, use este comando:

adb shell dumpsys -l

Opções de linha de comando

A tabela abaixo lista as opções disponíveis ao usar dumpsys:

Tabela 1. Lista de opções disponíveis para dumpsys

adb shell dumpsys procstats -h
    

Inspecionar diagnósticos de entrada

Especificar o serviço input, conforme mostrado no comando abaixo, despeja o estado dos dispositivos de entrada do sistema, como teclados e telas touchscreen, 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ções que você normalmente encontra.

Estado do hub de eventos

Confira 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 touch. 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 agente de entrada

O InputDispatcher é responsável por enviar eventos de entrada para aplicativos. Conforme o exemplo de saída abaixo, o despejo de estado mostra informações sobre qual janela está sendo tocada, o estado da fila de entrada, se um ANR está em andamento e outras informações de evento de entrada:

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

Confira abaixo uma lista de itens a serem considerados ao inspecionar a saída 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 os arquivos estiverem ausentes ou tiverem erros de sintaxe, eles não vão ser 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 vai precisar ser -2. Caso contrário, ele precisa 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. Os dispositivos de teclado de funções especiais precisam ter arquivos de mapeamento de caracteres de tecla que contenham apenas a linha type SPECIAL_FUNCTION.

Estado do leitor de entrada:

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

Estado do agente 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 o desempenho da interface

A especificação do serviço gfxinfo fornece informações de desempenho relacionadas aos frames de animação que ocorrem durante a fase de gravação. O comando abaixo usa gfxinfo para reunir dados de desempenho da interface 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 para que seja possível rastrear e depurar problemas com mais precisão:

adb shell dumpsys gfxinfo package-name framestats

Se quiser saber mais sobre como usar gfxinfo e framestats para integrar a medição de desempenho da interface à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 desta forma:

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ções que você normalmente encontra.

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"

Confira 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

Confira este exemplo 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 este 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 exemplo de despejo anterior, procure linhas que tenham 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 conferir estas informações para cada intervalo de duas horas, que bucketDuration especifica em milissegundos:

• set=DEFAULT indica o uso da rede em primeiro plano, e 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 sobre o uso da bateria de um dispositivo, organizados pelo ID de usuário único (UID). Para saber como usar a ferramenta dumpsys para testar as opções "Soneca" e "App em espera" no aplicativo, consulte Testes com os recursos Soneca e App em espera.

O comando para batterystats é este:

adb shell dumpsys batterystats options

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

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 a saída adequada para a máquina

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

adb shell dumpsys batterystats --checkin

Confira abaixo um exemplo da saída:

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 sobre o uso da bateria podem ser feitas 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 estes 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 carregamento.
  • l para --charged (uso desde a última carga).
  • u para --unplugged (uso desde a última desconexão). Descontinuado no Android 5.1.1.
• Identificador de seção que determina como interpretar valores subsequentes na linha.

A tabela abaixo descreve os vários identificadores de seção que você pode encontrar:

Tabela 2. Lista de identificadores de seção

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 (Diversos). No Android 6.0 e versões mais recentes, o uso de energia desses componentes é rastreado na seção pwi (Item de uso de energia) com rótulos individuais (wifi, blue, cell) para cada componente.

Conferir 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 momento específico, usando meminfo. As seções abaixo mostram como usar os dois métodos.

procstats

procstats possibilita saber 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 que podem afetar o desempenho (como vazamentos de memória), 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 (PSS, na sigla em inglês), tamanho de conjunto exclusivo (USS) e tamanho de conjunto de residentes (RSS).

Para conferir estatísticas de uso de memória do aplicativo nas últimas três horas, em formato legível, execute este comando:

adb shell dumpsys procstats --hours 3

Conforme mostrado no exemplo abaixo, a saída mostra o percentual de tempo em execução do aplicativo e o PSS, USS e RSS como minPSS-avgPSS-maxPSS/minUSS-avgUSS-maxUSS/minRSS-avgRSS-maxRSS com relação ao 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 registrar um snapshot de como a memória do seu app está dividida entre diferentes tipos de alocação de RAM com o comando a seguir:

adb shell dumpsys meminfo [-d] package_name|pid

A sinalização -d fornece mais informações relacionadas ao uso de memória Dalvik e ART. A flag -h mostra todas as flags compatíveis.

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

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

RAM particular (limpa e suja)

Esta é a memória usada somente pelo seu processo. É a quantidade de RAM que o sistema pode resgatar quando o processo do app é destruído. Geralmente, a parte mais importante é a RAM particular e suja, que é a mais cara porque é usada apenas pelo seu processo e os componentes dela existem exclusivamente em RAM e não podem ser paginados em armazenamento já que o Android não usa swap. Todas as alocações de heap Dalvik e nativas feitas são RAMs particulares e sujas. As alocações nativas e Dalvik que você compartilha com o processo Zigoto são RAMs sujas compartilhadas.

Tamanho do conjunto proporcional (PSS)

Esta é 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. Já 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 contribui metade do tamanho para o PSS de cada processo.

Uma característica 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.

Confira abaixo o resultado do processo do Google Maps em um dispositivo Nexus 5:

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

Observação: a informação exibida pode ser um pouco diferente do que é mostrado aqui, porque 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

Confira um dumpsys mais antigo do app Gmail em 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 fornecem dados interessantes.

Confira abaixo mais informações sobre as diferentes alocações de memória que você precisa observar:

Dalvik Heap

A RAM usada no seu app pelas alocações Dalvik. O Pss Total inclui todas as alocações de Zigoto, medidas por compartilhamento entre processos, como descrito na definição de PSS. O Private Dirty é o valor verdadeiro da RAM usado apenas nos heaps do seu app, composto por suas próprias alocações e por todas as páginas de alocação de 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 o heap Dalvik não incluem sobrecargas 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 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 o código de plataforma compartilhado entre apps. Private Clean é o código do seu próprio app. Geralmente, o tamanho real do mapeamento é maior. A RAM mostrada aqui é apenas o valor que atualmente precisa estar na RAM para o código que foi executado pelo app. No entanto, o .so mmap tem uma grande RAM particular e suja, que é causada por correções no código nativo quando ele é carregado no endereço final.

.oat mmap

Esta é a quantidade de RAM usada pela imagem do código. Ela é baseada nas classes pré-carregadas normalmente usadas por vários apps. A imagem é compartilhada por todos os apps e não é afetada por nenhum app em especial.

.art mmap

Esta é a quantidade de RAM usada pela imagem de heap. Ela é baseada nas classes pré-carregadas normalmente usadas por vários apps. A imagem é compartilhada por todos os apps e não é afetada por nenhum app em especial. Embora a imagem de ART contenha instâncias de Object, ela não é considerada no 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)

Esta é 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)

Este é o custo indireto para a coleta de lixo. Não há como reduzir essa sobrecarga.

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

Esta é a quantidade de memória usada pelos caches de código e dados JIT. Normalmente, esse valor é zero, porque todos os apps são compilados durante a instalação.

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

Esta é 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 é alocado.

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

Esta é a quantidade de RAM usada pelo espaço fixo do 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)

Esta é a quantidade de RAM usada pelas tabelas de referência indireta do 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 de 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 Dalvik, o Pss Total para Unknown 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. Quando o processo é destruído, toda a RAM dessas alocações é liberada de volta para o sistema. Private Clean também pode ser paginada e liberada antes que o processo seja destruído, mas Private Dirty é liberada apenas na destruição do processo.

A RAM suja são páginas que foram modificadas e, portanto, continuam alocadas na 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.