Android课程读书笔记,张绍文android开发高手课读书笔记3-卡顿优化篇

下面进入正题

卡顿根本原因

造成卡顿的原因可能有千百种，不过最终都会反映到CPU 时间上.

CPU时间分两种用户时间 执行用户态应用程序代码所消耗的时间

**系统时间 **执行内核态系统调用所消耗的时间，包括 I/O、锁、中断以及其他系统调用时间

CPU使用状态有以下几个指标CPU 使用率:  如果 CPU 使用率长期大于 60% ，表示系统处于繁忙状态,就需要进一步分析用户时间和系统时间的比例。对于普通应用程序，系统时间不会长期高于 30%，如果超过这个值，就得考虑是否I/O调用过多或者锁调用的过于频繁的问题。(Android studio 3.0的版本之后可以直接观测到CPU的使用情况)

CPU 饱和度:  CPU 饱和度反映的是线程排队等待 CPU 的情况，也就是 CPU 的负载情况。

CPU 饱和度首先会跟应用的线程数有关，如果启动的线程过多，易导致系统不断地切换执行的线程，把大量的时间浪费在上下文切换,要知道每一次 CPU 上下文切换都需要刷新寄存器和计数器,至少需要几十纳秒的时间。

卡顿排查工具

分两个流派,instrument和sample.instrument: 获取一段时间内所有函数的调用过程，可以通过分析这段时间内的函数调用流程，再进一步分析待优化的点。

sample:  有选择性或者采用抽样的方式观察某些函数调用过程，可以通过这些有限的信息推测出流程中的可疑点，然后再继续细化分析。

具体的工具如下:

Traceview

属于instrument派系,利用 Android Runtime 函数调用的 event 事件，将函数运行的耗时和调用关系写入 trace 文件中。

Traceview属于比较早起的工具,性能开销过大,有时无法反映真实的运行状况,另外无法反混淆。

在Android 5.0之后，新增了 sample类型,减少开销,但是信息量就不一定达到分析需求了。

Nanoscope

相比起Traceview,Uber开源的Nanoscope的性能消耗就小了许多。

但由于Nanoscope是直接修改Android虚拟机源码,会有不少的局限性。

比如需要自己刷ROM或者用它提供的x86的模拟器,就算自己刷ROM也只支持Nexus 6P。

如果想要简便的使用Nanoscope的话，需要一系列自动化脚步协助。

systrace

systrace则是利用Linux的ftrace调试工具,相当于在系统各个关键位置都添加了一些性能探针.

一说到Linux可能很多人就比较蒙,拿Android下的知识来讲,你可以理解为类似Activity Manager类似的监控。

Simpleperf

Native函数的监控.(不了解)

卡顿监控张老师在课中讲的多是比较深入的知识和解决问题的思路。

就好比一个应用满分100分，张老师讲的是如何把应用从90分拉向100分.

然而实际上大部分人需要的是如何到90分.

任重而道远

微信的卡顿监控也经过了几个过程

消息队列监控最开始通过替换主现场消息队列中Looper的MessageLogging来获取卡顿时间。

以及打印对应的函数信息//参考的代码Printer logging = me.mLogging;if (logging != null) {

logging.println(">>>>> Dispatching to " + msg.target + " " +

msg.callback + ": " + msg.what);

}

实现原理可以参考BlockCanary这个库或者这篇博文 Android卡顿检查-BlockCanary浅析上线之后发现性能有所下降,替换方案。

开一个监控线程,每隔1s向主线程消息头插入一条空消息,1秒后去检查主现程头部是否是之前插入的空消息。如果是,说明主线程卡顿了0～1秒,为什么会是一个区间呢？因为你发送空消息的时候也需要考虑在内。

那如果监控一个3秒的卡顿,在第4秒的时候去检查空消息是否被消费,如果没有,说明确实发生了一个3秒以上的卡顿。

消息队列监控也存在一些问题。

比如主线程卡顿了3秒,在这3秒钟有多个函数,而通过这种方式只能得到最后一个函数的一些信息.

但实际上耗时比较久的函数不一定是最后一个.

不过对于用户量比较大的应用来说,根据反馈回来的数据比例还是能得到具体耗时的函数是那个。

插桩

利用lnline Hook技术和上文中提到systrace。

Profile

FaceBook开源的Profile库,性能确实很高。

但是其中黑科技太多，所以兼容性还是个大问题。

帧率监控

业界都使用 Choreographer 来监控应用的帧率

监听界面是否存在绘制行为getWindow().getDecorView().getViewTreeObserver().addOnDrawListener

Android Vitals 将连续丢帧超过 700 毫秒定义为冻帧，也就是连续丢帧 42 帧以上。

作者：niknowzcd

链接：https://www.jianshu.com/p/85da1a53d5e5