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

最新推荐文章于 2024-04-03 22:40:03 发布

大渔歌_

最新推荐文章于 2024-04-03 22:40:03 发布

阅读量609

点赞数

分类专栏： android 内存优化文章标签：性能优化

原文链接：https://blog.csdn.net/zoky_ze/article/details/65958628

版权

android 内存优化专栏收录该内容

13 篇文章 1 订阅

订阅专栏

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。

断点管理与视图显示

这里写图片描述

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

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

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

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相当于在一个特殊的时间点上生成的一个快照。

我们可以在左上角选择查看的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表示这个方法中调用的其他方法，可以叫做子方法

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

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

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

转载:https://blog.csdn.net/zoky_ze/article/details/65958628