Android进阶-Android性能优化

1、布局优化

系统在渲染UI界面的时候讲消耗大量的资源，一个好的UI不仅应该具有良好的视觉效果，更应该具有良好的使用体验，因此布局优化就显得非常重要。

1.1、Android UI渲染机制

人眼所感觉的流畅画面，需要画面的帧数达到40帧每秒到60帧每秒，而最佳fps大概在60fps左右，这也是评价一个显卡性能高低的标准之一。
在Android中，系统通过VSYNC信号触发对UI的渲染、重绘，其间隔时间是16ms。这个16ms其实就是1000ms中显示60帧画面的单位时间，即1000/60。
如果不能在16ms以内完成绘制，那么就会造成丢帧显现，这就会导致画面卡顿的原因。
Android系统提供了检测UI渲染时间的工具，打开“开发者选项”，选择“GPU呈现模式分析”，并选中“在屏幕上显示为条形图”的选项，这时候就会显示如下图

每一条柱状线都包含三部分：

• 蓝色代表测量绘制Display List的时间；
• 红色代表OpenGL渲染Display List所需要的时间；
• 蓝色代表CPU等待GPU处理的时间；

中间绿色横线代表VSYNC时间16ms，需要尽量将所有条形图都控制这条绿色线之下。

1.2、避免Overdraw

Overdraw，过渡绘制会浪费很多的CPU、GPU资源，例如系统默认会绘制Activity的背景，而如果再给布局绘制了重叠的背景，那么默认Activity的背景就属于无效的过渡绘制—Overdraw。
Android系统在开发者选项中提供了这样一个检测工具—“调试GPU过渡绘制”，并选中“显示过渡绘制区域”。选中之后可以通过界面上的颜色来判断Overdraw的次数，这里借助Google开发者博客上的一张图来演示。

通过这个工具可以查看当前区域中的绘制次数，从而尽量的优化绘图层次，尽量增大蓝色区域，减少红色区域。

1.3、优化布局层级

在Android中，系统对View进行测量、布局和绘制时，都是通过对View数的遍历来进行操作的。如果一个View树的高度太高，就会严重影响测量、布局和绘制的速度，因此优化布局的第一个方法就是降低View树的高度，Google也在API文档中建议View树的高度不宜超过10层。
在现在版本的Android中，Google已经使用RelativeLayout来替代LineraLayout作为默认的跟布局，其原因就是通过扁平的RelativeLayout来降低通过LineraLayout嵌套所产生布局树的高度，从而提高UI渲染的效率。

1.4、避免嵌套过多无用布局

嵌套的布局会让View树的高度越来越高，因此在布局时，需要根据自身布局的特点来选择不同的Layout组件，从而避免通过某一种Layout组件来实现功能时的局限性，从而造成嵌套过多的情况发生。

1.4.1、使用<include>标签重用Layout

在一个应用程序界面中，为了风格上的统一，很多界面都会存在一些共通的UI，比如一个应用的Topbar、Bottombar等。对于这些共通的UI，如果在每个界面中都来复制一段这样的代码，不仅不利于后期的维护，更增加了程序的冗余度。因此，可以使用<include>标签来定义这样一个共通的UI。

下面用案例演示一下<include>的使用，首先编写

common_ui.xml文件：
<?xml version="1.0" encoding="utf-8"?>
<TextView 
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="0dp"
    android:layout_height="0dp"
    android:text="this is a common ui"
    android:textSize="30sp"/>

接着在布局中使用<include>标签：

<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    tools:context="com.itman.perforoptimizingdemo.MainActivity" >

    <TextView
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="@string/hello_world" />

    <include
        layout="@layout/common_ui"
        android:layout_alignParentBottom="true"
        android:layout_width="match_parent"
        android:layout_height="wrap_content" />
</RelativeLayout>

这样就完成了<include>的使用，注意的是里面的属性会覆盖掉common_ui里面相同的属性。运行结果如下：

1.4.2、使用<ViewStub>实现View的延迟加载

可以使用标签来实现对一个View的引用并实现延迟加载，是一个非常轻量级的组件，它不仅不可视，而且大小为0。
下面通过案例演示一下，先准备not_often_use.xml文件：

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical" >

    <TextView
        android:id="@+id/tv"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="not often use"
        android:textSize="30sp" />

