Changed Objects Count：类对象实例变化数（增加数+减少数）
New Count：类对象新增数量
GC Count：类对象释放数量
New-GC=常驻，常驻理想状态下不应存在，如果必须存在请控制在合理范围内（1-20）
TIPS:内存泄露查找诀窍：闭环一次和多次对比操作，看对象变化
原则上，反复操作，内存应该起伏稳定在一个区间内，如果出现曲线持续上升，就肯定存在内存泄露（但要尽量排除外来干扰，比如手Q被动接收各种消息）
2）方法二、详细分析。取dump（a）、dump（c）、dump（d），在dump（d）上finder->TwoExecutionThreeDump，在-2S中指定dump（c），-1S中指点dump（a）
FirstInc、SecondInc分别为第一次使用和第二次使用之后的内存增量，两次都有大量增量的对象，着重分析对象作用和引用者，确定增量是否合理，此处需要代码能力和对源码的熟悉程度较强。
6．3 电量测试
合流标准（建议安装release包）：
6.3.1 挂机5分钟CPU<0%
0）该项检测目的：切后台、灭屏，9成9的用户应该都是希望该程序就不要再耗我的电了，CPU持续占用的apk必然会上耗电榜。
apt选中apk进程，指定监控CPU，挂机5分钟后观察CPU曲线
有时并不能完美的达到0%占用，比如手QMSF就一直都在工作，来消息CPU就波动下，因此请酌情分析。
6.3.3 合理使用wakelock
0）该项检测目的：wakelock会锁定屏幕，防止手机自动休眠，亮屏是非常耗电的。
1）项目接入xcode可静态扫描wakelock的不合理使用
2）未接入xcode可如下分析：adb shell cat /proc/wakelocks
原则上长时间停留在当前场景，不存在长时间未释放的wakelock
6.3.4 避免无端电量消耗
0）该项检测目的：新开界面耗电时长控制（音视频除外）经过时间1分钟，CPU < 50%单核主频1G)，即使长时间使用功能也要保证更长的续航时间。
1） apt选中apk进程，指定监控CPU，进入场景界面1分钟后观察CPU占用
6.4 流量测试
合流标准：
6.4.1 流量上报
0）该项检测目的：新增业务要上报流量，通过大量用户数据分析新增业务带来的平均新增流量，及时发现流量风险并后续优化
1）与产品开发确认上报，一般开发自测
6.4.2 非WIFI不能静默拉取资源（>200KB）
0）该项检测目的：移动网络静默拉取资源>200KB要么让用户知晓并同意，要么不拉取，静默拉取比如用户主动访问网页，该网页后台静默下载首屏之外的数据。
1）PC端安装ATS，监控指定apk进程，程序稳定后，入口处流量记录清零，进入场景页面，数据加载稳定后，查看ATS实时流量，首屏<200KB，就不用分析该项，如果超过，那么首先就不符合关键路径单次操作不能>200KB的规范，详细分析需要一键抓包工具（见附件）+wireshark深入分析，如下介绍
Wireshark点击pcap包可查看终端所有的请求，包含协议，理论上完整的流量就是pcap包的大小
2） Wireshark——待补充
6.4.3 大于100KB的资源增量拉取
0）该项检测目的：超过100KB的资源增量拉取，避免网络不稳定时导致资源总是拉取不下来，不断重试浪费流量。
1） fiddler热点抓包，分析>100KB的资源是否增量拉取，如HTTP协议包响应码为206
6.4.4 资源无重复拉取
0）该项检测目的：需要反复调用的资源，设置缓存，避免重复调用带来流量浪费
1）方法一、Fiddler热点抓包，分析一次访问是否重复拉取了相同资源
2）方法二、一键抓包工具+wireshark，使用wireshark打开pcap，在菜单栏点击File 依次选择Export Objects ->HTTP，弹框中选择Save All按钮，保存所有http请求对象到目录，查看是否有重复文件，同时也能查看是否存在过大图片资源问题。
方法二还可以这样分析，用wireshark直接查看http get/post 包来查看，现在Filter里出入http后按回车过滤出所有http包，然后点击Info栏按请求信息排序，然后查看是否有相同的请求URL