背景Android 性能稳定性测试工具mobileperf github 如果您觉得有帮助，请给个star，有问题欢迎加入文底钉钉群交流 露客 2018年加入天猫精灵，之前有过一些性能 稳定性测试经验，但天猫精灵跟我之前的项目经验不太一样，之前大多服务于单独的APP，比如测手淘就只是测手淘，而天猫精灵业务更复杂一些，主要有如下挑战： 1、除了天猫精灵手机APP，还有带屏天猫精灵上很多APP都需要支持，比如天猫精灵CC上有13个app，每个app使用场景各有不同，涵盖了通讯录、视频、音乐、购物等各种场景 2、相比手机app，除了点击操作的触屏链路，天猫精灵还有语音链路 3、手机app monkey test一般可能也就云测平台上跑几个小时，语音压测需要连续测试72个小时以上，测试时长远超云测工具，对工具的稳定性提出了新的要求 4、相对现在定价动辄几千块，均价2千左右的手机，天猫精灵定价只有几百，硬件配置差些，所遇到的性能 稳定性挑战会更严峻 需求本着前期先能发现问题，再深入定位问题，所以确定了线下、线上分步走的策略 1、线下方案，能方便采集性能数据，工具要支持Android手机、天猫精灵各种Android定制设备，支持Android全版本，轻量化，使用低门槛，尽可能少侵入甚至零侵入设备 2、线上性能指标 问题定位 本文是Android线下篇 线下方案选型工具选型
劣势：Android低版本有些功能需要root，Android高版本跨进程获取数据，权限限制，不兼容
优势：非侵入，权限高，能发现问题 劣势：需要连接数据线，便携性差点
劣势：侵入式，需集成SDK，不利于做竞品测试 GT github上已表示Android GT后续不再支持GT APP版本，只支持GT SDK 由于Android权限控制越来越严格，通过APP跨进程获取性能数据在Android高版本已越来越困难，由于adb shell权限比较高，相信Android会一直开放开发者权限，故方案选型阶段，采用了依赖adb的方案，开发了一套Android性能数据采集工具mobileperf 还有一种思路，仍然是app形态，但用了adb wifi通道，露客之前也有过一些测试工具app的经验，相比采用adb usb方式mobileperf的担忧：
工具对比mobileperf跟GT APP对比如下：  架构mobileperf整体架构图：  工具自身影响mobileperf对PC的影响  测试PC:MacBook Pro (Retina,15-inch, Mid 2015) 2.2 GHz 四核Intel Core i7 工具稳定性：mobileperf能支持跑72个小时以上，adb断开重连都能继续采集 工具适用性：支持mac linux windows平台 工具Android兼容性验证mobileperf Android版本兼容性验证结果如下
# 效果mobileperf在项目中使用1年半，天猫精灵总共发现了性能 稳定性类问题几百个，bug解决率都是100% 采集原理cpu方案调研1、dumpsys cpuinfo 2、top命令 3、通过proc/stat计算cpu使用率 两者区别：Android CPU使用率：top和dump cpuinfo的不同，看网上一番讨论，top更准 通过实验发现采集频率非常快时，top有点耗cpu，对手机本身性能有影响，自测，采集频率1s，top在低端手机上（红米）会占到7%（100%统计方式）的cpu使用率，天猫精灵采集频率5s，会有20%占用（400%统计方式），发现top的底层实现是读取proc文件，top对每个进程都有计算 网上提供了一种计算方式，原理上跟top一样，如果计算指定进程的cpu使用率，只需读对应的proc文件，通过jiffies计算就可以了，这样比top方式占用cpu低，计算方式如下 整机cpu使用率 通过读取/proc/stat ，这个文件包含了所有cpu核的汇总情况，所以后面计算不用考虑核数，占用率不会超过100% cpu使用时间 = user+nice+system+iowait+irq+softirq CPU总时间=user+nice+system+idle+iowait+irq+softirq = cpu使用时间 +cpu idle时间 总cpu使用率=（cpu使用时间2-cpu使用时间1）/(cpu总时间2-cpu总时间1)*100% 进程cpu使用率 通过读取/proc/pid/stat 进程cpu使用时间 = utime+stime 进程cpu使用率=（进程cpu使用时间2-进程cpu使用时间1）/(cpu总时间2-cpu总时间1)*100% 选定方案采集时间间隔 ，配置文件中默认5秒，由于对采集频率要求不高，top支持同时采集多进程，结果简单易处理，实时性 可信度高，决定采用top的方式 测试过程中会生成cpuinfo.csv，可以测试过程中查看，表中各列解释  汇总xlsx文件会在测试结束后生成，xlsx数据跟csv数据完全一致，xlsx汇总是根据csv的数据画的曲线（csv没有画图功能）  内存整机内存 可用内存通过dumpsys meminfo获取 Total RAM 、Free RAM 各进程pss通过dumpsys meminfo package获取TOTAL行 Pss Total所在列的值，各进程PSS也可以通过dumpsys meminfo获取，只是拿不到各进程更详细的内存占比情况，比如堆大小、native、system、so大小等 经在CC上测试发现dumpsys meminfo比dumpsy meminfo package耗时长，dumpsys meminfo耗时6s多，dumpsys meminfo package能在一秒内完成，采集频率5s，dumpsy meminfo会导致CC上system_server系统进程cpu由2%增高到80%，所以降低了dumpsys meminfo采集频率，采用10倍设置频率采集（比如 dumpsys meminfo package 5s，dumpsy meminfo则50s） 由于要支持多进程的情况，现在各进程pss通过解析dumpsys meminfo结果得到，dumpsys meminfo package来获取各个进程的详细内存情况 在测试过程中会生成一个meminfo.csv文件，可以查看，表中各列解释  这个csv表格是用dumpsys meminfo得出的，汇总xlsx文件会在测试结束后生成，对应meminfo这个表格  每个进程会有pss_部分包名的csv表格，这个表格是用dumpsys meminfo package得出的  能把每个进程的详细内存展示出来 汇总xlsx中对应pss_部分包名这个表格  如果进程发生了内存泄露，根据曲线，很方便一眼就看出是哪部分导致泄漏 为了帮助定位内存泄漏问题，工具每隔一个小时会执行am dumpheap package ，dump进程内存，但不能像LeakCanary直接翻译出GC引用链，仍需人工分析下 流畅度（fps/丢帧）fps通过dumpsys SurfaceFlinger或dumpsys gfxinfo(android8.0之后)获得最近128帧数据计算得出，fps=帧数/耗费时间 如果以上两种方式都不OK，机器有root，用service call SurfaceFlinger 1013获取帧数 通过dumpsys SurfaceFlinger的方式还会计算丢帧janky值 丢帧：相邻两次绘制之间的丢帧数，丢帧数越多，说明问题越严重，mobileperf默认丢帧数超过10帧算是严重丢帧 流畅度数据在fps.csv中 表中各列解释  页面打开耗时mobileperf从logcat日志中抓取am_activity_fully_drawn_time和am_activity_launch_time（大多数情况）日志， 会生成launch_logcat.csv  不过这种方式有个弊端，日志的耗时不能完全反馈真实的体验耗时，我们内部已有其他方案测试启动耗时 monkey（可限制activity）mobileperf调用了Android原生的monkey，如果您想限制在指定内activity内跑monkey ，可以通过配置项，开启monkey 后，会在测试目录下生成monkey.log logcat日志（支持异常日志检测）工具会保留全量logcat日志，每隔60万行会新建文件，辅助定位问题 如果配置文件中配置了异常日志 会将logcat中出现的异常日志都保存在exception.log中 根据异常汇总日志，再去logcat日志查看详细上下文信息，可以快速定位问题 流量通过读取/proc/net/xt_qtaguid/stats文件获取，因为Android提供的流量统计API – TrafficStats中，对uid进行流量统计的方法，能区分应用，底层就是读取了该文件 流量数据在traffics_uid.csv中，表中各列解释 <=android9 读取/proc/net/xt_qtaguid/stats获取流量 Android10,/proc/net/xt_qtaguid/stats not found,用/proc/net/dev /proc/pid/net/dev 获取流量 电量先通过dumpsys batteryproperties获取，如果获取不到，再通过dumpsys battery获取（Android9） 问题：插着usb，这两种方式获取到的并不精准，并非专业级电流电量测试，只能作为参考 电量数据在powerinfo.csv中，表中各列解释 由于功耗软件测试方式不太精准，我们内部已用硬件方案测试功耗，此项mobileperf中默认关闭 常驻进程pid监控天猫精灵是整机，跟很多手机app不一样，是应用级别app，可能会被用户手动kill掉，天猫精灵上有些系统优先级进程，不能挂掉，一旦挂掉，会导致无法使用，所以mobileperf新增了常驻进程pid监控，一旦pid发生了变化，认为发生了异常 磁盘剩余空间检查天猫精灵跟很多手机app不一样，随便压测就是3天以上，如果有写文件不正常，占满磁盘空间，会导致机器彻底无法使用，影响用户体验，所以测试结束时，添加了对磁盘剩余空间检查，如果使用空间超过80%，则自动提单 进程线程数通过进程名获取pid，ls -lt /proc/pid/task，统计多少行数即线程数 答疑为了方便大家更容易的接入mobileperf或讨论相关技术，大家可加入钉钉交流群32266824。为了方便大家交流，入群请注明姓名与公司等信息。 |
|
|
