目录

UI 优化究竟指的是什么呢？

UI 渲染的背景知识

UI优化主要分为三部分：

系统做的优化

硬件加速

Project Butter

RenderThread

我们可以具体实施的优化方案

java代码布局

View重用

异步创建view

xml布局优化

异步布局框架Litho

屏幕适配

Flutter

Jetpack Compose

工具篇

Choreographer

LayoutInspector/Android Device Monitor

Systrace

参考

UI 优化究竟指的是什么呢？

所谓的 UI 优化，应该包含两个方面：

一个是效率的提升，我们可以非常高效地把 UI 的设计图转化成应用界面，并且保证 UI 界面在不同尺寸和分辨率的手机上都是一致的；

另一个是性能的提升，在正确实现复杂、炫酷的 UI 设计的同时，需要保证用户有流畅的体验。

UI 渲染的背景知识

1. 屏幕与适配

屏幕的尺寸从 3 英寸到 10 英寸，分辨率从 320 到 1920 应有尽有，除此之外，材质也是屏幕至关重要的一个评判因素。目前智能手机主流的屏幕可分为两大类：一种是 LCD（Liquid Crystal Display），即液晶显示器；另一种是 OLED（Organic Light-Emitting Diode 的）即有机发光二极管。

对于屏幕碎片化的问题，Android 推荐使用 dp 作为尺寸单位来适配 UI。

2. CPU 与 GPU

除了屏幕，UI 渲染还依赖两个核心的硬件：CPU 与 GPU。UI 组件在绘制到屏幕之前，都需要经过 Rasterization（栅格化）操作，而栅格化操作又是一个非常耗时的操作。GPU（Graphic Processing Unit ）也就是图形处理器，它主要用于处理图形运算，可以帮助我们加快栅格化操作。

可以从图上看到，软件绘制使用的是 Skia 库，它是一款能在低端设备如手机上呈现高质量的 2D 跨平台图形框架，类似 Chrome、Flutter 内部使用的都是 Skia 库。

3. OpenGL 与 Vulkan

对于硬件绘制，我们通过调用 OpenGL ES 接口利用 GPU 完成绘制。OpenGL是一个跨平台的图形 API，它为 2D/3D 图形处理硬件指定了标准软件接口。而 OpenGL ES 是 OpenGL 的子集，专为嵌入式设备设计。

Android 7.0 把 OpenGL ES 升级到最新的 3.2 版本同时，还添加了对Vulkan的支持。Vulkan 是用于高性能 3D 图形的低开销、跨平台 API。相比 OpenGL ES，Vulkan 在改善功耗、多核优化提升绘图调用上有着非常明显的优势。在国内，“王者荣耀”是比较早适配 Vulkan 的游戏，虽然目前兼容性还有一些问题，但是 Vulkan 版本的王者荣耀在流畅性和帧数稳定性都有大幅度提升，即使是战况最激烈的团战阶段，也能够稳定保持在 55～60 帧。

UI优化主要分为三部分：

第一部分，系统为我们做的优化。

由于前端中UI展示的特殊性和重要性，Android团队也是在不断想办法提高UI方面的渲染速度，所以也是更新了很多系统优化方案，比如：硬件加速、黄油计划、RenderThread。

第二部分，我们可以具体实施的优化方案。

主要包括：java代码布局、View重用、异步创建View、xml布局优化、异步布局框架Litho、屏幕适配、Flutter、Jetpack Compose。

第三部分，工具使用。

主要包括：Choreographer、monitor、Systrace

系统做的优化

硬件加速

上面介绍过，一个图形的绘制是CPU，GPU和屏幕三方合作的结果。在Android3.0之前，还没有硬件加速，都是通过CPU进行数据计算，然后通过Skia库进行软件绘制，但是CPU对于图形处理并不高效。

于是从3.0开始，Android支持了硬件加速，到Android4.0默认开启硬件加速。开启硬件加速后，就是由CPU进行图形缓存数据的绘制。这样CPU和GPU就能比较好的分工，各司其职了。CPU用于控制复杂绘制逻辑、构建或更新DisplayList（基础元素）；GPU用于完成图形计算、渲染DisplayList（基础元素）。

