缘起

老板交代需要针对新的大版本进行专项测试,于是乎开始了 android 端的测试

随着

软件的安装运行,针对 cpu 的验证开启,突然发现不对,对于应用我并没有进行任何操作,界面一直停留在登录页面,为何 cpu 使用率如此之高呢?


思考

界面无任何操作,难道是后台不停的在进行交互么?

验证


查看内存使用,并无明显异常


查看日志,嘿,有点意思


为了进一步确认问题,监控流量看看,问题基本可以确认

问题得到确认,那么接下来是否可以提交开发了?

对于进一步的人来说,当然是 no 了

分析

通过日志分析及流量分析发现,后台存在一定频率的做上传动作,俗称心跳,查看了下时间为 5s,总所周知,这个一般都是由服务端控制,那么我们是否可以通过修改服务端的频率来控制从而解决此问题呢

动手

通过查询服务端的配置项,对于心跳的频率进行了调整为 15 分钟一次,再次查看 cpu 的使用率,大吃一惊,cpu 不降反而升

什么鬼
难道是服务端的配置项没生效?客户端存在此控制?

为了验证疑惑,再次打印日志来查看频率,结果是

果然
服务端的配置没有生效!!!!

为何服务端的配置没有生效?难道客户端没有从服务端拉取最新的控制选项?还是需要某种机制来触发?
回想一下修改服务端的配置后,貌似我的测试客户端并没有重启?会不会和此有关系?
于是乎
重启客户端,再次查看日志,三分钟过去了,没有再次打日志,终于服务端的配置生效了

但是
问题解决了么,怀着忐忑的心再次查看 cpu 的消耗,无任何改变!!!!!

难道和心跳无关?回想一下此前测试的前一个版本 cpu 并没有这么高的消耗,上个版本峰值都不超出40%

看了下本版本和上版本的功能点对比,只是增加了一个 xx 轨迹,这个就是我们当初查看日志发现的心跳,那么问题必然出现在此,但为何单纯的修改心跳频率并不能修复 cpu 的消耗过高的问题呢,是否还有未知?

不死心的我继续往下走
内存对比
这次我们再次打开一个系统浏览器应用,看到 cpu 的消耗大约在 50%,但是被测应用还是在 100% 以上,对比分析内存,突然发现被测应用的虚拟机内存消耗很高啊

难道是虚拟机一直在运行吃高内存导致 cpu 居高不下?
新增的功能的进程也是挂在虚拟机运行?

再次查看应用的内存使用,发现果然存在 dalvik 里面的内存不释放!

到此
问题确认

后记

查询应用的源码,存在 2 个死循环,第一个是上传数据机制,第二个是查询本地数据机制 ╮(╯_╰)╭


↙↙↙阅读原文可查看相关链接,并与作者交流