说实在的我是不想现在说太多，这样我觉得我这个书写的意义就不大了。索性不出版了...
我上周帮助公司也做了一下app的
性能测试，整个过程历时一天半，当然仅仅是针对测试，燃烧了我大半小宇宙。
首先现在移动应用的性能测试一般分成三种测试的方向，或许说是找基线的方向： 1. 先对于竞品进行测试，从而进行对比
2. 经过测试，团队讨论得出一个大家认可的数据，从而变成基线
3. 在系统，应用等限制中找到一个基线，打比方说比如某些应用的画面需要60fps的帧率进行平滑的渲染等
而无论是哪种得到数据并非非常容易，性能测试往往与应用逻辑，架构，业务牢牢的绑定。
Android和ios的内存泄漏也许是很多人关心的一个方面。在此之前当然我们应该先进行静态的代码扫描，find bugs，lint，code Analysis等。内存泄漏其实并非一定有什么基线，在我看来每个不同类型的应用其基线可能都是不同的，然后内存泄漏现在常用的方法如下：
1. 对应用进行”Cause GC”操作，查看object data的走势，如该数值持续上涨说明有内存泄漏的可能。
2. Android获取hprof文件。其一，在进行压测之后获取hprof使用MAT进行分析。其二，可以在某些重要业务场景前后分别去Dump HPROF，从而对比前后某些对象是否有重复引用等
3. ios的话要请教中国ios之父了...我目前还是只是用instruments自带的一些工具在业务场景中进行查看。
4. dumpsys也不失为一个比较简单的方法，但是就是比较难定位问题在哪里
当然我之前也一直推崇的systemtrace以及gnxinfo也是很不错的性能测试工具。其运用在自己要测试的场景中就能够得出很精准的数据，包括应用的启动，包括绘制函数方法的耗时等，报告如下：
其他也有电量，流量等，这类其实现在现成的测试app也有。我们自己要去写个也不是什么难事，比如写一个很傻的activity，然后启动几个监控的service就可以了。通过系统api都是能够获取到我们想要的数据的，当然
百度等公司还是会用万用表来进行电量测试，我表示我肯定做不到。部门代码如下：
当然我上周在做的时候，顺便让我们测试的同学把关键业务做了下，然后生成的code coverage报告也让开发协助测试增加了很多有用的
测试用例。这也是我觉得真心不错的一个发展方向。
English » | | | | | | | | |
Text-to-speech function is limited to 100 characters