Android Studio 调试机制及性能优化工具使用

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/zoky_ze/article/details/65958628

Android Studio调试步骤

1.设置断点

双击代码左侧的空白区域,即可设置断点
设置断点

2.按下debug快捷键进入debug模式启动app

这里写图片描述

3.触发断点

应用启动后,执行到断点时,AS会自动弹出debug面板,开始debug模式。接下来分析下各个快捷键的作用。
debug控制面板

4.功能分析

调试按键

单步调试
从左到右来看下各个快捷键的功能:

1. Show Execution Point :
点击该按钮时, 光标将定位到当前正在调试的位置。在我们进行追踪代码后使用这个功能能够很快继续下一步调试。

2. Step Over :
单步跳过,点击该按钮将导致程序向下执行一行。如果当前行是一个方法调用,此行调用的方法被执行完毕后再到下一行,而不会进入方法内部。

3. Step Into :
单步跳入,执行该操作将导致程序向下执行一行。如果该行有自定义的方法,则进入该方法内部继续执行,如果是类库中的方法,则不会进入方法内部。

4. Force Step Into :
强制单步跳入,和step into功能类似,主要区别在于:如果当前行有任何方法,则不管该方法是我们自行定义还是类库提供的,都能跳入到方法内部继续执行

5. Drop Frame:
中断执行,并返回到方法被调用的地方,在这个过程中该方法对应的栈帧会从栈中移除,且不会改变上下文。

6. Force Run to Cursor:
忽略已经存在的断点,将光标定位到相应的位置,然后执行Force Run to Cursor即可执行到指定的地方。

7.Evaluate expression :
能够获取到程序中的某个变量,然后输入需要执行的操作,进行evaluate后能够显示出结果,如下图中,想知道message的长度时,可以对message变量进行计算,输入messag.length即可获取result。
evaluate

断点管理与视图显示

这里写图片描述

1. View Breakpoints
显示当前的各类视图的数量及位置,能对每一个断点进行管理,设置enable等属性

2.Mute Breakpoints :
使用该按钮来切换断点的状态:启动或者禁用.在调试过程中,你可以禁用暂时禁用所有的断点,已实现应用正常的运行.该功能非常有用,比如当你在调试过程中,突然不想让断点干扰你所关心的流程时,可以临时禁用断点.

3.Get thread dump :
获取线程Dump,点击该按钮将进入线程Dump界面,可以看到系统各个线程的活动状态,下面一张是网上参考的Thread的各种状态图标。
thread dump

4. Restore Layout:
可以查看到当前压入方法栈中的方法,帮助我们返回到之前调用该方法的位置。

restore layout

5. Settings :
这里的 Auto-Variables Mode是指 开启这个功能后,idea的Debugger会自动评估某些变量当你执行在某个断点时,Debugger会检测当前调试点之前或者之后的变量的状态,然后在变量区选择性输出,未开启该功能之前,变量区输出所有的变量信息:
setting

在Android Studio 调试过程中,我们也可以很方便的使用setvalue功能去动态改变某一个变量的值,达到满足调试需求的效果。

断点的类型

在Android Studio中 ,断点分为以下五种类型。
- 条件断点
- 日志断点
- 异常断点
- 方法断点
- 属性断点

这里着重了解以下 异常断点和属性断点

异常断点就是在调试过程中,一旦发生异常(可以指定某类异常),则会立刻定位到异常抛出的地方。比如在调试异常中,我们非常关注运行时异常,希望在产生任何运行异常时及时定位,那么此时就可以利用该类型异常

Filed WatchPoint是本质上是一种特殊的断点,也称为属性断点:当我们某个字段值被修改的时候,程序暂停在修改处。通常在调试多线程时尤为可用。

性能优化工具

Android Studio 自带的内存分析工具Memory,可以很方便的查看应用内存情况,实时地显示出内存占用情况,内存泄漏发生时的主要表现为内存抖动,可用内存慢慢变少,我们可以根据实际情况分析,从而使用leakCanary等工具进一步去分析内存泄漏和OOM等问题。
memory

在Memory提供几个功能按钮帮助我们对内存进行操作和查看。

这里写图片描述

1. Initial GC:
这个命令会让APP执行一次Full GC。一般是在Dump Heap之前执行一次,这样会减少很多 用的对象。

2. Dump Java Heap :
Java Heap 是所有类实例和数组对象分配的一个运行时数据区,其间所有Java VM线程在执行期间共享Heap 中的数据。那么一个Java heap dump相当于在一个特殊的时间点上生成的一个快照。
dump java heap

