本文内容：基于Android基础性能检测与分析

版权声明：本文为原创文章，未经允许不得转载

博客地址：http://blog.csdn.net/kevindgk

前言
UI性能分析
应用启动时间计算以及程序启动白屏问题
内存分析
耗电量分析
性能检测和分析工具
云测平台
引用
联系方式

前言

最近一段时间以来，开始深入学习App的性能检测、分析和优化等方面的内容，接触的越多越发现相关的技能点太多了，而且说起来容易做起来难。尤其是学习到持续自动化框架的方案和搭建，才觉得自己了解的不过是冰山一角。只能说，学无止境，任重而道远!

不过，在学习的过程中，发现了很多非常实用的技巧以及很棒的性能优化和检测工具，能够帮助自己及时发现程序的一些问题，比如UI界面的性能、启动时间的优化、OOM异常、内存泄露、电量分析等，并且对自己的软件的整体性能有一个综合的分析。

本文主要的研究方向都是来自与《Android 群英传之神兵利器》，只不过小编整理了内部较为实用的内容，然后深入研究了一下。

GO！GO！GO！

1.UI性能分析

目标：减少绘图和显示数据的等待时间，使帧率更加平稳、连贯，给人更好的视觉体验。

16msUI绘制准则

一般来说，Android设备的屏幕刷新率为60帧/s，要保持画面流畅不卡顿，要求每一帧的时间超过1000/60=16.6ms，这就是16ms的黄金准则，如果中间的某些帧的渲染时间超过16ms，就会导致这段时间的画面发生了跳帧，因此原本流畅的画面变发生了卡顿。

在Android 5.0之后，系统增加了Render Thread(渲染线程)，来进行异步绘制，即使某一帧发生延迟也不会影响下一帧的绘制。

在手机的开发者选项中打开Pofile GPU Rending(剖析GPU渲染)选项，就可以看到底部的柱状图，表示的就是渲染的时间。一条绿色的横线表示的就是16ms(17ms)基准线，如果高于该线，就表示人眼会觉得绘制的不流畅。通过这种方式，就可以数据化的分析界面的流畅度，然后再逐步找到问题所在，优化我们的界面。

在Android Studio中，Android Monitor->Monitors->GPU界面也可以看到该信息，但是要求安装AS插件，并且要求向手机安装追踪GPU渲染数据的应用，要求手机有root权限才可以。

布局

如果使用LinearLayout，则一定要保证层级不能太深，google官方建议用户界面的View不宜超过8层；

如果使用RelativeLayout，则一定要尽量避免嵌套，因为相对布局在测量的时候往往需要多次测量，嵌套时十分耗时。

eg：可以使用include标签进行view的复用；使用drawableleft方法来进行控件组合。

最根本的还是尽量减少View的数量。

图形过度绘制

如果控件出现了叠加，而且都有背景，就会造成重叠部分多次绘制，浪费了资源和时间。可以打开开发者选项中的Debug GPU Overdraw，可以检测过渡绘制，即一块区域经过了几次叠加绘制：

原色：没有过度绘制

蓝色：1次过度绘制

绿色：2次过度绘制

粉色：3次过度绘制

红色：>=4次过度绘制

修改建议：

①控件尽量避免重叠摆放；

②当控件与主背景色颜色相同时，移除不需要背景色；

③自定义view在绘制的时候，使用clipRect属性减少重绘区域。

2.应用启动时间计算以及程序启动白屏问题

这里的应用启动时间指的是，安装完应用以后的第一次启动，这也是评判一个App性能好坏的重要指标，直接影响用户的对应用的第一印象。

可以通过ADB命令来统计应用从打开到开启第一个界面的时间：

adb shell am start -W com.dgk.test/.login.SplashActivity

该命令是用Activity Manager去开启界面，然后统计时间，最终终端会打印时间：

Starting: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] cmp=com.dgk.test/.login.SplashActivity }
Status: ok
Activity: com.dgk.test/.login.SplashActivity
ThisTime: 1212  // 最后一个启动的Activity的启动耗时
TotalTime: 1212 // 自己的所有Activity的启动耗时
WaitTime: 1219  // AMS启动App的Activity的总时间，包含当前Activity的onPause()和自己Activty的启动
Complete

如果第二次启动你会发现，基本上也就在200-500ms之间。

