其中一个json块数据格式参照如下:
{
"Threads" : 12,
"UnixSyscalls" : 14314,
"Command" : "com.baidu.ime.Ba",
"VirtualSize" : 718213120,
"ContextSwitches" : 5774,
"Ports" : 166,
"PageIns" : 4881,
"Shared" : 12976128,
"PPID" : 1,
"CPUUsage" : 0,
"UID" : 501,
"TotalMicroSeconds" : 307788,
"Timestamp" : 1421818303.125269,
"VPrivate" : 29028352,
"Date" : "-01-21 13:31:43:125",
"MessagesSent" : 4042,
"PID" : 721,
"TotalSeconds" : 1,
"Private" : 9338880,
"PGID" : 721,
"MachSyscalls" : 7186,
"ResidentSize" : 39362560,
"Architecture" : 16777228,
"Faults" : 19274,
"MessagesReceived" : 1709
}
3. 统计ResidentSize、VirtualSize字段,使用python的matplotlib图形库生成内存变化图表。
然而对于内存测试,如果你觉得只是需要跟踪app的内存使用情况,那么你就错了。一套完整的内存管理测试方案需要关注的点其实还有很多,比如使用Leaks分析内存泄漏,使用Allocations分析内存浪费,使用Zombie分析野指针,使用VMTracker测试虚拟内存,代码中是否仍使用ARC机制等等。
其中关于虚拟内存的测试或许是最容易被忽略的,浏览器就曾经发现过实际内存占用不高,但虚拟内存上涨很快,从而导致app因为内存不足被系统kill的问题。
那么如何分析app的虚拟内存呢?我们可以通过Instruments的VM Tracker进行查看。VM Tracker主要用于记录app的虚拟内存分配,该模板会显示app中分配了多大的虚拟内存空间,其中多少是Dirty的内存,有多少是被映射到实际物理内存中,并且可以显示详细的虚拟内存分配情况。
图6 VM Tracker查看虚拟内存
关于上图中的dirty size,这里介绍一下dirty & clean的概念。
在程序使用的内存page中,iOS区分两种内存,一种为clean,一种为dirty。
clean page的概念为所有可以被废弃并且重新生成的page,例如二进制代码等从磁盘读取的文件,例如未曾读写过的page,或者被标识为可擦除的内存等。
dirty page的概念为无法重新生成的page,即app生成的,并且已经写入过的page,例如使用malloc分配的heap内存,全局变量,stack内存等。
当系统发现可用内存较少时,会将resident中的clean page进行清除,当有需要使用时直接从磁盘读取就行。系统不能卸载掉dirty memory,因为iOS是没有内存置换机制的。当dirty memory达到一个上限时,应用会被kill,由系统回收内存。
说到上限,这里可能有人会问,在iOS设备中打开很多app后,打开被测app,该app占用内存的上限能达到多少呢?我们可以通过demo app,手动malloc内存,也可以通过instruments查看,观察内存警告时,App被kill时的日志输出。
下表列出了对各种设备进行测试后得到的数值,供大家参考。
图7 不同设备内存占用限制
四、CPU测试
CPU测试的方法和内存较为类似,可以通过Instruments中的Activity Monitor模板查看,也可以通过客户端打点的方法获取。
在浏览器性能测试中,重点模块的CPU测试还需要针对不同机型不同Architecture指令集进行兼容。例如在iPhone浏览器播放内核库的测试中就需要兼容armv7、armv7s、arm64、i386、x86-64五种CPU上都经过测试。
五、流畅度
对于浏览器而言,会存在着较多网页浏览、动画显示等操作,这时是否存在卡顿对于用户体验就显得较为重要。关于流畅度的测试我们可以通过使用instruments的core animation工具,浏览网页或加载动画,查看fps的帧数。一般而言,当用户操作时,如果fps帧数小于40,则说明存在卡顿的情形。
图8 Core Animation查看fps帧数
22/2<12
如果觉得《什么软件测试iphone性能 iPhone浏览器性能测试》对你有帮助,请点赞、收藏,并留下你的观点哦!