1.性能测试的几个指标：
2.性能测试环境准备：
3.启动时间
3.1，监控值的获取方法
启动分为冷启动和热启动，冷启动：应用程序首次启动，进程首次创建并加载资源的过程；热启动：应用程序启动后点“back”键、“Home”键，应用程序退到后台，并未被完全“杀死”的状态，再次启动；
3.1.1，冷启动
启动App命令：adb shell am start -W -n package/activity 停止App命令：adb shell am force-stop package
获取package/activity的方法：1.先执行监控指令 adb logcat | grep START，再启动程序，生成的log信息中可以查看该程序的包名和activity名
ThisTime:647 这条信息中的时间就作为这次应用启动的耗时
3.1.2，热启动
启动App命令：adb shell am start -W -n package/activity 停止App命令：adb shell input keyevent 3 (发送一个keyevent事件，3代表点击手机上的“back”键)
ThisTime:427 这条信息中的时间就作为这次应用启动的耗时
3.2，“启动时间”监控的脚本实现
“启动时间”监控的脚本实现有两种方式：1.获取命令执行时间，作为启动时间参考值；2.在命令前后加上时间戳，以差值作为参考值（此种方式相对更精准）
脚本中需要创建两个类以及方法：
脚本实现如图1、2
得到的数据在csv文件中，数据分析时去掉第一次的数据，取均值，并绘制出一个数据曲线，得到的均值的参考价值的体现方式有两种形式：1.取竞品的数据作为对比（比如测试的是google浏览器，用其他浏览器做对比）；2.取历史版本的数据做对比（版本间对比，看最新版本的开发过程中是否造成了启动时间的延长）
3.2.2，时间戳差值监控用到的类以及方法：
4，CPU监控值的获取方法、脚本实现和数据分析
4.1获取方法：
取图中第一个百分数作为cpu状态值
脚本实现如图3、4
注意：关于cpu的状态测试的时间要稍长一些，需要配合一个自动化脚本来实现对设备的操作，例如重复搜索100次，同时执行监控命令，来获取搜索100次之后的cpu状态值
5，流量监控值的获取方法、脚本实现和数据分析
5.1获取方法：
1.首先要获取进程的ID，命令：adb shell ps | grep packagename；
，如图中的“5715”就是我们想要的进程的ID。
2.获取进程的ID流量，命令：adb shell cat/proc/pid/net/dev(pid:第一步中获取到的进程的ID)；
如图，得到的结果中只需要关注两个值：Receive（app接收到的数据）、Transmit（app发出的请求数据）；流量等于这两个值的和：Receive+Transmit。只取eth0、eth1两个网卡的Receive和Transmit即可，也就是把图中框起来的4个数值相加。
脚本实现如图5、6
在实际的测试采集过程中，需要多次采集数据，取最后一次采集到的流量值和第一次采集到的流量值的差，作为我们本次测试过程中的流量消耗，这也是我们关注的重点！
6，电量监控值的获取方法、脚本实现和数据分析
*注意：一般，用硬件去测试电量的消耗更为准确，用脚本的方式去获取电量值会与用硬件获得的值有一点的偏差，但是用脚本的方式适合硬件资源相对有限的创业公司。
6.1获取方法：
1.命令：adb shell dumpsys battery；2.因为测试过程中需要手机和电脑通过USB线连接，这样会造成测试电量的过程中手机同时也在充电，所以需要通过命令切换成“非充电状态”，此命令为：adb shell dumpsys battery set status 1；
如图，level值就是电量，取测试结束后和测试开始时的电量做差，就是我们要得到的测试过程中电量的消耗。
脚本实现如图7、8
7，内存监控值的获取方法、脚本实现和数据分析
7.1.内存监控值的获取方法
命令：adb shell top；执行完命令后，在所得的数据中，需要关注两个字段：VSS（虚拟耗用内存）、RSS（实际使用物理内存），然后对测试过程中VSS、RSS的变化情况做曲线图，得出测试过程中内存的变化情况。
具体的步骤：1.
，（-d：命令刷新的频率，1的单位是“秒”），将得到的数据输出到meminfo文件中
2.操作被测试的应用
3.对得到的数据过滤，过滤出所测试应用的内存值（如图）
7.2.脚本实现如图9、10
7.3.数据分析
打开得到的csv文件，windows系统可以用excel打开，然后对VSS、RSS做曲线图
得到的曲线图中，具体什么样的表现是有问题的、不可以接受的，需要长时间的测试之后才可能发现一些问题；
1.例如连续测试2个小时或以上，然后看内存变化的区间范围，如图中内存的变化区间（最大值-最小值）为6M，可以认为6M的变化对app的影响并不大！如果长时间测试之后得出的变化区间在几百M，一般认为此时的内存消耗是有问题的。
2.由于每次软件发版都会测试内存，我们要在多次测试的过程中根据内存的变化得出一个经验值（参考值），然后对比本次测试所得的值和经验值，来判断本次测试所得的值是不是在合理区间内。
8，FPS&过渡渲染的概念和监控方法--分析页面卡慢的方法
A.FPS：Android应用的帧率FPS（每秒的帧数）是衡量应用流畅度的一个非常重要的指标，可以根据FPS对应用做一些优化，Android系统里定义每秒大于60帧是流畅的（一帧的完成时间是16ms），如果每帧的完成时间大于16ms，我们认为就有卡顿的现象。
1.获取方法：进入到开发者选项，可以看到有“GPU呈现模式分析”的选项，开启后即可以条形图和线形图的方法显示系统的界面响应速度，可以用以观察系统流畅度。那么要如何根据曲线判断系统是否流畅呢？实际上这个曲线表达的是GPU绘制每一帧界面的时间，只要不超过顶部绿线，都可以视为足够流畅。
开启GPU呈现模式分析
只要下方的曲线不超过绿线，都可以视之为流畅
使用系统自带方法测试流畅度的好处很多，首先是数据准确，系统肯定最知道自己的帧率如何；其次是不占资源，对流畅度测试的影响比较小。那么这个方法是否万无一失呢？其实还是有一些缺点的。比如说利用CPU渲染UI的App界面，就无法得到测试结果（当然这些界面基本无一例外卡顿无比，不用测也知道不流畅）；当系统停顿了一下，例如微博加载图片时，响应速度会大幅增加，曲线瞬间突破绿线——这情况不能说不流畅，因为这属于内容和界面先后响应的机制，如果光凭曲线是否突破绿线判断是否流畅，未免太过局限。所以，在测试应用程序的时候，需要一边操作应用，去直观的感受流畅度，一边观察曲线的走势，如果直观的感受流畅度差，并且曲线也大量的突破绿线，那么此时我们认为测试应用的流畅度低，需要优化。
1.在设置里打开GPU呈现模式分析。点击Android设备的“设置”->"开发者选项"，然后勾选“GPU显示配置文件”。
2.
2.1.点击Android设备的“设置”->"开发者选项"，然后勾选“GPU显示配置文件”。重启我们的应用。启动应用以后，在应用的页面上做滑动
2.2.lijiedeMacBook-Air:~ lijie$ adb shell dumpsys gfxinfo com.dianping.v1>fps.txt （com.dianping.v1即packagename）
2.数据分析：
打开生成的fps.txt，找到Profile data in ms这部分数据。
4.为了看得更直接，我们可以把数据放到Excel中，然后以图表的形式进行查看。
从图中可以看出来，我这个应用的流畅度是很低的，正常情况下每帧的完成时间在16ms左右，如果1秒60帧的话，而且Execute时间太长！所以是需要进行优化的。
a: "Draw" : 创建显示列表(display lists，记录所有view对象的绘制指令)的时间开销。
b: "Process" : 执行显示列表中绘制指令的时间。UI视窗中的View数量越多，需要执行的绘画命令就越多。
c: "Execute" : 将一帧图像交给合成器compostior的时间。这部分占用的时间通常比较少
测试方法二：FPS Meter测试安卓帧数
FPS Meter是一款非常实用的小软件，能够用数字实时显示安卓界面的每秒帧数，非常直观。此外，FPS Meter还可以显示最大帧数、最小帧数以及平均帧数，用来评价安卓流畅度极具价值。由于涉及到了系统功能，所以FPS Meter需要root。如果你打算尝试，请先root机后再使用。
FPS Meter的使用很简单，开启App后启动服务即可。在App内，你可以选择帧数显示的位置，以及是否开启平均帧数、最低/最高帧数显示。开启服务后，即可看到有帧数显示于界面上。这里要注意，使用FPS Meter测量帧数需要在开发者选项中停用HW叠加层才会比较准确。
FPS Meter可以显示最大最小帧数以及平均帧数
FPS Meter可以测试界面帧数，不过某些手机如果界面静止，帧数会为0。FPS Meter除了测量系统界面帧数外，还可以用来测量游戏的帧数，所以用FPS Meter来测试某部安卓机游戏性能多强也是个很好的选择。
当然，FPS Meter也并非十全十美。由于属于第三方App，所以可能会有一些兼容性问题。某些安卓机或者ROM使用FPS Meter可能会不兼容，即使成功开启了帧数显示也没法测量到准确数值，而某些设备使用FPS Meter甚至会死机。不过在大多数情况下，这款App还是相当值得信任的。
安卓在多个版本中都通过新技术提升了流畅度，比如说安卓2.3引入Dalvik、安卓4.0引入GPU界面绘制、安卓4.1引入黄油计划、安卓4.3引入Trim以及安卓4.4引入ART等等。
2.过渡渲染：
屏幕上的某个像素在同一帧的时间内被绘制了多次。简单言，app的一个页面所显示的效果是由像素一帧一帧绘制而成，过度绘制就是意味着这一帧被绘制多次。
如果是静态的布局，可能影响不是很大，如果是动态的，比如ListView，GridView,ViewPager等在性能上就会差一点，常见的比如listView上下滑动，过度绘制的情况下，就会出现卡顿，或者跳跃感很明显。 当然过度绘制肯定无法避免，我们只能减少不必要的绘制，那么如何看的出来，一个页面是否过度绘制呢？
下面我们来看一下，下面说的这个工具只有Android 4.2以上有此功能。
2.1.打开我们的手机设置--开发者选项--调试GPU过度绘制（可能有些手机不是这样的叫法，有的是显示GPU过度绘制，根据手机而来），选择显示过度绘制区域，此时手机页面会显示成这样，不要惊慌。。
这里给大家介绍下，绘制颜色的标识，从好到差：蓝色(1x次绘制)-》浅绿色(2x绘制)-》淡红色(3x绘制)-》红色(4x绘制)
2.2.怎么减少过度绘制
一般情况下，最好把绘制控制在2次以下，3次绘制有时候是不能避免的，尽量避免，4次的绘制基本上是不允许的。
怎么减少绘制是我们最关心的，我们来看一个图（自己项目里面的。。我们以图片下面的ListView为例子）从图上看的出来，被绘制3次甚至4次
我们来看下代码：listView和item
红色标记出来的，是问题的所在，背景颜色绘制了三次，最后一个是选择器，因为有点击效果，现在把前2个都给删掉，只留最后一个，现在我们看一下图片，看是不是达到预期的效果。
这里只是一个简单的例子，当然有很多原因组成，我们可以从以下几个方面着手：
第一：如果是相对比较复杂的布局，建议使用相对布局；
第二：如果需要多层嵌套，我们可以使用merge标签来减少嵌套；
第三：减少背景颜色的多次绘制；
第四：对于使用Selector当背景的Layout(比如ListView的Item,会使用Selector来标记点击,选择等不同的状态),可以将normal状态的color设置 为”@android:color/transparent”,来解决对应的问题；
第五：当一个页面有多种不同的显示效果，最常见的是listview 中的多种item布局，我们可以采用抽取的方式，等等。
下面再介绍以下Android studio自带的工具，
首先 打开 Android Device mointor，找到 Hierarychy view （这里我简称 视图树）
将你要查看的项目运行到模拟器或者真机上，在Android device mointor 上windows 找到当前的模拟器或者真机，找到当前的项目，
如图：点击当前项目某一个布局，在View里面会显示当前这个布局的各个节点图，然后点击3（profile node）,在视图里面就会显示4上面的三个点
他们分别表示 测量 布局 绘制，再次点击的时候，我们就可以看到子节点上着三个圆点在变化，他有3个颜色，绿色，黄色，红色，红色代表着耗时最长，也就意味着我们需要优化，我们可以不断点击，查看 测量布局以及绘制所需要的时间，从而优化。
以上，简单介绍了Android app性能测试的几个指标，希望对大家有帮助。