android 如何分析应用的内存(十四)——jdb命令行

android 如何分析应用的内存(十四)

前面的系列文章介绍了android应用如何分析native内存。

接下来就是android应用如何分析java内存。同native一样,我们也希望能够看到
ART的堆和栈的情况,以及锁的情况,方法的本地变量,以及栈帧等

因此ART的内存分析就变成两个部分:

  1. 查看栈内容,如当前栈帧的本地变量等
  2. 查看堆内容,即对象分配情况

注意:在Android中,有几个特殊的堆内存,如存储dex文件的image heap和存储共有资源的zygote heap。他们属于Framework应该关心的内容,因此不在此系列中做介绍。

使用jdb进行查看

如何查看ART的栈情况呢?还是跟native一样,可以使用调试器进行查看。
java的调试器,称为jdb。

跟native的gdb和lldb的远程调试一样,jdb也分成两个部分:

  1. 一个放在Android设备端,这部分由ART负责
  2. 另一个放在pc端。这部分由jdb负责

这两个部分要进行通信,他们的通信协议叫做JDWP(java debug wire protocol)

因为ART属于标准java虚拟机之一,所以任何一个jdb即可调试Android的java应用。

app的准备

需要在编译的时候,加上-g选项。如果使用的是Android studio,则在编译器中配置如下
android 如何分析应用的内存(十四)——jdb命令行_第1张图片

如果能自定义ROM,在编译的时候加上-g选项,则可以调试整个Frmawork代码,此处不涉及Framework因此,不过多介绍。

如何查看是否含有调试信息

使用javap命令,查看对应的xxx.class是否包含:LineNumberTable和LocalVariableTable

  • LineNumberTable 包含了源代码行号与字节码指令的对应关系,用于在调试时定位源代码行号。
  • LocalVariableTable 包含了方法中局部变量的信息,包括变量名称、数据类型和作用域范围等,用于在调试时查看变量的值。

举例截图如下:

 javap -v ./MainActivity.class | grep -E "LineNumberTable|LocalVariableTable" 

android 如何分析应用的内存(十四)——jdb命令行_第2张图片

开始调试

  1. 安装应用,并运行adb jdwp其中adb jdwp用于查看满足jdwp协议的应有有哪些。列出的数字为进程pid

  2. 将本地调试的端口转发给Android应用,运行如下命令:

## 此处我们再次选择了5039端口用于jdwp的连接。(在gdb和lldb中也是使用了5039见:http://t.csdn.cn/QkkH3和http://t.csdn.cn/JWgcF)
adb forward tcp:5039 jdwp:6405
  1. 使用jdb连接上tcp:5039即可,如下:
jdb -attach localhost:5039

则输出如下,表示连接成功:

设置未捕获的java.lang.Throwable
设置延迟的未捕获的java.lang.Throwable
正在初始化jdb...
>

注意:在运行jdb之前,一定要先停止Android studio的运行,否则连接不上

注意:在本文中,井号开头的行表示注释.而右尖括号,表示键入的命令

挂起线程

## suspend [thread id(s)]    -- 挂起线程 (默认值: all)
> suspend 

查看有哪些线程

#threads [threadgroup]     -- 列出线程
>threads

如下图
android 如何分析应用的内存(十四)——jdb命令行_第3张图片

打印堆栈

#where [ | all] -- 转储线程的堆栈
> where 0x4e81

输出如下:
android 如何分析应用的内存(十四)——jdb命令行_第4张图片

同时将main线程选为了当前线程

打印本地变量

#locals  打印本地变量
>locals 

输出如下
android 如何分析应用的内存(十四)——jdb命令行_第5张图片

移动栈帧

# up [n frames]             -- 上移线程的堆栈
# down [n frames]           -- 下移线程的堆栈

打印变量

# dump 变量名
> dump view.mTextClassifierHelper

输出如下
android 如何分析应用的内存(十四)——jdb命令行_第6张图片

设置源代码位置

# 在jdb启动的时候,添加选项-sourcepath 路径1:路径2  即可添加源代码的路径
# 这样在调试AOSP代码的时候,会变得异常方便
# 还可以在jdb内部,使用use命令,修改源码路径
# 如下面使用jdb调试Android原生代码里面的MessageQueue

android 如何分析应用的内存(十四)——jdb命令行_第7张图片

注意:在后面会有一个AMS的源码分析,将会非常频繁的使用本章介绍的jdb内容

列出源代码

# list [line number|method] -- 输出源代码
# 见上图

设置断点

# stop in .[(argument_type,...)] 在方法处设置一个断点
# stop at : 在某行设置一个断点
# clear .[(argument_type,...)] 清除断点 
# clear : 清除断点
# clear 列出断点
# stop 列出断点
>stop in com.example.test_malloc.MainActivity.click