</LinearLayout>

在布局中使用：

<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    tools:context="com.itman.perforoptimizingdemo.ViewStubActivity" >

    <ViewStub
        android:id="@+id/not_often_use"
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:layout="@layout/not_often_use" />

</RelativeLayout>

这是加载布局，并没有显示出来，这时有两种方法来重新显示这个View

• VISIBLE

ViewStub mViewStub = (ViewStub) findViewById(R.id.not_often_use);
mViewStub.setVisibility(View.VISIBLE);

• inflate

ViewStub mViewStub = (ViewStub) findViewById(R.id.not_often_use);
View inflateView = mViewStub.inflate();

这两种方法唯一的区别就是inflate()方法可以返回引用的布局，从而可以再通过View.findViewById()方法来找到对应的控件

View inflateView = mViewStub.inflate();
TextView textView = (TextView) inflateView.findViewById(R.id.tv);
textView.setText("Haha!");

运行结果：

不管使用哪种方法，一旦<ViewStub>被设置为可见或是被inflate了，<ViewStub>就不存在了，取而代之的是被inflate的Layout，并将这个Layout的ID重新设置为<ViewStub>中通过android:inflateView属性所指定的ID，这就是为什么两次调用inflate()方法会报错的原因。

<ViewStub>标签与View.GONE有什么区别：
他们的共同点都是初始时不会显示，但是<ViewStub>标签只会在显示时，才去渲染整个布局。而View.GONE，在初始化布局树的时候就已经添加在布局树上了，相比之下<ViewStub>标签的布局具有更高的效率。

1.5、Hidrarchy Viewer

• 通常情况下，Hidrarchy Viewer无法在真机上进行使用，它只能在工厂的Demo即和模拟器上使用，即非加密过的设备。
• Google的“大神”—Romain Guy 提供了一个开源项目View
  Server，通过这个程序可以让普通手机也能使用Hidrarchy Viewer，程序的网址：
  http://github.com/romainguy/ViewServer
• Hierarchy Viewer位于sdk\tools目录下，在命令行中输入hierarchyviewer.bat，启动程序。
• 关于Hierarchy Viewer的使用可查看下面的博客：Hierarchy Viewer

2、内存的优化

站在用户的角度想，不管是什么应用，都应该把内存效率、用户体验放在首位。

2.1、什么是内存

由于Android应用的沙箱机制，每个应用所分配的内存大小是有限度的，内存太低就会触发LMK—Low Memory Killer机制。这里说的内存通常是指手机的RAM，它包括以下几个部分

• 寄存器（Registers）

速度最快的存储场所，因为寄存器位于处理器内部，在程序中无法控制。

• 栈（Stack）

存放基本类型的数据和对象的引用，但对象本身不存放在栈中，而是存放在堆中。

• 堆（Heap）

堆内存用来存放由new创建的对象和数组。在堆中分配的内存，有Java虚拟机的自动垃圾回收器（GC）来管理

• 静态存储区域（Static Field）

静态存储区域就是指在固定的位置存放应用程序运行时一直存在的数据，Java在内存中专门划分一个静态存储区域来管理一些特殊的数据变量，如静态的数据变量

• 常量池（Constant Pool）

JVM虚拟机必须为每个被装在的类型维护一个常量池。常量池就是该类型所用到常量的一个有序集合，包括直接常量（基本类型，String）和对其他类型、字段和方法的符号引用。

在以上的概念中最容易搞错的是堆和栈：
栈：当定义一个变量时，JVM虚拟机就会在栈中为该变量分配内存空间，当该变量作用域结束后，这部分内存控件会被用作新的空间进行分配
堆：使用new的方式创建一个变量，那么就会在堆中为这个对象分配内存控件，即使该对象的作用域结束，这部分内存也不会立即被回收，而是等待系统的GC进行回收

在程序中，可以使用代码来获取堆的大小：

ActivityManager manager = (ActivityManager) getSystemService(Context.ACTIVITY_SERVICE);
int heapSize = manager.getLargeMemoryClass();

2.2、获得Android系统内存信息

Process Stats：是系统内存监视服务，通过”Setting-Developer-options-Process Stats”来开启这个功能，也可以使用Dumpsys命令来获取这些信息。

