轉(zhuǎn)載請(qǐng)標(biāo)注出處: http://www.lxweimin.com/p/8facd77fac09
Android DisplayList 構(gòu)建過(guò)程 寫(xiě)了DisplayList的構(gòu)建，接下來(lái)要做的事情就是開(kāi)始渲染DisplayList了，具體的函數(shù)是nSyncAndDrawFrame , UI線程通過(guò)RenderProxy請(qǐng)求RenderThread執(zhí)行一個(gè)DrawFrameTask, 然后阻塞式等著RenderThread的通知
void DrawFrameTask::postAndWait() {
AutoMutex _lock(mLock);
mRenderThread->queue(this);
mSignal.wait(mLock); //UI線程blocking等著 RenderThread的回應(yīng)
}
當(dāng)RenderThread調(diào)度到DrawFrameTask時(shí)會(huì)執(zhí)行DrawFrameTask::run()函數(shù)。
void DrawFrameTask::run() {
bool canUnblockUiThread;
bool canDrawThisFrame;
{
TreeInfo info(TreeInfo::MODE_FULL, *mContext);
info.observer = mObserver;
canUnblockUiThread = syncFrameState(info); //同步DisplayList信息
canDrawThisFrame = info.out.canDrawThisFrame;
}
// Grab a copy of everything we need
CanvasContext* context = mContext;
if (canUnblockUiThread) {
//是否unblock ui線程, 有可能需要RenderThread在這一幀畫(huà)完后才unblock ui thread
unblockUiThread();
}
if (CC_LIKELY(canDrawThisFrame)) {
context->draw();
}
if (!canUnblockUiThread) { //與上面的 if(canUnblockUiThread)相反，肯定最后都會(huì)unblock ui的，否則就會(huì)發(fā)生ANR了
unblockUiThread();
}
}
上面的run函數(shù)包含兩個(gè)動(dòng)作，一是sync DisplayList的動(dòng)作，一個(gè)是渲染DisplayList的動(dòng)作，這篇blog僅分析 DisplayList同步的過(guò)程
注意: 這里并不考慮Texture, Layer相關(guān), 那么syncFrameState簡(jiǎn)化后的代碼如下，
bool DrawFrameTask::syncFrameState(TreeInfo& info) {
// mFrameInfo是一個(gè)int形數(shù)組，它主要記錄事件發(fā)生的各種時(shí)刻，
// 比如接收到vsync時(shí)間, draw start時(shí)間等等
int64_t vsync = mFrameInfo[static_cast<int>(FrameInfoIndex::Vsync)];
mRenderThread->timeLord().vsyncReceived(vsync);
bool canDraw = mContext->makeCurrent();
mContext->prepareTree(info, mFrameInfo, mSyncQueued, mTargetNode);
// If prepareTextures is false, we ran out of texture cache space
return info.prepareTextures;
}
其中 makeCurrent()函數(shù)直接調(diào)用了eglMakeCurrent,
eglMakeCurrent(mEglDisplay, mEglSurface, mEglSurface, mEglContext)
該接口將申請(qǐng)到的display，draw（surface）和 egl context進(jìn)行了綁定。也就是說(shuō)，在egl context下的OpenGL API指令將draw（surface）作為其渲染最終目的地, 而display作為draw（surface）的前端顯示。調(diào)用后，當(dāng)前線程使用的EGLContex為mEglContext. 參考這篇文章
而參數(shù) TreeInfo是個(gè)臨時(shí)變量，它的初始化在 DrawFrameTask::run()
TreeInfo info(TreeInfo::MODE_FULL, *mContext);
如果傳入的就 MODE_FULL, TreeInfo里的成員prepareTextures將會(huì)置為true, 因?yàn)楸纠a并不涉及到Texture相關(guān)，所以返回值 info.prepareTextures始終為true.
syncFrameState接著開(kāi)始 prepareTree, 它從CanvasContext開(kāi)始調(diào)用. 如圖所示, 就是遞歸遍歷整個(gè)Tree.
void CanvasContext::prepareTree(TreeInfo& info, int64_t* uiFrameInfo,
int64_t syncQueued, RenderNode* target) {
info.damageAccumulator = &mDamageAccumulator;
for (const sp<RenderNode>& node : mRenderNodes) {
// info.mode 依然是MODE_FULL
info.mode = (node.get() == target ? TreeInfo::MODE_FULL : TreeInfo::MODE_RT_ONLY);
node->prepareTree(info);
}
}
CanvasContext里的mRenderNodes是一個(gè)Vector，也就是它儲(chǔ)存了一系列的RenderNode, 但是這個(gè)盒子只有一個(gè)RenderNode, 也就是整個(gè)UI的RootRenderNode.
void RenderNode::prepareTree(TreeInfo& info) {
prepareTreeImpl(info, functorsNeedLayer);
}
void RenderNode::prepareTreeImpl(TreeInfo& info, bool functorsNeedLayer) {
info.damageAccumulator->pushTransform(this);
if (info.mode == TreeInfo::MODE_FULL) {
pushStagingPropertiesChanges(info);
}
...
if (info.mode == TreeInfo::MODE_FULL) {
pushStagingDisplayListChanges(info);
}
prepareSubTree(info, childFunctorsNeedLayer, mDisplayList);
info.damageAccumulator->popTransform();
}
由prepareTreeImpl的實(shí)現(xiàn)看出，先同步 當(dāng)前的 RenderNode, 然后再遞歸同步子RenderNode.
一、同步RenderProperties和DisplayList
1.1 pushStagingPropertiesChanges
void RenderNode::pushStagingPropertiesChanges(TreeInfo& info) {
if (mDirtyPropertyFields) {
mDirtyPropertyFields = 0;
damageSelf(info);
info.damageAccumulator->popTransform();
syncProperties();
info.damageAccumulator->pushTransform(this);
damageSelf(info);
}
}
mDirtyPropertyFields是一個(gè)int變量，它的每一位都表示一種Dirty的類型， 只要RenderNode中 RenderProperties(mStagingProperties表示，該值由UI線程維護(hù))發(fā)生變化時(shí)，mDirtyPropertyFields就不為0，就表示要同步該P(yáng)roperties.
而同步的方法就是 mProperties = mStagingProperties
其中 mProperites由RenderThread線程維護(hù)， 而mStagingProperties由 UI線程維護(hù).
1.2 pushStagingDisplayListChanges
void RenderNode::pushStagingDisplayListChanges(TreeInfo& info) {
mNeedsDisplayListSync = false;
damageSelf(info);
syncDisplayList(&info);
damageSelf(info);
}
}
當(dāng)Java層調(diào)用RenderNode.end()后，就會(huì)將Canvas中的DisplayList更新到RenderNode中的mStagingDisplayList中，具體參考 Android DisplayList 構(gòu)建過(guò)程第三節(jié)。
同時(shí)會(huì)將 mNeedDisplayListSync置為true, 這樣，在sync的時(shí)候就會(huì)去同步DisplayList, 同步過(guò)程如下所示.
void RenderNode::syncDisplayList(TreeInfo* info) {
// Make sure we inc first so that we don't fluctuate between 0 and 1,
// which would thrash the layer cache
if (mStagingDisplayList) {
for (auto&& child : mStagingDisplayList->getChildren()) {
child->renderNode->incParentRefCount(); //增加parent的引用計(jì)數(shù)
}
}
deleteDisplayList(info ? info->observer : nullptr, info);
mDisplayList = mStagingDisplayList; //重新賦值
mStagingDisplayList = nullptr;
...
}
從代碼中看出，在同步DisplayList后，UI線程維護(hù)的mStagingDisplayList就被重新置為null了。而 RenderThread 維護(hù)的mDisplayList指向了UI線程的mStagingDisplayList.
二、遞歸同步子RenderNode
void RenderNode::prepareSubTree(TreeInfo& info, bool functorsNeedLayer, DisplayList* subtree) {
if (subtree) {
for (auto&& op : subtree->getChildren()) {
RenderNode* childNode = op->renderNode;
info.damageAccumulator->pushTransform(&op->localMatrix);
childNode->prepareTreeImpl(info, childFunctorsNeedLayer);
info.damageAccumulator->popTransform();
}
}
}
RenderNode在同步完自己的RenderProperties和DisplayList后，開(kāi)始遞歸同步子RenderNode信息。
就這樣就把整個(gè)DisplayTree的信息從UI thread同步到了RenderThread.
三、計(jì)算臟區(qū)域
3.1 damageSelf()
damageSelf在同步Properties和DisplayList時(shí)被調(diào)用了兩次。
damageSelf這個(gè)函數(shù)從字面上理解就是"自毀"，那自毀什么呢？從函數(shù)定義來(lái)看
void RenderNode::damageSelf(TreeInfo& info) {
if (isRenderable()) {
if (properties().getClipDamageToBounds()) {
info.damageAccumulator->dirty(0, 0, properties().getWidth(), properties().getHeight());
} else {
info.damageAccumulator->dirty(DIRTY_MIN, DIRTY_MIN, DIRTY_MAX, DIRTY_MAX);
}
}
}
damageSelf()是RenderNode里面的函數(shù)，猜想這個(gè)自毀應(yīng)該是和RenderNode相關(guān)。
- 自毀的前提
damageSelf要工作的一個(gè)前提就是 RenderNode是可Renderable (isRenderable())的，從 isRenderable函數(shù)定義可以看出，也就是當(dāng)前的RenderNode已經(jīng)同步過(guò)DisplayList(pushStagingDisplayListChanges)，并且這個(gè)DisplayList里有繪制命令。
-
自毀什么？
從if else可以看出，自毀是調(diào)用DamageAccumulator->dirty
void DamageAccumulator::dirty(float left, float top, float right, float bottom) {
mHead->pendingDirty.join(left, top, right, bottom);
}
原來(lái)是將mHead的pendingDirty與自毀的區(qū)域求并集(具體可以查看 join函數(shù)),
DirtyStack* mHead
mHead是在DamageAccumulator里定義的，DamageAccumulator里維護(hù)著一個(gè)棧，棧頂由mHead指定。
整個(gè)DamageAccumulator的棧圖如下所示
damageSelf()函數(shù)會(huì)計(jì)算出 圖中淺藍(lán)色背景方塊的 pendingDirty, 也就是臟區(qū)域. 注意這幅圖是針對(duì)第一次同步時(shí)的棧圖。
- 為什么damageSelf都調(diào)用兩次呢？
從 1.2 的pushStagingPropertiesChanges和 1.3 的 pushStagingDisplayListChanges可以看出，這兩個(gè)函數(shù)都分別調(diào)用了兩次 damageSelf(), 為什么呢？
pushStagingPropertiesChanges和pushStagingDisplayListChanges都是從UI線程同步相應(yīng)的信息到RenderThread線程，那說(shuō)明RenderThread的線程里保存的是舊數(shù)據(jù)，而UI線程是新數(shù)據(jù)，
既然是求臟區(qū)域，那么不能只求新數(shù)據(jù)的臟區(qū)域啊，比如，如果一個(gè)操作是將View從 1200x300(舊數(shù)據(jù)) 縮小到1200x150(新數(shù)據(jù)), 那么這塊臟區(qū)域是多少呢？ 1200x150？這顯然不對(duì)了吧，數(shù)據(jù)從1200x300變換到1200x150, 那么整個(gè)臟區(qū)域就應(yīng)該是它們的并集，1200x300.
所以調(diào)用兩次damageSelf，第一次是針對(duì)舊數(shù)據(jù)，得到一個(gè)臟區(qū)域，第二次是針對(duì)新數(shù)據(jù)，然后再計(jì)算它們的并集也就是整個(gè)臟區(qū)域。
- 臟區(qū)域的大小
這個(gè)就具體參考 getClipDamageToBounds了，它的意思是說(shuō)是否可以裁剪臟區(qū)域到固定的區(qū)域, 如果可以的話，那么就將臟區(qū)域裁剪到 View的 Width和Height.
3.2 push/pop Transform
pushTransform與popTransform都是成對(duì)出現(xiàn)的，它們是DamageAccumulator里的成員函數(shù)，
pushTransform有兩種定義
pushTransform(const RenderNode* transform)
這種函數(shù)形式在prepareTreeImpl中調(diào)用，主要是將當(dāng)前的RenderNode push進(jìn)棧pushTransform(const Matrix4* transform)
這種函數(shù)形式在prepareSubTree中調(diào)用，主要是將RenderNodeOp中的localMatrix進(jìn)棧popTransform()
這個(gè)就是出棧的操作
通過(guò)pushTransform操作就形成了圖2 DamageAccumulator的棧圖
圖中1和2是子view, 它們本就沒(méi)有子children，所以棧的操作是先對(duì)TextView入棧，待TextView的DisplayList與RenderProperties更新完后就會(huì)依次對(duì)TextView的RenderNode pop，然后對(duì)TextView的matrix4 pop.
那么popTransform的操作是干什么的呢？
void DamageAccumulator::popTransform() {
DirtyStack* dirtyFrame = mHead;
mHead = mHead->prev;
switch (dirtyFrame->type) {
case TransformRenderNode:
applyRenderNodeTransform(dirtyFrame);
break;
case TransformMatrix4:
applyMatrix4Transform(dirtyFrame);
break;
case TransformNone:
mHead->pendingDirty.join(dirtyFrame->pendingDirty);
break;
default:
LOG_ALWAYS_FATAL("Tried to pop an invalid type: %d", dirtyFrame->type);
}
}
從代碼可以看出來(lái)，先將棧頂元素出棧得到 dirtyFrame, 然后再重新assign 棧頂， 接著針對(duì)dirtyFrame的類型再作具體的變換。
以TextView為例
TransformRenderNode
void DamageAccumulator::applyRenderNodeTransform(DirtyStack* frame) {
if (frame->pendingDirty.isEmpty()) { //此時(shí)的frame為圖中的dirtyFrame, 可以看出它的pendingDirty不為空
return;
}
const RenderProperties& props = frame->renderNode->properties();
if (props.getAlpha() <= 0) { //如果 alpha是透明的，那么就沒(méi)必要繼續(xù)計(jì)算臟區(qū)域了，
return;
}
// Perform clipping
if (props.getClipDamageToBounds() && !frame->pendingDirty.isEmpty()) {
//進(jìn)入分支，
if (!frame->pendingDirty.intersect(0, 0, props.getWidth(), props.getHeight())) {
frame->pendingDirty.setEmpty();
}
}
// apply all transforms
mapRect(props, frame->pendingDirty, &mHead->pendingDirty);
...
}
- getAlpha() <=0
那說(shuō)明這個(gè)是透明的屬性， 透明的意思就是不顯示？ 就不需要應(yīng)用這些矩陣變換了 - frame->pendingDirty.intersect()
這個(gè)是求交集的意思，pendingDirty的區(qū)域是 (0, 0, 1200, 120)， 而props,getWidth(), props.getHeight()分別也是1200, 120
接下來(lái)看mapRect, frame->pendingDrity這塊區(qū)域是(0, 0, 1200, 120), 而mHead->pendingDirty是圖3中淺黃色的pendingDirty (0, 0, 0, 0)
static inline void mapRect(const RenderProperties& props, const SkRect& in, SkRect* out) {
if (in.isEmpty()) return;
const SkMatrix* transform = props.getTransformMatrix();
SkRect temp(in);
if (transform && !transform->isIdentity()) { //不會(huì)進(jìn)入該分支
if (CC_LIKELY(!transform->hasPerspective())) {
transform->mapRect(&temp);
} else {
// Don't attempt to calculate damage for a perspective transform
// as the numbers this works with can break the perspective
// calculations. Just give up and expand to DIRTY_MIN/DIRTY_MAX
temp.set(DIRTY_MIN, DIRTY_MIN, DIRTY_MAX, DIRTY_MAX);
}
}
temp.offset(props.getLeft(), props.getTop());
out->join(temp);
}
- isIdentity()
這個(gè)判斷是否是單位矩陣，一般都是單位矩陣， 所以并不會(huì)進(jìn)入 if分支. 所以最后out的區(qū)域大小為(0, 0, 1200, 120). 也就是mHead->pendingDirty，也就是下圖黃色塊區(qū)域
TransformMatrix4
void DamageAccumulator::applyMatrix4Transform(DirtyStack* frame) {
mapRect(frame->matrix4, frame->pendingDirty, &mHead->pendingDirty);
}
static inline void mapRect(const Matrix4* matrix, const SkRect& in, SkRect* out) {
if (in.isEmpty()) return;
Rect temp(in);
if (CC_LIKELY(!matrix->isPerspective())) {
matrix->mapRect(temp);
} else {
// Don't attempt to calculate damage for a perspective transform
// as the numbers this works with can break the perspective
// calculations. Just give up and expand to DIRTY_MIN/DIRTY_MAX
temp.set(DIRTY_MIN, DIRTY_MIN, DIRTY_MAX, DIRTY_MAX);
}
out->join(RECT_ARGS(temp));
}
那么現(xiàn)在TextView相關(guān)的棧圖如下所示
此時(shí) mHead指向LinearLayout_2, dirtyFrame指向淺黃色的DirtyStack.
即 frame->pendingDirty 區(qū)域是(0, 0, 1200, 120), mHead->pendingDirty (0, 0, 1200, 1776),
代碼中 isPerspective() 這個(gè)意思是判斷矩陣是否是投影矩陣。在一般的矩陣都不是投影矩陣，所以一般會(huì)進(jìn)入 if分支 matrix->mapRect(temp), 最后再和out( mHead->pendingDirty)求并集， 最后的out(mHead->pendingDirty)的pendingDirty依然還是 (0, 0, 1200, 1776)
四、小結(jié)
經(jīng)過(guò)1, 2小節(jié)后，整個(gè)DisplayList tree都同步更新了，并且經(jīng)過(guò)3 算出來(lái)整張畫(huà)布的臟區(qū)域, 因?yàn)槭堑谝淮瓮剑赃@里算出來(lái)的臟區(qū)域?yàn)槟J(rèn)的最大畫(huà)布(DIRTY_MIN, DIRTY_MIN, DIRTY_MAX, DIRTY_MAX), 且它的值保存在DamageAccumulator.mHead->pendingDirty中.
可以看出， syncFrameState就完成兩件事，一件是從UI線程同步 RenderProperties和DisplayList 到RenderThread線程，第二件事就是計(jì)算出畫(huà)面的臟區(qū)域。
