
这是鼎叔的第一百四十一篇原创文章。行业大牛和刚毕业的小白都可以进来聊聊。欢迎关注本专栏《敏捷测试转型》星标收藏大量原创思考文章陆续推出。本人专著《无测试组织-测试团队的敏捷转型》已出版机械工业出版社。接上文聊聊移动APP的性能评测体系我们继续聊聊过去十五年来移动APP专项测试的核心指标和优化方法。电量测试电量的公式大家在中学应该都学过吧电能电功率*时间电功率电压*电流一般而言我们假定手机的电压是恒定的那只要知道电流就可以知道整个耗电的大小因为它跟时间是成正比的。究竟应该怎么测试电量呢当年我们常用的三种方法有一直接读取Android API通过和battery有关的API获取电量情况。这个方法的问题是不准因为它是纯软件估算的可能和真实情况有很大差距。另外如果手机休眠时我就没法进行电量测试了。而且这个API本身也会消耗电量。二部分手机可以采用外接的手段直接读取电池传感器但现在绝大多数手机做不了电池都是封装起来的。三采用外置的电流仪可以进行高精度的采样我们之前曾做了一个假电池去外接电流仪。方法三的主要缺点是专业电量仪太贵啦再重温一下以前的文章当年我和武汉的小团队是怎么自制电量仪的回想起来依然很有成就感。聊聊如何自研200元的电量测试仪电量测试的TIPS一当年的手机流行超频的概念现在好像不流行了超频和功耗是有一定正相关的打开超频会导致耗电增加。二手机屏幕的背景色和功耗也有密切关系。屏幕的亮度对电量测试有直接影响所以我们要固定合适的亮点去做基准电量测试。三之前通过硬件测试电量有一个问题它测出来的是整机功耗而不是被测APP的功耗但是手机能给你各个APP的功耗百分比。当然这个百分比存在一定的误差这是没有办法避免的APP的耗电非常微量。如果我们想用软件手段测试APP电量可以用谷歌提供的battery historian这是个系统级的分析工具到今天还在使用展示效果非常细致清晰。然后我们还可以使用Android studio的energy profile,以及dumpsys batterystats这就是个反馈统计结果的命令行。当然你也可以使用当年我们TMQ团队开发的GT工具实时在被测的APP上用浮窗展示它当前的耗电情况。iOS这边的电量测试工具就比较少了因为电量管理由系统严格控制如后台应用限制、硬件模块访问权限其电量统计依赖Xcode instrument中的energy dinosaustic还可用energy log专门打印出跟耗电有关的日志。如图我每次看到谷歌的historian就倍感亲切它能清晰展示某个进程的耗电很厉害然后我们通过研究原因提炼了不少优化经验和经典案例掌握好它们你就可以成为半个电量测试的专家了。案例一APP在后台待机时耗电特别快。我们分析CPU的时间片耗时情况发现某个进程中的时间片消耗特别异常通过代码去定位问题大概率会发现这里产生了大量的循环然后导致功耗异常。所以正如前文所说电量优化首先就是要减少大循环逻辑。还有一种可能性有一种所谓内存锁导致APP在后台无法真正进入休眠状态内存锁会定时激活。这种内存锁是干啥用的?鼎叔讲讲当年APP常见的流氓行为: 有些APP为了常驻内存避免在后台挂起后被KILL掉就在后台定时被激活达到提高业务活跃度的目的但这会导致手机无法真正休眠省电。当年我带团队开发一个护眼监控APP为了精确知道用户看了多久的手机屏幕以触发疲劳提醒功能就使用了内存锁功能哪知道使用半天后手机发热功耗严重。案例二跟网络切换有关的事件也会导致耗电。手机会不断发送广播或者监听广播然后触发相应的处理。为了避免频繁的广播事件处理开发者应该只对有效的数种广播进行响应。案例三跟传感器有关的耗电很常见。手机中有大量传感器在不断采集数据如位置相关、摄像头相关、速度相关、姿态相关的传感器相关算法调用频率也需要优化降低。案例四很多APP会频繁上报数据如果频率超出预期的多也会影响到电量同时也会带来流量异常的专项问题。以金融类APP为例什么场景的耗电可能性比较大? 很明显实时行情、交易咨询算是一类典型。用户会不断拉数据不断去互动导致耗电概率高。最后耗电的测试场景和内存测试一样也要分为前台操作耗电和后台挂机耗电的场景。流畅度测试我们先看一张经典的图手机屏幕当年是一秒钟刷新24次连续的动画就应该是每一帧都有一些不同如果GPU绘制卡壳了就导致当前的这一帧保持不变视觉上就是“跳”了一帧形成卡顿。补充一个知识用FPS来形容流畅度是不精确的FPS只是一个客观的刷新动作它不能反映“绘制图片没有完成”的问题所以我们会用英文单词junk来描述图片未完成刷新的卡顿junk率就是每秒钟junk次数除以总帧数这体现了卡顿的严重程度。我们还可以把发生卡顿的时间片总长度除以总时间结果称为shutter率也定量体现了卡顿情况。还有一个和junk含义相反的概念单词是smoothness即流畅度如果完全没有卡顿smoothnessSM就是满分。以60Hz显示设备为例如果一秒junk了5次那就是丢了10帧SM分数就是60-1050。不流畅产生的原因第一 UI层过度绘制同一个UI层内容被重复绘制。第二UI布局不合理控件继承结构过于复杂。如果用更少的次数就能调用到叶子节点控件UI流畅度也能提升。第三代码导致的流畅度问题。我们可以使用一个古老的工具Link来扫描出哪些流畅度相关的代码可以优化。流畅度分析工具安卓平台的流畅度主要看渲染的线程GPU是专门用来绘图的芯片而主线程的阻塞必然会发生一些卡顿行为。建议大家尽量选择高精度的测试工具前面提到一秒钟60赫兹的绘制频率如果精度不够是难以定位到准确的卡顿地方的。推荐谷歌的实时分析工具Systrace直到今天也是最常用工具能够系统化地看到各个线程的渲染情况。第二个应用级工具是Android studio里的GPU profile和CPU profile帮助我们发现负载过高的慢线程。第三个工具是安卓9引入的系统级综合监控Perfmon从中也能看到一些容易发生卡顿的事件。iOS平台的流畅度分析则依赖于XCODE生态它提供了称为“call animation”的能力模板我们从中观察渲染性能、触控延时、GPU负载等指标它们和卡顿现象有密切关系。另外还有metal system traceXcode debug option这两个工具分别可以做GPU的深度分析和可视化调试。以典型金融APP场景为例可以重点分析实时行情页的K线图渲染耗时是否因复杂路径阻塞绘制交易页的按钮点击延迟如主线程被数据库查询占用如何优化流畅度根据过往的多年实践经验做一个方法提炼:方法一按照Link扫描代码提供的建议进行优化简单粗暴。方法二用traceview工具看卡顿的地方看哪个函数占用了更多的CPU时间片看主线程IO操作次数频繁也很容易造成卡顿。我们还经常通过systrace获得运行线程和API执行信息通过设置计时器看看程序中的具体运行时间看看是否有重复绘制。方法三看磁盘的IO吞吐这也可能给页面绘制带来一些渲染过慢的问题这需要我们采集磁盘读写信息来核实。方法四有些流畅度问题来自于快速滑动场景。如用户在快速滑动屏幕时机器性能不够可能产生页面加载不及时的情况。我们可以采取异步加载的技巧即在滑动过程中不要实时地显示图片而是事后再加载。方法五针对前面布局层次过于复杂引发卡顿那我们就主动减少布局层次以及尽量复用控件去掉多余的背景颜色。不要在线程以外再去操作UI。方法六最重要的仍然是避免死循环这是低性能的万恶之源。流量测试这些年随着流量越来越便宜我以为流量测试没有那么重要。但询问APP开发leader对方说流量测试还是非常重要的一是不能传跟用户无关的废信息避免让用户担心传送隐私数据包二是不能重复传输信息。在十年前APP流量测试是很重要的。当年鹅厂有一个性能监控SDK出了一个BUG导致用户手机一天上报了7个G的流量都是重复的crash信息在当时算是不小的事故了。大量传输重复数据也会导致耗电异常。测试方法可能有流量测试经验的读者很少其实方法也挺简单。方法一抓包如TCPDump。首先建议关闭其他APP的联网避免我们采集到的数据包是其他APP干的。其次根据被测APP的UID获取收发包的数量抓下来分析。方法二长时间测试。因为流量测试往往需要一个很长的观测时间。我们可以选择一个24小时的挂机或者重复各种操作通过后台的固定策略去触发一定事件避免只做“纯待机”测试。比如对一个交易APP会定时做一些用户常见的下单和卖单操作再检查流量是否正常。具体用到的工具有安卓平台上的TCPDumpWireshark的抓包分析另外安卓studio profile也有网络相关的数据。iOS平台封闭性比较高不会提供太多网络包的拆解能力所以我们会用到第三方工具如Charles还有XCODE instrument提供的network template模式都能分析网络流量中的信息。流量优化思路提炼出以下流量优化思路多年经验总结条条经典一 对协议中的重复内容进行排重因为很多协议消息会传递很多重复信息。我们要么降低信息发送的频次要么就把协议内容做好归并减少信息传递的重复率。二 预取逻辑只在WIFI环境执行。对于不需要实时上报的信息可以降低在非WIFI环境中发送的频次。三 很多消息都是服务器动态下发的我们可以对服务器增量消息做一个配置指定特定场景才需要下发消息避免一天到晚发送消息同时还能保持重要的连接达到最高的性价比。四 很多网络请求是可以合并的以减少发送的总次数。五 长连接。对某些应用而言服务端需要和客户端保持长连接对于PUSH消息的机制而言相对省流量。六 流量的精细化监控。分析消息的整体数据是否合理且安全避免敏感信息被发送出去也可以针对域名去细分流量并判断协议发送逻辑和频次是否合理。补充- GT工具我们之前团队自研的开源工具GT名气不凡它能够在各项APP专项测试中大放异彩不但能精准测试各种指标还能让开发非常方便的进行性能参数调优。下次再具体介绍GT以及其他几个重要专项指标优化安装包大小弱网络响应速度等。