一、APP测试点
1、移动App测试与传统台式机测试相比有一定的复杂性。这些复杂性可以被分类为：
环境（大量的设备，各种移动OSs，适应频繁OSs变化） 。
设备（触摸式和非触摸式设备，有限的内存容量，电池耗电量） 。
网络（不同的网络和运营商，在不好或无网络的情况下的App行为，离线支持） 。
可用性（方向，触摸，多触摸，缩放，分页和导航的局限性，各种干扰，如来电，来电短信，闹钟，和低电量警报） 。
2、移动App崩溃原因【一些崩溃原因（排名不分先后）】：
1、设备碎片化：由于设备极具多样性，App在不同的设备上可能有表现不同。
2、带宽限制：带宽不佳的网络对App所需的快速响应时间可能不够。
3、网络的变化：不同网络间的切换可能会影响App的稳定性。
4、内存管理：可用内存过低，或非授权的内存位置的使用可能会导致App失败。
5、用户过多：连接数量过多可能会导致App崩溃。
6、代码错误：没有经过测试的新功能，可能会导致App在生产环境中失败。
7、第三方服务：广告或弹出屏幕可能会导致App崩溃。
3、一些通用的触发移动App崩溃的测试场景：
1 验证在有不同的屏幕分辨率，操作系统和运营商的多个设备上的App行为。
2 用新发布的操作系统版本验证App的行为。
3 验证在如隧道，电梯等网络质量突然改变的环境中的App行为。
4 通过手动网络从蜂窝更改到Wi-Fi ，或反过来，验证App行为。
5 验证在没有网络的环境中的App行为。
6 验证来电/短信和设备特定的警报（如警报和通知）时的App行为。
7 通过改变设备的方向，以不同的视图模式，验证App行为。
8 验证设备内存不足时的App行为。
9 通过用测试工具施加载荷验证App行为。
10 用不同的支持语言验证App行为。
二、Android性能
Android 性能测试，跟 pc 性能测试一样分为客户端及服务器，但在客户端上的性能测试分为 2 类：一类为 rom 版本的性能测，一类为应用的性能测试
对于应用性能测试，包括很多测试项，如启动时间、内存、CPU、GPU、功耗、流量等。 但针对 rom 版本的性能测试，一般关注功耗。对于启动时间、内存、cpu 测试大家一般都使用外部提供的第三方工具来辅助测试，如GT、安测试等、这些工具的原理都是基于调用 android 底层的一些 api 来获取到测试所用到的值，当然我们也可以采用其他方法，如使用 android 本身提供的一套 adb 即可完成上述测试。对于 GPU、功耗、等测试来说，用第三方工具测试得到的数值一般都不是很准确，这个时候我们需要引入硬件来进行测试了，GPU 可以采用高速相机来进行测试，功耗可以使用万用表或安捷伦电源仪来进行测试（ps：有硬件动手能力的可以DIY一个小板进行）
rom 版本的性能测试，rom 版本一般就关注功耗测试，不过 rom 版本的功耗测试跟应用的功耗测试会有所差异，当然只是用例设计方面的差异，工具仍然采用安捷伦电源仪进行
1、启动时间
关于应用的启动时间的测试分为三类：
1. 首次启动 --应用首次启动所花费的时间
2. 非首次启动 --应用非首次启动所花费的时间
3. 应用界面切换--应用界面内切换所花费的时间
|
首次启动时间(平均值) |
1.首启条件 |
1、 长按home键（不同手机按键不同）打开“内存使用情况”列表，点击清除应用； |
|
非首次启动时间(平均值) |
1.非首启条件 |
1、 点击home键，点击桌面应用图标，启动应用，应用完全启动后点击home键； |
|
应用内切换响应速度 |
1、 启动应用，进入应用主界面； |
做启动时间的测试一般我们分为2类，一类为使用软件来测试，一类为使用硬件来测试。
1.1软件测试的方法
可以使用 android 提供的 DisplayManager 来获取 activity 的启动时间
●通过日志过滤关键字 Displayed 来过滤所有 activity 所打印的日志。通过 adb logcat>/address/logcat.txt 然后使用 find “Displayed” /address/logcat.txt>/newaddress/fl.txt
●通过 activity 名来过滤获取所测应用 find “ActivityName” /newaddress/fl.txt>/newaddress/last.txt
●通过计算 activity 的时间之和即可
除了 DisplayManager 的打印时间方法，还有通过 am 获取启动时间。
1.2硬件的测试方法
1）测试准备：
1、手机处于“开发者模式”。
2、点击设置--开发人员选项--找到“窗口缩放、过渡动画缩放、动画程序时长调整”三个选项，分别关闭动画。
2）测试方法和步骤：
主要通过手机录像来实现，具体操作步骤及注意事项如下：
1、用两部手机测试，A手机安装正确的版本作为测试机，B手机用来拍照，
2、将测试手机整个屏幕置于录像视野内，以便在数帧时候观察屏幕变化状态；
3、测试过程中如果出现录像模糊的情况，应等待清晰后再开始进行点击屏幕的操作；
录制视频的手机进行如下设置：
1、点击更多
2、选择慢动作效果进行视频录制
3、点击左下角倍数设置按钮，模式设置为8X（240帧/秒，也可以选其他模式）
a、首次启动时间测试方法：
1、安装好apk后，设置-应用管理-相关apk-清空缓存-强行停止；
2、点击桌面应用图标，启动应用；
3、待应用程序完全加载后，重复步骤1、2；
4、共测试4组，求平均值。
b、非首次启动时间测试方法：
1、点击home键，点击桌面应用图标，启动应用，应用完全启动后点击back键退出应用；
2、点击桌面应用图标，启动应用；
3、界面完全展开后，点击back键，然后重复步骤2；
4、共测试4组，求平均值。
c、数帧方法和注意事项
将视频在VirtualDub.exe这一工具中打开，（鼠标右键可以调节区域大小）按键盘上的→向右箭头，观察视频变化，记录手指离开图标的前一帧的时间，如图可以看出手指离开了图标，按一下键盘上←向左箭头，记录时间。 记录下起始时间，单位是ms。当界面完全展开时，记录下此刻时间，记为终止时间。
起始时间和终止时间的判断规则如下：
1、起始时间：手机离开图标的前一帧作为应用启动的起始时间；
2、终止时间：一般认为是应用界面在手机屏幕上全部清晰显示的时刻；如果页面需要加载，考虑到网速问题，这时候大体框架出现即可记为终止时间。
3、另外我们选择数据的时候要选择时间差相差较小的五组数据来计算平均值获得应用的平均响应时间。
2、内存
移动端关注的是内存消耗，这个测试目标是为了让应用不占用过多的系统资源且及时释放内存，保障整个系统的稳定性。关于内存测试在这里我们需要引入几个概念，
内存消耗测试主要是测试应用在正常使用过程中占有的系统资源，确保应用不会占用过多的系统内存且能及时释放，以保障整个系统性能的稳定性。
VSS：Virtual Set Size 虚拟耗用内存（包含共享库占用的内存），对内存真实消耗的作用很小；
RSS：Resident Set Size 实际使用物理内存（包含共享库占用的内存），共享库是当前进程独占时，RSS=PSS；
PSS：Proportional Set Size 实际使用的物理内存（比例分配共享库占用的内存），各进程PSS总和才是真实的内存占用；
USS：Unique Set Size 进程独自占用的物理内存（不包含共享库占用的内存）。怀疑某个程序有内存泄露可以查看这个值是否一直有增加
一般来说内存占用大小有如下规律：VSS >= RSS >= PSS >= USS
空闲状态：指打开应用后，点击home键让应用后台运行，此时应用处于的状态叫做空闲。
中等规格：指的是对应用的操作时间的间隔长短不一，中等规格时间较长，
满规格：指的是对应用的操作时间的间隔长短不一，满规格时间较短，
存在很多测试子项，如下清单所示
1.空闲状态下的应用内存消耗情况
2.中等规格状态下的应用内存消耗情况
3.满规格状态下的应用内存消耗情况
4.应用内存峰值情况
5.应用内存泄露情况
6.应用是否常驻内存
7.压力测试后的内存使用情况
|
APK内存泄漏-特殊场景 |
1.反复进入-》退出应用，次数不少于20次 |
1.无内存泄露 |
|
APK内存泄漏-空负载-前台空闲 |
1、进入应用主页面，前台静置10分钟 |
1.记录测试过程中的内存占用稳定均值和峰值 |
|
APK内存泄漏-空负载-后台空闲 |
1、进入应用主页面，后台静置10分钟 |
1.记录测试过程中的内存占用稳定均值和峰值 |
|
APK内存消耗 |
1、10分钟内快速遍历应用1、2级功能，检测整个过程的内存情况 |
1.记录测试过程中的内存占用稳定均值和峰值 |
|
APK进程常驻内存情况-开机 |
1、测试手机重新启动，静置 |
|
|
APK进程常驻内存情况-使用完毕 |
1、运行应用应用->正常操作 |
3、使用完毕后主动关闭 |
现在关于android内存测试的方法基本分为几类，
1.使用 android 本身提供的 ActivityManager.MemoryInfo() 方法获得（此方法请百度或google）此类第三方工具有如网易的Emmagee、安测试、腾讯的GT等
2.使用 android 提供的 adb shell dumpsys meminfo |grep packagename >/address/mem.txt 来获取
3.使用 android 提供的 procrank
这里我们详解一下 procrank 方法（批处理）
首先去google获取procrank、procmem、libpagemap.so 三个文件 .
然后push文件，执行 adb push procrank /system/xbin adb push procmem /system/xbinadb push libpagemap.so /system/lib
赋权 adb shell chmod 6755 /system/xbin/procrank adb shell chmod 6755 /system/xbin/procmemadb shell chmod 6755 /system/lib/libpagemap.so ,
在开启工具记录 adb shell procrank |grep packagename >/address/procrank.txt
剩下的就是整理测试数据了
关于内存泄露方面的测试，可以通过几个方面来测试
1.通过monkey压力测试记录内存使用情况，分析数据曲线图及日志情况
2.通过eclipse上的mat+heap来分析存在内存泄露方面的节点
3、CPU
CPU跟内存一样，存在一些测试子项，如下清单所示
1.空闲状态下的应用CPU消耗情况
2.中等规格状态下的应用CPU消耗情况
3.满规格状态下的应用CPU消耗情况
4.应用CPU峰值情况
CPU的测试方法分为几类
1.使用android提供的adb shell dumpsys cpuinfo |grep packagename >/address/cpu.txt来获取
2.使用top命令 adb shell top |grep packagename>/address/cpu.txt 来获取
4、GPU性能
GPU在移动端性能测试领域都知晓，但对于应用的GPU该如何来测试呢，我们先引入几个名词：
1过度绘制：是指界面显示的 activity 套接了多层而导致。
2帧率：是指屏幕刷新率。
3帧方差：是指屏幕刷新帧间隔方差
GPU的测试目前业界使用的均为硬件来进行，软件测试的数据相较硬件差异较大。对于不同机型需设定不同的帧率及帧方差的测试标准。对于GPU 的测试主要包括以下几个测试子项
1界面过度绘制
2屏幕滑动帧速率
3屏幕滑动平滑度
过度绘制
|
严格模式下apk操作无红框 |
1、测试样机为Android5.0以上的手机 |
1、【设置】→【开发人员选项】→打开“严格模式已开启”，在空规格下遍历apk界面&功能测试 |
1、对于所有的界面&功能遍历操作,上下滑动页面和页面静止时出现红框闪烁就需要提单跟踪 |
|
界面过度绘制 |
1、测试样机为Android4.2以上的手机 |
1、进入应用应用，观察其所有界面颜色 |
1、不允许存在4x过度绘制（红色区域）；不允许存在面积超过屏幕1/4区域的3x过度绘制（淡红色区域） |
1严格模式操作步骤：
1、【设置】-【开发者选项】-【启用严格模式】；
2、待测应用，对于所有的界面&功能遍历操作,上下滑动页面和页面静止时观察是否有红框出现。
严格模式标准：对于所有的界面&功能遍历操作,上下滑动页面和页面静止时不出现红框闪烁。
2过度绘制操作步骤：
1、【设置】→【开发人员选项】→勾选“显示GPU过度绘制”；
2、进入待测应用，观察界面颜色；
界面颜色含义如下：
没有颜色：表示没有重绘。每个像素只画了一次。
蓝色：1x过度绘制。每个像素只画了两次。
绿色：2x过度绘制。每个像素画了三次。
淡红色：3x过度绘制。这个像素被画了四次。
红色：4x过度绘制。这个像素被画了五次及以上。需要解决。
过度绘制标准：1、不允许存在4x过度绘制（红色区域）；2、不允许存在面积超过屏幕1/4区域的3x过度绘制（淡红色区域）。
屏幕滑动帧速率
FPS即Frames per second。是用于测量显示帧数的量度。测量单位为每秒显示帧数。帧率的高低体现了手机对动态界面的显示能力理想状态每秒展示60帧时人眼感受不到卡顿，1000ms/60帧，即每帧绘制时间不应超过16.67ms。想要让大脑觉得动作是连续的，至少是每秒10-12帧的速度，而想达到流畅的效果，至少需要每秒24帧。这也是为什么电影片源通常都是24帧的原因，不过60帧每秒的流畅度是最佳的，当然超过60帧速的话大部分人还是会受不了的。综上所述，APP需要尽可能的超过24帧/秒，接近60帧/秒的速度，并且在使用的过程中保持这个速率。
a软件测试的方法：
1、在开发者选项中的CPU呈现模式分析中选择adb shell dumpsys gfxinfo，则adb shell dumpsys gfxinfo命令将输出最近120帧的时间信息，并将其分成几个不同的类别，可以直观的显示各部分的快慢。
2启动应用以后，在应用的页面上做滑动:adb shell dumpsys gfxinfo com.excelliance.dualaid.vend > fps.txt
framestats信息和frame耗时信息通常为2s收集一次（一次120帧，一帧16ms，耗时约2s）。
adb shell dumpsys gfxinfo com.huawei.mycenter reset 重置所有计数器，并重新收集的数据
adb shell dumpsys gfxinfo com.huawei.mycenter framestats
adb shell dumpsys gfxinfo com.huawei.mycenter
3.打开生成的fps.txt，找到Profile data in ms这部分数据。（Android M 版本以上才支持）
Draw:表示在Java中创建显示列表部分中，OnDraw()方法占用的时间。
Process：表示渲染引擎执行显示列表所花的时间，view越多，时间就越长
Execute：表示把一帧数据发送到屏幕上排版显示实际花费的时间。其实是实际显示帧数据的后台缓存区与前台缓冲区交换后并将前台缓冲区的内容显示到屏幕上的时间。
Draw + Process + Execute = 完整显示一帧 ，这个时间要小于16ms才能保证每秒60帧。
gfxinfo：
1记录最近128帧的绘制时间，每帧不同阶段的时间相加，不超过16.67ms就是流畅的；
2若停止不动，app内部也没有刷新处理屏幕的需求，会输出0，有时未开始滑动会直接没有数据输出；
3以上导致了如果app内部也没有刷新处理屏幕的需求，很流畅，但由于实际每秒处理的帧数不多，fps的值可能也会很少；
本方案需要拖动屏幕产生的数据才比较准确，对于需要适配多种机型和版本的情况就不太适合了
b硬件的方法
这里需要引入高速相机，打开高速相机，开启摄像模式，录制人滑动或者扫动被测应用的视频，再通过人工或者程序（VirtualDub、Avidemux）数帧的方法对结果进行计算得到帧率。
对于屏幕滑动平滑度的测试，方法如同帧率测试，唯一的差异就是最后的结果计算公式的差异
手机屏幕正常连续显示两张不同画面时，由于留影的效果，在高速相机下观察得到的手机屏幕变化效果为：清晰——模糊——清晰。又手机屏幕采取逐行扫描的方式进行显示，因此如果界面上的某一处出现了“清晰——模糊——清晰”的变化过程，则说明此帧显示正常；如果屏幕未能正常显示两帧，即界面未发生变化，则界面在高速相机下效果为没有明显的清晰-模糊变化。
1滑动帧率测试方法：
1、保证测试的界面内容超过一个屏幕；
2、高速相机在被测手机的正上方开始摄像；
3、手指从手机的任一端，滑动2/3以上屏幕，停顿1~2秒钟，然后以反方向滑动2/3以上屏幕，上下各滑动5次，期间手指不离开屏幕；
4、测试结束，将视频放置到分帧器中处理；
5、利用VirtualDub.exe分帧器将视频打开。点击键盘中的向右箭头，一直到手指接触到屏幕。当手指接触到屏幕后，一帧一帧的观看屏幕图像，记录屏幕变模糊的那一刻 Frame 数值，之后连续按三次向右箭头，4帧一组测试。之后每4帧一组数据，观察图像的清晰模糊变化。当一个范围内清晰模糊没有明显变化时，判断为结束，记录下此刻的Frame 数值。
2扫动帧率测试方法：
1、保证测试的界面内容超过一个屏幕；
2、高速相机在被测手机的正上方开始摄像；
3、手指从手机的任一端，扫动2/3以上屏幕，停顿1~2秒钟，然后以反方向扫动2/3以上屏幕，上下各扫动5次，扫动后手指离开屏幕；
4、测试结束，将视频放置到分帧器中处理；
5、同样利用分帧器将视频打开，前期操作都一样，记录的数值是图像变模糊的前一帧数据，比如654帧时图像变模糊，那么我们记录653为起始帧，之后连续按向右箭头两次，653/654/655/656 这4帧变为一组数据。之后的操作和滑动一样，4帧一组观察图像的清晰模糊变化。
3帧率计算方法：
以240帧的速率对手机屏幕进行摄像，则录像中的4帧相当于手机上的一帧。如果前进4帧，界面某处出现清晰-模糊变化，则为正常刷新；如界面没有明显的清晰-模糊变化，则出现丢帧。手机理论帧率为60fps，则:实际帧率=实际帧数/理论帧数*理论帧率（60）
如视频中界面起始帧数为284，终止帧数为475。则在滑动过程中视频一共经历191帧，理论手机刷新应为191 /4=47.75帧，而实际刷新46.75帧 （丢了1帧），这本次滑动的实际帧率为：
实际帧率=46.75*60/47.75=58.74 fps
4数丢失帧：
鼠标点击软件界面左方向按钮或按动键盘左方向键，每四次记为一帧，如果在这四次中，画面一直保持清晰，则记为丢失一帧；如果四次中，画面有模糊到清晰的变化，则正常。
5注意事项：
1、起始帧和终止帧必须是奇、偶，或者偶、奇。比如起始帧是543、那么终止帧就是550，比如起始帧是542，那么终止帧就是549；
2、在操作过程中，最好不要操作到底部或者顶部，在中间范围内进行滑动和扫动操作最好。
5、流量
流量测试，同样需要引入几个名词。中等负荷：应用正常操作。高负荷：应用极限操作
流量测试包括以下测试项：
- 应用首次启动流量提示
- 应用后台连续运行 2 小时的流量值
- 应用高负荷运行的流量峰值
- 应用中等负荷运行时的流量均值
流量测试一般都是用软件来进行的，这里我们一般分为2类：
- 采用市场提供的第三方工具来进行测试，如流量宝之类的
- 自研工具进行测试
自研工具进行测试一般包含 2 类方法，
- 通过
tcpdump抓包，再通过wireshake直接读取包信息来获得流量 - 首先获得被测应用的
uid信息，可以通过adb shell dumpsys package来获取 然后在未操作应用之前，我们可以通过查看adb shell cat /proc/uid_stat/uid/tcp_rcv 和adb shell cat /proc/uid_stat/uid/tcp_snd获取到应用的起始的接收及发送的流量，然后我们再操作应用，再次通过上述 2 条命令可以获取到应用的结束的接收及发送的流量，通过相减及得到应用的整体流量消耗
6、功耗
功耗测试主要从以下几个方面入手进行测试：1测试手机安装目标APK前后待机功耗无明显差异。2常见使用场景中能够正常进入待机，待机电流在正常范围内。3长时间连续使用应用无异常耗电现象。功耗测试的方法分为两类，一类为软件测试，一类为硬件测试。
a软件测试一般分为2类，
1就是自写工具进行，这里一般会使用3种方法：第一种基于android提供的PowerManager.WakeLock来进行，第二种比较复杂一点，功耗的计算=CPU消耗+Wake lock消耗+数据传输消耗+GPS消耗+Wi-Fi连接消耗，第三种通过 adb shell dumpsys battery来获取
b硬件测试
一般使用万用表或者功耗仪进行测试，使用功耗仪（Agilent（安捷伦））测试的时候，需要制作假电池来进行的，有些不能拔插电池的手机还需要焊接才能进行功耗测试
|
关闭数据业务 空载待机电流 |
1、测试样机恢复出厂设置； |
1、按power键灭屏，测试空载待机30分钟电流； |
|
开启数据业务 空载待机电流 |
1、测试样机恢复出厂设置； |
1、开启数据业务，如果应用需要联网，需要在设置-》应用联网管理，关闭其他应用联网开关，同时限制后台移动数据； |
|
静态IDEL功耗 |
1、测试手机无后台应用运行 |
1、在桌面无图标一屏，测试3分钟亮屏电流。 |
|
关闭数据业务 应用待机电流 |
1、测试样机恢复出厂设置； |
1、安装测试应用，并开启应用放后台运行； |
|
数据业务 应用待机电流 |
1、测试样机恢复出厂设置； |
1、开启数据业务，如果应用需要联网，需要在设置-》应用联网管理，关闭其他应用联网开关，同时限制后台移动数据； |
|
单次被动类业务电流测试 |
1、测试样机恢复出厂设置； |
1、启动应用并将应用放后台运行； |
|
数据加载-数据业务 |
1、测试手机无其他后台应用运行 |
1、从设备桌面点击应用icon 2、记录从开始进入首页到加载完成首页的亮屏平均电流 |
|
心跳电流测试 |
1、测试样机恢复出厂设置； |
1、启动应用并将应用放后台运行； |
|
wifi应用待机电流 |
1、测试样机恢复出厂设置； |
1、打开数据业务； |
|
wifi单次被动类业务电流测试 |
1、测试样机恢复出厂设置； |
1、开启wifi，并连接热点； |
|
数据加载-WiFi |
1、测试手机无其他后台应用运行 |
1、从设备桌面点击应用icon，在账号登录页面登录已在本机同意过协议的账号 |
|
wifi心跳电流测试 |
1、测试样机恢复出厂设置； |
1、开启wifi，并连接热点； |
|
应用唤醒次数测试 |
1、测试样机恢复出厂设置； |
1、启动应用并将应用放后台运行； |
|
应用唤醒时间测试 |
1、测试样机恢复出厂设置； |
1、启动应用并将应用放后台运行； |
三、兼容性测试
Android App兼容性测试是一个比较重要的App评价内容，实际上兼容性测试不仅仅和测试人员相关，在开发阶段就应当着重考虑，因为兼容性问题是除了实现App本身要求的功能后，必须要关注、而且至关重要的一个点。因此，App兼容性是否良好，首先要求App开发人员在开发阶段进行保障，有经验的Android工程师能够在开发过程中保证60%以上用户机型的兼容与适配，经验丰富的工程师几乎能够做到90%以上的兼容适配。当然，由于市场上Android机型出新速度快，系统升级快，一味的追求在开发阶段的兼容适配保障，一方面延误开发进度，另一方面需要较高的开发投入，因此需要做好权衡，这也是后续Android兼容性测试这一关键测试阶段必要存在的原因。
再说到测试阶段，兼容性测试主要是对App在各类机型上的兼容、适配等情况进行测试。搞清楚这一阶段的测试重点后，因此，Android App在进行兼容性测试前，一定要做好其前序测试内容，否则兼容性测试效果将会较差，甚至出现无效测试。
前面说了那么多，重点说下题主的问题，如何做兼容测试。
题主问题主要是两个，一个是兼容性测试如何展开，这是兼容性测试流程问题；另一个是为了兼容性测试，需要配置各类机型手机么，这是兼容性测试的设备基础问题。
我先说下第二个问题，机型配置问题。
Android兼容测试一定要做到宽范围覆盖，如果做不到这个，那么就违背了兼容性测试的目标——测试App在各类机型、系统上的运行是否兼容、适配。
因此，兼容性测试必须要在各个机型、系统上对App进行运行、测试，查看相关UI是否适配、功能是否正常。所以，必须要为兼容性测试配备尽可能多的机型。这是不是意味着，你的公司要去购置各类机型设备？当然不是。对于一般的公司或者开发者，这将会是一大笔开销，为了节约资金而造成进行覆盖率较低的话，则失去了兼容性测试的意义。另外，这也是没必要的，因为往往你就一个或两三个App，为了这少量App测试，而去购置如此大量的设备，无疑是一种资源浪费。除此，还有一个原因，将在兼容性测试如何展开里去说。除此，机型量的多少也是一个权衡的过程，目前，通用的兼容性测试一般覆盖Top100-300的机型，对于实在是小量机型或者老旧机型，用户量非常小，在一定程度上，是否需要覆盖则需要权衡，总的来说，Top排名的手机基本足够。
再来说一下第一个问题，兼容性如何展开？
这是一个经验性的过程，可以去借鉴大型互联网公司的成熟App的测试方法。目前，无论是国际知名App，还是国内知名App，谷歌、Facebook，BAT等，他们都有大量的App对外推出，对于App兼容性要求非常高，因此，他们的做法是非常值得借鉴的。这些公司的兼容性测试，都有一个相同的解决方案，那就是自动化测试框架与平台的实现。通过浏览上述公司在各种大会公布的内容，或者通过论坛知识分享，都能看到，他们不仅有自己的测试实验室，拥有大量的手机，除此，还有一整套的自动化测试平台，来完成兼容性测试。这就是前面说的不用配置如此多的机型的另一个原因，即便是配置足够的机型，你还缺乏一套兼容性测试自动化平台，能养得起一大批测试人员和维护人员。因此，我们可以看到，兼容性测试目前大型互联网公司的做法，通常是采用自动化测试平台，搭建自己的测试实验室，完成如此多的机型测试。
题主目前可能已经面临大量机型采购与测试人力不足的问题吧。如果是大型公司并且有多款App需要测试，那么资金不是问题，测试人力可以扩充，那就可以考虑仿照大型公司，搭建自己的测试实验室，开发自动化测试平台，进行测试。
针对个人开发者、初创公司，以及App比较单一的公司，实际上是不推荐效仿大型公司的做法，这种做法提高了App发布成本，另外还需要扩充开发团队，增加管理成本，最终落实到实际使用上又造成了较大的资源浪费。那如何去完成呢？实际上，目前很多的公司，已经提供了兼容性云测服务，例如TestIn、TestBird，除此，大型公司也对外推出自己的测试工具，比如谷歌、腾讯WeTest、百度MTC、阿里MQC等等，这些平台，我都有去体验使用过，其实不乏一些付费项目。
在这里，我主要推荐給题主腾讯WeTest（WeTest腾讯质量开放平台 - 专注游戏，提升品质），一方面，我自己就是腾讯的，在公司内部，我一直在使用这个平台，另一方面，WeTest背靠腾讯，本是作为内部工具，经验丰富，具有很多优点，确实值得推荐。在这里，针对题主的问题，我主要给题主推荐平台几个功能，一个是兼容性测试，这就是题主所提到的兼容性测试功能，WeTest提供大量机型，拥有完善的自动化测试平台，提供大量云端的真机使用，只需要上传apk，就能够进行简单兼容性测试，并且利用云真机进行调试App。再者，推荐下第三方脚本测试能力，标准兼容测试采用Monkey测试，为了更深入的测试，你可以开发自己的测试脚本，如基于Appium、UIAutomator等，WeTest提供了这样一种机制，让你运行自己的脚本去测试，相当于手机直接交给你去使用。除此，WeTest其他很多服务，也可以体验下，或许就满足你的需求，比如耗电量测试、弱网络测试、性能测试等等。
四、Monkey
1、Monkey简介
Monkey程序由Android系统自带，使用Java语言写成，在Android文件系统中的存放路径是：/system/framework/monkey.jar；system文件夹一般是看不到了，要拥有ROOT权限。Monkey可以运行在模拟器里或实际设备中。它向系统发送伪随机的用户事件流(如按键输入、触摸屏输入、手势输入等)，实现对正在开发的应用程序进行压力测试、稳定性、健壮性。Monkey测试的对象仅为应用程序包，有一定的局限性。Monky测试使用的事件流数据流是随机的，不能进行自定义。可对Monkey测试的对象，事件数量，类型，频率等进行设置。
按照测试类型考虑：Monkey分为手机应用程序的稳定性测试和压力测试。
按照测试对象考虑：Monkey分为单一应用程序测试和应用程序集合测试。
按照测试目的考虑：Monkey分为解决问题测试（忽略应用程序崩溃和异常）和验收测试（不忽略应用程序崩溃和异常）。
Monkey的基本用法
基本语法如下： adb shell monkey [options] <event-count>
如果不指定options，Monkey将以无反馈模式启动，并把事件任意发送到安装在目标环境中的全部包。
adb shell monkey -p your.package.name -v 500
这是一个典型的命令行，它启动指定的应用程序，并向其发送500个伪随机事件：
adb shell monkey -p ctrip.android.view --throttle 500 --ignore-crashes --ignore-timeouts --ignore-security-exceptions --ignore-native-crashes --monitor-native-crashes -v -v -v 100000>e:monkeylogmonkeyScreenLog.log
这条monkey命令在ctrip.android.view中产生10万次伪随机操作（包括触摸、按键、手势等），每次间隔500ms。
monkey测试中常用的命令组合有：
1、monkey -p com.yourpackage -v 500 #简单的输出测试的信息。
2、monkey -p com.yourpackage -v -v 500 #以深度为二级输出测试信息。
4、monkey -p com.yourpackage -s 数字 -v 500 #为随机数的事件序列定一个值，若出现问题下次可以重复同样的系列进行排错。
5、monkey -p com.yourpackage -v --throttle 3000 500 #为每一次执行一次有效的事件后休眠3000毫秒。
6、adb shell monkey -p com.example.findyou 10 #指定一个包
7、adb shell monkey -p com.example.findyou –p com.example.findyou1 -p com.example.findyou2 100 #指定多个包
2、Monkey命令选项
基础参数： -V -S --throttle -p
发送事件的类型：--pct-touch --pct-motion --pct-trackball --pct-nav --pct-majornav --pct-syskeys --pct-anyevent
调试选项：--dbg-no-events --ignore-crashes --ignore-timeouts --ignore-security-exceptions --kill-process-after-error --monitor-native-crashes --wait-dbg
参数: -v
命令行的每多一个-v将增加一级的反馈信息级别。日志的详细程度总共分3个级别，分别对应的参数如下表所示：
日志级别 Level0
示例：adb shell monkey -p cn.emoney.acg –v 100
说明：缺省值，仅提供启动提示、测试完成和最终结果等少量信息
日志级别 Level 1
示例：adb shell monkey -p cn.emoney.acg –v -v 100
说明：提供较为详细的日志，包括每个发送到Activity的事件信息
日志级别 Level 2
示例：adb shell monkey -p cn.emoney.acg –v -v –v 100
说明：最详细的日志，包括了测试中选中/未选中的Activity信息
事件
参数：-s <seed>
用于指定伪随机数生成器的seed值，如果seed相同，则两次Monkey测试所产生的事件序列也相同的。Monkey命令中的-s命令，根据它的工作原理(如果用相同的seed值再次运行Monkey，它将生成相同的事件时序。)，我们可以利用它进行Monkey测试结果的回归验证和问题复现。经过反复验证，seed值不会因手机重启、恢复出厂设置甚至手机版本的升级而改变。它被保存在手机的系统里，当同一部手机使用相同的seed值再次运行，即可复现Monkey的随机事件流。也就是复现Monkey的操作步骤。如果中间插入了其他seed的值的Monkey测试，之前Monkey发送的一系列事件流将不能再复现
adb shell monkey -p cn.emoney.acg -s 10 100
参数：--throttle <milliseconds>
模拟用户操作（即事件间的时延，单位是毫秒，如果不指定该选项，Monkey将不会被延迟）
参数：--pct-｛+事件类别｝｛+事件类别百分比｝
用于指定每种类别事件的数目百分比（在Monkey事件序列中，该类事件数目占总事件数目的百分比）如果在monkey参数中不指定上述参数，这些动作都是随机分配的，9个动作其每个动作分配的百分比之和为100%，我们可以通过添加命令选项来控制每个事件的百分比，进而可以将操作限制在一定的范围内。红色的数字对应下面百分比对应的数字。
不加动作百分比控制使用系统默认分配的情况：adb shell monkey -v -p your.www.com 500
控制事件百分比之后的情况：adb shell monkey -v -p your.www.com --pct-anyevent 80 500
--pct-touch <percent> 0
调整触摸事件的百分比(触摸事件是一个down-up事件，它发生在屏幕上的某单一位置)（点击事件，涉及down、up）
--pct-motion <percent>1
调整动作事件的百分比(动作事件由屏幕上某处的一个down事件、一系列的伪随机事件和一个up事件组成) （move事件涉及down、up、move三个事件）
--pct-trackball <percent>2
调整轨迹事件的百分比(轨迹事件由一个或几个随机的移动组成，有时还伴随有点击)--（轨迹球）
--pct-nav <percent>3
调整“基本”导航事件的百分比(导航事件由来自方向输入设备的up/down/left/right组成)
--pct-majornav <percent>4
调整“主要”导航事件的百分比(这些导航事件通常引发图形界面中的动作，如：5-way键盘的中间按键、回退按键、菜单按键)
--pct-syskeys <percent>5
调整“系统”按键事件的百分比(这些按键通常被保留，由系统使用，如Home、Back、Start Call、End Call及音量控制键)
--pct-appswitch <percent>6
调整启动Activity的百分比。在随机间隔里，Monkey将执行一个startActivity()调用。（从一个Activity跳转到另一个Activity）
--pct-flip <percent>7
调整“键盘翻转”事件的百分比。
--pct-anyevent <percent>8
调整其它类型事件的百分比。它包罗了所有其它类型的事件，如：按键、其它不常用的设备按钮、等等。
约束限制
参数：-p <allowed-package-name>
如果用此参数指定了一个或几个包，Monkey将只允许系统启动这些包里的Activity。如果不指定任何包，Monkey将允许系统启动全部包里的Activity。要指定多个包，需要使用多个 -p选项，每个-p选项只能用于一个包。
参数：-c <main-category>
如果用此参数指定了一个或几个类别，Monkey将只允许系统启动被这些类别中的某个类别列出的Activity。如果不指定任何类别，Monkey将选择下列类别中列出的Activity： Intent.CATEGORY_LAUNCHER或Intent.CATEGORY_MONKEY。要指定多个类别，需要使用多个-c选项，每个-c选项只能用于一个类别。
调试
参数：--dbg-no-events
设置此选项，Monkey将执行初始启动，进入到一个测试Activity，然后不会再进一步生成事件。为了得到最佳结果，把它与-v、一个或几个包约束、以及一个保持Monkey运行30秒或更长时间的非零值联合起来，从而提供一个环境，可以监视应用程序所调用的包之间的转换。
参数：--hprof
设置此选项，将在Monkey事件序列之前和之后立即生成profiling报告。这将会在data/misc中生成大文件(~5Mb)，所以要小心使用它。
参数：--ignore-crashes
当应用程序崩溃或发生任何失控异常时，Monkey将停止运行。如果设置此选项，Monkey将继续向系统发送事件，直到计数完成。
adb shellmonkey -p cn.emoney.acg --ignore-crashes 1000 #即使程序崩溃，Monkey依然会继续发送事件直到事件数目达到1000为止
adb shellmonkey -p cn.emoney.acg 1000 #测试过程中，如果acg程序崩溃，Monkey将会停止运行
参数：--ignore-timeouts
当应用程序发生任何超时错误(ANR Application Not Responding)时，Monkey将停止运行。如果设置此选项，Monkey将继续向系统发送事件，直到计数完成。
adb shellmonkey -p cn.emoney.acg --ignore-timeouts 1000
参数：--ignore-security-exceptions
当应用程序发生许可错误(如启动一个需要某些许可的Activity)时，Monkey将停止运行。如果设置了此选项，Monkey将继续向系统发送事件直到计数完成。
adb shellmonkey -p cn.emoney.acg --ignore-security-exception 1000
参数：--kill-process-after-error
用于指定当应用程序发生错误时，是否停止其运行。如果指定此参数，当应用程序发生错误时，应用程序停止运行并保持在当前状态。应用程序仅是静止在发生错误时的状态，系统并不会结束该应用程序的进程。
adb shellmonkey -p cn.emoney.acg --kill-process-after-error 1000
参数：--monitor-native-crashes
用于指定是否监视并报告Android系统中本地代码的崩溃事件。如果设置了--kill-process-after-error，系统将停止运行。
adb shellmonkey -p cn.emoney.acg --monitor-native-crashes 1000
参数：--wait-dbg
停止执行中的Monkey，直到有调试器和它相连接。
三、Monkey测试的停止条件
Monkey Test执行过程中在下列三种情况下会自动停止：
1、如果限定了Monkey运行在一个或几个特定的包上，那么它会监测试图转到其它包的操作，并对其进行阻止。
2、如果应用程序崩溃或接收到任何失控异常，Monkey将停止并报错。
3、如果应用程序产生了应用程序不响应(application not responding)的错误，Monkey将会停止并报错。
4、手动停止monkey的方法：在shell中执行 ps |grep monkey查找后台monkey进程的id，然后 kill id（adb shell ps |findstr monkey adb shell kill id）
跑monkey的时候或者想抓程序log导出时，有时会提示：cannot create D:monkeytest.txt: read-only file system
后来发现跟使用使用习惯不一样，一会是先进入adb shell 再用命令，一会是直接命令进入。进入adb shell后就相当于进入linux的root下面，没有权限在里面创建文件~
二、Monkey测试方案
Monkey的测试方案如下：
|
测试类型 |
测试对象 |
是否忽略异常 |
Monkey测试方案 |
解释说明 |
|
手机稳定性测试 |
单一APK |
忽略异常 |
# monkey -p [APK包名] --throttle 1000 -s 10000 --ignore-crashes --ignore-timeouts --ignore-security-exceptions --ignore-native-crashes --monitor-native-crashes -v -v -v 150000 > /mnt/sdcard/monkey report 2>&1 |
对单一APK进行忽略异常的Monkey测试，事件间的延时为1000毫秒，执行次数为150000，可执行12个小时。 |
|
APK集合 |
# monkey --pkg-blacklist-file /data/blacklist.txt --throttle 1000 -s 20000 --ignore-crashes --ignore-timeouts --ignore-security-exceptions --ignore-native-crashes --monitor-native-crashes -v -v -v 150000 > /mnt/sdcard/monkey report 2>&1 |
执行黑名单之外的，手机中的所有APK，对它们进行忽略异常的Monkey测试。事件间的延时为1000毫秒，执行次数为150000，可执行12小时。 |
||
|
单一APK |
不忽略异常 |
# monkey -p [APK包名] --throttle 1000 -s 10000 -v -v -v 150000 > /mnt/sdcard/monkey report 2>&1 |
对单一APK进行不忽略异常的Monkey测试，事件间的延时为1000毫秒，执行次数为150000，如果没有出现任何异常，可执行12个小时。 |
|
|
APK集合 |
# monkey --pkg-blacklist-file /data/blacklist.txt --throttle 1000 -s 20000 -v -v -v 150000 > /mnt/sdcard/monkey report 2>&1 |
执行黑名单之外的，手机中的所有APK，对它们进行不忽略异常的Monkey测试。事件间的延时为1000毫秒，执行次数为150000，如果没有出现任何异常，可执行12小时。 |
||
|
手机压力、健壮性测试 |
单一APK |
忽略异常 |
# monkey --p [APK包名] --throttle 500 -s 10000 --ignore-crashes --ignore-timeouts --ignore-security-exceptions --ignore-native-crashes --monitor-native-crashes -v -v -v 150000 > /mnt/sdcard/monkey report 2>&1 |
对单一APK进行忽略异常的Monkey测试，事件间的延时为500毫秒，执行次数为150000，可执行12个小时。 |
|
单一APK |
不忽略异常 |
# monkey --p [APK包名] --throttle 500 -s 10000 -v -v -v 150000 > /mnt/sdcard/monkey report 2>&1 |
对单一APK进行不忽略异常的Monkey测试，事件间的延时为500毫秒，执行次数为150000，如果没有出现任何异常，可执行12个小时。 |
1、黑名单的设置方法如下：
新建一个txt文本文件，名字为blacklist.txt ，文本文件的内容为APK的包名，换行输入新的APK包名。格式要求如下：
com.android.package1
com.android.package2
com.android.package3
将该文本文件push到手机中：adb push [blacklist.txt] /data目录下 (也可以放到sd卡目录下)
使用的命令为：--pkg-blacklist-file /data/whitelist.txt
2、白名单的设置方法：
添加白名单和添加黑名单的方式一样，只需将文本文件名改为whitelist即可，使用的命令为：--pkg-whitelist-file /data/whitelist.txt
注意：黑名单和白名单不能同时使用，也不能和-p [package name]命令同时使用。
3、APK包名的查询方法：
1）、可以通过adb shell命令获取：
adb shell
$ pm list package
2）、还可以在data目录下查询，（手机需要有root boot权限）
adb shell
# cd data
# ls
3）、如果只查看一个APK名，可以直接在ddms中查看：
进入ddms->file explorer->system->app,打开APK列表，每一个APK后面的Info属性里都显示了该APK的包名。
4、搭建测试环境
1.电脑端设置
进入“控制面板硬件和声音电源选项”，点击当前电源计划的“更改计划设置”，将“使计算机进入睡眠状态：”改为“从不”。
2确认待测版本是否满足Monkey测试
由于Monkey操作的随机性，在测试过程中，Monkey会点触到通知栏上的USB存储和USB连接，从而断开手机和打电脑的连接，导致测试报告和log信息的丢失。Google原始代码中已经有屏蔽Monkey操作的设计，如，手机在跑Monkey脚本时，“恢复出厂设置”选项就变成无效的。只有重启手机后，才可以进行“恢复出厂设置”的操作。为了保证产品能正常Monkey测试。需要在Monkey运行前，运行Monkey命令（# monkey –v 5），待monkey运行结束后，检查手机的通知栏上，USB连接和USB存储是否已经disable了，重启手机后，检查这两项是否又可以正常使用。假如软件并不满足上述Monkey测试条件，我们还可以将com.android.settings和com.systemui.com这两个APK应用放到黑名单中，屏蔽掉这两个模块的测试来保证Monkey测试不被中断。
5、系统设置
1、恢复出厂设置；
2、勾选开发人员选项中的USB调试、保持唤醒状态、允许模拟地点；
3、将蓝牙、GPS、数据业务、重力感应打开；
4、在系统管理功能中，清除缓存和日志信息；
5、安装程序：使用命令或adb工具集中的安装功能将待测应用安装至手机中。
6、开启wifi：将自动打开wifi开关；并手动连接wifi；
7、在设置里打开安全，勾选未知来源
8、设置眠时间5分钟以上
9、启动应用后，进入应用市场登陆账号
10、按HOME键将应用退至后台。
6、参数设置
1）种子数设置：种子数大于500
2）执行次数设置：输入数不要过小，通常设置为100万次
3）延迟设置：通常设置为500
4）其余设置选择默认
Monkey测试结果分析
一、 Android平台应用程序可能产生以下四种Crash：
App层：
1、Force Close
2、ANR
Native层：
3、Tombstone (Native cash)
Kernel层：
4、Kernel Panic
1.ANR(Application Not Responding：无响应)：
发生场景：应用发生ANR。
崩溃症状：系统弹出窗口询问用户选择“Force Close”或者“Wait”。
“Force Close”将杀掉发生ANR的应用进程。“Wait”将会等待系统择机恢复此应用进程。
发生原因：（1）应用主线程卡住，对其他请求响应超时。（2）死锁。（3）系统反应迟钝。（4）CPU负载过重。
2.Force Close：
发生场景：应用进程崩溃。
崩溃症状：系统弹出窗口提示用户某进程崩溃。
发生原因：空指向异常或者未捕捉的异常。
3.Tombstones：
发生场景：Native层崩溃
崩溃症状：如果发生崩溃的native层和UI有关联（比如Browser），我们可以在UI上发现这个崩溃。
如果发生崩溃的native层是在后台并且和UI没有直接联系，那么对于用户来说是不可见的，如果是debug版本可能会有Log打印出当时的底层现场。
发生原因：各种各样，需要具体情况具体分析。
4.系统服务崩溃（System Server Crash）：
发生场景：系统服务是Android核心进程，此服务进程发生崩溃。
崩溃症状：手机重启到Android启动界面
发生原因：（1）系统服务看门狗发现异常。（2）系统服务发生未捕获异常。（3）OOM。（4）系统服务Native发生Tombstone。
5.Kernel Panics：
发生场景：Linux内核发生严重错误
崩溃症状：手机从bootloader开始完全重启
发生原因：（1）Linux内核内存空间发生内存崩溃。（2）内核看门狗发现异常。（3）空指针操作内核。
二、初步分析方法
Monkey测试出现错误后，一般的查错步骤为以下几步：
1、找到是monkey里面的哪个地方出错
2、查看Monkey里面出错前的一些事件动作，并手动执行该动作
3、若以上步骤还不能找出，可以使用之前执行的monkey命令再执行一遍，注意seed值要一样--复现
如果可以，在monkey测试时也最好记录如下Log文件：
/data/anr日志，保存发生anr crash 时的相关信息；
/data/dontpanic日志，保存发生Kernel Panic时的相关信息；
/data/tombstones/日志，保存发生Tombstone Crash时的错误信息；(主要搜素data_app_wtf，data_app_anr，data_app_crash，system_server_watchdog)
/data/data/com.android.shell/files/bugreports日志，保存发生异常时的相关系统信息，也可以通过adb shell bugreport命令提取；
三、LOG分析方法
将执行Monkey生成的log，从手机中导出并打开查看该log；在log的最开始都会显示Monkey执行的seed值、执行次数和测试的包名。
Monkey log中第一个Switch主要是查看Monkey执行的是那一个Activity。
比如下面的log中执行的是com.tencent.smtt.SplashActivity，如果在下一个swtich之间前出现了崩溃或其他异常，那就可以在该Activity中查找问题。
:Switch:#Intent;action=android.intent.action.MAIN;category=android.intent.category.LAUNCHER;launchFlags=0x10000000;component=com.tencent.smtt/.SplashActivity;end
// Allowing start of Intent {act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER]cmp=com.tencent.smtt/.SplashActivity } in package com.tencent.smtt
在下面的log中，Sending Pointer ACTION_DOWN和Sending Pointer ACTION_UP代表当前执行了一个单击的操作;
Sleeping for 500 milliseconds这句log是执行Monkey测试时，throttle设定的间隔时间，每出现一次，就代表一个事件。
SendKey(ACTION_DOWN) //KEYCODE_DPAD_DOWN 代表当前执行了一个点击下导航键的操作；
Sending Pointer ACTION_MOVE 代表当前执行了一个滑动界面的操作。
:Sending Pointer ACTION_DOWN x=47.0 y=438.0
:Sending Pointer ACTION_MOVE x=-2.0 y=-4.0
如果Monkey测试顺利执行完成，在log的最后，会打印出当前执行事件的次数和所花费的时间；// Monkey finished代表执行完成。Monkey执行中断，在log的最后也能查看到当前已执行的次数。Monkey执行完成的log具体如下：
Events injected: 6000
:Dropped: keys=0 pointers=9 trackballs=0 flips=0
## Network stats: elapsed time=808384ms (0ms mobile, 808384ms wifi, 0msnot connected)
// Monkey finished
monkey日志会保存Monkey测试过程、应用层错误信息，发生Native Crash时也会有记录；Monkeylog分析，我们可以通过几个关键词来判断测试是否通过。
1）Monkey finished
打开LOG，查看log的最下端，是否有类似以下字段：
## Network stats: elapsed time=5123ms (5123ms mobile, 0ms wifi, 0ms not connected)
// Monkey finished
这个字段表明本次的Monkey没有异常，测试通过。
2）CRASH
同样，在得到LOG后，搜索”CRASH”字段，如果搜索到有结果，则表明有进程出现问题，测试不通过。
// CRASH: com.onekchi.downloadmanager (pid 12919)
3）ANR
在Log中搜素该字段，如果有搜索有结果，则表示测试过程中，测试对象出现了无响应的现象，因此测试不通过。--throttle <毫秒>值建议为500。在日志中搜索“ANR”
4）Exception
程序崩溃的关键词 。崩溃问题：在日志中搜索“Exception” FC（Force Close 强制关闭）
5）其他
搜索关键字：tombstones、error、leaked、out of memory
三、monkey自动化实例
# -*- coding: utf-8 -*-
import os
import sys
import time
packageName = 'com.qiyi.video'
seed = 10000
interval = 500
frequency = 100
SN = '127.0.0.1:7555' #木木模拟器
class monkeyTest():
adrr = os.getcwd()
path = "%s\monkeylog" % adrr
anr = "%s\anr" % path
dontpanic = "%s\dontpanic" % path
tombstones = "%s\tombstones" % path
bugreports = "%s\bugreports" % path
if not os.path.isdir(anr):
os.makedirs(anr)
if not os.path.isdir(anr):
os.makedirs(anr)
if not os.path.isdir(dontpanic):
os.makedirs(dontpanic)
if not os.path.isdir(tombstones):
os.makedirs(tombstones)
if not os.path.isdir(bugreports):
os.makedirs(bugreports)
# packageName包名，interval间隔时间单位ms ，frequency执行次数
def monkeyApp(self,SN,packageName, seed,interval, frequency):
try:
os.popen(
"adb -s %s shell monkey -p %s -s %s --throttle %s --ignore-crashes --ignore-timeouts --ignore-security-exceptions --ignore-native-crashes --monitor-native-crashes -v -v -v %s >%smonkeyScreenLog.log" % (
SN,packageName,seed, interval,frequency,self.path), 'r')
except Exception as e:
print(e)
# 导出日志
def copyErrorLog(self):
try:
os.popen("adb pull /data/anr %s" % self.anr, 'w')
os.popen("adb pull /data/dontpanic %s" % self.dontpanic, 'w')
os.popen("adb pull /data/tombstones %s" % self.tombstones, 'w')
os.popen("adb pull /data/data/com.android.shell/files/bugreports %s" % self.bugreports, 'w')
except Exception as e:
print(e)
def pand(self):
# 判断是否执行完成，执行完成后导出日志
monkeylog = open("%s\monkeyScreenLog.log" % self.path, 'r')
temp = monkeylog.read()
if temp.count('Monkey finished') > 0:
myApp.copyErrorLog()
monkeylog.close()
else:
time.sleep(2)
if __name__ == "__main__":
myApp = monkeyTest()
myApp.monkeyApp(SN,packageName,seed,interval, frequency)
myApp.pand()
以上做到了自动执行monkey命令，并在monkey执行完成后将日志导出到PC以供分析。
四、Android压力测试工具Monkey
Monkey信息自动收集脚本
1、应用Findyou的Monkey脚本
a、配置文件：config.conf
[appinfo]
appCnName=Findyou
appEnName=Findyou
appversion=V1.0.0
packageName=com.Findyou.you
b、脚本文件：Monkey_findyou.bat
@ECHO OFF
ECHO.
IF NOT EXIST %~dp0config.conf GOTO EXIT
ECHO.::::::::::::::::: Monkey测试准备:::::::::::::::::
ECHO.
ECHO.[ INFO ] 读取config.conf中信息
FOR /F "tokens=1,2 delims==" %%a in (config.conf) do (
IF %%a == packageName SET packageName=%%b
IF %%a == appEnName SET appEnName=%%b
IF %%a == appversion SET appversion=%%b
)
SET c_date=%date:~0,4%%date:~5,2%%date:~8,2%
REM 获取得小时,格式为：24小时制，10点前补0
SET c_time=%time:~0,2%
IF /i %c_time% LSS 10 (
SET c_time=0%time:~1,1%
)
SET c_time=%c_time%%time:~3,2%%time:~6,2%
REM 将当运行时间点做为日志文件名
SET logfilename=%c_date%%c_time%
IF NOT EXIST %~dp0\%c_date% md %~dp0\%c_date%
SET logdir="%~dp0\%c_date%\%appEnName%%appversion%"
IF NOT EXIST %logdir% (
ECHO.[ Exec ] 创建目录：%c_date%\%appEnName%%appversion%
md %logdir%
)
adb shell cat /system/build.prop>phone.info
FOR /F "tokens=1,2 delims==" %%a in (phone.info) do (
IF %%a == ro.build.version.release SET androidOS=%%b
IF %%a == ro.product.model SET model=%%b
IF %%a == ro.product.brand SET brand=%%b
)
del /a/f/q phone.info
ECHO.[ INFO ] 读取手机信息，写入%logfilename%_%model%.txt
ECHO.手机信息>"%logdir%\%logfilename%_%model%.txt"
ECHO.手机品牌: %brand%>>"%logdir%\%logfilename%_%model%.txt"
ECHO.手机型号: %model%>>"%logdir%\%logfilename%_%model%.txt"
ECHO.系统版本: Android %androidOS%>>"%logdir%\%logfilename%_%model%.txt"
ECHO.[ Exec ] 使用Logcat清空手机中log，测试中logcat写入%logfilename%_logcat.log
adb logcat -c
ECHO.[ Exec ] monkey日志写入%logfilename%_monkey.log
ping -n 2 127.0.0.1>nul
ECHO.
ECHO.:::::::::::::::::开始执行Monkey命令:::::::::::::::::
ECHO.
adb shell am force-stop %packageName%
ECHO.adb shell monkey -p %packageName% -s %c_time% --throttle 500 -v -v -v 100000
adb shell monkey -p %packageName% -s %c_time% --throttle 500 -v -v -v 100000>%logdir%\%logfilename%_monkey.log
ECHO.[ INFO ] 执行Monkey命令结束
ECHO.
ECHO.[ Exce ] 手机截屏
adb shell screencap -p /sdcard/monkey_run_end.png
ECHO.[ INFO ] 拷贝截屏图片至电脑
adb pull /sdcard/monkey_run_end.png %logdir%
cd %logdir%
ECHO.
ECHO.[ Exec ] 使用Logcat导出日志
adb logcat -d >%logdir%\%logfilename%_logcat.log
:EXIT
ECHO.
ECHO.[ INFO ] 请按任意键关闭窗口...
PAUSE>nul
注意:保存bat时注意为文件格式 ANSI
2、使用方法
a、保存脚本：拷贝本文中的config.conf、Monkey_findyou.bat内容保存在同一目录下
b、修改配置：修改 config.conf 中内容为你需要测试的APP对应的信息
c、执行脚本：双击 Monkey_findyou.bat 即可
温馨提示：此版脚本没有对同时连接电脑的多台安卓设备进行检测，只能对单台手机进行测试与操作
3、脚本讲解
a、核心：Monkey命令
adb shell monkey -p %packageName% -s %c_time% --throttle 100 -v -v -v 10000
-p %packageName% 指定测试包名，%packageName%变量值来自文件config.conf中的packageName对应的值。
-s %c_time% %c_time%为执行脚本当时的时间(小时、分、秒)，以时间为值即达到随机目的，也为后续需要再模拟此次测试提供事件序列。
--throttle 100 代表间隔时间，即每次操作的时间间隔，此命令的含义就是增加500ms的时间间隔。
-v -v -v 10000 -v -v -v日志级别 Level 2，最详细的日志，包括了测试中选中/未选中的Activity信息。10000即执行10000次随机事件。
b、配置文件
config.conf
[appinfo]
appCnName=Findyou
appEnName=Findyou
appversion=V1.0.0
packageName=com.Findyou.you
1)、appCnName：此脚本中暂时未用到
2)、appEnName：待测APP名称，建议用英文或拼音，多处用到此项值
3)、appversion：待测APP版本号，不要有空格，bat脚本没有做处理
4)、packageName：待测APP版本package名
Monkey日志自动分析脚本
1)、Monkey_Log分析.bat
@ECHO OFF
ECHO.::::::::::::::::::::Monkey日志分析:::::::::::::::::::
REM 方法一：手动设置Monkey日志路径
SET monkeyLogFile=F:Monkey20140808FindyouV1.0.020140825181801_monkey.log
REM 方法二：直接将Monkey日志拖到此bat文件上
IF NOT "%1"=="" SET monkeyLogFile=%1
ECHO.[ INFO ] Monkey日志: %monkeyLogFile%
ECHO.
ECHO.:::::::::::::::::::::开始分析:::::::::::::::::::::::
SET blnException=0
ECHO.
REM 如果觉得分析太快，没有感觉，把下面注释去掉假装分析中，有停顿感
REM ping -n 2 127.0.0.1>nul
::ANR日志
FOR /F "delims=" %%a IN ('FINDSTR /C:"ANR" %monkeyLogFile%') DO (
SET strANR=%%a
)
::崩溃日志
FOR /F "delims=" %%a IN ('FINDSTR /C:"CRASH" %monkeyLogFile%') DO (
SET strCRASH=%%a
)
::异常日志
FOR /F "delims=" %%a IN ('FINDSTR /C:"Exception" %monkeyLogFile%') DO (
SET strException=%%a
)
::正常
FOR /F "delims=" %%a IN ('FINDSTR /C:"Monkey finished" %monkeyLogFile%') DO (
SET strFinished=%%a
)
IF NOT "%strFinished%" == "" (
ECHO.[ INFO ] 分析Monkey日志存在: 执行成功标记
ECHO.[ INFO ] ------------------------------------
ECHO. "%strFinished%"
ECHO.
) ELSE (
IF %blnException% EQU 0 ECHO.[ INFO ] 分析Monkey日志结果: Monkey执行异常中断，请重新执行Monkey脚本!
ECHO.
)
IF NOT "%strANR%" == "" (
ECHO.[ INFO ] 分析Monkey日志存在: ANR
ECHO.[ INFO ] ------------------------------------
ECHO. "%strANR%"
SET /a blnException+=1
ECHO.
)
IF NOT "%strCRASH%" == "" (
ECHO.[ INFO ] 分析Monkey日志存在: CRASH
ECHO.[ INFO ] ------------------------------------
ECHO. "%strCRASH%"
SET /a blnException+=1
ECHO.
)
IF NOT "%strException%" == "" (
ECHO.[ INFO ] 分析Monkey日志存在: 异常
ECHO.[ INFO ] ------------------------------------
ECHO. "%strException%"
SET /a blnException+=1
)
ECHO.
REM 如果blnException不为0，说明存在异常，改变字体为淡紫色
IF %blnException% NEQ 0 (
Color 0D
ECHO.[ INFO ] 分析Monkey日志结果:存在异常日志，请手工再仔细检查！
ECHO.
) ELSE (
ECHO.[ INFO ] 分析Monkey日志结果:正常
ECHO.
)
ECHO.
ECHO.[ EXIT ] 按任意键关闭窗口...
PAUSE>nul
2)、使用方法
方法一：手动设置Monkey日志路径，修改脚本中的monkeyFile变量
方法二：直接将Monkey日志拖至bat文件上
脚本核心思想：搜索关键字，通过关键字判读有无异常。如果Monkey命令存在调试选项如：--ignore-crashes --ignore-timeouts，此脚本还需要增加判断条件，如有兴趣可以自己再优化增强。
3)、脚本执行结果
a、正常
b、异常
五、弱网测试
弱网测试作为健壮性测试的重要部分，对于移动端测试来说必不可少。这是因为目前移动端产品的使用用户所处的网络并非完全的流畅WIFI环境，仍有相当体量的用户主要使用4G、3G、2G等网络，另外因移动端产品使用场景多变，如进地铁、上公交、进电梯等，使得弱网测试显得尤为重要。毕竟考虑到各种场景的客户端展示及容错，能极大提升产品印象和用户体验。
一、弱网测试的思路篇
总结了下（如上图所示），弱网测试主要进行特殊网络状态下的功能测试同时关注用户体验，具体来说，弱网测试包括弱网功能测试、无网状态测试、网络切换测试等，测试的同时关注用户体验的诸多方面。
1.弱网功能测试
这一部分主要是在各种非wifi网络环境下进行的功能测试，同时模拟高延时和高丢包的异常网络环境进行健壮性测试。2G/3G/4G的网络可以通过使用电话卡移动／联通／电信等网络进行模拟，关注页面的响应时间、页面呈现是否完整一致等。高延迟和高丢包的网络环境需要借助工具来模拟，在windows环境下可以使用fiddler和network emulator for windows toolkit来模拟，在mac环境下则可以使用charles和Xcode自带的开发环境网络异常模拟工具进行。工具的使用在工具篇具体介绍。
弱网功能测试建议将整体的功能测试用例在弱网环境下进行一轮测试，相同模块下的功能可以分多个网络条件进行测试。这部分发现的问题可能会有：页面图片在弱网环境下加载不出来（图片加载逻辑需优化）、需要模版的页面版式结构混乱（模版文件在弱网环境的加载需优化）、页面响应时间较长没有任何显示（页面显示逻辑待优化、重试机制加入）等。
2.无网状态测试
无网状态测试则是在切段网络的情况下进行的测试，主要关注页面的显示与交互、本地数据的存储、断网功能的使用等，经常该部分也需要与网络切换部分协同进行。通常来说，（1）断网情况下请求一个非本地数据的页面需要设定一定的时间等待上限，及时提示网络异常以及提示重试；（2）断网情况下请求一个部分本地数据的页面需要观察本地数据的部分是否加载显示正常，待请求的部分是否符合交互给的缺省样式一致；（3）断网情况下请求一个完全本地数据的页面是否显示正常。这里还需考虑本地数据存储的情况，有些需要联网后上报服务器的数据本地是否正确存储，联网后这些数据能否正常上报。
无网状态测试建议按照页面划分进行，针对每个页面单独测试无网状态的显示，页面间跳转的显示，页面内功能的点击和显示，同时关注无网到有网时的页面恢复显示状态、数据上报情况是否正常。
3.网络切换测试
这部分主要是进行几个不同网络场景的切换，包括wifi-2G/3G/4G、wifi-无网、2G/3G/4G-wifi、2G/3G/4G-无网、无网-2G/3G/4G、无网-wifi等。主要关注页面的显示与交互，尤其是弱网到wifi，wifi到弱网的情况，是否会有页面的crash以及显示的错乱、session是否一致、请求堆积处理等。
4.用户体验关注
弱网测试的目的就是尽可能保证用户体验，关注的关键点包括：
（1）页面响应时间是否可接受，关注包括热启动、冷启动时间，页面切换，前后台切换，首字时间，首屏时间等。
（2）页面呈现是否完整一致
（3）超时文案是否符合定义，异常信息是否显示正常。
（4）是否会有超时重连
（5）安全角度：是否会发生dns劫持、登录ip更换频繁、单点登录异常等。
（6）大流量事件风险：是否会在弱网下进行更新apk包、下载文件等大流量动作。
Network-Emulator
一、安装弱网测试工具-Network-Emulator-Toolkit
这个工具的作用主要是设置丢包率和延时；
2、再次安装一个共享wifi工具
下载地址：http://wifi.liebao.cn/ 猎豹wifi。以上就是进行弱网测试的前期准备工作；
二、Network-Emulator-Toolkit使用教程
1、新建VirtualChannel，File->new或者 Configuration->New Channel;
2、再建一个过滤器Filter,Configuration->New Filter
设置说明：
1. All Network 是指所有网络；
2. IPV4、IPV6(本地IP(Local IP)，或者远程IP(Remote IP)及子网掩码(IP Mask))；
3.可以指定本地端口(Local Port)或远程端口(Remote Port)大小范围；
4.协议(Protocol)，针对TCPUDP协议；
5.可以选择网卡适配器(Adapaters），对适配器增删改；
3、新建连接Link,Configration->New Link
注:未配置的情况下，左右两条线都是灰色的
4.设置UpStream和DownStream
双击link或者悬浮link上方鼠标右键，打开UpStream、DownStream;
【loss】丢包：
●No Loss：默认，不模拟丢包。
●Periodic loss: 模拟周期性的丢包。按填写数量(设为x个)，每x个包，就丢一个包(one packet is dropped per given number of packets)。
●Random loss: 模拟随机丢包，按给定丢包的概率，随机丢包。
●Burst loss: 模拟根据给定的可能性进行丢包。当发生一个丢包事件时，接着连续丢几个包（丢包数量控制在最大(max)最小值(min)之间）。
●G-E loss: 模拟发生数据包丢失遵循Gilbert-Elliot模型，由两个状态组成：好的状态和坏的状态。可分别为这2个状态指定数据包丢失率,同时可设置网络传输在这两种状态的概率
（And the network transit between the two states is at given transition probabilities）
【error】数据错误（网络传输过程中，包中一个或者多个字节出现Error）
●No Error 不模拟数据传输错误
●Random error：根据给定的比例，模拟随机发生传输错误。
●G-E error：发生传输错误遵循Gilbert-Elliot Model, 模型，由两个状态组成：好的状态和坏的状态。可分别为这2个状态指定数据包丢失率,同时可设置网络传输在这两种状态的概率(the network transit between the two states according to given transition probabilities)
●错误概率单元(Error Rate Unit):
Bit error: 设置出错概率为每个字节出错的概率。
Packet error: 设置出错概率为每个包出错的概率。
【Latency】出错和丢包的关系
大多数情况下，包出错导致包丢失，特殊情况下，包中的数据被编码，协议栈可恢复被损坏的包，经过修正后，包为可接受的包，即包不丢失。此外，除了包出错会导致包丢失，其它因素也会影响包丢失，如连接失败（Link failure），缓冲区溢出(buffer overflow)，队列管理和传输超时(transmission timeout)等。
●延迟来自某应用发送的数据包被另一个应用程序接收到的时间。
●Fixed delay: 按给定值，延迟固定时间（单位：毫秒）packets are delayed for a fixed amount of time.
●Uniform delay: 按统一分布，延迟一定量的时间(时间控制在最大最小值之间)
●Normal delay: 按正态分布.延迟一定量的时间（average：平均值，Devation：偏差)
●Linear delay: 延迟一定量的时间（在给定时间周期(Period)内，延迟的时间大小从最小值线性增加到最大值，当达到最大值时，又从最小值开始。
●Burst delay: 根据给定概率（Probability），延迟一定量的时间(Latency)， 丢包数控制最大值和最小值之间
【BW&Queue】
如果不指定带宽（bandwith），则不修改传输速率。如果不设置队列，则不对接到的包做任何队列操作
队列：
Normal queue：所有接收到的包都被放入一个指定队列大小的先进先出(First In, First Out)队列。
Randomly Early Detection (RED) queue：所有接收到的包都被放入一个RED队列。如果队列大小小于给定的最低阈值(Minimum Threshold),队列被评估为不拥挤的，什么都不做；如果队列大小大于给定最大阈值（Maximum Threshold）,则队列被评估为拥挤的，根据丢包规则，丢弃一些包。
丢包规则：
Drop front: 必要时，丢弃位于队列头部的包。.
Drop tail: 必要时，丢弃位于队列尾部的包。
Drop random：必要时，根据统一分布，随机丢个包。
Queue Mode：设置队列大小的单位，以包(Packet Mode)为单位或者以字节为单位Byte Mode
【BgTraffic】背景流->延时效果
一些网络数据包交换和模拟的两端没有任何关系，被指为背景流(background traffic)。这些背景流会带来延时效果。
Constant-bit rate (CBR) traffic: 根据给定的固定比例生成背景流（每XX kbps、mbps数据包，xx字节背景流）
Exponential traffic：根据指数On/Off时间分布生成背景流。 个人理解，Burst则为生成背景流时间，Idle则不生成背景流时间(时间单位：秒
Pareto traffic: 同上，不过是排列图分布（Pareto）
【Recorder】接收顺序
模拟收到的包不是按发送顺序排序的。
No Recoder：不模拟
【Disconnection】模拟周期性断开
模拟周期性断开连接的行为。
Connection time: 一段时间周期内，link保持连接状态的持续时间。
Disconnection time: 一段时间周期内，link保持断开状态的持续时间
Disconnection rates: link发生断开连接的比率
例子：设置connection time为10秒，disconnection为5秒，那么周期为15秒，如果设置rate为0.4，那么平均每10秒内，有4秒是link处于连接断开的时间（if connection time is 10 seconds, time is 5 seconds, the period will be 15 seconds. If rate is 0.4, then on average in 4 out of 10 periods disconnection occurs. ）。
工具栏介绍
连接方式：
Dialup56k：通过传输速率为56kbps的modem进行连接
ADSL(128/512): 通过上行128kbps，下行512kbps的ADSL连接。
GPRS：它是GSM移动电话用户可用的一种移动数据业务，理论传输速率115kbit/s，实际可达53.6Kbps。
CDMA2000：3G移动通讯标准。
WCDMA：宽带码分多址（英语：Wideband Code Division Multiple Access，常简写为W-CDMA），是一种3G蜂窝网络，使用的部分协议与2G GSM标准一致。
IEEE802.11b：通过无线局域网，带宽最高可达11Mbps，实际的工作速度在5Mb/s左右，室外为300米；在办公环境中最长为100米
丢包或者延时，能够带来哪些危害呢？
1、丢包：丢包最常见，在TCP协议中，需要不停的发送请求，来确认连接状态，一旦发生丢包，就需要重传；这个时候，就需要去测试一下 产品的处理机制，UI界面是否给出友好提示，服务端是否做了异常处理；
2、延时：由于出现了网络波动，导致数据包在传输的时候出现了抖动，导致请求出现超时现象；这个时候就需要去测试一下产品的处理机制，UI界面是否给出友好提示，服务端是否做了异常处理；
App弱网测试与常用模拟工具
1. 弱网模拟工具
1.1. iOS平台，通过自带的开发者选项 》Network Link Conditioner, 即可简单的模拟各种速度的网络情况：
1.2 通过抓包工具，设置延迟，进行模拟不同的网络情况，比如常用的fiddler, charles:
1.2.1 fiddler操作：自定义延迟 》开启网络模拟即可，如图：
fiddler主要是使用Rules->Performance->Simulate Modem Speeds功能进行的网络延迟模拟，点击Rules->Customize Rules进行设置，打开自定义脚本编辑器，如下图所示：
这里通过计算上行和下行的网络延迟时间，可以模拟出想要的网络效果。利用 （1KB/下载速度）x1000 = 要delay的毫秒数 来计算。比如我们要模拟2G的网络。
1.2.2 Charles操作：延迟设置 》选择相应的网络延迟设置或者自定义延迟 》开启延迟即可，如图：
备注：不同网络环境设置可参考如下图：
==================================
Applications Graphics Acceleration Info:
Uptime: 22215460 Realtime: 38892707
** Graphics info for pid 4731 [net.oneplus.launcher] ** #表明当前dump的为设置界面的帧信息，pid为4731
Stats since: 54444436332ns #表示该应用的统计信息是从系统开机多长时间（纳秒）后开始统计的。
Total frames rendered: 11835 #总帧数, 本次dump搜集了11835帧的信息
Janky frames: 2803 (23.68%) #总帧数中有2803帧耗时超过了16ms，卡顿率为23.68%
50th percentile: 12ms #表示50%的帧是在12ms中完成的
90th percentile: 21ms #表示90%的帧是在21ms中完成的
95th percentile: 27ms #表示95%的帧是在27ms中完成的
99th percentile: 61ms #表示99%的帧是在61ms中完成的
Number Missed Vsync: 296 #垂直同步延迟1ms以上的帧数量
Number High input latency: 32 #处理input耗时超过1.5*f的帧数量 (f为处理一帧的理想时间1/fps)
Number Slow UI thread: 1092 #因UI线程上的工作导致耗时超过0.5*f的帧数量
Number Slow bitmap uploads: 159 #因bitmap的加载耗时超过0.2*f的帧的数量
Number Slow issue draw commands: 1251 #因绘制导致耗时超过0.75*f的帧的数量
#直方图数据，输出用时为某秒的帧数，如耗时0-5ms为1254帧,5-6ms的为581帧。帧数之和等于Total frames rendered中的总帧数
HISTOGRAM: 5ms=1254 6ms=581 7ms=663 8ms=697 9ms=720 10ms=930 11ms=917 12ms=981 13ms=753 14ms=646 15ms=530 16ms=597 17ms=419 18ms=332 19ms=298 20ms=320 21ms=179 22ms=140 23ms=91 24ms=73 25ms=69 26ms=33 27ms=35 28ms=29 29ms=31 30ms=30 31ms=24 32ms=53 34ms=29 36ms=42 38ms=33 40ms=35 42ms=34 44ms=22 46ms=16 48ms=27 53ms=26 57ms=21 61ms=16 65ms=19 69ms=13 73ms=11 77ms=12 81ms=12 85ms=2 89ms=2 93ms=5 97ms=2 101ms=2 105ms=1 109ms=2 113ms=0 117ms=4 121ms=1 125ms=0 129ms=0 133ms=1 150ms=9 200ms=1 250ms=3 300ms=3 350ms=0 400ms=1 450ms=0 500ms=0 550ms=0 600ms=1 650ms=1 700ms=0 750ms=0 800ms=1 850ms=0 900ms=0 950ms=0 1000ms=0 1050ms=0 1100ms=0 1150ms=0 1200ms=0 1250ms=0 1300ms=0 1350ms=0 1400ms=0 1450ms=0 1500ms=0 1550ms=0 1600ms=0 1650ms=0 1700ms=0 1750ms=0 1800ms=0 1850ms=0 1900ms=0 1950ms=0 2000ms=0 2050ms=0 2100ms=0 2150ms=0 2200ms=0 2250ms=0 2300ms=0 2350ms=0 2400ms=0 2450ms=0 2500ms=0 2550ms=0 2600ms=0 2650ms=0 2700ms=0 2750ms=0 2800ms=0 2850ms=0 2900ms=0 2950ms=0 3000ms=0 3050ms=0 3100ms=0 3150ms=0 3200ms=0 3250ms=0 3300ms=0 3350ms=0 3400ms=0 3450ms=0 3500ms=0 3550ms=0 3600ms=0 3650ms=0 3700ms=0 3750ms=0 3800ms=0 3850ms=0 3900ms=0 3950ms=0 4000ms=0 4050ms=0 4100ms=0 4150ms=0 4200ms=0 4250ms=0 4300ms=0 4350ms=0 4400ms=0 4450ms=0 4500ms=0 4550ms=0 4600ms=0 4650ms=0 4700ms=0 4750ms=0 4800ms=0 4850ms=0 4900ms=0 4950ms=0
#内存相关的信息，没啥好说的
Caches:
Current memory usage / total memory usage (bytes):
TextureCache 3108068 / 100663296 #纹理缓存已使用大小/最大可用大小
LayerCache 0 / 67108864 (numLayers = 0) # layer缓存使用大小/最大可用大小（texture）
Layers total 0 (numLayers = 0) # layer数量
RenderBufferCache 0 / 12582912
GradientCache 0 / 1048576
PathCache 0 / 40894464
TessellationCache 0 / 1048576
TextDropShadowCache 108736 / 7340032
PatchCache 128 / 131072
FontRenderer A8 60887 / 4194304
A8 texture 0 60887 / 4194304
FontRenderer RGBA 0 / 0
FontRenderer total 60887 / 4194304
Other:
FboCache 0 / 0
Total memory usage: #使用缓存的总大小
7411236 bytes, 7.07 MB
Pipeline=FrameBuilder
Profile data in ms:
# FrameInfoVisualizer（帧信息视图）的统计信息。draw行代表绘制信息 prepare 同步时间 Process gl绘制时间 Execute swapbuffer时间
Draw:表示在Java中创建显示列表部分中，OnDraw()方法占用的时间。
Process：表示渲染引擎执行显示列表所花的时间，view越多，时间就越长
Execute：表示把一帧数据发送到屏幕上排版显示实际花费的时间。其实是实际显示帧数据的后台缓存区与前台缓冲区交换后并将前台缓冲区的内容显示到屏幕上的时间。
Draw + Process + Execute = 完整显示一帧 ，这个时间要小于16ms才能保证每秒60帧。
net.oneplus.launcher/net.oneplus.launcher.Launcher/android.view.ViewRootImpl@a827964 (visibility=0)
Draw Prepare Process Execute
5.41 0.26 3.94 0.77
2.54 0.23 9.28 1.34
8.46 7.72 23.74 1.36
1.81 0.20 1.17 2.42
9.37 0.23 6.01 0.66
1.30 0.19 16.54 0.59
1.20 0.22 15.05 0.47
1.15 0.27 16.66 0.90
1.87 0.44 11.98 2.56
3.19 0.42 3.83 1.29
1.57 0.36 2.11 0.88
1.49 0.31 2.06 0.85
1.41 0.30 2.23 0.91
2.00 0.32 2.00 0.92
3.45 0.39 2.97 1.19
#Framestats数据格式
以上这些数据是怎么统计得到的呢，是通过framestat，framestat是每一个frame的信息，记录这不同阶段下的时间戳，也就是更精准的帧的时间戳信息。在Android 6.0以后为gfxinfo 提供了一个新的参数framestats，其作用可以从最近的帧中提供非常详细的帧信息，以便您可以更准确地跟踪和调试问题。此输出的每一行代表应用程序生成的一帧。每一行的列数都相同，每列对应描述帧在不同的时间段的耗时情况。下一节将详细介绍这种格式，包括每列代表的内容。由于数据块以CSV格式输出，因此将其粘贴到您选择的电子表格工具中非常简单，或者通过脚本进行收集和分析。下表说明了输出数据列的格式。所有的时间戳都是纳秒。打印每一帧的统计信息(最多120帧且是最后的120帧)。adb shell dumpsys gfxinfo PACKAGENAME framestats
---PROFILEDATA--- Flags,IntendedVsync,Vsync,OldestInputEvent,NewestInputEvent,HandleInputStart,AnimationStart,PerformTraversalsStart,DrawStart,SyncQueued,SyncStart,IssueDrawCommandsStart,SwapBuffers,FrameCompleted,DequeueBufferDuration,QueueBufferDuration,
0,21256019939003,21256019939003,9223372036854775807,0,21256021611264,21256021663399,21256021840691,21256023720795,21256025349180,21256025417982,21256025679753,21256029621160,21256030392410,491000,416000,
0,21256036634257,21256036634257,9223372036854775807,0,21256037009024,21256037028503,21256037252253,21256038165482,21256039177670,21256039226160,21256039455118,21256048731055,21256050073347,432000,376000
---PROFILEDATA---
View hierarchy:
net.oneplus.launcher/net.oneplus.launcher.Launcher/android.view.ViewRootImpl@a827964
368 views, 466.32 kB of display lists #view的数量大小，通过allocer统计
Total ViewRootImpl: 1 #viewroot总数量
Total Views: 368 #view总数量
Total DisplayList: 466.32 kB #总大小
注：
●FLAGS
FLAGS列为'0'的行可以通过从FRAME_COMPLETED列中减去INTENDED_VSYNC列计算其总帧时间。
如果非零，则该行应该被忽略，因为该帧的预期布局和绘制时间超过16ms，为异常帧。
●INTENDED_VSYNC
帧的的预期起点。如果此值与VSYNC不同，是由于 UI 线程中的工作使其无法及时响应垂直同步信号所造成的。
●VSYNC
花费在vsync监听器和帧绘制的时间（Choreographer frame回调，动画，View.getDrawingTime（）等）
●OLDEST_INPUT_EVENT
输入队列中最旧输入事件的时间戳，如果没有输入事件，则输入Long.MAX_VALUE。
此值主要用于平台工作，对应用程序开发人员的用处有限。
●NEWEST_INPUT_EVENT
输入队列中最新输入事件的时间戳，如果帧没有输入事件，则为0。
此值主要用于平台工作，对应用程序开发人员的用处有限。
然而，通过查看（FRAME_COMPLETED - NEWEST_INPUT_EVENT），可以大致了解应用程序添加的延迟时间。
●HANDLE_INPUT_START
将输入事件分派给应用程序的时间戳。
通过查看这段时间和ANIMATION_START之间的时间，可以测量应用程序处理输入事件的时间。
如果这个数字很高（> 2ms），这表明程序花费了非常长的时间来处理输入事件，例如View.onTouchEvent（），也就是说此工作需要优化，或者分发到不同的线程。请注意，某些情况下这是可以接受的，例如发起新活动或类似活动的点击事件，并且此数字很大。
●ANIMATION_START
运行Choreographer注册动画的时间戳。
通过查看这段时间和PERFORM_TRANVERSALS_START之间的时间，可以确定评估运行的所有动画器（ObjectAnimator，ViewPropertyAnimator和常用转换器）需要多长时间。
如果此数字很高（> 2ms），请检查您的应用是否编写了自定义动画以确保它们适用于动画。
●PERFORM_TRAVERSALS_START
PERFORM_TRAVERSALS_STAR-DRAW_START，则可以提取布局和度量阶段完成的时间。（注意，在滚动或动画期间，你会希望这应该接近于零..）
●DRAW_START
performTraversals的绘制阶段开始的时间。这是录制任何无效视图的显示列表的起点。
这和SYNC_START之间的时间是在树中所有无效视图上调用View.draw（）所花费的时间。
●SYNC_QUEUED
同步请求发送到RenderThread的时间。
这标志着开始同步阶段的消息被发送到RenderThread的时刻。如果此时间和SYNC_START之间的时间很长（> 0.1ms左右），则意味着RenderThread忙于处理不同的帧。在内部，这被用来区分帧做了太多的工作，超过了16ms的预算，由于前一帧超过了16ms的预算，帧被停止了。
●SYNC_START
绘图的同步阶段开始的时间。
如果此时间与ISSUE_DRAW_COMMANDS_START之间的时间很长（> 0.4ms左右），则通常表示有许多新的位图必须上传到GPU。
●ISSUE_DRAW_COMMANDS_START
硬件渲染器开始向GPU发出绘图命令的时间。
这段时间和FRAME_COMPLETED之间的时间间隔显示了应用程序正在生产多少GPU。像这样出现太多透支或低效率渲染效果的问题。
●SWAP_BUFFERS
eglSwapBuffers被调用的时间。
●FRAME_COMPLETED
帧的完整时间。花在这个帧上的总时间可以通过FRAME_COMPLETED - INTENDED_VSYNC来计算。