Android Studio 调试机制及性能优化工具使用
2017-03-26 16:17
567 查看
Android Studio调试步骤
1.设置断点
双击代码左侧的空白区域,即可设置断点2.按下debug快捷键进入debug模式启动app
3.触发断点
应用启动后,执行到断点时,AS会自动弹出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:
可以查看到当前压入方法栈中的方法,帮助我们返回到之前调用该方法的位置。
5. Settings :
这里的 Auto-Variables Mode是指 开启这个功能后,idea的Debugger会自动评估某些变量当你执行在某个断点时,Debugger会检测当前调试点之前或者之后的变量的状态,然后在变量区选择性输出,未开启该功能之前,变量区输出所有的变量信息:
在Android Studio 调试过程中,我们也可以很方便的使用setvalue功能去动态改变某一个变量的值,达到满足调试需求的效果。
断点的类型
在Android Studio中 ,断点分为以下五种类型。- 条件断点
- 日志断点
- 异常断点
- 方法断点
- 属性断点
这里着重了解以下 异常断点和属性断点
异常断点就是在调试过程中,一旦发生异常(可以指定某类异常),则会立刻定位到异常抛出的地方。比如在调试异常中,我们非常关注运行时异常,希望在产生任何运行异常时及时定位,那么此时就可以利用该类型异常
Filed WatchPoint是本质上是一种特殊的断点,也称为属性断点:当我们某个字段值被修改的时候,程序暂停在修改处。通常在调试多线程时尤为可用。
性能优化工具
Android Studio 自带的内存分析工具Memory,可以很方便的查看应用内存情况,实时地显示出内存占用情况,内存泄漏发生时的主要表现为内存抖动,可用内存慢慢变少,我们可以根据实际情况分析,从而使用leakCanary等工具进一步去分析内存泄漏和OOM等问题。在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数据,我们可以知道某一个thread里面的所有的调用过的方法所分配的堆大小,通过这些数据可以让我们针对方法级别堆程序进行优化。
LeakCanary
LeakCanary是Square开源的一个内存泄露自动探测神器,它是一个Android和Java的内存泄露检测库,可b292
以大幅度减少了开发中遇到的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中文使用说明
如果应用中出现内存异常的时候,能够帮助我们定位到哪个地方出现问题:
TraceView
TraceView是从每个方法运行的时间的角度来分析应用的性能,现来看一下整个TraceView界面的图,整个界面包括上下两部分,上面是你测试的进程中每个线程的执行情况,每个线程占一行;下面是每个方法执行的各个指标的值。
上面一部分是你测试进程的中每个线程运行的时间线,下图中可以可以看到,主要只有一个main线程在执行。
使用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调试技巧
相关文章推荐
- instruments xcode自带调试工具 iOS性能优化:Instruments使用实战
- 使用 ETW 改善调试和性能优化
- 大型网站调试工具之一(php性能优化分析工具XDebug)
- SQL/PLSQL性能优化思路和工具使用【不断完善】
- android性能优化(3)—Eclipse MAT 工具的使用(a)
- 怎样提高SQL Server 2005 性能,以及优化工具的使用
- 大型网站调试工具之一(php性能优化分析工具XDebug)
- [Sql2005笔记] Sql2005性能工具(SQL Server Profiler和数据库引擎优化顾问)使用方法详解
- java 性能调试工具jprofiler安装和使用
- 使用性能优化工具 MVC Mini Profiler (MVC3+EF4.1)
- 使用Adobe Scout性能分析工具优化flash项目
- 大型网站调试工具之一(php性能优化分析工具XDebug)
- 网页速度分析 && 网页头文件解析 && 性能优化 && httpwatch工具使用
- 网页速度分析 && 网页头文件解析 && 性能优化 && httpwatch工具使用
- 大型网站调试工具之一(php性能优化分析工具XDebug)
- 自带的性能分析调试工具TraceView使用方法
- 大型网站调试工具之一(php性能优化分析工具XDebug)
- 大型网站调试工具之一(php性能优化分析工具XDebug)
- Android 性能优化 二 TraceView工具的使用
- 大型网站调试工具之一(php性能优化分析工具XDebug)