UI 优化系列专题，来聊一聊 Android 渲染相关知识，主要涉及 UI 渲染背景知识、如何优化 UI 渲染两部分内容。
UI 优化系列专题
- UI 渲染背景知识
《View 绘制流程之 setContentView() 到底做了什么？》
《View 绘制流程之 DecorView 添加至窗口的过程》
《深入 Activity 三部曲（3）View 绘制流程》
《Android 之 LayoutInflater 全面解析》
《关于渲染，你需要了解什么？》
《Android 之 Choreographer 详细分析》
- 如何优化 UI 渲染
《Android 之如何优化 UI 渲染（上）》
《Android 之如何优化 UI 渲染（下）》
在 Android 中使用动画是非常常见的，无论是使用补间动画还是属性动画，都离不开 View 的绘制任务。我们知道 Android UI 绘制任务“都”是在主线程中完成的。那异步绘制是否可行呢？答案是肯定的，其关键就是今天要介绍的 RenderThread，对于 RenderThread 可能很多人对它并不了解，接下来我将教会大家如何利用 RenderThread 实现动画的异步渲染。
什么是 RenderThread ?
大家是否曾注意过，Android 在 5.0 之后对动画的支持更加炫酷了，但是 UI 绘制并没有因此受到影响，反而更加流畅。这其中很大的功劳源自于 RenderThread 的变化。在介绍 RenderThread 之前，我们需要先来了解下 Android 系统 UI 渲染的演进之路。
在 Android 3.0 之前（或者没有启用硬件加速时），系统都会使用软件方式来渲染 UI。但是由于 CPU 在结构设计上的差异，对于图形处理并不是那么高效。这个过程完全没有利用 GPU 的图形高性能。
CPU 和 GPU 结构设计如下：
- 从结构图可以看出，CPU 的控制器较为复杂，而 ALU 数量较少，因此 CPU 更擅长各种复杂的逻辑运算，但不擅长数学尤其是浮点运算。而 GPU 的设计正是为实现大量数学运算。GPU 的控制器比较简单，但包含大量 ALU。GPU 中的 ALU 使用了并行设计，且具有较多的浮点运算单元。可以帮助我们加快栅格化操作。
所以从 Android 3.0 开始，Android 开始支持硬件加速，但是到 Android 4.0 时才默认开启硬件加速。有关 Android 渲染框架详细内容，你可以参考《关于 UI 渲染，你需要了解什么？》。
优化是无止境的，Google 在 2012 年的 I/O 大会上宣布了 Project Butter 黄油计划，并且在 Android 4.1 中正式开启了这个机制。Project Butter 主要包含三个组成部分，VSYNC、Triple Buffer 和 Choreographer。有关它们的详细分析，你可以参考如下资料：
- Android 之 Choreographer 详细分析
- Android 之 Project Butter 详细介绍
经过 Android 4.1 的 Project Butter 黄油计划之后，Android 的渲染性能有了很大的改善。不过你有没有注意到这样一个问题，虽然利用了 GPU 的图形高性能运算，但是从计算 DisplayList，到通过 GPU 绘制到 Frame Buffer，整个计算和绘制都在 UI 主线程中完成。
UI 线程“既当爹又当妈”，任务过于繁重。如果整个渲染过程比较耗时，可能造成无法响应用户的操作，进而出现卡顿的情况。GPU 对图形的绘制渲染能力更胜一筹，如果使用 GPU 并在不同线程绘制渲染图形，那么整个流程会更加顺畅。
正因如此，在 Android 5.0 引入两个比较大的改变。一个是引入了 RenderNode 的概念，它对 DisplayList 及一些 View 显示属性都做了进一步封装。另一个是引入了 RenderThread，所有的 GL 命令执行都放到这个线程上，渲染线程在 RenderNode 中存有渲染帧的所有信息，可以做一些 View 的异步渲染任务，这样即便主线程有耗时操作的时候也可以保证渲染的流畅性。
至此，我们已经知道 RenderThread 是 Android 5.0 之后的产物，用于分担主线程绘制任务的渲染线程。UI 可以进行异步绘制，那动画可以异步似乎也成为可能。所以，带着疑问，接下来我们还要对其进行一番探索实践，看如何利用 RenderThread 实现动画的异步渲染。
原理探索
经过查看官方文档，得知 RenderThread 目前仅支持两种动画的完全渲染工作（RenderThread 的文档介绍真的是少之又少）。
- ViewPreportyAnimator
- CircularReveal
关于 CircularReveal（揭露动画）的使用比较简单且功能较为单一，在此不做过多的探索，今天我们着重探索下 ViewPropertyAnimator。
final View view = findViewById(R.id.button);
final ViewPropertyAnimator animator = view.animate().scaleY(2).setDuration(1000);
animator.start();
通过 View 的 animate() 即可创建 ViewPropertyAnimator 动画，注意它并不是 Animator 的子类。其内部提供了缩放、位移、透明度相关方法。
public class ViewPropertyAnimator {
/**
* A RenderThread-driven backend that may intercept startAnimation
*/
private ViewPropertyAnimatorRT mRTBackend;
public ViewPropertyAnimator scaleX(float value) {
animateProperty(SCALE_X, value);
return this;
}
// ... 省略 scaleY
public ViewPropertyAnimator translationX(float value) {
animateProperty(TRANSLATION_X, value);
return this;
}
// ... 省略 translationY
public ViewPropertyAnimator alpha(float value) {
animateProperty(ALPHA, value);
return this;
}
/**
* 开始动画
*/
private void startAnimation() {
// 是否能够通过 ReanderThread 渲染关键在这里
if (mRTBackend != null && mRTBackend.startAnimation(this)) {
// 使用 RenderThread 异步渲染动画
return;
}
// 否则将会降解为普通熟悉动画
ValueAnimator animator = ValueAnimator.ofFloat(1.0f);
// ......
animator.start();
}
}
我们需要重点关注的是 startAnimator 方法，在该方法首先对 mRTBackend 进行了判断，它的实际类型是 ViewPropertyAnimatorRT，如果不为 null，则由它来执行动画。如果 if 条件不成立，也就是此时不支持 RenderThread 完全渲染。很明显 RenderThread 渲染动画和 ViewPropertyAnimatorRT 有直接关系。
class ViewPropertyAnimatorRT {
.....
ViewPropertyAnimatorRT(View view) {
mView = view;
}
public boolean startAnimation(ViewPropertyAnimator parent) {
cancelAnimators(parent.mPendingAnimations);
// 关键在这里判断是否成立
if (!canHandleAnimator(parent)) {
return false;
}
// 执行 RenderThread 异步渲染动画
doStartAnimation(parent);
return true;
}
......
}
可以看到 startAnimation 方法先通过 canHandleAnimator 方法判断是否成立，如果不成立返回 false，此时回到 ViewPropertyAnimator 动画将会退化成普通属性动画。否则执行 doStartAnimation 方法。
我们先看下 canHandleAnimator 的判断条件，它的参数是 ViewPropertyAnimator：
private boolean canHandleAnimator(ViewPropertyAnimator parent) {
if (parent.getUpdateListener() != null) {
return false;
}
if (parent.getListener() != null) {
// TODO support
return false;
}
if (!mView.isHardwareAccelerated()) {
// TODO handle this maybe?
return false;
}
if (parent.hasActions()) {
return false;
}
// Here goes nothing...
return true;
}
可以看出代码逻辑是比较清楚了，① 是否支持硬件加速（Android 在 3.0 开始支持硬件加速，在 4.0 默认开启），② 是否设置了监听 Listener 或 UpdateListener，或者设置了 Action（监听动画开始、结束）都会导致 canHandleAnimator 方法返回 false，从而导致 doStartAnimator 方法无法执行。在此我们得到一个非常重要的条件是不进行任何监听器设置，确保 canHandleAnimator 返回 true。
下面接着看 doStartAnimation 方法，执行 doStartAnimation 方法表示动画将被 RenderThread 执行。
private void doStartAnimation(ViewPropertyAnimator parent) {
int size = parent.mPendingAnimations.size();
// 启动延迟时间
long startDelay = parent.getStartDelay();
// duration 执行时间
long duration = parent.getDuration();
// 插值器
TimeInterpolator interpolator = parent.getInterpolator();
if (interpolator == null) {
// Documented to be LinearInterpolator in ValueAnimator.setInterpolator
// 默认线性插值器
interpolator = sLinearInterpolator;
}
if (!RenderNodeAnimator.isNativeInterpolator(interpolator)) {
interpolator = new FallbackLUTInterpolator(interpolator, duration);
}
for (int i = 0; i < size; i++) {
NameValuesHolder holder = parent.mPendingAnimations.get(i);
int property = RenderNodeAnimator.mapViewPropertyToRenderProperty(holder.mNameConstant);
final float finalValue = holder.mFromValue + holder.mDeltaValue;
// 对于每个动画属性都创建了RenderNodeAnimaor
RenderNodeAnimator animator = new RenderNodeAnimator(property, finalValue);
animator.setStartDelay(startDelay);
animator.setDuration(duration);
animator.setInterpolator(interpolator);
animator.setTarget(mView);
animator.start();
mAnimators[property] = animator;
}
parent.mPendingAnimations.clear();
}
ViewPropertyAnimator 的 mPendingAniations 保存了动画的每个属性。doStartAnimation 方法为每个动画属性都创建了一个 RenderNodeAnimator，然后将对应的动画参数也设置给了 RenderNodeAnimator，此处就完成了动画和属性的绑定。
接下来我们要跟踪下 RendernodeAnimator，
public class RenderNodeAnimator extends Animator {
public void setTarget (View view) {
mViewTarget = view;
setTarget (mViewTarget.mRenderNode);
}
private void setTarget (RenderNode node){
......
mTarget = node;
mTarget.addAnimator(this);
}
}
setTarget 方法将当前 View 的 RenderNode 和 RenderNodeAnimator 通过 addAnimator 进行绑定。在 RenderNode 的 addAnimator 方法通过 Native 方法 nAddAnimator 将其注册到 AnimatorManager 中。
public class RenderNode {
public void addAnimator(RenderNodeAnimator animator) {
if (mOwningView == null || mOwningView.mAttachInfo == null) {
throw new IllegalStateException("Cannot start this animator on a detached view!");
}
// Native 方法注册到AnimatorManager
nAddAnimator(mNativeRenderNode, animator.getNativeAnimator());
mOwningView.mAttachInfo.mViewRootImpl.registerAnimatingRenderNode(this);
}
}
nAddAnimator 方法实现如下：
static void android_view_RenderNode_addAnimator (JNIEnv* env, jobject clazz, jlong renderNodePtr, jlong animatorPtr ){
RenderNode* renderNode = reinterpret_cast (renderNodePtr);
RenderPropertyAnimator* animator = reinterpret_cast (animatorPtr);
renderNode -> addanimator(animator);
}
void RenderNode :: addAnimator (const sp& animator){
// 添加到 AnimatorManager
mAnimatorManager.addAnimator(animator);
}
至此，我们清楚了动画是如何被添加到 AnimatorManager 中。根据其官方文档的介绍，后续 AnimatorManager 和 RenderThread 的操作交由系统处理，进而让 RenderThread 去完全管理动画，实现由 RenderThread 渲染动画。
代码实践
通过上面原理探索阶段，为了能够让动画顺利交给 RenderThread，除了不能设置任何回调且 View 支持硬件加速（Android 4.0 之后默认支持）之外，还必须必须满足 ViewPropertyAnimatorRT 不为 null，它是让动画交由 RenderThread 的关键。
但是翻阅源码，并未发现任何创建该对象的地方。此时我们需要一些特殊的操作以达到预期的效果。通过查看源码，发现 ViewPropertyAnimatorRT 属于包保护级别，而且没有被 @hide（Android P 之后也没有关系），所以我们直接采用反射的方式完成。
ps：国外一篇博客中介绍：每个组件都是隐藏的，因此要使用它们，必须通过反射获得对所有需要类 / 方法的引用。
为 View 创建 ViewPropertyAnimatorRT 对象：
private static Object createViewPropertyAnimatorRT(View view) {
try {
final Class animRtCalzz = Class.forName("android.view.ViewPropertyAnimatorRT");
final Constructor animRtConstructor = animRtCalzz.getDeclaredConstructor(View.class);
animRtConstructor.setAccessible(true);
return animRtConstructor.newInstance(view);
} catch (Exception e) {
e.printStackTrace();
}
return null;
}
然后将 ViewPropertyAnimatorRT 设置到对应的 ViewPropertyAnimator：
private static void setViewPropertyAnimatorRT(ViewPropertyAnimator animator, Object rt) {
try {
final Class animClazz = Class.forName("android.view.ViewPropertyAnimator");
final Field animRtField = animClazz.getDeclaredField("mRTBackend");
animRtField.setAccessible(true);
animRtField.set(animator, rt);
} catch (Exception e) {
e.printStackTrace();
}
}
在动画执行前需要先执行上述步骤以满足相关条件：
final View view = findViewById(R.id.button);
final ViewPropertyAnimator animator = view.animate().scaleY(2).setDuration(1000);
// 必须在 start 之前
AsyncAnimHelper.onStartBefore(animator, view);
animator.start();
设置两种动画分别在执行 1s 后，让主线程休眠 2s（模拟主线程卡顿）。可以很明显看到普通属性动画，在主线程阻塞的时候，会出现丢帧卡顿现象。而使用 RenderThread 渲染的动画即使阻塞了主线程仍然不受影响，如下图所示（上面控件为普通属性动画）：
以上便是关于 RenderThread 实现动画的异步渲染的探索和实践，文中如果不妥或有更好的分析结果，欢迎您的分享留言或指正。
Android 渲染框架非常庞大，并且演进的非常快，更多 Android 渲染框架的知识，感兴趣的朋友可以参考如下资料：
- Android 之如何优化 UI 渲染（上）
- Android 之如何优化 UI 渲染（下）
- Android 之理解 VSYNC 信号
- Android 之 ViewTreeObserver 全面解析
- 深入 Activity 三部曲（3）之 View 绘制流程
最后，如果你有更好的分析结果或实践方案，欢迎您的分享留言或指正。
文章如果对你有帮助，请留个赞吧！
其他系列专题
- Android 存储优化系列专题
- Android 对象序列化之追求完美的 Serial
- Android 之不要滥用 SharedPreferences（上）
- Android 存储选项之 SQLite 优化那些事儿
- Android 对象序列化之你不知道的 Serializable