第十章 Android性能优化
Android 群英传笔记
第一章Android体系与系统架构
第二章 Android开发工具及技巧
第三章 Android控件架构与事件拦截机制
第四章 ListView 使用技巧
第五章 Android Scroll 分析
第六章 Android 绘图机制与屏幕适配
第七章 Android 动画机制与使用技巧
第八章 Activity与Activity调用栈分析
第九章 Android 系统信息与安全机制
第十章 Android性能优化
本文出自:
http://www.jianshu.com/u/a1251e598483
本章的主要内容:
1. 布局优化
2. 内存优化
3. 使用各种工具进行分析，优化
1. 布局优化
系统在渲染图片的时候需要消耗大量的资源，一个好的UI，不仅要有良好的视觉体验，更应该具有良好的使用体验，因此布局优化就显得很重要了
Android UI渲染机制
人眼所看到的流畅画面，需要画面的帧数达到40帧每秒到60帧每秒，相信玩过PC游戏的都应该对帧有一个详细的概念，最佳的ftp在60左右，这也是评价一个显卡性能的一个高低标准之一，在Android中，系统通过VSYNC信号出发对UI的渲染、重绘，其间隔时间是16ms。这个16ms其实就是1000ms中显示60帧画面的单位时间。即1000/60，如果系统每次渲染都保持在16ms之内，那么我们看到的UI将十分的流畅，但这也是需要将所有的逻辑都保证在16ms里，如果16ms不能完成绘制，那么就会造成丢帧的现象，即当前该重绘的帧被未完成的逻辑阻塞
Android系统提供了检测UI渲染时间的工具，打开“开发者选项”，选择“Profile GPU Rendering”（我的手机是“GPU呈现模式分析”），选中“On screen as bars”（我的为“在屏幕上显示为条形图”）。每一条柱状线都包括三部分，蓝色代表测量绘制Display List的时间，红色代表OpenGL渲染Display List所需要的时间，黄色代表CPU等待GPU处理的时间，中间绿色横线代表VSYNC时间16ms，需要尽量将所有条形图都控制在这条绿线之下。
避免Overdraw
Overdraw,过渡绘制会浪费很多CPU、GPU资源，例如系统默认会绘制Activity的背景，而如果再给布局绘制了重叠的背景，那么默认Activity的背景就属于无效的过渡绘制。Android系统在开发者选项中提供了这样一个检测工具–“Enable GPU Overdraw”。借助它可以判断Overdraw的次数。尽量增大蓝色的区域，减少红色的区域,这里，我们用一张Google开发者博客上的图片来表示
Enable GPU Overdraw
通过这个工具可以查看当前区域中绘制的次数，从而尽量优化绘图层次，尽量增大蓝色的区域，减少红色的区域
优化布局层级
在Android中系统对View的测量、布局和绘制都是通过遍历View树来进行的，如果View树太高，就会影响其速度，因此优化布局的第一个方法就是减低view树的高度，Google也在其api文档中建议view树的结构不宜超过十层
不知道是否读者有注意到，在早期的Android版本中，Google使用线性布局作为默认布局，而在现在的Android使用的是相对布局（默认），原因就是通过扁平的相对布局来降低通过线性布局所产生的树的高度，从而提高布局的效率
避免嵌套过多无用的布局
嵌套的布局会让view树的高度越来越高，所以在布局中，需要根据自身布局的特点，来选择不同的layout组件，从而避免通过某一种layout组件来实现功能时的局限性，从而造成嵌套过多的情况
- 使用< include>标签重用布局
在一个应用程序里，为了风格和是哪个的统一，很多界面都会存在一些共同的UI，比如toolbar什么的，我们就可以使用< include>标签重用布局
- 使用< ViewStub>实现view的延迟加载
除了把一个view作为公用的ui，还可以对他进行延时加载，用< ViewStub>就可以轻松实现，< ViewStub>是一个轻量级的组件，他不仅不可视，而且大小为0，我们用小案例说话
<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=".MainActivity">
<TextView
android:id="@+id/tv"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="not often use" />
</RelativeLayout>
然后使用ViewStub
<?xml version="1.0" encoding="utf-8"?>
<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=".MainActivity">
<ViewStub
android:id="@+id/viewStub"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:layout_centerInParent="true"
android:layout="@layout/activity_main" />
</RelativeLayout>
运行之后，我们发现引用的组件确实没有加载出来，那要怎么去加载尼？，同样的，我们需要找控件
ViewStub viewStub = (ViewStub) findViewById(R.id.viewStub);
通过调用ViewStub的setVisibility()方法来显示这个view ,也可以 通过调用ViewStub的inflate方法来显示这个view
viewStub.setVisibility(View.VISIBLE);
View inflateView = viewStub.inflate();
这两种方式都可以让ViewStub重新展开，显示引用的布局，而唯一的区别就是inlalte方法可以返回引用的布局
这里可能有同学有疑问了, ViewStub标签和设置View.GONE有什么区别，的确，他们两个刚开始都不会加载，但是ViewStub只会显示的时候，才去渲染这个布局，而后者不是，这就是优势
Hierarchy Viewer
无论哪本将优化的书，他们都不得不提到Hierarchy Viewer，Android Studio支持这个功能,可以在tools -->android-->android Device Monitor 中打开
2. 内存优化
应用App内存的使用,也是评价一个应用性能高低的一个重要指标。虽然现在智能手机的内存越来越大,但是一个好的应用应当将效率发挥到极致,精益求精。而现在有很多应用, 为了自己的利益，使用一些非常影响系统效率的方法, 不仅败坏了Androld的口碑, 更极大地影响了系统的稳定性，例如某 “X米”团购应用,在启动应用的时候会fork一个子线程, 用于监听用户卸载应用。在KK下, 该线程在卸载时不能被kill,且每次启
动都将fork新的进程;这就导致内存消耗不断增高, 极大地影响了低端机的使用体验，因此，不管是什么应用,都应该把内存效率，用户体验放在首位,而不是为了满足自己的利益
什么是内存
由于Android的沙箱机制,每个应用所分配的内存大小是有限度的,内存太低就会触发LMK-Low Memory Killer机制。那么到底什么是内存呢?通常情况下我们所说的内存是指手机的RAM,它包括以下几个部分
Java 内存划分
- 寄存器(Registers)
速度最快的存储场所,因为寄存器位于处理器内部.在程序中无法控制
- 栈（Stack）
存放基本类型的数据和对象的引用.但对像本身不存放在栈中,而是存放在堆中
- 堆内存（Heap）
堆内存用来存放由new创建的对象和数组.在堆中分配的内存，由java虚拟机的自动垃圾回收（GC）管理
- 静态存储区域(static Field)
静态存储区域就是指在固定的位置存放应用程序运行时一直存在的数据，java在内存中专门划分了一个静态存储区域来管理一些特殊的 数据变量如静态的数据变量
- 常量池(Constant Pool)
JVM虚拟机必须为每个被装载的类型维护一个常量池，常量池就是该类型所用到常量的一个有序集合，包括直接常量(基本类型，String)和对其他类型. 字段和方法的符号引用
在这些概念中最容易搞错的就是堆和栈的区分。当定义一个变量，Java虚拟机就会在栈中为该变量分配内存空间 这部分内存空间会马上被用作新的空间进行分配，如果使用new的方式创建一个变量, 那么就会在堆中为这个对象分配内存空间，即使该时象的作用域结束, 这部分内存也不会立即被回收.而是等待系统Gc进行回收，堆的大小随着手机的不断发展而不断变大，在过程中.可以使用如下所示的代码来获得堆的大小，所谓的
内存分析,正是分析Heap中的内存状态。
ActivityManager manager = (ActivityManager) getSystemService(Context.ACTIVITY_SERVICE);
int heapSize = manager.getLargeMemoryClass();
获取Android系统内存信息
内存回收
java对于C/C+这类语言最大的优势就是不用手动管理系统资源,java创建了垃圾收集器线程来自动进行资源的管理 这样做的好处是大大降低了程序开发人员对内存管理的繁琐工作，但这也带来了很多问题，例如java的gc是系统自动进行的，但何时进行却是开发者无法控制的，即使调用system.gc方法,也只是建议系统进行GC,但是系统是否采纳你的建设.那就不一定了。JVM虚拟机虽然能够自动控制GC,但是再强大的算法，也难免会存在部分对象忘记回收的现象发生, 这就是造成内存泄漏的原因
- Bitmap 优化
Bitmap是造成内存占用过高甚至是OOM的最大威胁,下面给出一些使用Bitmap的技巧
- 使用适当分辨率和大小的图片
- 及时回收内存
- 使用图片缓存
- 代码优化
关于代码优化:
对常量使用static修饰符
使用静态方法,静态方法会比普通方法提高15%左右的访问速度
减少不必要的成员变量 ,这点在Android Lint工具上已经集成检测了.如果一个变量可以定义为局部变量，则会建议你不要定义为成成变量.
减少不必要的对象 使用基础类型会比使用对象更加节省资源, 同时更应该避免频繁创建短作用域的变量
尽量不要使枚举、少使用迭代器。
对Cursor,Receiver，Sensor,Fiie等对象,要非常注意对它们的创建.回收与注册解注册。
避免使用IOC框架.IOC通常使用注解.反射来进行实现,虽然现在java对反射的效率已经进行了很好的优化.但大量使用反射依然会带来性能的下降.
使用RenderScript，openGL来进行非常复杂的绘图操作.
使用surfaceView来替View进行大量.频繁的绘图操作.
尽量使用视图缓存，而不是每次都执行inflaler()方法解析视图
- Lint 工具
关于性能优化工具的介绍,使用,找个时间再介绍吧,今天就先到这了
