【Android 性能优化】—— 打造丝滑的 UI 界面

本文同时发布在简书上,欢迎查看

Android 高手核心知识点笔记(不断更新中)点击查看 PS:各位童鞋不要忘记给我 star 一波哦~~
#1. 前言
随着最近几年移动市场蓬勃发展,引来大批人员投入到Android、IOS的开发前线,与此同时全国各大培训机构每月都培养出成千上万名号称拥有2到3年工作经验的开发者。当然,这都已经不是什么秘密了,从目前来看,中国IT行业的主力军基本上都走过培训的道路。

但问题是,这号称23年工作经验者,使招聘单位错误的认为:23年开发经验和刚刚结束的培训经历,基本上划等号。这就导致了企业大幅度提高用人标准,造成了为何如今移动开发市场依旧火热,但是工作却不好找的现状。

最悲惨的例子恐怕就是前几年IOS如日中天,可时间就过了一年开发人员就出现了井喷的情况,大量IOS开发者找不到工作。

总的来说:工作机会的确是很多,但是企业把用人要求都大大提高了。如何在万千人群中脱颖而出,走上人生巅峰,迎娶白富美,没有亮点,是万万不行滴。。。

接下来我就一起学习Android UI优化吧

#2. Android渲染机制分析

大家在开发应用的时候或多或少都遇到过可感知的界面卡顿现象,尤其是在布局层次嵌套太多,存在不必要的绘制,或者onDraw方法中执行了过多耗时操作、动画执行的次数过多等情况下,很容易造成此类情况。如今APP设计都要求界面美观、拥有更多的动画、图片等时尚元素从而打造良好的用户体验。但是大量复杂的渲染工作很可能造成Android系统压力过大,无法及时完成渲染工作。那么多久执行一次渲染,才能让界面流畅运行呢?

【Android 性能优化】—— 打造丝滑的 UI 界面_第1张图片

如上图所示,Android系统每隔16ms就会发送一个VSYNC信号(VSYNC:vertical synchronization 垂直同步,帧同步),触发对UI进行渲染,如果每次渲染都成功,这样就能够达到流畅的画面所需要的正常帧率:60fps。一旦这时候系统正在做大于16ms的耗时操作,系统就会无法响应VSYNC信号,执行渲染工作,导致发生丢帧现象。

