1.5.2 DDMS使用
注：以下所有操作必须手机连接PC，连接时确认手机处于"USB调试"模式；
1.5.2.1 线程监测
DDMS中的线程监控和评测浏览对于管理大量线程的应用很有用。
要启用，点击 Update Threads（更新线程）图标即可开始，如下图：
右侧对应的Threads窗口会显示面向选中VM进程的所有线程的名称和其他细节，如下图：
utime 和stime代表了线程在瞬间运行用户代码（utime）和系统代码（STIME）所花的总时间。一瞬间的时间是由系统定义的，但通常为10毫秒。星号表示守护线程；native状态表示线程正执行原生代码。查看上述样本数据时，除了查看应用主线程花费时间，也要关注GC花费时间，便于测试中发现GC问题或观察处理对象创建，提出有助于优化性能建议。
1.5.2.2 内存检测
可以使用DDMS中的Heap和Allocation tracker一起定位内存问题，如下：
点击Update Heap（更新堆）按钮，获得有关选定虚拟机中堆分配的信息，如下图：
右侧对应的Heap，点击"Cause GC"，Heap视图中便会显示当前应用的内存使用量的详细情况；
测试中如何判断程序是否有内存泄漏的可能性呢？需要关注一个值：Heap视图中部有一个Type叫做data object，即数据对象，也就是我们的程序中大量存在的类型的对象。在data object一行中有一列是"Total Size"，其值就是当前进程中所有Java数据对象的内存总量，一般情况下，这个值的大小决定了是否会有内存泄漏，可以这样判断：
（1）不断的操作当前应用，同时注意观察data object的Total Size值；
（2）正常情况下Total Size值都会稳定在一个有限的范围内，虽然不断的操作会不断的生成较多对象，但是虚拟机在不断的进行GC的过程中，对象都被回收了，内存占用量会会落到一个稳定的水平，也就是说程序代码良好，无内存泄露情况出现；
（3）反之如果代码中存在没有释放对象引用的情况，则data object的Total Size值在每次GC后不会有明显的回落，随着操作次数的增多Total Size的值会不断增大，累加到一个极限后导致进程被kill掉。
所以我们测试中可以预判下那些场景容易出现内存泄露，可以重复这个场景的操作，观察heap size值和data object"Total Size" 的变化，若发现内存泄露情况，可使用DMS另一个自带的内存分配跟踪工具Allocation tracker进行跟踪。
操作步骤：
（1）点击 "Start Tracking"；
（2）点击"Get allocations"，更新内存分配显示；
（3）filter输入应用名称进行筛选;
（4）继续不断重复场景操作，再点击"Get allocations"；
（5）若发现某个类占用的内存最大，且有上升的趋势，可点击该类，下方展示该类中运行的各方法，可定位到该类中的具体方法，双击method名，定位到对应的代码；
1.5.2.3 响应时间检测
Method Profiling（方法分析）对于快速概览应用中时间的消耗分布非常有用，也可用于时间关键型函数的详细查看。
响应时间测试的场景主要是在：遍历查询、递归查询等（循环判断）。
点击Start Method Profiling 
图标开始方法分析，操作场景测试，点击Stop Method Profiling
停止分析如下图：
图标开始方法分析，操作场景测试，点击Stop Method Profiling 停止分析如下图：
分析结果如下图：
incl cpu time%，将各方法时间消耗进行排序；
Incl cpu time%: inclusive时间占总时间的百分比
Excl cpu time%: 执行占总时间的白分比
Calls+Recur Calls/Total: 调用和重复调用的次数
Time/Call: 总的时间(ms)排序
单击底部窗格中的方法调用可创建一个层级结构，显示该方法--先是调用该方法的母方法，然后是从选定方法中调用的子方法，若发现某个方法占用CPU时间过长，可定位到对应代码,查看代码逻辑，针对性发现问题。
1.5.2.4 UI检查
DDMS下Dump view UI hierarchy for Automator针对程序开发中UI调试好处多多，对于测试而言该工具在UI视觉测试时也是一个利器，该工具能够定位到每个View在屏幕中的绝对位置（精确到具体的PX（像素）级别），在视觉检查测试时可以帮我们很轻松的发现UI视觉问题。
启动时，点击Dump view UI hierarchy for Automator图标，如下图：
启动后进入正式界面，可以逐个元素的进行UI视觉稿检测，有问题立即便可知晓，如下图：
1.5.2.5 流量统计
测试中流量大小是1个重要测试点，而DDMS提供了流量统计工具network statistics，该工具可以实时统计查看程序使用网络的情况，也可以通过设置不同的Tag(标签)来区分不同类型的流量使用情况，数据在DDMS中通过图表显示，点击右侧视图中的network statistic，并Start即开始统计，如下图：
1.5.2.6 CPU/Memory/FPS抓取
测试中CPU、内存、帧率测试必不可少，同样DDMS针对此提供了System Information工具，可以用来对CPU、内存和帧进行抓取，可以抓取到整个系统的某个瞬间信息。使用时点击右侧视图中的System Information即可，具体使用方法比较简单，不再赘述。
1.5.2.7 log抓取
日志一般用于记录程序运行信息，从而使开发者方便开发调试，便于发现问题。我们先看看android.util.Log常用的方法，共有以下六种：Log.v() 、Log.d() 、Log.i() 、Log.w()、 Log.e()以及Log.a() (android 4.0新增加的)。根据首字母对应VERBOSE、DEBUG、INFO、WARN、ERROR、Assert，重要程度排序Assert > Error > Warn > Info > Verbose。
(1)Log.v 的调试颜色为黑色的，任何消息都会输出，平时使用就是Log.v("","");
(2)Log.d的输出颜色是蓝色的，仅输出debug调试的意思，但他会输出上层的信息，过滤起来可以通过DDMS的Logcat标签来选择.
(3)Log.i的输出为绿色，一般提示性的消息information，它不会输出Log.v和Log.d的信息，但会显示i、w和e的信息
(4)Log.w的意思为橙色，可以看作为warning警告，一般需要我们注意优化Android代码，同时选择它后还会输出Log.e的信息。
(5)Log.e为红色，可以想到error错误，这里仅显示红色的错误信息，这些错误就需要我们认真的分析，查看栈的信息了;
(6)Log.a为4.0新增加的，Assert表示断言失败后的错误消息，这类错误原本是不可能出现的错误，现在却出现了，是极其严重的错误类型;
而我们平时测试Android App过程中会经常通过log定位问题，而DDMS中LogCat则是一个抓取APP运行log的利器，具体操作如下：
打开LogCat窗口，Window -> Show View -> LogCat.
手机连上本地PC，并打开usb调试模式，即可收集到app运行log了。
收集中可以增加log规律规则，点击窗口右上的加号，在Filter Name中输入需要过滤的的字符串。点击OK就行了。
多个设备的Log查看
在模拟器、真机数量多于两个的时候，DDMS仍然适用，DDMS试图，在左上角Devices中双击想要看log的设备即可，具体适用与单设备完全一致。
1.5.2.8 DDMS其他工具
DDMS其它工具，如广播状态信息、模拟电话呼叫、模拟接收及发送SMS、虚拟地理坐标、端口重定向，实际测试使用极少，这里不再讲解。
以上为本人日常工作中用到并总结的一些点，不足之处颇多，谢谢您能读完，十分感谢！
版权声明：本文出极测 jingming，51Testing软件测试网原创出品，未经明确的书面许可，任何人或单位不得对本文进行复制、转载或镜像，否则将追究法律责任。