adb shell dumpsys procstats

Meminfo：是系统上的一个非常重要的内存监视工具，通过”Settings-Apps-Running”中打开这个界面，也可以使用Dumpsys命令来获取这些信息。

adb shell dumpsys meminfo

2.3、内存回收

Java对于C、C++这类语言最大的有时就是不用手动管理系统资源，Java创建了垃圾回收器线程（Garbage Collection Thread）来自动进行资源的管理。
但是也带来很多问题，Java的GC是系统自动进行的，但何时进行祛湿开发者无法控制的，即使调用System.gc()方法，也只是建议系统进行GC，但系统是否采纳你的建议，那就不一定了。
JVM虚拟机虽然能够自动控制GC，但是再强大的算法，也难免会存在部分对象忘记回收的现象发生，这就是造成内存泄露的原因。

2.4、内存优化实例

2.4.1、Bitmap优化

Bitmap是造成内存占用过高甚至是OOM（Out Of Memory）的最大威胁。下面给出一些使用Bitmap的小技巧

• 使用适当的分辨率和大小的图片

在图片列表界面可以使用图片的索罗图thumbnails，而在显示详细图片的时候在显示原图；或者在堆图像要求不高的地方，尽量降低图片的精度

• 及时回收内存

一旦使用完Bitmap后，一定要及时使用bitmap.recycle()方法释放内存资源。自Android 3.0之后，由于Bitmap被放置到堆中，其内存由GC管理，就不需要进行释放了。

• 使用图片缓存

通过内存缓存（LruCache）和硬盘缓存（DiskLruCache）可以更好地使用Bitmap。

2.4.2、代码优化

任何Java类，都讲占用大约500字节的内存空间。创建一个类的实例会小号大约15字节的内存。从代码的实现方式上，也可以对内存进行优化，这里同样总结了一些小的技巧。

• 对常量使用static修饰符。
• 使用静态方法，静态方法会比普通方法提高15%左右的访问速度
• 减少不必要的成员变量，这点在Android Lint工具上已经集成检测了，如果一个变量可以定义为局部变量，则会建议你不要定义为成员变量
• 减少不必要的对象，使用基础类型会比使用对象更加节省资源，同时更应该避免频繁创建短作用域的变量。
• 尽量不要使用枚举，少用迭代器
• 对Cursor、Receiver、Sensor、File等对象，要非常注意对他们的创建、回收与注册、解注册
• 避免使用IOC框架，IOC通常使用注解、反射来进行实现，虽然现在Java对反射的效率已经进行了很好的优化，但大量使用反射依然会带来性能的下降
• 使用RenderScript、OpenGL来进行非常复杂的绘图操作
• 使用Surface来替代View进行大量、频繁的绘图操作
• 尽量使用视图缓存，而不是每次都执行inflate()方法解析视图

3、Lint工具

Android Lint工具是Android Studio中集成的一个Android代码提示工具，它可以给你的布局、代码提供非常强大的帮助。有兴趣的自己再去深究。

4、使用Android Studio的Memory Monitor工具

Memory Monitor工具是Android Studio自带的一个内存监视工具，它可以很好地帮助我们进行内存实时分析，通过点击Android Studio右下角的“Memory Monitor”标签，打开Memory Monitor工具。

5、使用TraceView工具优化App性能

TraceView是一个Android下的可视化性能调查工具，它是用来分析TraceView日志。

5.1、生成TraceView日志的两种方法

• 利用Debug类帮助我们生成日志文件
• 利用Android Device Monitor工具辅助生成日志文件

5.1.1、通过代码生成精确范围的TraceView日志

使用Debug类的方法开启TraceView监听。通过调用Debug.startMethodTracing()方法开启监听，通过调用Debug.stopMethodTracing()方法结束监听。
通常在onCreate()方法里面调用startMethodTracing()方法来开始监听，在onDestroy()方法里调用stopMethodTracing()方法来结束监听。
TraceView的日志将会保存到”/sdcard/dmtrace.trace”目录下，因此需要增加权限：

<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"/>

当然，除了使用默认的输出日志名，也可以自定义路径和日志名。
当要监听的内容执行完毕后，可以通过ADB命令将日志文件到处到本地：