大家在察觉到APP卡顿的时候,可以看看logcat控制台,会有drop frames类似的警告
本引用来自:[ Android UI性能优化实战 识别绘制中的性能问题](http://blog.csdn.net/lmj623565791/article/details/45556391/)

【Android 性能优化】—— 打造丝滑的 UI 界面_第2张图片

例如上图所示:如果你的某个操作花费时间是24ms,系统在得到VSYNC信号的时候就无法进行正常渲染,只能等待下一个VSYNC信号(第二个16ms)才能执行渲染工作。那么用户在32ms内看到的会是同一帧画面。(我就是感觉google给的图给错了,明明是 32ms,怎么给标了一个34ms,难道是有其他寓意我没有理解上去???)

用户容易在UI执行动画、ListView、RecyclerView滑动的时候感知到界面的卡顿与不流畅现象。所以开发者一定要注意在设计布局时不要嵌套太多层,多使用 include方法引入布局。同时不要让动画执行次数太多,导致CPU或者GPU负载过重

看到这里同学可能会疑问:为什么是16ms渲染一次,和60fps有什么关系呢?下面让我们看一下原理:

16ms意味着着1000/60hz,相当于60fps。

那么只要解释为什么是60fps,这个问题就迎刃而解:

这是因为人眼和大脑之间的写作无法感知超过60fps的画面更新,12fps大概类似手动快速翻动书籍的帧率,这是明显可以感知到不够顺滑的。
24fps使得人眼感知的是连续的线性运动,这其实是归功于运动模糊效果,24fps是电影胶圈通常使用的帧率,因为这个帧率已经足够支撑大部分电影画面需要表达的内容,同时能够最大的减少费用支出。
但是低于30fps是
无法顺畅表现绚丽的画面内容的,此时就需要用到60fps来达到想要的效果,当然超过60fps是没有必要的
本引用来源:Google 发布 Android 性能优化典范 - 开源中国社区

#3.1 界面卡顿的主要元凶—— 过度绘制(Overdraw)
##3.1 什么是过度绘制?
**过渡绘制是指屏幕上某个像素在同一帧的时间内绘制了多次。**在多层次的UI结构里面,如果不可见的UI也在做绘制操作,这就会导致某些像素区域被绘制了多次,这就是很大程度上浪费了CPU和GPU资源。最最常见的过度绘制,就是设置了无用的背景颜色!!!

3.2 如何发现过度绘制?

对于Overdraw这个问题还是很容易发现的,我们可以通过以下步骤打开显示GPU过度绘制(Show GPU Overrdraw)选项

设置 -> 开发者选项 -> 调试GPU过度绘制 -> 显示GPU过度绘制

打开以后之后,你会发现屏幕上有各种颜色,此时你可以切换到需要检测的程序与界面,对于各个色块的含义,请看下图:

【Android 性能优化】—— 打造丝滑的 UI 界面_第3张图片

蓝色,淡绿,淡红,深红代表了4种不同程度的Overdraw情况,
蓝色: 意味着overdraw 1倍。像素绘制了两次。大片的蓝色还是可以接受的(若整个窗口是蓝色的,可以摆脱一层)。
绿色: 意味着overdraw 2倍。像素绘制了三次。中等大小的绿色区域是可以接受的但你应该尝试优化、减少它们。
淡红: 意味着overdraw 3倍。像素绘制了四次,小范围可以接受。
深红: 意味着overdraw 4倍。像素绘制了五次或者更多。这是错误的,要修复它们。
我们的目标就是尽量减少红色Overdraw,看到更多的蓝色区域。

3.3 解决问题的工具和方法

通过Hierarchy Viewer去检测渲染效率,去除不必要的嵌套
通过Show GPU Overdraw去检测Overdraw,最终可以通过移除不必要的背景。

4. UI优化实践

4.1 移除不必要的background

(由于公司项目还处于保密阶段,所以摘取了Android UI性能优化实战 识别绘制中的性能问题的部分示例)
下面看一个简单的展示ListView的例子:

  • activity_main
?xml version="1.0" encoding="utf-8"?>


    

    

  • item的布局文件




    

    

        

            

            
        

        
    

  • Activity的代码
package com.zhy.performance_01_render;

import android.os.Bundle;
import android.os.PersistableBundle;
import android.support.annotation.Nullable;
import android.support.v7.app.AppCompatActivity;
import android.view.LayoutInflater;
import android.view.View;
import android.view.ViewGroup;
import android.widget.ArrayAdapter;
import android.widget.ImageView;
import android.widget.ListView;
import android.widget.TextView;

/**
 * Created by zhy on 15/4/29.
 */
public class OverDrawActivity01 extends AppCompatActivity
{
    private ListView mListView;
    private LayoutInflater mInflater ;

    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState)
    {
        super.onCreate(savedInstanceState);

        setContentView(R.layout.activity_overdraw_01);

        mInflater = LayoutInflater.from(this);
        mListView = (ListView) findViewById(R.id.id_listview_chats);

        mListView.setAdapter(new ArrayAdapter(this, -1, Droid.generateDatas())
        {
            @Override
            public View getView(int position, View convertView, ViewGroup parent)
            {

                ViewHolder holder = null ;
                if(convertView == null)
                {
                    convertView = mInflater.inflate(R.layout.chat_item,parent,false);
                    holder = new ViewHolder();
                    holder.icon = (ImageView) convertView.findViewById(R.id.id_chat_icon);
                    holder.name = (TextView) convertView.findViewById(R.id.id_chat_name);
                    holder.date = (TextView) convertView.findViewById(R.id.id_chat_date);
                    holder.msg = (TextView) convertView.findViewById(R.id.id_chat_msg);
                    convertView.setTag(holder);
                }else
                {
                    holder = (ViewHolder) convertView.getTag();
                }

                Droid droid = getItem(position);
                holder.icon.setBackgroundColor(0x44ff0000);
                holder.icon.setImageResource(droid.imageId);
                holder.date.setText(droid.date);
                holder.msg.setText(droid.msg);
                holder.name.setText(droid.name);

                return convertView;
            }

            class ViewHolder
            {
                ImageView icon;
                TextView name;
                TextView date;
                TextView msg;
            }

        });
    }


}

实体的代码

package com.zhy.performance_01_render;

import java.util.ArrayList;
import java.util.List;

public class Droid
{
    public String name;
    public int imageId;
    public String date;
    public String msg;


    public Droid(String msg, String date, int imageId, String name)
    {
        this.msg = msg;
        this.date = date;
        this.imageId = imageId;
        this.name = name;
    }

