其中一个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" : "2015-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帧数
