使用 TraceView 找到卡顿的元凶以及 StrictMode 优化代码逻辑

android studio 教程 | 2018-12-18 07:27

code小生,一个专注 Android 领域的技术平台

作者:Android_Jieyao链接:声明:本文已获Android_Jieyao授权发表,转发等请联系原作者授权

读完本文你将了解到:

1.TraceView 是什么;2.如何生存trace文件;3.根据TraceView显示定位问题4.解决DDMS中find功能无法使用的问题5.TraceView使用场景6.StrictMode严苛模式使用

TraceView 是 Android SDK 中内置的一个工具,它可以加载 trace 文件,用图形的形式展示代码的执行时间、调用次数及调用栈,便于我们分析。trace 文件是 log 信息文件的一种,可以通过代码,Android Studio,或者 DDMS 生成。使用 Android SDK 提供的工具可以生成很多 log 文件,便于我们分析当前应用的内存、布局等状况,下面是几种文件的截图:

手机卡顿很多时候都是由于某个操作过于耗时,在茫茫代码中查找元凶未免太过痛苦,这时候就该体现 TraceView 的价值了。

生成 trace 文件有三种方法:

使用代码生成

Debug.startMethodTracing("shixintrace"); //开始 trace保存文件到 "/sdcard/shixintrace.trace"    // ...    Debug.stopMethodTracing();    //结束代码很简单,当你调用开始代码的时候,系统会生产 trace 文件,并且产生追踪数据,当你调用结束代码时,会将追踪数据写入到 trace 文件中。

下一步使用 adb 命令将 trace 文件导出到电脑:

adb pull /sdcard/shixintrace.trace /tmp使用代码生成 trace 方式的好处是容易控制追踪的开始和结束,缺点就是步骤稍微多了一点。

使用 Android Studio生成

Android Studio 内置的 Android Monitor 可以很方便的生成 trace 文件到电脑。在 CPU 监控的那栏会有一个闹钟似的的按钮,未启动应用时是灰色:

启动应用后,这个按钮会变亮,点击后开始追踪,相当于代码调用 startMethodTracing:

当要结束追踪时再次点击这个按钮,就会生成 trace 文件了。生成 trace 后 Android Studio 自动加载的 traceview 图形如下:

从这个图可以大概了解一些方法的执行时间、次数以及调用关系,也可以搜索过滤特定的内容。

左上角可以切换不同的线程,这其实也是直接用 Android Studio 查看 trace 文件的缺点:无法直观地对比不同线程的执行时间。

鼠标悬浮到黄色的矩形上,会显示对应方法的开始、结束时间,以及自己占用和调用其他方法占用的时间比例:

使用 DDMS生成

DDMS 即 Dalvik Debug Monitor Server ,是 Android 调试监控工具,它为我们提供了截图,查看 log,查看视图层级,查看内存使用等功能,可以说是如今 Android Studio 中内置的 Android Monitor 的前身。双击 shift 弹出全局搜索,搜索 “Android Device Monitor”:

或者直接在 设置里设置 Android Device Monitor 的快捷键:

打开 Android Device Monitor,在 DDMS 中打开 trace 文件,DDMS 会启动 TraceView 加载 trace 文件:

上图介绍了 TraceView 的大致内容:

上半部分显示了不同线程的执行时间其中不同的颜色表示不同的方法同一个颜色越长,说明执行时间越久,如图中的主线程 main空白表示这个时间段内没有执行内容

下半部分展示了不同方法的执行时间信息,关键指标有三个:Cpu Time/Call :该方法平均占用 CPU 的时间Real Time/Call :平均执行时间,包括切换、阻塞的时间,>= Cpu TimeCalls + Recur Calls/Total :调用、递归次数

点击下面的任意一个方法,可以看到它的详细信息:

Parents:选中方法的调用处

Children:选中方法调用的方法

定位问题时, TraceView 的使用方式:

从上半部分查看哪些线程执行时间长?什么时候开始执行?与主线程交错时间?

哪些方法的执行需要花费很长时间点击 TraceView 中的 Cpu Time/Call,按照占用 CPU 时间从高到低排序

哪些方法调用次数非常频繁点击 TraceView 中的 Calls + Recur Calls/Total ,按照调用次数从高到底排序

排序后,然后逐个排查是否有项目代码或者依赖库代码,有的话点击查看详情,查看是这个方法还是调用的子方法的问题,进一步定位问题。

Traceview 中信息太多,想要查找可以使用最下方的 find:

但是目前 DDMS 中的 TraceView 有 bug,find 无法使用, 解决办法就是直接使用 SDK 中的 TraceView。直接打开 SDK 中的 TraceView :

然后打开之前生成的 trace 文件:

如果直接打开 traceview 有问题,可以通过命令行 traceview 打开:

虽然提示 deprecated,但起码在搜索上还是比 Android Device Monitor 中好用。

