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开销导致的耗电情况