注意：如果是debug版本，第一次启动的时间会有很长时间的白屏，有时候能达到10s左右。这个是因为为了要让Instant Run功能可以正常工作，程序首次安装的时候需要做非常多的初始化工作，使得后期开发效率增大。所以说，这个是正常的，因为在release版本就没有这个情况了。最好不要直接禁用掉该功能，毕竟调试阶段以开发为主，利大于弊。

3.内存分析

内存优化原则

①在对象不需要的时候确保能够及时回收；

②尽量复用需要多次使用的对象；

内存区分

寄存器 Registers：用于存储指令、地址、数据；
栈Stack：存放基本类型的数据、对象的应用和函数地址等，系统控制，使用完毕后由虚拟机释放该变量占用的空间；
堆Heap：存放对象本身和数组，开发者创建，生命周期结束后由GC回收；
静态域static field：存储静态变量；
常量池constant pool：存储常量。

内存分析

adb shell getprop|findstr dalvik.vm

可以查看到手机能够给App分配的实际物理内存大小，这些数值跟手机相关，都是定义在系统的ROM中的系统属性，在编译的时候就已经写入了系统：

dalvik.vm.heapgrowthlimit 256m // 单个App的分配物理内存最大值为256MB
dalvik.vm.heapsize 512m // 单个App申请了large heap后的最大值为512MB
虚拟机内存：可以通过上面提到过的adb shell dumpsys meminfo 包名来获取时时的内存信息，但是Android Studio已经在Android Monitor中的Monitors中查看Memory窗口中查看内存的波动信息，该内存指的是Heap Alloc，即分配的虚拟机堆内存大小，我的测试程序在25-30M浮动，如果开多线程或者调用扫描二维码，会达到近40M。

该功能被集成在了Android Studio中：

当连接上ADB，有进程在监听的时候，点击途中的图标就可以看到内存信息：

重点关注一下图中加了注释的和圈起来的数据就可以了，很直白的就可以看到该程序：

实际分配的内存：78682KB = 76.8MB
虚拟机分配的内存：26328KB = 25.6MB，已经分配出去使用了23733KB = 23.2MB，使用率为90%
内存中的类：
    Activity：0
    APPContexts：2
    。。。
数据库：0

当程序一直运行的时候，这个数据会不断的变化，如果想要仅仅简单的看一下虚拟机的内存，可以从AS的Monitors里看，如果想要看详细的信息，可以不断的执行下面的命令来不断的更新内存状态

adb shell dumpsys meminfo 包名

在这个过程中，重点关注一下PSS Total，物理内存总大小，以及各个对象的数量。

分析场景1：

让App界面多次开启和关闭，查看Views和Activities的数量是否在退出后变回开启前的数量，比如在测试的时候，第一次进入程序SplashActivity->MainActivity，由于SplashActivity finish了，这个时候应该显示只有1个界面。此时，我打开了一个WebViewActivity，然后又关掉了，这个时候界面仍然显示2个界面。所以我不断的打开和关闭H5界面，发现内存增长的特别快，很快就到了150MB，按照这个速度，100下估计就能达到该手机的应用可分配的最大阈值256MB了。

于是，问题来了，说明WebViewActivity并没有被销毁掉，往往第一反应就是发生了内存泄露。查看了一下代码，由于H5和Android有很多次业务交互，在JSObject中持有了WebViewActivity的引用，当Activity onDestroy的时候，仅仅是销毁了视图而已，内存并没有回收。所以我将WebViewActivity传递为Context，然后测试了一下，发现是可以正常回收的，但是我还需要调用Activity的逻辑，所以就使用了大量的接口。虽然稍微麻烦了一些，但是解决了内存泄露的问题。

分析场景2：

那么，如果获取更多的内存，避免程序OOM异常呢？

①开多进程：因为每个进程都会分配一块内存，加起来就很多，但是也会造成更多的系统开销和跨进程沟通问题；

②使用本地堆内存：Android系统限制的是Java Heap的大小，而Native Heap的内存分配是由系统分配的不受限制，所以可以通过jni来申请分配heap。例如Fresco就是通过在Native Heap上进行内存分配来减少使用虚拟机内存，从而避免因图像占用内存过大而造成的OOM异常；

③使用OpenGL

④申请LargeHeap：在清单文件中设置LargeHeap参数来给App分配更多的内存，但是也会增加了GC的难度，所以有利也有弊。