    public static List generateDatas()
    {
        List datas = new ArrayList();

        datas.add(new Droid("Lorem ipsum dolor sit amet, orci nullam cra", "3分钟前", -1, "alex"));
        datas.add(new Droid("Omnis aptent magnis suspendisse ipsum, semper egestas", "12分钟前", R.drawable.joanna, "john"));
        datas.add(new Droid("eu nibh, rhoncus wisi posuere lacus, ad erat egestas", "17分钟前", -1, "7heaven"));
        datas.add(new Droid("eu nibh, rhoncus wisi posuere lacus, ad erat egestas", "33分钟前", R.drawable.shailen, "Lseven"));

        return datas;
    }


}

现在的效果是:
【Android 性能优化】—— 打造丝滑的 UI 界面_第4张图片
注意,我们的需求是整体是Activity是个白色的背景。
开启Show GPU Overdraw以后:
【Android 性能优化】—— 打造丝滑的 UI 界面_第5张图片
对比上面的参照图,可以发现一个简单的ListView展示Item,竟然很多地方被过度绘制了4X 。 那么,其实主要原因是由于该布局文件中存在很多不必要的背景,仔细看上述的布局文件,那么开始移除吧。

  • 不必要的Background 1

我们主布局的文件已经是background为white了,那么可以移除ListView的白色背景

  • 不必要的Background 2

Item布局中的LinearLayout的android:background="@android:color/darker_gray"

  • 不必要的Background 3

Item布局中的RelativeLayout的android:background="@android:color/white"

  • 不必要的Background 4

Item布局中id为id_msg的TextView的android:background="@android:color/white"

这四个不必要的背景也比较好找,那么移除后的效果是:
【Android 性能优化】—— 打造丝滑的 UI 界面_第6张图片
对比之前的是不是好多了~~~接下来还存在一些不必要的背景,你还能找到吗?

  • 不必要的Background 5

这个背景比较难发现,主要需要看Adapter的getView的代码,上述代码你会发现,首先为每个icon设置了背景色(主要是当没有icon图的时候去显示),然后又设置了一个头像。那么就造成了overdraw,有头像的完全没必要去绘制背景,所有修改代码:

Droid droid = getItem(position);
                if(droid.imageId ==-1)
                {
                    holder.icon.setBackgroundColor(0x4400ff00);
                    holder.icon.setImageResource(android.R.color.transparent);
                }else
                {
                    holder.icon.setImageResource(droid.imageId);
                    holder.icon.setBackgroundResource(android.R.color.transparent);
                }

ok,还有最后一个,这个也是非常容易被忽略的。

  • 不必要的Background 6

记得我们之前说,我们的这个Activity要求背景色是白色,我们的确在layout中去设置了背景色白色,那么这里注意下,我们的Activity的布局最终会添加在DecorView中,这个View会中的背景是不是就没有必要了,所以我们希望调用mDecor.setWindowBackground(drawable);,那么可以在Activity调用getWindow().setBackgroundDrawable(null);

setContentView(R.layout.activity_overdraw_01); 
getWindow().setBackgroundDrawable(null);

ok,一个简单的listview显示item,我们一共找出了6个不必要的背景,现在再看最后的Show GPU Overdraw 与最初的比较。
【Android 性能优化】—— 打造丝滑的 UI 界面_第7张图片 【Android 性能优化】—— 打造丝滑的 UI 界面_第8张图片ok,对比参照图,基本已经达到了最优的状态。

4.2 使用布局标签优化布局

###4.2.1 标签
相信大家使用的最多的布局标签就是 了。 的用途就是将布局中的公共部分提取出来以供其他Layout使用,从而实现布局的优化。这种布局的编写方式大大便利了开发,个人感觉这种思想和React Native中的面向组件编程思想有着异曲同工之妙,都是将特定功能抽取成为一个独立的组件,只要控制其中传入的参数就可以满局不同的需求。例如:我们在编辑Android界面的时候常常需要添加标题栏,如果在不使用的情况下,只能在每一个需要显示标题栏的xml文件中编写重复的代码,费时费力。但是只要我们将这个需要多次被使用的标题栏布局抽取成一个独立的xml文件,然后在需要的地方使用标签引入即可。
下面以在一个布局main.xml中用include引入另一个布局foot.xml为例。main.mxl代码如下:



    

    