在发现某个页面或者操作会卡顿时,可以使用 TraceView 定位问题代码。比如启动,加载图片列表卡顿等情况。还有一点,不要过早优化!

1.简介StrictMode类是Android 2.3 (API 9)引入的一个工具类,可以用来帮助开发者发现代码中的一些不规范的问题,以达到提升应用响应能力的目的。举个例子来说,如果开发者在UI线程中进行了网络操作或者文件系统的操作,而这些缓慢的操作会严重影响应用的响应能力,甚至出现ANR对话框。为了在开发中发现这些容易忽略的问题,我们使用StrictMode,系统检测出主线程违例的情况并做出相应的反应,最终帮助开发者优化和改善代码逻辑。2.用途使用严格模式,系统检测出主线程违例的情况会做出相应的反应,如日志打印,弹出对话框亦或者崩溃等。换言之,严格模式会用不同的策略对应用的违例细节做监控,通过一定的方式暴露给开发者方便优化与改善。3.使用通常在Activity或者自定义的Application类的onCreate方法中启动StrictMode.

// DEVELOPER_MODE代表只在调试模式下启用StrictModeif (DEVELOPER_MODE) {   //线程方面的策略   StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder()           .detectDiskReads()           .detectDiskWrites()           .detectNetwork()   // or .detectAll() for all detectable problems           .penaltyLog()           .build());   // VM方面的策略   StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder()           .detectLeakedSqlLiteObjects()           .detectLeakedClosableObjects()           .penaltyLog()           .penaltyDeath()           .build());}StrictMode通过策略方式来让你自定义需要检查哪些方面的问题,主要有两种策略:

ThreadPolicy:线程方面的策略StrictMode.ThreadPolicy.Builder主要方法解释:

detectNetwork():用于检查UI线程中是否有网络请求detectDiskReads()和detectDiskWrites():磁盘读写检查detectCustomSlowCalls():主要用于帮助开发者发现UI线程中调用的哪些方法执行的比较慢,要和StrictMode.noteSlowCall配合使用,只有通过StrictMode.noteSlowCall标记“可能会”执行比较慢的方法,只有标记过的方法才能被检测到,日志中会记录方法的执行时间(注意:只有在主线程中执行的方法才会显示执行时间,在其他线程中执行的方法,就算是使用StrictMode.noteSlowCall标记,在日志中也不会打印执行时间)VmPolicy:VM方面的策略StrictMode.VmPolicy.Builder()主要方法解释:detectActivityLeaks(): 用户检查 Activity 的内存泄露情况detectLeakedClosableObjects() 和 detectLeakedSqlLiteObjects():资源没有正确关闭时回触发detectLeakedSqlLiteObjects() 和 detectLeakedClosableObjects()的用法类似,     只不过是用来检查 SQLiteCursor 或者 其他 SQLite 对象是否被正确关闭detectLeakedRegistrationObjects() 用来检查 BroadcastReceiver或者ServiceConnection注册类对象是否被正确释放setClassInstanceLimit(),设置某个类的同时处于内存中的实例上限,可以协助检查内存泄露

惩罚:penaltyDeath():当触发违规条件时,直接Crash掉当前应用程序penaltyDeathOnNetwork():当触发网络违规时,Crash掉当前应用程序penaltyDialog():触发违规时,显示对违规信息对话框penaltyFlashScreen():会造成屏幕闪烁,不过一般的设备可能没有这个功能penaltyDropBox():将违规信息记录到 dropbox 系统日志目录中(/data/system/dropbox),    你可以通过如下命令进行插件adb shell dumpsys dropbox dataappstrictmode --printpermitCustomSlowCalls()、permitDiskReads ()、permitDiskWrites()、permitNetwork: 如果你想关闭某一项检测,可以使用对应的permit*方法

最后:我们也可以在Android设备的设置(Settings)中启用StrictMode(亲测没有什么效果):开发者选项 > 启用严格模式。最后分享一个小例子:

D/StrictMode: StrictMode policy violation; ~duration=3 ms: android.os.StrictMode$StrictModeDiskWriteViolation: policy=65567 violation=1at android.os.StrictMode$AndroidBlockGuardPolicy.onWriteToDisk(StrictMode.java:1253)at java.io.FileOutputStream.<init>(FileOutputStream.java:220)at com.perf.strictmodedemo.MainActivity.writeToExternalStorage(MainActivity.java:44)at com.perf.strictmodedemo.MainActivity$1.onClick(MainActivity.java:28)at android.view.View.performClick(View.java:5619)at android.view.View$PerformClick.run(View.java:22298)at android.os.Handler.handleCallback(Handler.java:754)at android.os.Handler.dispatchMessage(Handler.java:95)at android.os.Looper.loop(Looper.java:165)at android.app.ActivityThread.main(ActivityThread.java:6365)at java.lang.reflect.Method.invoke(Native Method)at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:883)at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:773)使用penaltyDialog():

总结:StrictMode适合作为一些基础规范问题排查。

分享技术我是认真的