这里也找了一张各种场景下，硬件加速前后的流程与加速效果(Android6.0背景)：

但是硬件加速也是有缺点的：

• 启用硬件加速需要更多资源，因此应用会占用更多内存。
• 比较低的版本，由于有些Canvas API还没有支持，所以使用硬件加速可能会有问题。那么我们就可以手动关闭某个view的硬件加速：

  myView.setLayerType(View.LAYER_TYPE_SOFTWARE, null)

Project Butter

黄油计划，Android4.1之后，Google提出了黄油计划，主要包括两个内容：

• VSYNC
• Triple Buffering(三级缓冲)

VSYNC

垂直同步信号，每当收到这个信号后，CPU就开始准备Buffer数据，并在16ms之内和GPU把屏幕需要的缓存数据准备好。

Triple Buffering(三级缓冲)

在Android4.1之前，是双缓冲机制，大部分情况是没问题的。但是当CPU/GPU绘制过程较长，超过一个vsync信号周期，一般是16ms，就会导致丢帧，CPU无法使用被GPU或者屏幕占用的缓存区。如果下一帧绘制如果又超时，那么又会丢帧。所以再加上一个缓冲区，这样，CPU、GPU、Display三者都有各自的缓存区，互不影响，就能保证时间的最大化利用，也就能减少上述的情况了。

RenderThread

RenderThread是在Android5.0提出的，从这个名字就能知道，它是一个线程，一个专门执行GL命令的线程，也就是一部分的绘制工作。有了它之后，当CPU处理数据给GPU后，就不需要等GPU渲染完毕了，而是将一些绘制任务交给RenderThread，这样就能减少主线程的工作，保证画面的流畅。同时还提供了RenderNode，用来做view的属性封装，渲染帧的信息等等。

我们可以具体实施的优化方案

java代码布局

我们一般都是用XML文件进行布局，但是XML解析也是很耗时的，并在这个解析过程在主线程进行。所以我们有的时候也许可以通过Java代码或者kotlin进行View的创建？理论中，这样确实能减少布局加载的消耗时间，但是Java代码创建View太麻烦了，而且无法可视化。当然，也有一些库可以帮助我们将xml代码转换成java代码，比如X2C（https://github.com/iReaderAndroid/X2C)，但是它并不支持所有的情况，比如merge标签，appCompat兼容控件等等。

所以我们需要在这之中找到平衡点，有的时候，UI简单并且要求高性能的前提下，我们可以试试用这样的方法，即用java代码代替XmL代码。

View重用

参照Recyclerview的做法，我们也可以将一些常用的view保存到缓存池中，这样在不同的界面中就能复用缓存池里面的view。

异步创建view

这是Google提出的一个方案——AsyncLayoutInflater。它可以异步加载布局文件，并且回调给主线程，从而减少主线程耗时。简单贴下主要代码：

new AsyncLayoutInflater(MainActivity.this).inflate(R.layout.activity_main, null, new AsyncLayoutInflater.OnInflateFinishedListener() {
        @Override
        public void onInflateFinished(@NonNull View view, int i, @Nullable ViewGroup viewGroup) {
        //回调给主线程
            setContentView(view);
    }
});

xml布局优化

• 减少布局嵌套
• 多使用ViewStub、Merge、ConstraintLayout
• 优化开销，在界面设计阶段多考虑，找到最优解

异步布局框架Litho

Litho是Facebook开源的一款在Android上高效建立UI的声明式框架。

主要有以下特点：

1. 声明式：它使用了声明式的API来定义UI组件
2. 异步布局：它把 measure 和 layout 都放到了后台线程，只留下了必须要在主线程完成的 draw，这大大降低了 UI 线程的负载
3. 视图扁平化：由于 Litho 使用了自有的布局引擎（Yoga)，在布局阶段就可以检测不必要的层级、减少 ViewGroups，来实现 UI 扁平化
4. 优化 RecyclerView：Litho 还优化了 RecyclerView 中 UI 组件的缓存和回收方法

