1.开机时间：
一般测试的方法是人工计时，这的确是个不错的方法，但是耗时耗力，最重要的人工测试误差较大，而我经过查问，知道了在adb工具下有个命令：
adb shell cat /proc/bootprof
（说白了也就是查看Linux内黑下的proc文件夹中的内容）是可以反映出启动过程中的每个进程消耗了多少时间，依此叠加来显示开机时间。
2.主页滑动时的刷新率（home_fps）
一般来说，桌面是用户接触最多的一个场景，而桌面滑动的流畅性是至关重要的一个体验标准。即使使用当今最强的CPU，系统优化不好，桌面程序写的不行，要卡还是得卡，这个用安卓的朋友都有很大的体验。它的测试在MTK的平台下，笔者借助的是SurfaceFlinger，只要执行：
adb logcat -s SurfaceFlinger | findstr fps
当快速滑动住页面的时候，屏幕上就会闪现当前的fps值，即屏幕刷新率。一般来说，只有fps达到60的时候，人眼才会感觉很丝滑流畅，没有卡顿，可惜笔者测试了几个机器，都没有达到这个水准的。
3.应用第一次启动时间
应用第一次启动的时候，内存中没有任何该应用的信息，是从头开始，才能正确反应速度的快慢。
②通过eclipse的DDMS工具，过滤log，过滤的tag值为ActivityManager，Level值为I，在启动的时候可以找启动应用所需要的时间，经过验证与方法1时间长短是一致的
4.非滑动下的fps，这个就是你日常操作的时候的流畅度，有专门的软件：fps2d 可以测试
2.1 性能指标
a，响应时间/加载速度
b，动画帧率
图片处理器每秒刷新的帧数(FPS)，可用来指示页面是否平滑的渲染。高的帧率可以得到更流畅，更逼真的动画，不过帧率达到60fps以上，人眼主观感受到的差别就不大了。所以以60fps作为衡量标准，即要求每一帧刷新的时间小于16ms，这样才能保证滑动中平滑的流畅度。
c，内存使用
在android系统中，每个APP进程除了同其他进程共享(shared dirty)外，还独用私有内存(private dirty)，通常我们使用PSS(=私有内存+比例分配共享内存)来衡量一个APP的内存开销。移动设备的内存资源是非常有限，为每个APP进程分配的私有内存也是有限制。一方面我们要合理的申请内存使用，以免导致频繁的GC影响性能和大对象申请发生内存溢出；另一方面，我们要及时释放内存，以免发生内存泄漏。
d，电量
相对于PC来说，移动设备的电池电量是非常有限的，保持持久的续航能力尤为重要。另外，android的很多特性都比较耗电(如屏幕，GPS，sensor传感器，唤醒机制，CPU，连网等的使用)，我们必须要慎重检查APP的电量使用，以免导致用户手机耗电发热，带来不良体验。
e，流量
目前的网络类型包含2G\3G\4G\wifi，其中还有不同运营商的区分，我们在APP的使用中经常遇到大资源，重复请求，调用响应慢，调用失败等各种情况。在不同的网络类型之下，我们不仅要控制流量使用，还需要加快请求的响应。
f，ANR
在android应用程序中，如果主线程(即UI线程)在超时间内对用户输入时间没有处理完毕，就会出现Application note responding弹出框，用户可以选择等待或者强制关闭来杀死进程。
g，app crash闪退
由于空指针，内存泄漏，数组越界等等编码问题，导致应用程序在移动设备上运行异常，发生闪退，进程被杀。
频繁发生的问题会导致用户体验差，最终使用户卸载APP。
2.2 适配机型
对市面上的android机型活跃用户数量进行统计。将其划分为高，中，中低，低4类型机，分别选择其中使用量最大的作为代表机型，进行细致深入的性能测试分析。
也可以使用虚拟机进行模拟。
2.3 网络
目前网络有2G,2G/3G，3G，3G/4G，4G，wifi。通过统计查看每个网路的使用量。 其中弱网络也许关注。特别是弱网络+低端机型，性能的瓶颈尤其容易碰触到。
(问题: 什么情况或者什么样的网络传输速度可以称为弱网络?)
3 场景设计
具体哪些场景需要性能测试，可以初步依据下面角度进行判断:
1，业务层面，用户最核心基础的模块。
2，新增的基础逻辑，例如登入模块，大量的用户段时间内访问，如此必须保证性能
3，活动需求，因为活动上的新逻辑，存在较的用户访问，需要尽力提升用户体验
4，用户体验不好的模块
当场景A需要进行客户端性能测试，那么个性能指标唯独的表现都需要关心，排除改场景中是否存在下面这些性能问题:
a，页面加载是否缓慢
b，滑动是否流畅
c，是否存在在内存泄露
d，流量开销大不大
e，cpu占用高不高
f，电量消耗是否合理
g，是否有异常的crash和ANR
h，低端机下ANR是否加剧
开发相关:
a，主线程有没有不合理的io调用
b，有没有重复的网络请求
c，图片大小有没有控制好
测试相关:
弱网络下的加载速度是否可接受
网络切换或者断网时是否有异常
机型适配中是否有特殊情况等
4 监控分析
4.1 加载响应速度
在测试之前，我们需要了解一下activity的生命周期，比如从activity1跳转到activity2，在我们点击触发之后，activity1是如何被暂停而activity2又是如何被创建执行的，过程中那些activity方法被调用到(也可以结合adb logcat -v time -b events查看对应activity切换事件)。
测试执行中，发现问题的方法有很多，肉眼也不失是一种办法，如果想要更准确，可以通过埋点进行度量。另外adb logcat -v time -b events监控的am_activity_launch_time时间也可以参加，不过它仅仅统计到Activity.onResume()的调用。
一旦发现耗时问题，可以通过详细的埋点来分析定位耗时的方法逻辑，当然还有一个更值得推荐的工具: traceview, 下面我们稍稍介绍一下它的使用。
1) 安装可debug的apk包，启动DDMS，找到对应进程，按下头部工具栏按钮"Start method profiling"，如图4-1所示，一旦其变灰，开始监控。
2) 操作app，完成被测业务后，再次点击头部工具按钮栏的对应按钮，使其变红。此时，监控结束，会自动生成解析后的trace文件
另外不通过DDMS，直接在app代码中植入Debug类的StartMonitor和StopMonitor方法，也可在sdcard中得到trace文件，pull文件到电脑上，用sdk tools下的traceview命令打开trace文件即可。
4.2 滑动流畅度
4.2.1 View渲染原理
Android UI视图窗口可以有N多个View组成，其中ViewGroup是一个特殊的View，继承自android.view.view, 类似容器管理其子View和子ViewGroup。
4.2.2 流程度测试分析工具
4.2.2.1 gfxinfo
Android4.1引入gfxinfo，用于监控分析GPU profiling信息，Draw+Process+Execute是一帧的绘制渲染时间，如果持续超过16ms，用户会明显感知卡顿:
a: "Draw" : 创建显示列表(display lists，记录所有view对象的绘制指令)的时间开销。
b: "Process" : 执行显示列表中绘制指令的时间。UI视窗中的View数量越多，需要执行的绘画命令就越多。
c: "Execute" : 将一帧图像交给合成器compostior的时间。这部分占用的时间通常比较少
使用方法:
1) 打开android手机 “设置->开发者选项->GPU呈现模式分析"
2) 执行测试场景(比如滑动页面)后，执行adb shell dumpsys gfxinfo packageName
3) 找到"Profile data in ms"的Draw Process Exceute这三列数据，Excel做出表格，sum出每列的总GPU时间
4) 针对时间大不幅度>16ms，可以使用systrace进行分析定位瓶颈。
4.2.2.2 systrace
Systrace是Android4.1引入的一套用于做性能分析的工具，使用它来诊断绘图卡顿问题是非常有效的。生成的trace.html文件中可以在同一时间轴上清晰的对比进程线程的运行内容和状态，展示VSYNC间隔, SurfaceFlinger进程信息,调用方法的执行耗时等，让上下文运行状态的分析更简单方便。
4.2.2.3 Show GPU overdraw
显示GPU过度渲染，从最美到最差依次是: 蓝，绿，淡红，红
a，没有颜色意味着没有透支。像素只画了一次。
b，蓝色 : 意味着透支1倍。像素绘制了2次。
c，绿色：意味着透支2呗。像素绘制了3此
d，淡红：意味着透支3倍。像素绘制了4次
e，红：意味着透支4倍。像素绘制了5次或者更多
4.3 内存使用
虽然Android L 版本正式使用ART代替Dalvik虚拟机运行机制，但是考虑到当前市场份额，我们再次仍重要关注Dalvik虚拟机内存管理机制。需要注意：在Android2.×系统上，Bitmaps存储在Navtive memory中，有recycle()进行释放，而android3.0之后，bitmaps则存储在dalvik heap中，由GC垃圾惠州机制进行回收释放。
android app的内存问题主要发生在dalvik heap和navtive heap上。而dalvik heap的内存问题最为常见: 比如Activity内存泄漏，Bitmap内存泄漏，Bitmaps导致的内存溢出。
我们先了解一下对象和引用的关系，然后通过GC log看一下GC垃圾回收的集中模型
4.4 CPU 监控
在CPU持续使用较高或者不正常时，我们首先要确定APP相关进程的的占用，找到有问题的进程，在进一步跟进到具体线程，所以排除方位。比借助traceview和systemtrace进行分析。
4.5 流量
通常来说APP流量使用最大的两部分是: 服务端api交互，图片/css/js等cdn静态资源。减少这两个部分的资源个数和资源大小，能有效的限制流量的使用。另外还需要严格控制后台静默时流量的使用。
4.5.1 流量统计工具
DDMS Network Statistics
3款代理工具: fiddler, charles, wmock
抓包工具 : tcpdump
4.5.3 弱网络模拟&网络切换测试
使用 charles throttle settings模拟，能够对上下行带宽，丢包率，延迟等网络参数进行设置
4.6 耗电量
4.6.1 耗电原理
手机中的每个部件运行时对应的能耗值都放在power_profile.xml文件中，而系统的 设置->电池->使用情况中，统计的能耗使用情况也是以power_profile.xml的value作为基础参数的。通过命令监控app个部件的使用时长，然后结合设备耗电的基础参宿进行加权计算，即可得到app使用的耗电量。
4.6.2 电量测试监控方法
充电关注前台静默和后台静默。即APP没有被操作，但却偷偷的在耗电。
a，系统自带电池使用监控工具
b，adb shell dumpsys batteryinfo\batterystat 查看各部件耗时
4.6.3 查看CPU开销导致的耗电情况
转载自：
http://blog.csdn.net/tianxuhong/article/details/50911186
http://blog.csdn.net/tianxuhong/article/details/50911186