adb pull /sdcard/trace_log.trace/local/LOG/

5.1.2、通过Android Device Monitor生成TraceView日志

打开Android Studio的Android Device Monitor工具，选择要调试的进程，点击工具栏中的“start method profiling”按钮。TraceView提供了两种监听方式：

• 整体监听

跟踪内一个方法执行的全部过程，这种方式资源消耗较大。

• 抽样监听

按照指定的频率来进行超欧阳调查，这种方式需要执行较长时间来获取准确的样本数据。

5.2、打开TraceView日志

对于导出的TraceView日志文件，可以使用SDK中的”sdk\tools\traceview.bat”工具来打开。或者在ADM工具中，在”File”菜单下，选择”Open File…”选项打开TraceView日志文件。

5.3、分析TraceView日志

TraceView的分析界面分为两部分，上面是用于显示方法执行时间的时间轴区域，下面是显示详细信息的profile区域。

时间轴区域：时间轴区域显示了不同线程在不同的时间段内的执行情况。
在时间轴中，每一行都代表了一个独立的线程。
使用鼠标滚轮可以放大时间轴
不同的色块代表了不同的执行方法，色块的长度，代表了方法所执行的时间。

profile区域：显示了你选择的色块所代表的方法在该色块所处的时间段内的性能分析。

• Incl CPU Time：某方法占用CPU的时间
• Excl CPU Time：某方法本身（不包含子方法）占用CPU的时间
• Incl Real Time：某方法真正执行的时间
• Excl Real Time：某方法本身（不包含子方法）真正执行的时间
• Calls+RecurCalls：调用次数+递归回调的次数

每个时间都包含两列，一个是实际的时间，另一个是百分比，如果占用时间长且Calls+RecurCalls次数少，那么就可以列为怀疑对象

6、使用MAT工具分析App内存状态

MAT（Memory Analyzer Tool）工具是一个分析内存的强力助手

6.1、生成HPROF文件

首先打开Android Device Monitor工具，选择要监听的线程，并点击菜单栏中的“Update Heap”按钮。

在Heap标签中点击“Cause GC”按钮，就会显示当前内存状态

这里有一个判断当前是否存在内存泄露的小技巧：当我们不停的点击“Cause GC”按钮时，如果“data object”一览众的“Tofal Size”有明显变化，就代表可能存在内存泄露。

上面是手动查看Heap状态，下面点击菜单栏的“Dump HPROF File”按钮。

系统会生成一个.hprof文件，默认名为包名.hprof，不过还不能直接使用MAT工具查看，还需要进行格式转换，在SDK目录的platform-tools目录下，使用hprof-conv工具帮助转换，命令如下所示：

D:\sdk\platform-tools>hprof-conv F:\Heap\com.handsome.heap.hprof heap.hprof

格式命令：”hprof-conv infile outfile”生成heap.hprof文件利用MAT工具就可以进行内存分析

6.2分析HPROF文件

打开MAT工具，选择”Open a Heap Dump”选项，进入分析：

Histogram

• Histogram直方图，用于显示内存中每一个对象的数量、大小和名称。
• 在选择对象上单击鼠标右键，在弹出的快捷菜单中选择”List objects-with incoming
  references”选项查看具体的对象。

Dominator Tree

• Dominator Tree支配书会将内存中的对象按照大小进行排序，并显示对象之间的引用结构。

• 对象已经按照“Retained
  Heap”进行排序了，即按照对象及其所持有的引用的内存总和进行排序。通过分析内存占用大的对象来找出内存消耗的原因。

7、使用Dumpsys命令分析系统状态

Dumpsys命令的功能非常强大，可使用的参数配置也非常多，Dumpsys官方信息：
https://source.android.com/devices/input/dumpsys.html
使用Dumpsys命令，只需要输入”adb shell dumpsys+参数”即可

• adb shell dumpsys activity：查看Activity栈的详细信息
• adb shell dumpsys meminfo：查看内存信息
• adb shell dumpsys battery：查看电池信息
• adb shell dumpsys package：查看包信息
• adb shell dumpsys wifi：显示Wi-Fi信息
• adb shell dumpsys alarm：显示alarm信息
• adb shell dumpsys procstats：显示内存信息