屏幕适配

关于屏幕适配问题，也是老生常谈了。主要有以下几种方案：

dp适配方案

这是系统自带的适配单位，dp是基于屏幕物理分辨率一个抽象的单位，用于说明与密度无关的尺寸和位置。所以它能在不同分辨率的手机上有相对大小的适配性。计算公式是：px=dp * (dpi/160)。但是dpi有可能会被人为调整（比如几部相同分辨率不同尺寸的手机的ppi可能分别是是430,440,450,那么在Android系统中，可能dpi会全部指定为480），所以还是有可能在一些设备上出现适配问题。

宽高限定符适配方案

简单地说，这个方案就是穷举市面上所有的Android手机的宽高像素值。然后找到对应的文件夹使用下面的资源文件所对应的px值。但是这方案有个缺陷，就是必须精确命中才行。比如1920x1080的手机就一定要找到1920x1080的限定符，否则就只能用统一的默认的dimens文件了。所以容错性太低，不推荐。

smallestWidth适配方案

这个方案就是通过手机的宽度值来找到对应限定符文件夹下的资源文件，可以看做宽高限定符屏幕适配方案的升级版。

假如我们的设计图宽为360dp，那么就创建values-sw360dp文件夹，并添加资源文件：

<?xml version="1.0" encoding="UTF-8"?>
<resources>
    <dimen name="dp_1">1dp</dimen>
    <dimen name="dp_2">2dp</dimen>
    <dimen name="dp_3">3dp</dimen>
    ...
    <dimen name="dp_359">359dp</dimen>
    <dimen name="dp_360">360dp</dimen>
</resources>

很简单，分为360份，然后我们实际写布局文件的时候，直接引用对应的dimen值即可。然后新建其他设备宽度的文件夹，并在每个文件夹里添加对应的资源文件，这里以400dp为例：

├── src/main
│   ├── res
│   ├── ├──values
│   ├── ├──values-sw320dp
│   ├── ├──values-sw400dp
│   ├── ├──...
│   ├── ├──values-sw640dp

<?xml version="1.0" encoding="UTF-8"?>
<resources>
    <dimen name="dp_1">1.1111dp</dimen>
    <dimen name="dp_2">2.2222dp</dimen>
    <dimen name="dp_3">3.3333dp</dimen>
    <dimen name="dp_4">4.4444dp</dimen>
    ...
    <dimen name="dp_359">398.8889dp</dimen>
    <dimen name="dp_360">400.0000dp</dimen>
</resources>

也就是说，所有的设备都分为360份了，这样就能保证在不同宽度设备上都能有差不多的效果。如果我们的设备宽度为400dp，那么就会调用values-sw400dp对应的资源文件，如果找不到，就会向下查找。比如我们宽度是402dp，找不到对应的，就会向上找到400dp对应的资源文件，所以也有比较好的容错性。也是一个比较好的适配方案。

当然这种重复性工作肯定不需要我们自己手动去实现，有专门的插件可以生成相应的文件和文件夹，这里也推荐一个：https://github.com/ladingwu/dimens_sw

今日头条适配方案

这个大家应该都很熟悉了，主要是通过动态修改density值来保证所有设备的屏幕宽度都是固定的dp值。用到的公式就是px = density * dp。

比如设计图宽为360dp，我们只要保证所有设备的宽度都是360dp就能适配了。而宽度的px值我们是已知的，所以就是要修改这个 density 值来完成我们的适配目的。具体代码我就不贴了，网上很多。这种方案侵入性低，使用方便，是个不错的适配方案。

Flutter

Flutter是 Google 推出并开源的移动应用开发框架，开发者可以通过 Dart 语言开发 App，一套代码同时运行在 iOS 和 Android 平台。

这种方式，简单说就是走上了另一条渲染道路，不在Android提供的道路内。

Flutter框架现在也是特别火，实际运用到很多的大厂项目，比如闲鱼今日头条。它相对于Android其实是另外一套APP架构了，它没有基于系统本身的渲染引擎，而是app中自带Skia引擎，虚拟机也是使用的Dart虚拟机。

