Android卡顿优化

2019-03-04 本文已影响0人 34sir

造成卡顿的原因有很多最终会反映到CPU时间上
CPU时间分为两种：
1⃣️用户时间
执行用户态应用程序代码消耗的时间
2⃣️系统时间
执行内核态系统调用所消耗的时间包括 I/O 锁中断以及其他系统调用的时间

CPU性能

评价CPU的性能需要看主频 核心数 缓存等参数
获取CPU信息：

// 获取 CPU 核心数
cat /sys/devices/system/cpu/possible  

// 获取某个 CPU 的频率
cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq

卡顿问题分析指标

查看CPU的使用率 可以通过 /proc/stat 得到整个系统的CPU使用情况通过 /proc/[pid]/stat得到某个进程的CPU使用情况

proc/self/stat:
  utime:       用户时间，反应用户代码执行的耗时  
  stime:       系统时间，反应系统调用执行的耗时
  majorFaults：需要硬盘拷贝的缺页次数
  minorFaults：无需硬盘拷贝的缺页次数

如果CPU使用率大于60% 表示系统处于繁忙状态需要进一步分析用户时间和系统时间的比例
对于普通应用程序系统时间不会长期高于30% 如果超过应该进一步检查是否I/O过多还是其他系统调用问题

相关工具：
top 命令 查看哪个进程是CPU的消耗大户
vmstat 命令 实时动态监视操作系统的虚拟内存和CPU
strace 命令 跟踪某个进程中所有的系统调用

除了需要查看CPU的使用率还需要查看CPU饱和度(线程排队等待CPU的情况也就是CPU的负载情况）
CPU饱和度首先和应用的线程数有关如果启动的线程过多容易导致系统不断切换执行的线程把大量的时间浪费在上下文切换每一次CPU上下文切换都需要刷新寄存器和计数器至少需要几十纳秒的时间

可以通过使用 vmstat 命令或者 /proc/[pid]/schedstat 文件来查看CPU上下文切换次数特别需要注意 nr_involuntary_switches被动切换的次数

proc/self/sched:
  nr_voluntary_switches：     
  主动上下文切换次数，因为线程无法获取所需资源导致上下文切换，最普遍的是 IO。    
  nr_involuntary_switches：   
  被动上下文切换次数，线程被系统强制调度导致上下文切换，例如大量线程在抢占 CPU。
  se.statistics.iowait_count：IO 等待的次数
  se.statistics.iowait_sum：  IO 等待的时间

通过uptime 命令可以检查 CPU在1分钟 5分钟和15分钟内的平均负载比如一个4核的CPU 如果当前平均负载是8 表明每个CPU又来了一个线程在运行还有一个线程在等待
一般平均来负载应该控制在 0.7*核数以内

另外一个影响CPU饱和度的是 线程优先级 线程优先级会影响Android系统的调度策略主要由 nice 和 cgroup 类型共同决定 nice值越低抢占CPU时间片的能力越强当CPU空闲时线程的优先级对执行效率的影响不会特别明显但是在CPU繁忙时影响就非常大

关于线程优先级需要注意是否存在高优先级的线程空等低优先级线程，例如主线程等待某个后台线程的锁
从应用程序的角度看用户时间系统时间等待CPU的调度都是程序运行花费的时间

Android卡顿排查工具

Traceview systrace 等
从实现上分两个流派：
1⃣️ instrument 获取一段时间内所欲呕函数的调用过程分析这个过程进一步分析优化的点
2⃣️ sample 有选择性或者采用抽样的方式观察某些函数的调用过程分析可疑点

Traceview
利用Android Runtime函数调用event事件将函数运行的耗时和调用关系写入trace 文件中
属于instrument 可以查看整个过程有哪些函数调用但是本身性能开销大
Android 5.0 之后新增了startMethodTracingSampling 方法使用基于样本的方式进行分析以减少对运行时的性能影响
Nanoscope
instrument 类型的性能分析工具性能损耗较小
原理是 直接修改Android虚拟机源码在ArtMethod 执行入口和执行结束位置增加卖点代码将所有的信息先写到内存等到trace结束后才统一生成结果文件
限制：
1⃣️ 需要自己刷ROM 并且当前只支持Nexus 6P 或者对应的模拟器
2⃣️ 默认只支持主线程采集其他线程需要代码手动设置
非常适合做启动耗时时的自动化分析
生成的是符合Chrome tracing规范的HTML文件可以通过脚本来实现两个功能：
1⃣️ 反混淆 通过mapping自动反混淆结果文件
2⃣️ 自动化分析 传入相同的起点和终点实现两个结果文件的diff 自动分析差异
systrace
可以跟踪系统的I/O操作 CPU负载 Surface渲染 GC等
利用了Linux的ftrace 调试工具相当于在系统各个位置添加了一些性能探针
Android 在ftrace的基础上封装了atrace 增加了更多特有的探针如 Graphics、Activity Manager、Dalvik VM、System Server

只能监听特定系统调用的耗时情况所以属于sample类型性能开销很低不支持应用程序代码的耗时分析

Simpleperf
分析Native函数的调用属于sample类型性能开销很低
利用CPU的性能监控单元(PMU)提供的硬件perf事件
使用Simpleperf可以看到所有的Native代码的耗时例如加载dex vertify class

Simpleperf同时封装了systrace的监控功能
发展的几个阶段：
第一个阶段：在Android M和以前 Simpleperf不支持Java代码分析
第二个阶段：在Android O和以前需要手动编译OAT文件
第三个阶段：在Android P以后 Simpleperf支持Java代码分析

除了Nanoscope之外的工具都只支持debugable的应用程序需要root才能测试release包

总结如果需要分析Native代码的耗时可以选择Simpleperf；如果想分析系统调用可以选择systrace；如果想分析整个程序执行流程的耗时可以选择Traceview或者插桩版本的systrace

可视化方法

Android Studio 3.2 的Profiler中集成了几种性能分析工具：

Sample Java Methods 的功能类似于Traceview的sample类型
Trace Java Methods 类似Traceview的instrument类型
Trace System Calls 类似systrace
SampleNative(API Level 26+) 类似 Simpleperf

这些工具都支持Call Chart 和 Flame Chart 两种展示方式

Call Chart Traceview 和 systrace 默认使用的展示方式按照应用程序的函数执行顺序来展示适合分析整个流程的调用
Flame Chart 火焰图以全局视野看待一段时间的调用分布s s s

Android卡顿优化

CPU性能

卡顿问题分析指标

Android卡顿排查工具

可视化方法

猜你喜欢

热点阅读