android 如何分析应用的内存（十四）——jdb命令行
android 如何分析应用的内存（十四）
前面的系列文章介绍了android应用如何分析native内存。
接下来就是android应用如何分析java内存。同native一样，我们也希望能够看到
ART的堆和栈的情况，以及锁的情况，方法的本地变量，以及栈帧等
因此ART的内存分析就变成两个部分：
- 查看栈内容，如当前栈帧的本地变量等
- 查看堆内容，即对象分配情况
注意：在Android中，有几个特殊的堆内存，如存储dex文件的image heap和存储共有资源的zygote heap。他们属于Framework应该关心的内容，因此不在此系列中做介绍。
使用jdb进行查看
如何查看ART的栈情况呢？还是跟native一样，可以使用调试器进行查看。
java的调试器，称为jdb。
跟native的gdb和lldb的远程调试一样，jdb也分成两个部分：
- 一个放在Android设备端，这部分由ART负责
- 另一个放在pc端。这部分由jdb负责
这两个部分要进行通信，他们的通信协议叫做JDWP（java debug wire protocol）
因为ART属于标准java虚拟机之一，所以任何一个jdb即可调试Android的java应用。
app的准备
需要在编译的时候，加上-g选项。如果使用的是Android studio，则在编译器中配置如下
如果能自定义ROM，在编译的时候加上-g选项，则可以调试整个Frmawork代码，此处不涉及Framework因此，不过多介绍。
如何查看是否含有调试信息
使用javap命令，查看对应的xxx.class是否包含：LineNumberTable和LocalVariableTable
- LineNumberTable 包含了源代码行号与字节码指令的对应关系，用于在调试时定位源代码行号。
- LocalVariableTable 包含了方法中局部变量的信息，包括变量名称、数据类型和作用域范围等，用于在调试时查看变量的值。
举例截图如下：
javap -v ./MainActivity.class | grep -E "LineNumberTable|LocalVariableTable"
开始调试
-
安装应用，并运行adb jdwp其中adb jdwp用于查看满足jdwp协议的应有有哪些。列出的数字为进程pid
-
将本地调试的端口转发给Android应用，运行如下命令：
## 此处我们再次选择了5039端口用于jdwp的连接。（在gdb和lldb中也是使用了5039见：http://t.csdn.cn/QkkH3和http://t.csdn.cn/JWgcF）
adb forward tcp:5039 jdwp:6405
- 使用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
如下图
打印堆栈
#where [ | all] -- 转储线程的堆栈
> where 0x4e81
输出如下：
同时将main线程选为了当前线程
打印本地变量
#locals 打印本地变量
>locals
输出如下
移动栈帧
# up [n frames] -- 上移线程的堆栈
# down [n frames] -- 下移线程的堆栈
打印变量
# dump 变量名
> dump view.mTextClassifierHelper
输出如下
设置源代码位置
# 在jdb启动的时候，添加选项-sourcepath 路径1:路径2 即可添加源代码的路径
# 这样在调试AOSP代码的时候，会变得异常方便
# 还可以在jdb内部，使用use命令，修改源码路径
# 如下面使用jdb调试Android原生代码里面的MessageQueue
注意：在后面会有一个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
出现如下的输出
触发断点如下
其中bci表示：字节码索引
单步
# step -- 执行当前行,可理解为单步进入
# step up -- 执行直到当前方法返回到它的调用者
# stepi -- 执行当前指令
# next -- 步进一行，可以理解为单步over
# cont -- 从断点处继续执行
修改值
# set = 赋值字段，变量，数组元素新值
跟踪线程的方法进入和退出
# trace [go] methods [thread]
-- 跟踪方法进入和退出。
-- 除非指定 'go', 否则挂起所有线程
# trace [go] method exit | exits [thread]
-- 跟踪当前方法的退出, 或者所有方法的退出
-- 除非指定 'go', 否则挂起所有线程
untrace [methods] -- 停止跟踪方法进入和/或退出
trace method 命令在调试大型程序或复杂的方法调用关系时特别有用。它可以帮助你定位问题，理解代码的执行流程，并找到潜在的错误或异常。
捕获异常
# catch [uncaught|caught|all] | 当指定的异常发生时，暂停，如下图
# ignore [uncaught|caught|all] | 取消捕获某个异常
打印锁信息
# lock -- 打印某个对象上面的锁信息
# threadlocks [thread id] --打印线程上面的锁信息
计算表达式
# eval 表达式——计算表达式的值
# 计算变量x和y的值
>eval x+y
即时调试
同native一样，即时调试分成两部分
- 程序一启动就等待调试器的加入
- 程序一崩溃就等待调试器的加入
程序一启动就等待调试器的加入
- 告诉系统，停在合适的位置
android 提供了一个命令行选项，告诉app，启动之后，等待debugger的接入。命令如下：
adb shell am set-debug-app -w com.example.test_malloc
说明：set-debug-app [-w] [--persistent]
-w: 应用开始，就等待debugger接入
--persistent: 这个值一直存在，不会因为应用消失之后被清除掉
设置成功之后，应用打开将会出现如下的情况
- 告诉jdb，连上app之后，不要马上运行而是挂起所有线程。
在user目录下，创建配置文件。
- Linux和Macos叫做.jdbrc
- windows叫做jdb.ini
保存如下内容：
suspend
可以看到如下的截图
- 设置好对应操作之后（如断点），再开始使用resume命令开始。
如下图
注意：除了通过上面的操作等待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提供的功能更加丰富，多出来的功能有：
- 单独操作某个具体的线程
- 修改源码位置
- 跟踪方法的进入和退出
- 主动捕获异常
- 打印锁信息
上面多出来的功能，有助于：分析大型Android项目，分析AOSP系统级代码，分析Android漏洞，分析多线程编程
在完成jdb的命令行介绍之前，先对jdb能观察的内存内容做一个小结：
- 查看堆帧
- 查看本地变量
- 查看锁
- 查看对象
本文完。
在进行java堆内容查看之前。先引入对应的UI界面，下一小节将介绍VSCode调试Android应用