这一篇文章我们继续分析另外一个重要的类RenderNode， 这个在前面绘制流程里有也有提到，这里我将更加深入的介绍这个类
1 简介
RenderNode是一个绘制节点，一个大的界面是由很多小的绘制单元组成，这个正如View的层级结构，整个界面由很多控件组成，这样带来的好处就是需要整体绘制界面的时候，只有那些变化的单元重新绘制，然后在重新组装界面即可。这让我联想到了活字印刷术，当我们要印刷一页内容的时候，如果将所有的字都刻在一块板上，当要修改的时候，就需要整体重新来刻，效率很低成本很高，但是如果是将每一个字作为一个组件，页面只是这些字拼接出来的，修改或者重用的话就相对容易很多，RenderNode就相当于是一个个的字。
尽管在应用层我们很少使用这个类，但是实际上的每个View都持有 一个RenderNode,我们可以这样去理解，View作为一个组件，会由很多业务，比如事件，布局，测量和绘制等，而绘制业务正是委托给RenderNode去完成，绘制需要Canvas也是由这个RenderNode提供的。RenderNode除了为View提供绘制能力外，还为其他可绘制的API提供绘制能力，最常见的就是Drawable，我们也可以封装自己的绘制组件，基于RenderNode的绘制是利用了硬件加速的绘制。
在应用层，View会形成树型的层级结构，因此RenderNode也会相应的构造一个出绘制节点的树形结构。但是RenderNode的树形结构和View的树形结构可能是不一样的，因为一个View可能会对应着几个RenderNode，比如View的背景也会转换成一个RenderNode，因此一个View节点可能会产生多个RenderNode对象，通常一个View的背景和View的的Children是平级的。
2 属性
2.1 Java层
RenderNode 的功能主要是在C层实现的。在java层，它持有一个mCurrentRecordingCanvas，表示当前正在使用的那个Canvas
frameworks/base/graphics/java/android/graphics/RenderNode.java
private RecordingCanvas mCurrentRecordingCanvas;
这个Canvas的类型是RecordingCanvas， 它由RenderNode的beginRecording方法创建的
public @NonNull RecordingCanvas beginRecording(int width, int height) {
if (mCurrentRecordingCanvas != null) {
throw new IllegalStateException(
"Recording currently in progress - missing #endRecording() call?");
}
mCurrentRecordingCanvas = RecordingCanvas.obtain(this, width, height);
return mCurrentRecordingCanvas;
}
这里可以看到beginRecording方法不能连续调用，需要在调用endRecording之后才能再次调用。这个canvas是通过RecordingCanvas获得的一个canvas，obtain方法往往代表是从缓存池中获取的，这里我们不深入介绍，我们知道这个Canvas 是再从这里获得的，它的类型是RecordingCanvas. 它是Canvas的子类。
RenderNode 也由很多其他的属性，但是在C层定义的，所以我们继续分析一下在C层的RenderNode
2.2 C层
在JNI 和C层这里，主要有这个几个文件
frameworks/base/libs/hwui/jni/android_graphics_RenderNode.cpp
frameworks/base/libs/hwui/RenderNode.h
frameworks/base/libs/hwui/RenderNode.cpp
以及专门用于存储属性的RenderProperties类
frameworks/base/libs/hwui/RenderProperties.h
frameworks/base/libs/hwui/RenderProperties.cpp
2.2.1 mStagingProperties
mStagingProperties记录的是修改过的属性，在没有提交前，所有的修改都临时存在mStagingProperties。
RenderProperties mStagingProperties;
对属性的修改，是通过一个宏定义来实现的，来分析一个简单属性的top的修改流程
frameworks/base/graphics/java/android/graphics/RenderNode.java
public boolean setTop(int top) {
return nSetTop(mNativeRenderNode, top);
}
frameworks/base/libs/hwui/jni/android_graphics_RenderNode.cpp
static jboolean android_view_RenderNode_setTop(CRITICAL_JNI_PARAMS_COMMA jlong renderNodePtr, int top) {
return SET_AND_DIRTY(setTop, top, RenderNode::Y);
}
通过SET_AND_DIRTY这个宏定义来调用mutateStagingProperties上的方法
#define SET_AND_DIRTY(prop, val, dirtyFlag) \
(reinterpret_cast<RenderNode*>(renderNodePtr)->mutateStagingProperties().prop(val) \
? (reinterpret_cast<RenderNode*>(renderNodePtr)->setPropertyFieldsDirty(dirtyFlag), true) \
: false)
扩展开就相当于是
reinterpret_cast<RenderNode*>(renderNodePtr)->mutateStagingProperties().setTop(top)
? (reinterpret_cast<RenderNode*>(renderNodePtr)->setPropertyFieldsDirty(dirtyFlag), true)
: false
renderNode->mutateStagingProperties() 返回的就是 mStagingProperties
frameworks/base/libs/hwui/RenderNode.h
RenderProperties& mutateStagingProperties() { return mStagingProperties; }
因此，会执行RenderProperties的setTop方法。如果setTop返回true，则会调用setPropertyFieldsDirty，记录发生变化的属性，这里传入的是RenderNode::Y这个枚举值，定义如下：
enum DirtyPropertyMask {
GENERIC = 1 << 1,
TRANSLATION_X = 1 << 2,
TRANSLATION_Y = 1 << 3,
TRANSLATION_Z = 1 << 4,
SCALE_X = 1 << 5,
SCALE_Y = 1 << 6,
ROTATION = 1 << 7,
ROTATION_X = 1 << 8,
ROTATION_Y = 1 << 9,
X = 1 << 10,
Y = 1 << 11,
Z = 1 << 12,
ALPHA = 1 << 13,
DISPLAY_LIST = 1 << 14,
};
frameworks/base/libs/hwui/RenderProperties.h
bool setTop(int top) {
if (RP_SET(mPrimitiveFields.mTop, top)) {
mPrimitiveFields.mHeight = mPrimitiveFields.mBottom - mPrimitiveFields.mTop;
if (!mPrimitiveFields.mPivotExplicitlySet) {
mPrimitiveFields.mMatrixOrPivotDirty = true;
}
return true;
}
return false;
}
RP_SET是一个宏定义
#define RP_SET(a, b, ...) ((a) != (b) ? ((a) = (b), ##__VA_ARGS__, true) : false)
也就是如果mPrimitiveFields.mTop与top不相同，则将top赋值给mPrimitiveFields.mTop， 并且返回true，否则直接返回false。
如果top变化了，同步修改高度。
这就是一个简单属性的修改流程。 那么RenderNode有那些属性呢？来看一看RenderProperties的定义
struct PrimitiveFields {
int mLeft = 0, mTop = 0, mRight = 0, mBottom = 0;
int mWidth = 0, mHeight = 0;
int mClippingFlags = CLIP_TO_BOUNDS;
SkColor mSpotShadowColor = SK_ColorBLACK;
SkColor mAmbientShadowColor = SK_ColorBLACK;
float mAlpha = 1;
float mTranslationX = 0, mTranslationY = 0, mTranslationZ = 0;
float mElevation = 0;
float mRotation = 0, mRotationX = 0, mRotationY = 0;
float mScaleX = 1, mScaleY = 1;
float mPivotX = 0, mPivotY = 0;
bool mHasOverlappingRendering = false;
bool mPivotExplicitlySet = false;
bool mMatrixOrPivotDirty = false;
bool mProjectBackwards = false;
bool mProjectionReceiver = false;
bool mAllowForceDark = true;
bool mClipMayBeComplex = false;
Rect mClipBounds;
Outline mOutline;
RevealClip mRevealClip;
} mPrimitiveFields;
我们可以看到这里的属性和我们在JAVA层View的几何属性是非常相似的，基本上View的几何属性都会类似setTop的方式反映到RenderProperties。大部分的简单属性比如top，bottom，translate，rotate，elevation，scale，pivot这些就不介绍了，我们分析一下两个比较特殊的属性mProjectBackwards 和 mProjectionReceiver。这两个属性会更改RenderNode绘制顺序。设置成mProjectionReceiver的RenderNode会成为一个锚点，被标记成mProjectBackwards的RenderNode不会被绘制在它的父节点，而是绘制到它最近的父节点中的标记成mProjectionReceiver的子节点中。例如P节点包含一个子节点C，以及P的背景PB，C包含一个背景CB. 一般的顺序应该是CB绘制到C中，然后C和PB绘制到P中。 但是如果PB被设置成mProjectionReceiver ，且CB被标记成mProjectBackwards，绘制的顺序将变成，C绘制到P中，CB绘制到PB 中，然后PB绘制到P中。也就是说将CB投影到PB中去。这种做法将使得CB的变化不会导致C重新绘制，从而提升效率，比如作为背景动画的RenderNode，它不会导致View自身的RenderNode的重新绘制。
2.2.1 mProperties
mStagingProperties暂存的修改将会与mProperties同步，从而正式成为影响绘制的参数。同步的方法很简单，直接赋值，在绘制帧之前会完成这些参数的同步。
void RenderNode::syncProperties() {
mProperties = mStagingProperties;
}
个人感觉好像第一同步之后，mProperties就和mStagingProperties指向同一个对象，只有似乎以后没有同步的必要了。
3 总结
RenderNode主要保存了一系列的属性，大部分的View属性都会反映到RenderNode，RenderNode使用RenderProperties来保存这些属性，在绘制帧的时候，这些属性会影响最终的绘制。RenderNode也会形成一颗树形的层级结构，但是它与View的层级结构并不是一一对应的，在同一级中的RenderNode不仅包含View的兄弟节点的RenderNode，也包含父View的背景等可绘制内容。除了属性之外，RenderNode的另外一个重要属性是DisplayList，它存放的是这个RenderNode的绘制指令，这个将在下一篇中继续分析。
以上内容是对RenderNode的分析，基于个人的理解，如有疏漏和错误，欢迎一起讨论研究。
