Android性能优化学习记录（一）概述、流畅性

_NOUS_

已于 2022-04-25 21:06:50 修改

阅读量2.1k

点赞数

分类专栏： Android 文章标签： Android 性能优化

于 2022-04-25 20:58:17 首次发布

本文链接：https://blog.csdn.net/qq_53749266/article/details/124414133

版权

Android 专栏收录该内容

22 篇文章 2 订阅

订阅专栏

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()
1. 作用：给 Canvas 设置一个裁剪区域，只有在该区域内才会被绘制，区域之外的都不绘制
2. 实例说明：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()
1. 作用：判断和某个矩形相交
2. 具体措施：若判断与矩形相交，则可跳过相交的区域，从而减少过度绘制

其他优化方案

在这里插入图片描述

绘制优化总结

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、不占用显示 & 位置
应用场景：引入只在特殊情况下才显示的布局（即 默认不显示），如：进度显示布局、信息出错出现的提示布局等
使用说明
1. 先设置好预显示的布局
2. 在其他布局通过标签引入外部布局（类似）；注：此时该布局还未被加载显示
3. 只有当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开发艺术探索

https://carsonho.blog.csdn.net/article/details/79708444

_NOUS_

关注

0
点赞
踩
3

收藏

觉得还不错? 一键收藏
2
评论
Android性能优化学习记录（一）概述、流畅性

Android性能优化学习记录（一）概述、流畅性Android性能优化学习记录（一）概述、流畅性Android性能优化学习记录（一）概述、流畅性一、性能优化概述目的需优化的性能指标优化方向二、流畅性2.1 启动速度2.2 页面显示速度2.2.1 绘制优化什么是绘制？优化方向方案一：降低View.onDraw（）的复杂度方案二：避免过度绘制（Overdraw）过度绘制的优化原则绘制优化方案1：移除默认的 Window 背景优化方案2：移除控件中不必要的背景优化方案3：减少布局文件的层级（减少不必要的嵌套
复制链接

扫一扫