UI渲染优化：让每一帧都丝滑如初

做Android开发这么多年，我遇到过最头疼的问题之一，就是UI卡顿。明明代码逻辑没问题，用户滑动列表时却像在放幻灯片。后来我才真正理解——UI渲染的瓶颈，往往不在业务逻辑，而在渲染管线本身。

今天我们就来聊聊UI渲染优化的核心内容。说白了，就是让系统在16ms内完成一帧的绘制。做不到？用户就会感受到卡顿。

16ms原则与垂直同步

为什么是16ms？因为人眼能接受的流畅画面是60帧/秒。1000ms ÷ 60 ≈ 16.67ms。也就是说，每一帧的绘制、合成、显示，必须在16ms内完成。

我刚开始做性能优化时，总觉得这个数字很抽象。直到有一次，我在一个列表页面上加了个复杂的阴影效果，结果帧率直接掉到30fps。嗯，那时候我才真正体会到——16ms其实很短，短到一次多余的measure都可能超时。

核心要点：Android系统每16ms发出一次VSync信号，通知CPU和GPU开始准备下一帧。如果一帧的绘制时间超过16ms，就会错过下一个VSync，导致掉帧。

垂直同步（VSync）是什么？你可以把它想象成一个节拍器。系统每16ms打一个拍子，CPU和GPU必须在这个拍子内完成工作。如果没完成，那就等下一个拍子。这中间就产生了丢帧。

我见过不少开发者，为了追求视觉效果，在列表item里塞了多层嵌套布局。结果呢？measure阶段就花了20ms。你想想看，这还没开始draw呢，时间已经超了。

过度绘制（Overdraw）检测与优化

过度绘制，说白了就是同一个像素被重复绘制了多次。比如你画了一个红色背景，又在上面盖了一个蓝色按钮，那这个像素就被画了两次。

怎么检测？Android Studio自带的GPU Overdraw工具就很好用。打开开发者选项，开启「调试GPU过度绘制」，屏幕会变成这样：

颜色 含义 建议
蓝色 过度绘制1次 可接受
绿色 过度绘制2次 需要关注
粉色 过度绘制3次 必须优化
红色 过度绘制4次以上 严重问题

我曾经接手过一个项目，整个页面都是红色。排查后发现，Activity的背景设成了白色，每个Fragment又设了白色背景，里面的CardView又设了白色背景。三层白色叠加，白白浪费了GPU性能。

优化技巧：去掉不必要的背景色。如果父布局已经设置了背景，子布局就不需要再设了。尤其是ListView/RecyclerView的item，默认背景往往可以去掉。

还有一个常见问题——自定义View的onDraw里画了太多东西。我见过有人在一个View里画了20多个圆，每个圆都调用了canvas.drawCircle()。其实完全可以用Path合并绘制。

ViewStub与Merge标签使用

这两个标签，是我个人非常推荐的优化利器。它们解决的是同一个问题——减少布局层级。

ViewStub：懒加载的占位符。它本身不占布局空间，只有当你调用inflate()时，才会真正加载布局。适合那些不是每次都需要显示的视图，比如网络错误提示、空状态页面等。

<!-- 布局中使用ViewStub -->
<ViewStub
    android:id="@+id/stub_empty"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:layout="@layout/layout_empty_state" />

// 代码中按需加载
ViewStub stub = findViewById(R.id.stub_empty);
if (dataList.isEmpty()) {
    stub.inflate();
}

我习惯在列表页面的空状态、加载失败、登录引导等场景使用ViewStub。因为这些视图可能90%的时间都不会显示，何必让它们占用布局测量时间呢？

Merge标签：减少一层不必要的ViewGroup。比如你有一个自定义的LinearLayout，里面只包含一个子布局。用Merge可以去掉这层嵌套。

<!-- merge_layout.xml -->
<merge xmlns:android="http://schemas.android.com/apk/res/android">
    <TextView
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:text="标题" />
    <TextView
        android:layout_width="match_parent"
        android:layout_height="wrap_content"
        android:text="内容" />
</merge>

// 在Activity中直接inflate
View view = getLayoutInflater().inflate(R.layout.merge_layout, parent, true);

注意：Merge标签只能作为根标签使用，且inflate时必须指定parent。它不能用于Fragment或Activity的setContentView中。

我曾经在一个项目中，把一个复杂的列表item从7层嵌套优化到了3层。主要手段就是Merge+ViewStub+去掉冗余背景。优化后列表滑动帧率从45fps提升到了58fps。效果立竿见影。

自定义View的onDraw优化

自定义View是性能问题的重灾区。我见过太多人在onDraw里做耗时操作，比如创建对象、读取文件、甚至网络请求。这些都是大忌。

onDraw方法每帧都会被调用，频率极高。任何在onDraw里的耗时操作，都会被放大60倍（每秒）。

优化原则其实很简单：

  • 不要在onDraw里创建对象：对象创建会触发GC，GC会导致卡顿。把对象创建移到构造方法或初始化方法中。
  • 不要在onDraw里做复杂计算：比如三角函数、路径计算等。提前算好，缓存结果。
  • 减少drawCall次数：能用Path合并绘制的，就不要一个个画。
  • 使用硬件加速：在AndroidManifest中开启硬件加速，让GPU分担绘制任务。
// 错误示例：在onDraw里创建对象
@Override
protected void onDraw(Canvas canvas) {
    Paint paint = new Paint(); // 每次绘制都创建对象
    paint.setColor(Color.RED);
    canvas.drawCircle(100, 100, 50, paint);
}

// 正确示例：对象在构造方法中创建
private Paint mPaint;

public MyView(Context context) {
    super(context);
    mPaint = new Paint();
    mPaint.setColor(Color.RED);
}

@Override
protected void onDraw(Canvas canvas) {
    canvas.drawCircle(100, 100, 50, mPaint);
}

还有一个容易被忽略的点——invalidate()的调用频率。我见过有人用Handler每10ms调用一次invalidate()，想让View动起来。结果呢？CPU被占满，UI卡成PPT。正确的做法是用ValueAnimator或Choreographer来控制刷新频率。

我的经验：自定义View的onDraw里，只做绘制操作。任何逻辑判断、数据准备、对象创建，都放到外面去。记住一句话——onDraw不是用来思考的，是用来画的。

知识体系总览

下面这张图，是我整理的UI渲染优化核心逻辑。你可以看到，所有优化手段最终都指向同一个目标——让每一帧在16ms内完成。

UI渲染优化知识体系 16ms原则 垂直同步（VSync） 过度绘制检测与优化 ViewStub & Merge 自定义View onDraw优化 GPU Overdraw工具 减少布局层级 去掉冗余背景色 避免onDraw创建对象 懒加载非必要视图 目标：每一帧都在16ms内完成

UI渲染优化，说到底就是一场与时间的赛跑。16ms很短，但只要我们掌握了正确的方法，完全可以让每一帧都丝滑流畅。从检测过度绘制开始，到优化布局层级，再到精雕细琢自定义View的onDraw方法——每一步都能带来实实在在的性能提升。

记住，优化的核心不是炫技，而是让用户感受不到优化的存在。好的性能，就是用户觉得「这App用着真顺手」，而不是「这App优化得真好」。

公众号:蓝海资料掘金营，微信deep3321

← 上一章 📖 返回目录 下一章 →