我们可以在左上角选择查看的heap类型
App heap - 当前app使用的堆
Image heap - 当前app在硬盘上的内存映射
Zygote heap - zygote 复制时继承来的库、运行时类和常量的数据集。zygote空间设备启动时创建,从不分配这里的空间。

以下步骤是典型工作流程:

  • 在HPROF文件查看工具中选择一个类名;
  • 选择该类的一个实例;
  • 查看引用树;
  • 当需要的时候可以右键引用树种的条目跳转到源码或者实例。

3. Start Allocation Tracking :
这个功能可以记录一段区间内各个线程各个方法的内存分配情况,主要用于调试在复杂系统里面短时间内存暴增造成GC频繁的Case。使用方法:先点击一次,然后会看到Memory Recorder开始转动,然后自己开始在APP上面做相应的操作。在合适的时间再点一次,结束记录。即可生成一个.alloc文件
alloc

通过分析alloc数据,我们可以知道某一个thread里面的所有的调用过的方法所分配的堆大小,通过这些数据可以让我们针对方法级别堆程序进行优化。

LeakCanary

LeakCanary是Square开源的一个内存泄露自动探测神器,它是一个Android和Java的内存泄露检测库,可以大幅度减少了开发中遇到的OOM问题。
使用方法也很简单,只需在Application中进行初始化,然后在需要检测内存泄漏的地方进行watch即可

dependencies {
   debugCompile 'com.squareup.leakcanary:leakcanary-android:1.5'
   releaseCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.5'
   testCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.5'
 }
public class ExampleApplication extends Application {

  @Override public void onCreate() {
    super.onCreate();
    if (LeakCanary.isInAnalyzerProcess(this)) {
      // This process is dedicated to LeakCanary for heap analysis.
      // You should not init your app in this process.
      return;
    }
    LeakCanary.install(this);
    // Normal app init code...
  }
}

LeakCanary中文使用说明

如果应用中出现内存异常的时候,能够帮助我们定位到哪个地方出现问题:
LeakCanary

TraceView

TraceView是从每个方法运行的时间的角度来分析应用的性能,
现来看一下整个TraceView界面的图,整个界面包括上下两部分,上面是你测试的进程中每个线程的执行情况,每个线程占一行;下面是每个方法执行的各个指标的值。
上面一部分是你测试进程的中每个线程运行的时间线,下图中可以可以看到,主要只有一个main线程在执行。

TraceView

使用TraceView主要有两种方式:

最简单的方式就是直接打开DDMS,选择一个进程,然后按上面的“Start Method Profiling”按钮,等红色小点变成黑色以后就表示TraceView已经开始工作了。然后我就可以滑动一下列表(现在手机上的操作肯定会很卡,因为Android系统在检测Dalvik虚拟机中每个Java方法的调用,这是我猜测的)。操作最好不要超过5s,因为最好是进行小范围的性能测试。然后再按一下刚才按的按钮,等一会就会出现上面这幅图,然后就可以开始分析了。

第2种方式就是使用android.os.Debug.startMethodTracing();和android.os.Debug.stopMethodTracing();方法,当运行了这段代码的时候,就会有一个trace文件在/sdcard目录中生成,也可以调用startMethodTracing(String traceName) 设置trace文件的文件名,最后你可以使用adb pull /sdcard/test.trace /tmp 命令将trace文件复制到你的电脑中,然后用DDMS工具打开就会出现上面图了。

每个方法前面都有一个数字,可能是全部方法按照Incl CPU Time 时间的排序序号,点一个方法后可以看到有两部分,一个是Parents,另一个是Children。

  • Parent表示调用这个方法的方法,可以叫做父方法

  • Children表示这个方法中调用的其他方法,可以叫做子方法

上图中横轴表示各个方法执行占用的各种时间,调用次数等,我们依次来看下

  1. Incl Cpu Time:这个指标表示 这个方法以及这个方法的子方法一共执行的时间
  2. Excl Cpu Time :就是方法本身除去子方法后,其他操作所占用的时间。
  3. Incl Real Time : 应该是这个方法的实际运行时间,可能是因为CPU的上下文切换、阻塞、GC等原因方法的实际执行时间要比Cpu Time 要稍微长一点。.
  4. Excl Real Time : 方法本身除去子方法后,其他操作所占用的实际时间。
  5. Calls + Recur Calls / Total: 一个Call表示这个方法调用的次数,Recur Call表示递归调用次数
  6. Cpu Time / Call : 如名字可知。。。。。
    参考文章:

你所不知道的Android Studio调试技巧

展开阅读全文

没有更多推荐了,返回首页