做测试调研的时候感觉不是很熟，就找了点资料来学习下DDMS、JDWP和调试器的东西。翻译了点资料。
DDM:dalvik debug monitor，调试监视器，很生硬的名字，但是这样可以表明它的作用，同时区别于Debugger调试器。它只是一个监视器，提供了UI，连接VM和Debugger，是server；
Debugger：调试器，这才是调试用的东西；
JDWP：传输协议，允许vm-DDM-debugger的数据传输模式。
vm：dalvikvm，是client，调试其实就是client-server模式
1、简介
能实时观察虚拟机的状态时非常有用的，对于Android，我们需要能监视通过USB或者无线连接的设备上的多个虚拟机（CR:每个app创建一个vm实例）。本文档描述了一个连接到多个vm的调试监视器终端（CR：下面都叫DDM，dalvik debug monitor server）以及一个API，虚拟机和应用可以通过API向监视器传递信息。
通过Dalvik调试监视器（DDM）可以监视的东西：
（1）线程状态：追踪线程创建、退出、忙/空闲状态；
（2）所有的堆的状态：对于heap bitmap display和片段分析很有用。
亦可以用除了VM之外的东西来作为DDM的客户端，但是这是次要目的。例子中包含了“logcat”信息和对虚拟内存使用及LOAD平均的系统监视。（CR：这句话不太明白）
通过将信息展现在设备的UI上，DDM也可以在设备上运行。但是，它最初的目的是一个利用桌面工具和屏幕资源来提供显示的工具。
DDM用JAVA语言写成，从而可移植，它通过桌面UI工具（SWT）来实现接口。
2、协议
为了利用已有的接口，DDM协议建立在JDWP协议之上（CR：piggy-back类似于在卡车后面挂车的意思）（java debug wire protocol，通常运行在vm和调试器之间）。这样，对于一个无DDM的客户端来说，DDM作用其实就像一个调试器。
JDWP协议和我们想要实现的功能很像，特别的：
（1）它允许vender-defined包，因此没有必要改变JDWP细则；
（2）VM可能在任何时间传出事件，这些事件不会导致调试器输出一个响应，这意味着客户端可以传出数据并且立刻继续工作而不需要等待事件响应；
（3）基本的协议是无状态、异步的，调试器端的请求包包含了一串数字，而vm则包含在了响应包中，这就实现了同时同步会话，意味着DDM通信和调试器通信可以交错进行。
下面是我们使用JDWP的一些情形：
（1）VM只等待和调试器的一个连接，因此你不能同时连接监视器和调试器。为此，就要将调试器和监视器连起来然后传输数据（我们目前可以通过jdwpspy传输数据，尽管还需要管理我们需要的ID）。连接了设备之后，通过这种方式比现在的方法（猜测传输端口号）更加方便；
（2）当调试器连接后，VM运行会不一样。它会更慢，任何传向监视器或者调试器的对象都不会产生GC；对此，我们可以通过直到监测到无DDM通信再激活慢路径（CR：slow path，不懂）。另外，我们还希望能产生“调试器已经断开/连接”的信息，从而使VM释放调试相关资源并且不断开连接；
（3）无DDM的vm在DDM连接后不应该出错，事实上三方vm并没有对此保证（例如某种主流vm会立刻崩溃），但是老式的JanVM会拒绝“hello”包。
2.1、建立连接
可以通过两种基本方法：DDM连接vm，vm连接DDM。前者没有后者“精确”，因为你必须扫描客户端，但是它也有自己的优点。
有三种有趣的情形：
（1）DDM开启，然后boot USB连接的设备或者启动模拟器；（DDM，设备）
（2）设备或模拟器在运行DDM之前已经在运行；（设备，DDM）
（3）DDM已经在运行了，当一个已经启动的设备通过USB连接的时候。（DDM，USB连接运行中的设备）
如果设备连接上了已经启动的DDM,我们只要处理情形1；如果DDM在它开启的时候扫描VM，我们只要处理情形2；没有处理情形3，而它可能是随着设备的运行最重要的一支。
因此可以设计一个下拉菜单，它有两个选项：扫描服务器、扫描设备。前者使得DDM扫描“本地主机”（localhost）上的vm，后者使得它查询adb连接另一边的vm。DDM会每隔几秒就扫描vm，或者检测已知vm端口序列（例如8000——8040），或者和设备上的某些数据库交互。改变模式会导致已有的连接中断。
当DDM第一次启动时，它会尝试运行“adb usb”来确保adb可以运行（注意：确保DDM从可以在该路径中运行adb的shell中启动很重要）。如果失败，和设备的交互很可能会等到adb守护进程运行才开始。