其中include引入的foot.xml为公用的页面底部,代码如下:

?xml version="1.0" encoding="utf-8"?>


    

使用起来很简单,只需要指定一个layout属性为需要包含的布局文件即可。当然还可以根据需求指定 android:idandroid:heightandroid:width属性来覆盖被引入根节点属性。

注意
在使用标签最常见的问题就是 findViewById查找不到进来地控件的跟布局,而这个问题出现的前提就是在include的时候设置了id当设置id后,原有的foot.xml跟布局Id已经被替换为在 中指定的id,所以在 findViewById查找原有id的时候就会报空指针异常。

View titleView = findViewById(R.id.my_foot_parent_id) ; // 此时id已经被覆盖 titleView 为空,找不到。此时空指针 
View titleView = findViewById(R.id.my_foot_ly) ; //重写指定id即可

标签简单的说就是相当与将layout指定的布局整体引入到main.xml中。所以我们就和操作直接在main.xml中的布局是一样的只不过有一个上面提到的更布局id被覆盖的问题。

###4.2.2 标签
ViewStub标签同include一样可以用来引入一个外部布局。不同的是,ViewStub引入的布局默认是不会显示也不会占用位置的,从而在解析的layout的时候可以节省cpu、内存等硬件资源。

ViewStub常常用来引入那些默认不显示,只在特定情况下才出现的布局,例如:进度条,网络连接失败显示的提示布局等。
下面以在一个布局main.xml中加入网络错误时的提示页面network_error.xml为例。main.mxl代码如下:




……
    


其中network_error.xml为只有在网络错误时才需要显示的布局,默认不会被解析,示例代码如下:




    

在代码中通过(ViewStub)findViewById(id)找到ViewStub,通过stub.inflate()展开ViewStub,然后得到子View,如下:

private View networkErrorView;

private void showNetError() {
  if (networkErrorView != null) {
    networkErrorView.setVisibility(View.VISIBLE);
  }else{
    ViewStub stub = (ViewStub)findViewById(R.id.network_error_layout);
    if(stub !=null){
      networkErrorView = stub.inflate();
    
      //  效果和上面是一样的
      //  stub.setVisibility(View.VISIBLE);   // ViewStub被展开后的布局所替换
      //  networkErrorView =  findViewById(R.id.network_error_layout); // 获取展开后的布局
    }
 }
}

private void showNormal() {
  if (networkErrorView != null) {
    networkErrorView.setVisibility(View.GONE);
  }
}

在上面showNetError()中展开了ViewStub,同时我们对networkErrorView进行了保存,这样下次不用继续inflate。

注意这里我对ViewStub的实例进行了一个非空判断,这是因为ViewStub在XML中定义的id只在一开始有效,一旦ViewStub中指定的布局加载之后,这个id也就失败了,那么此时findViewById()得到的值也会是空
viewstub标签大部分属性同include标签类似。

注意:
根据需求我们有时候需要将View的可讲性设置为GONE,在inflate时,这个View以及他的字View还是会被解析的。所以使用就能避免解析其中的指定的布局文件。从而加快布局的解析时间,节省cpu内存等硬件资源。同时ViewStub所加载的布局是不可以使用标签的

###4.2.3 标签
在使用了include后可能会导致布局嵌套太多,导致视图节点太多,减慢了解析速度。

merge标签可用于两种典型情况:

  1. 布局顶接点是FrameLayout并且不需要设置background或者padding等属性,可使用merge代替,因为Activity内容视图的parent view就是一个FrameLayout,所以可以用merge消除只能一个。
  2. 某布局作为子布局被其他布局include时,使用merge当作该布局的顶节点,这样在被引入时,顶结点会自动被忽略,而其自己点全部合并到主布局中。

以【4.2.1 标签 】中的代码示例为例,使用用hierarchy viewer查看main.xml布局如下图:

【Android 性能优化】—— 打造丝滑的 UI 界面_第9张图片

可以发现多了一层没必要的RelativeLayout,将foot.xml中RelativeLayout改为merge,如下:




    

运行后再次用hierarchy viewer查看main.xml布局如下图:
【Android 性能优化】—— 打造丝滑的 UI 界面_第10张图片
这样就不会有多余的RelativeLayout节点了。
参考:
Android UI性能优化实战 识别绘制中的性能问题
Google 发布 Android 性能优化典范
Android性能优化系列之布局优化

你可能感兴趣的:(Android进阶之旅,android,ui,性能优化)