主要有以下几个特点：

• 跨平台：现在flutter至少可以跨5种平台，常见的平台：MacOS,Windows ,Linux ,Android ,iOS ,到目前为止，Flutter算是支持平台最多的框架了。良好的跨平台性，大大减少了开发成本。
• 丝滑般的体验：使用Flutter内置的Material Design（android风格）和Cupertino（ios风格）风格组件，以及丰富的motion API,平滑而自然的滑动效果和平台感知，为用户带来全新的体验。
• 响应式框架：使用一系列基础组件和响应式框架，可以轻松构建用户界面。使用功能强大且灵活的API可以实现复杂的界面效果。
• 支持插件：使用插件可以访问平台本地API,如相机，蓝牙，WIFI等等。借助现有的Java，swift ,object c ， c++代码实现对原生系统的调用。
• 60fps超高性能：Flutter编写的应用可以达到60fps(每秒传输帧数)。Flutter采用GPU渲染技术，所以性能很好。完全可以胜任游戏开发。

Jetpack Compose

Jetpack Compose 是用于构建原生 Android 界面的新工具包

原来我们的布局文件都是写在xml文件中的，现在提供了一种新的view构建方式，也就是Compose。它是一种声明式UI，不再使用xml，而是使用kotlin进行UI布局。其实就跟我们之前提到的一点，用java代码去构建view一样的效果。这样就减少了xml解析的时间，提高了效率。

声明式UI。指的是只需要把界面声明出来，不需要手动更新。比如我们这里的Compose只需要写一遍，后续的UI改变会随着变量自动更新。而传统的xml布局方式就无法做到这一点，属于命令式UI，需要我们手动命令纸牌屋UI的修改。

官方也是宣称有以下几点优势：更少更直观的代码，更强大的功能，能提高开发速度。

贴一段代码，感受下Compose的写法：

class MainActivity : AppCompatActivity() {
  override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    setContent {
      Greeting("Android")
    }
  }
}

@Composable
fun Greeting(name: String) {
    Text (text = "Hello $name!")
}

工具篇

Choreographer

它主要有以下特性：

• 能获取整体的帧率
• 能在线上使用
• 获取的帧率几乎是实时的

主要原理就是利用postFrameCallback计算两次绘制的间隔时间，简单贴下代码：

private long mLastFrameTime;
Choreographer.getInstance().postFrameCallback(new Choreographer.FrameCallback() {
    @Override
    public void doFrame(long frameTimeNanos) {
        if (mLastFrameTime == 0) {
            mLastFrameTime = frameTimeNanos;
        }
        float diff = (frameTimeNanos - mLastFrameTime) / 1000000.0f;//得到毫秒，正常是 16.66 ms
        if (diff > 500) {
            double fps = (((double) (mFrameCount * 1000L)) / diff);
            mFrameCount = 0;
            mLastFrameTime = 0;
            Log.d("doFrame", "doFrame: " + fps);
        } else {
            ++mFrameCount;
        }
        Choreographer.getInstance().postFrameCallback(this);
    }
});

想细细研究的可以看看这个库（https://github.com/friendlyrobotnyc/TinyDancer ）

LayoutInspector/Android Device Monitor

LayoutInspector是AndroidStudio中的一个布局检查器，可以通过Tools > Layout Inspector找到，他可以检查应用中的某个界面的视图结构，但是无法查看非调式状态的应用。

如果要看其他应用的布局情况，可以使用Android Device Monitor，在Android Studio 3.1 以后，需要单独从文件夹打开了：android-sdk/tools/monitor

Systrace

Systrace是分析Android性能问题的神器，获取Systrace文件的方式有两种：

• 一是AndroidSDK/tools目录下，通过monitor.bat用Android Device Monitor可视化工具得到
• 二是通过python脚本获取

参考

https://www.jianshu.com/p/a4b8e4c5d9b0 

https://time.geekbang.org/column/article/81049 

https://juejin.cn/post/6844904047355363341 

https://juejin.cn/post/6844904048068395015 https://blog.csdn.net/u013425527/article/details/97046401