出现如下的输出
android 如何分析应用的内存(十四)——jdb命令行_第8张图片

触发断点如下

android 如何分析应用的内存(十四)——jdb命令行_第9张图片

其中bci表示:字节码索引

单步

# step -- 执行当前行,可理解为单步进入
# step up -- 执行直到当前方法返回到它的调用者
# stepi -- 执行当前指令
# next -- 步进一行,可以理解为单步over
# cont -- 从断点处继续执行

android 如何分析应用的内存(十四)——jdb命令行_第10张图片

修改值

# set  =  赋值字段,变量,数组元素新值

跟踪线程的方法进入和退出

# trace [go] methods [thread]
                          -- 跟踪方法进入和退出。
                          -- 除非指定 'go', 否则挂起所有线程
# trace [go] method exit | exits [thread]
                          -- 跟踪当前方法的退出, 或者所有方法的退出
                          -- 除非指定 'go', 否则挂起所有线程
untrace [methods]         -- 停止跟踪方法进入和/或退出

trace method 命令在调试大型程序或复杂的方法调用关系时特别有用。它可以帮助你定位问题,理解代码的执行流程,并找到潜在的错误或异常。
android 如何分析应用的内存(十四)——jdb命令行_第11张图片

捕获异常

# catch [uncaught|caught|all] |  当指定的异常发生时,暂停,如下图
# ignore [uncaught|caught|all] |  取消捕获某个异常

android 如何分析应用的内存(十四)——jdb命令行_第12张图片

打印锁信息

# lock  -- 打印某个对象上面的锁信息
# threadlocks [thread id] --打印线程上面的锁信息

android 如何分析应用的内存(十四)——jdb命令行_第13张图片

计算表达式

# eval 表达式——计算表达式的值
# 计算变量x和y的值
>eval x+y

android 如何分析应用的内存(十四)——jdb命令行_第14张图片

即时调试

同native一样,即时调试分成两部分

  1. 程序一启动就等待调试器的加入
  2. 程序一崩溃就等待调试器的加入

程序一启动就等待调试器的加入

  1. 告诉系统,停在合适的位置

android 提供了一个命令行选项,告诉app,启动之后,等待debugger的接入。命令如下:

adb shell am set-debug-app -w com.example.test_malloc
说明:set-debug-app [-w] [--persistent] 
      -w: 应用开始,就等待debugger接入
      --persistent: 这个值一直存在,不会因为应用消失之后被清除掉

设置成功之后,应用打开将会出现如下的情况
android 如何分析应用的内存(十四)——jdb命令行_第15张图片

  1. 告诉jdb,连上app之后,不要马上运行而是挂起所有线程。
    在user目录下,创建配置文件。
  • Linux和Macos叫做.jdbrc
  • windows叫做jdb.ini
    保存如下内容:
suspend

可以看到如下的截图
android 如何分析应用的内存(十四)——jdb命令行_第16张图片

  1. 设置好对应操作之后(如断点),再开始使用resume命令开始。
    如下图
    android 如何分析应用的内存(十四)——jdb命令行_第17张图片

注意:除了通过上面的操作等待jdb的连接以外,还可以通过代码的方法。如线程的挂起API或者一个循环。因为较简单,不再做过多介绍

问题排查

问题1:如果jdb连上之后,app依然在运行
解决:漏掉了上面的第2步

问题2:app启动之后,没有出现wait for debugger
解决:需要先查看自己所在的系统是否支持第1步中的命令。使用如下命令查看

adb shell am -h

根据上面的输出,设置成对应的命令即可

程序一崩溃就等待调试器的加入

因为java程序崩溃时,会输出一段详细的调用栈。而不像native程序那样情况复杂。所以对于程序的崩溃很好分析。因此这部分内容无。

注意:Android应用中,可能因为复杂的线程和锁关系,导致ANR,从而引起的崩溃。此时通过Android的ANR文件,即可分析出相应的原因。这不属于本文要介绍的范围。后续有时间再写一个怎么分析ANR

至此,java的jdb大部分功能已经介绍完毕,它比AS提供的功能更加丰富,多出来的功能有:

  1. 单独操作某个具体的线程
  2. 修改源码位置
  3. 跟踪方法的进入和退出
  4. 主动捕获异常
  5. 打印锁信息

上面多出来的功能,有助于:分析大型Android项目,分析AOSP系统级代码,分析Android漏洞,分析多线程编程

在完成jdb的命令行介绍之前,先对jdb能观察的内存内容做一个小结:

  1. 查看堆帧
  2. 查看本地变量
  3. 查看锁
  4. 查看对象

本文完。

在进行java堆内容查看之前。先引入对应的UI界面,下一小节将介绍VSCode调试Android应用

你可能感兴趣的:(android,内存分析,android,jdb,jdb打印堆栈,jdb查看锁,jdb捕获异常,jdb跟踪方法)