Android性能优化学习记录（一）概述、流畅性
Android性能优化学习记录（一）概述、流畅性
一个优秀的应用不仅仅是要有吸引人的功能和交互，同时在性能上也有很高的要求。运行Android系统的手机，虽然配置在不断的提升，但其不管是内存还是CPU的性能都无法做到像PC设备相比。这也意味着Android程序过多地使用内存会导致程序内存溢出，即OOM。一般是指做大量的耗时任务会过多地使用CPU资源，会导致手机变得卡顿甚至程序无法响应的情况，即**ANR**。由此来看，Android程序的性能问题就变得异常突出了，这对开发人员也提出了更高的要求。
性能优化中一个很重要的问题就是内存泄露，内存泄露并不会导致程序功能异常，但是它会导致Android程序的内存占用过大，这将提高内存溢出的发生几率。如何避免写出内存泄露的代码，这和开发人员的水平和意识有很大关系，甚至很多情况下内存泄露的原因是很难直接发现的，这个时候就需要借助一些内存泄露分析工具。
在做程序设计时，除了要完成功能开发、提高程序的性能以外，代码的可维护性和可扩展性也不容忽视。如果一个程序的可维护性和可扩展性很差，后续的代码维护代价就相当高的，比如需要对一个功能做一些调整、添加新功能，可能会出现牵一发而动全身的局面，整个代码看起来可读性也会很差。代码的可维护性和可扩展性看起来是一个很抽象的问题，但其实它是可以通过一些合理的设计原则去完成的，比如良好的代码风格、清晰的代码层级、代码的可扩展性和合理的设计模式。
一、性能优化概述
目的
性能优化的目的是为了让应用程序App 更快、更稳定 & 更省。具体介绍如下：
更快：应用程序 运行得更加流畅、不卡顿，快速响应用户操作
更稳定：应用程序 能 稳定运行 & 解决用户需求，在用户使用过程中不出现应用**程序崩溃（Crash） 和 无响应（ANR）**的问题
更省：节省耗费的资源，包括 内存占有、电池量、网络资源等
需优化的性能指标
针对上述目的，需优化的性能指标 含：流畅性、稳定性、资源节省性
优化方向
- 针对上述性能指标，本文主要讲解的优化方向如下：
二、流畅性
- 优化目的
应用程序 运行得更加流畅、不卡顿，快速响应用户操作 - 优化原因
利于 减少使用中的卡顿、响应时间久等问题，给与用户一个操作流畅的体验 - 优化方向
主要针对3个方面优化：启动速度、页面显示速度、响应速度
2.1 启动速度
- 优化原因（即 启动速度慢的原因）
初次打开应用时，需加载很多资源 or 功能逻辑 - 优化方案
采用 异步加载（多线程）、分步加载、延期加载的策略，减少启动应用时加载的任务，从而提高启动速度
由于我们打开的页面大多是Activity，下面将给出加速启动Activity的方式
2.2 页面显示速度
- 优化原因（即 页面显示速度慢的原因）
a. 页面需绘制的内容（布局 & 控件）太多，从而导致页面测量时间过长
b. 绘制**效率过低，**从而导致绘制时间过长 - 优化方案布局优化 & 绘制优化。
2.2.1 绘制优化
Android绘制View有三个主要的步骤，分别是measure、layout和draw。
什么是绘制？
App 每一个滑动的动效都是若干个静态的图片（帧）组合起来不停变换组成的。 app的动画动效是需要动态生成的，这样就需要大量的计算，如果太过复杂的话就会造成在短时间之内画不完，也就造成了卡顿。
优化方向
- 降低
View.onDraw（）的复杂度 - 避免过度绘制
（Overdraw）
方案一：降低View.onDraw（）的复杂度
onDraw方法每次界面刷新都会被调用，被调用频繁。
- onDraw（）中不要创建新的局部对象
如果在onDrat方法内创建局部对象，就会瞬间产生大量临时对象，会占用很多内存并导致系统频繁回收垃圾，降低程序的执行效率。
- 避免执行大量 & 耗时操作
Google官方性能优化标准：View的最佳绘制频率 = 60fps，即要求每帧绘制时间≤16ms。View.onDraw()中如果执行大量耗时操作，会抢占CPU时间片，导致View的绘制过程不流畅。因此我们应将onDraw()的大量耗时操作放在多线程或其他其他函数中执行。
方案二：避免过度绘制（Overdraw）
过度绘制的简介
过度绘制定义：应用可能会在单个帧内多次绘制同一个像素
发生原因：UI结构的多层次与重叠。在多层次重叠的UI结构中，如果不可见的UI也在绘制，就会导致某些像素区域被绘制多次。这样的过度绘制会导致屏幕显示的色块不同。
影响：会导致界面显示时浪费资源去渲染看不见（不必要）的背景。从而导致多次绘制，令界面在加载滑动时不流畅、掉帧。令用户绝对App卡顿。
过度绘制的表现形式
过度绘制 会导致屏幕显示的色块不同
检查过度绘制的步骤是：设置-更多设置-开发者选项-调试GPU过度绘制-显示过度绘制区域。
最理想的是蓝色,一个像素只绘制一次，合格的页面绘制是白色、蓝色为主，绿色以上区域不能超过整个的三分之一，颜色越浅越好。
过度绘制的优化原则
很多 过度绘制是难以避免的，如 上述实例的 文字 & 背景导致的过度绘制；只能尽可能避免过度绘制：
- 尽可能地控制 过度绘制的次数 =
**2次**（绿色）以下，蓝色最理想 - 尽可能避免 过度绘制的粉色 & 红色情况
- 不允许 3 次以上的过度绘制（淡红色）面积 超过 屏幕大小的 1/4
绘制优化方案1： 移除默认的 Window 背景
一般应用程序 默认 继承的主题 = windowBackground ，如默认的 Light 主题：
<style name="Theme.Light">
<item name="isLightTheme">true</item>
<item name="windowBackground">@drawable/screen_background_selector_light</item>
...
</style>
但这样的问题是，一般情况下，该默认的 Window 背景基本用不上：因背景都自定义设置
若不移除，则导致所有界面都多 1 次绘制
解决方案：移除默认的 Window 背景
// 方式1：在应用的主题中添加如下的一行属性
<item name="android:windowBackground">@android:color/transparent</item>
<!-- 或者 -->
<item name="android:windowBackground">@null</item>
// 方式2：在 BaseActivity 的 onCreate() 方法中使用下面的代码移除
getWindow().**setBackgroundDrawable(null)**;
<!-- 或者 -->
getWindow().**setBackgroundDrawableResource(android.R.color.transparent)**;
优化方案2：移除 控件中不必要的背景
如2个常见场景：
场景1：ListView 与 Item
列表页（ListView） 与 其内子控件（Item）的背景相同 = 白色，故可移除子控件（Item）布局中的背景
场景2：ViewPager 与 Fragment
对于1个ViewPager + 多个 Fragment 组成的首页界面，若每个
Fragment 都设有背景色，即 ViewPager 则无必要设置，可移除
关于更多场景，可使用工具 Hierarchy View 查看
优化方案3：减少布局文件的层级（减少不必要的嵌套）
- 原理：减少不必要的嵌套 ->> UI层级少 ->> 过度绘制的可能性低
- 优化方式：使用布局标签
<merge>& 合适选择布局类型
优化方案4：自定义控件View优化：使用 clipRect() 、 quickReject()
clipRect()- 作用：给 Canvas 设置一个裁剪区域，只有在该区域内才会被绘制，区域之外的都不绘制
- 实例说明：
DrawerLayout布局 = 左抽屉布局
@Override
protected boolean drawChild(Canvas canvas, View child, long drawingTim
// ...仅贴出关键代码
// 1. 遍历 DrawerLayout 的 child view，拿到抽屉布局
for (int i = 0; i < childCount; i++) {
final View v = getChildAt(i);
if (v == child || v.getVisibility() != VISIBLE
|| !hasOpaqueBackground(v) || !isDrawerView(v)
|| v.getHeight() < height) {
continue;
}
// a. 若是左抽屉布局
// 则取抽屉布局的右边界作为裁剪区的左边界、设置原主布局的裁剪区域，如上图裁剪区域
if (checkDrawerViewAbsoluteGravity(v, Gravity.LEFT)) {
final int vright = v.getRight();
if (vright > clipLeft) clipLeft = vright;
// b. 若是右抽屉布局
// 则取抽屉布局的左边界作为裁剪区的右边界、设置原主布局的裁剪区域
} else {
final int vleft = v.getLeft();
if (vleft < clipRight) clipRight = vleft;
}
}
// 2. 通过clipRect（）设置原主布局的显示范围 = 裁剪区域，使其仅在上图中的红框区域（即不阻碍抽屉布局的区域）显示
// 从而避免过度绘制
canvas.clipRect(clipLeft, 0, clipRight, getHeight());
}
......
}
quickreject()- 作用：判断和某个矩形相交
- 具体措施：若判断与矩形相交，则可跳过相交的区域，从而减少过度绘制
其他优化方案
绘制优化总结
2.2.2 布局优化
布局优化影响的性能
布局性能的好坏 主要影响 ：Android应用中的页面显示速度
布局优化方案1：选择 耗费性能较少的布局
- 性能耗费低的布局 = 功能简单 =
FrameLayout、LinearLayout - 性能耗费高的布局 = 功能复杂 =
RelativeLayout
注：即 布局过程需消耗更多性能（CPU资源 & 时间）
**嵌套所耗费的性能 > 单个布局本身耗费的性能，**即 完成需求时：宁选择 1个耗费性能高的布局，也不采用嵌套多个耗费性能低的布局
优化方案2：减少布局的层级（嵌套）
- 原理：布局层级少 ->> 绘制的工作量少 ->> 绘制速度快 ->> 性能提高
- 优化方式：使用布局标签
<merge>& 合适选择布局类型
优化方案2.1：使用布局标签
- 作用
减少 布局层级
配合
<include>标签使用，可优化 加载布局文件时的资源消耗
- 具体使用
// 使用说明：
// 1. <merge>作为**被引用布局A的根标签**
// 2. 当其他布局通过<include>标签引用布局A时，
**布局A中的<merge>标签内容（根节点）会被去掉**，
在<include>里存放的是布局A中的<merge>标签内容（根节点）的**子标签（即子节点）**，
以此**减少布局文件的层次**
/**
* 实例说明：在上述例子，在布局B中 通过<include>标签引用布局C
* 此时：布局层级为 = RelativeLayout ->> Button
* —>> RelativeLayout ->> Button
* ->> TextView
* 现在使用<merge>优化：将 被引用布局C根标签 的RelativeLayout 改为 <merge>
* 在引用布局C时，布局C中的<merge>标签内容（**根节点）会被去掉**，
在<include>里存放的是布局C中的<merge>标签内容（根节点）的子标签（即子节点）
* 即 <include>里存放的是：**<Button>、<TextView>**
* 此时布局层级为 = RelativeLayout ->> Button
* ->> Button
* ->> TextView
* 即 已去掉之前无意义、多余的<RelativeLayout>
*/
// 被引用的公共部分：布局C = layout_c.xml
<?xml version="1.0" encoding="utf-8"?>
<merge xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="match_parent"
android:layout_height="match_parent" >
<Button
android:id="@+id/button"
android:layout_width="match_parent"
android:layout_height="@dimen/dp_10"/>
<TextView
android:id="@+id/textview"
android:layout_width="match_parent"
android:layout_height="@dimen/dp_10"/>
</merge>
// 布局B：layout_b.xml
<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="match_parent"
android:layout_height="match_parent" >
<Button
android:id="@+id/Button"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:layout_marginBottom="@dimen/dp_10" />
<include layout="@layout/layout_c.xml" />
</RelativeLayout>
优化方案2.2：合适选择布局类型
- 通过合理选择布局类型，从而减少嵌套
- 即：完成 复杂的
UI效果时，尽可能选择1个功能复杂的布局（如RelativeLayout）完成，而不要选择多个功能简单的布局（如LinerLayout）通过嵌套完成
优化方案3：提高 布局 的复用性
- 优化原理：提取布局间的公共部分，通过提高布局的复用性从而减少测量 & 绘制时间
- 优化方案：使用 布局标签
<include>，其作用是实现 布局模块化，即 提取布局中的公共部分 供其他布局共用。 - 使用说明：通过标签引入抽取的公共部分布局C；
标签所需属性 = 公共部分的layout属性，作用 = 指定需引入、包含的布局文件 - 具体使用 抽取布局A、B中的公共部分布局C & 放入到布局B中使用.
/**
* 布局B：layout_b.xml
*/
<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="match_parent"
android:layout_height="match_parent" >
<Button
android:id="@+id/Button"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:layout_marginBottom="@dimen/dp_10" />
// 通过<include>标签引入抽取的公共部分布局C
// <include>标签所需属性 = 公共部分的layout属性，作用 = 指定需引入、包含的布局文件
<include layout="@layout/layout_c.xml" />
</RelativeLayout>
/**
* 公共部分的布局C：layout_c.xml
*/
<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="match_parent"
android:layout_height="match_parent" >
<Button
android:id="@+id/button"
android:layout_width="match_parent"
android:layout_height="@dimen/dp_10"/>
<TextView
android:id="@+id/textview"
android:layout_width="match_parent"
android:layout_height="@dimen/dp_10"/>
</RelativeLayout>
优化方案4：减少初次测量 & 绘制时间
主要优化方案：使用 布局标签<ViewStub> & 尽可能少用布局属性 wrap_content
优化方案4.1：使用 布局标签
- 作用：按需加载 外部引入的布局，属 轻量级
View、不占用显示 & 位置 - 应用场景：引入 只在特殊情况下才显示的布局（即 默认不显示），如：进度显示布局、信息出错出现的提示布局等
- 使用说明
- 先设置好预显示的布局
- 在其他布局通过标签引入外部布局（类似）；注：此时该布局还未被加载显示
- 只有当
ViewStub被设置为可见 / 调用了ViewStub.inflate()时，ViewStub所指向的布局文件才会被inflate、实例化，最终 显示指向的布局
- 具体使用：在布局A中引入布局B，只有在特定时刻C中才显示
// 步骤1：先设置好预显示的布局B = layout_b.xml
<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="match_parent"
android:layout_height="match_parent" >
<Button
android:id="@+id/button"
android:layout_width="match_parent"
android:layout_height="@dimen/dp_10"/>
<TextView
android:id="@+id/textview"
android:layout_width="match_parent"
android:layout_height="@dimen/dp_10"/>
</RelativeLayout>
// 步骤2：在布局A通过<ViewStub>标签引入布局B（类似<include>）；注：此时该布局还未被加载显示
// 布局A：layout_a.xml
<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:layout_width="match_parent"
android:layout_height="match_parent" >
<Button
android:id="@+id/Button"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:layout_marginBottom="@dimen/dp_10" />
<ViewStub
android:id="@+id/Blayout"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:layout="@layout/layout_b" />
</RelativeLayout>
// 步骤3：只有当ViewStub被设置为可见 / 调用了ViewStub.inflate()时，ViewStub所指向的布局文件才会被inflate 、实例化，最终 显示<ViewStub>指向的布局
ViewStub stub = (ViewStub) findViewById(R.id.Blayout);
stub.inflate();
小结：
ViewStub中的layout布局不能使用merge标签，否则会报错ViewStub的inflate只能执行一次，显示了之后，就不能再使用ViewStub控制它了
与
View.setVisible(View.Gone)的区别：View的可见性设置为gone后，在inflate时，该View及其子View依然会被解析；而使用ViewStub就能避免解析其中指定的布局文件，从而节省布局文件的解析时间 & 内存的占用
优化方案4.2：尽可能少用布局属性 wrap_content
布局属性wrap_content 会增加布局测量时计算成本，应尽可能少用；特别是在已知宽高为固定值时，不使用wrap_content。
布局优化总结
2.3 响应速度
- 优化原因
应用程序出现ANR情况，从而导致 应用程序响应速度慢
ApplicationNotResponding（应用程序无响应）是卡死在一个页面。Application(应用)在5s内未响应用户输入事件（如按键or触摸），广播接收器(BroadcastReceiver)在10秒内未完成相关的处理，服务(Service)在20秒内无法处理完成，会出现对话框让用户选择等待或强制关闭。 - 优化方案
使用多线程，将大量 & 耗时操作放在多线程中执行
- 多线程的方式 包括：
AsyncTask、继承 Thread类、实现 Runnable接口、Handler消息机制、HandlerThread等
- 注：实际开发中，当一个进程发生了ANR后，系统会在 /data/anr目录下创建一个文件
traces.txt，通过分析该文件可定位出ANR的原因
流畅性总结
参考资料
Android开发艺术探索
扫一扫
293
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
