转载地址：https://www.zybuluo.com/defias/note/592309
Android篇
1. 性能测试
-
Android性能测试分为两类：
1、一类为rom版本（系统）的性能测试
2、一类为应用app的性能测试
-
Android的app性能测试包括的测试项比如：
1、资源消耗
2、内存泄露
3、电量功耗
4、耗时
5、网络流量消耗
6、移动终端相关资源利用率
7、帧率
8、渲染等等....
-
工具：
（工具的原理都是基于调用android底层的一些api来获取到测试所用到的值）GT等
-
测试方法：
1、设计场景 ：手工或自动化场景
2、获取数据：可获取的数据包括：内存、cpu、电量功耗、hprof（内存泄露分析文件）、响应时间等等。。。。配合手工或自动化场景来获取数据（最好多取几次而且每次配合不同的设备看平均值）作为最后的对比分析
3、结果分析 ：拿到数据后分析哪些模块的数据异常再去Check code定位问题的原因
-
Android系统的几种场景状态：
1、空闲状态： 指打开应用后，点击home键让应用后台运行，此时应用处于的状态叫做空闲
2、中等规格和满规格状态：中等规格和满规格指的是对应用的操作时间的间隔长短不一，中等规格时间较长，满规格时间较短
1.1 内存篇
背景知识：
C/C++申请的内存空间在native heap中，而java申请的内存空间则在dalvik heap中。这个是因为Android系统对dalvik的vmheapsize作了硬性限制，当java进程申请的java空间超过阈值时，就会抛出OOM异常（这个阈值可以是48M、24M、16M等，视机型而定），可以通过adb shell getprop | grep dalvik.vm.heapgrowthlimit查看此值。也就是说，程序发生OMM并不表示RAM不足，而是因为程序申请的java heap对象超过了dalvik vmheapgrowthlimit。也就是说，在RAM充足的情况下，也可能发生OOM。
这样的设计似乎有些不合理，但是Google为什么这样做呢？这样设计的目的是为了让Android系统能同时让比较多的进程常驻内存，这样程序启动时就不用每次都重新加载到内存，能够给用户更快的响应。迫使每个应用程序使用较小的内存，移动设备非常有限的RAM就能使比较多的app常驻其中。但是有一些大型应用程序是无法忍受vmheapgrowthlimit的限制的
实际上dalvik.vm.heapgrowthlimit和dalvik.vm.heapsize都是java虚拟机的最大内存限制，应用如果不想在dalvikheap达到heapgrowthlimit限制的时候出现OOM，需要在Manifest中的application标签中声明android：largeHeap=“true”，声明后应用dalvik heap达到heapsize的时候才会出现OOM
-
内存测试中的测试子项：
1）空闲状态下的应用内存消耗情况
2）中等规格状态下的应用内存消耗情况
3）满规格状态下的应用内存消耗情况
4）应用内存峰值情况
5）应用内存泄露情况
6）应用是否常驻内存
7）压力测试后的内存使用情况
-
内存问题现象：
1）内存抖动
2）大内存对象被分配
3）内存不断增长
4）频繁GC
-
内存数据获取：
1、各种linux命令（top、free、meminfo…）
2、通过dumpsys
adb shell dumpsys meminfo [pakagename | pid]
3、通过/system/xbin/procrank工具
adb shell procrank
说明：
VSS – Virtual Set Size 虚拟耗用内存（包含共享库占用的内存）
RSS – Resident Set Size 实际使用物理内存（包含共享库占用的内存）
PSS – Proportional Set Size 实际使用的物理内存（比例分配共享库占用的内存）
USS – Unique Set Size 进程独自占用的物理内存（不包含共享库占用的内存） USS 是针对某个进程开始有可疑内存泄露的情况，是一个程序启动了会产生的虚拟内存，一旦这个程序进程杀掉就会释放。不过USS需要通过root的手机。一般没有root的手机我们可以获取PSS。而PSS通过如下命令来获取：<
