Android應用程序UI硬件加速渲染的動畫執行過程分析

在分析AnimatorManager類的成員函數addAnimator的實現之前，我們首先了解AnimatorManager類的三個成員變量：

1. mParent，它描述的是一個RenderNode對象，該RenderNode對象與當前正在處理的AnimatorManager對象關聯。

2. mNewAnimators，它描述的是一個Vector，該Vector用來保存新增加的動畫。

3. mAnimators，它描述的也是一個Vector。在繪制應用程序窗口的下一幀之前，新增加的動畫會從成員變量mNewAnimators描述的Vector轉移到成員變量mAnimators描述的Vector中去等待處理。

AnimatorManager類的成員函數addAnimator首先是增加參數animator描述的一個BaseRenderNodeAnimator對象的引用計數，因為後面要將它添加成員變量mNewAnimators描述的一個Vector中去。此外，AnimatorManager類的成員函數addAnimator還會調用參數animator描述的一個BaseRenderNodeAnimator對象的成員函數attach將該BaseRenderNodeAnimator對象與要顯示動畫的Render Node進行關聯。

這一步執行完成之後，我們就將要顯示的動畫設置到目標View關聯的一個RenderNode對象內部的一個AnimatorManager對象中去了。返回到Java層的RenderNode類的成員函數addAniamtor中，接下來我們繼續分析ViewRootImpl類的成員函數registerAnimatingRenderNode的實現，以便可以了解Render Thread知道有Render Node有新的動畫需要顯示的過程。

ViewRootImpl類的成員函數registerAnimatingRenderNode的實現如下所示：

public final class ViewRootImpl implements ViewParent,
        View.AttachInfo.Callbacks, HardwareRenderer.HardwareDrawCallbacks {
    ......

    public void registerAnimatingRenderNode(RenderNode animator) {
        if (mAttachInfo.mHardwareRenderer != null) {
            mAttachInfo.mHardwareRenderer.registerAnimatingRenderNode(animator);
        } else {
            if (mAttachInfo.mPendingAnimatingRenderNodes == null) {
                mAttachInfo.mPendingAnimatingRenderNodes = new ArrayList();
            }
            mAttachInfo.mPendingAnimatingRenderNodes.add(animator);
        }
    }

    ......
}

當ViewRootImpl類的成員變量mAttachInfo指向的一個AttachInfo對象的成員變量mHardwareRenderer的值不等於null的時候，它指向的是一個ThreadedRenderer對象。在這種情況下，ViewRootImpl類的成員函數registerAnimatingRenderNode會直接調用該ThreadedRenderer對象的成員函數registerAnimatingRenderNode將參數animator描述的一個Render Node注冊到Render Thread中去，以便Render Thread知道哪些Rendr Node有新的動畫需要顯示。

另一方面，當ViewRootImpl類的成員變量mAttachInfo指向的一個AttachInfo對象的成員變量mHardwareRenderer的值等於null的時候，這意味著應用程序窗口使用軟件渲染或者使用硬件加速渲染但是硬件加速渲染環境還沒有初始化好。在這兩種情況下，都是先將參數animator描述的Render Node保存在成員變量mAttachInfo指向的一個AttachInfo對象的成員變量mPendingAnimatingRenderNodes描述的一個列表中等待處理。

從前面Android應用程序UI硬件加速渲染的Display List構建過程分析一文可以知道，當使用硬件加速渲染時，應用程序窗口的渲染是從調用ThreadedRenderer類的成員函數draw開始的，它的實現如下所示：

public class ThreadedRenderer extends HardwareRenderer {  
    ......  
  
    @Override  
    void draw(View view, AttachInfo attachInfo, HardwareDrawCallbacks callbacks) {  
        ......  
  
        updateRootDisplayList(view, callbacks);  
        ......  
  
        if (attachInfo.mPendingAnimatingRenderNodes != null) {  
            final int count = attachInfo.mPendingAnimatingRenderNodes.size();  
            for (int i = 0; i < count; i++) {  
                registerAnimatingRenderNode(  
                        attachInfo.mPendingAnimatingRenderNodes.get(i));  
            }  
            attachInfo.mPendingAnimatingRenderNodes.clear();  
            // We don't need this anymore as subsequent calls to  
            // ViewRootImpl#attachRenderNodeAnimator will go directly to us.  
            attachInfo.mPendingAnimatingRenderNodes = null;  
        }  
  
        int syncResult = nSyncAndDrawFrame(mNativeProxy, frameTimeNanos,  
                recordDuration, view.getResources().getDisplayMetrics().density);  
        if ((syncResult & SYNC_INVALIDATE_REQUIRED) != 0) {  
            attachInfo.mViewRootImpl.invalidate();  
        }  
    }  
  
    ......  
}

ThreadedRenderer類的成員函數draw在調用成員函數updateRootDisplayList構建應用程序窗口的Display List之後，並且調用成員函數nSyncAndDrawFrame渲染應用程序窗口的Display List之前，會調用成員函數registerAnimatingRenderNode處理保存在上面提到的AttachInfo對象的成員變量mPendingAnimatingRenderNodes描述的一個列表中的每一個Render Node。

ThreadedRenderer類的成員函數registerAnimatingRenderNode的實現如下所示：

public class ThreadedRenderer extends HardwareRenderer {  
    ......  
  
    @Override
    void registerAnimatingRenderNode(RenderNode animator) {
        nRegisterAnimatingRenderNode(mRootNode.mNativeRenderNode, animator.mNativeRenderNode);
    }
  
    ......  
}  

ThreadedRenderer類的成員函數registerAnimatingRenderNode調用另外一個成員函數nRegisterAnimatingRenderNode將參數animator描述的一個Render Node注冊到Render Thread中去。

ThreadedRenderer類的成員函數nRegisterAnimatingRenderNode是一個JNI函數，由Native層的函數android_view_ThreadedRenderer_registerAnimatingRenderNode實現，如下所示：

static void android_view_ThreadedRenderer_registerAnimatingRenderNode(JNIEnv* env, jobject clazz,
        jlong rootNodePtr, jlong animatingNodePtr) {
    RootRenderNode* rootRenderNode = reinterpret_cast(rootNodePtr);
    RenderNode* animatingNode = reinterpret_cast(animatingNodePtr);
    rootRenderNode->attachAnimatingNode(animatingNode);
}

參數rootNodePtr指向的是一個RootRenderNode對象，該RootRenderNode對象描述的是應用程序窗口的Root Render Node，這裡主要就是將參數animatorNodePtr描述的一個Render Node注冊在上述的RootRenderNode對象的內部，這是通過調用RootRenderNode類的成員函數attachAnimatingNode實現的。

RootRenderNode類的成員函數attachAnimatingNode的實現如下所示：

class RootRenderNode : public RenderNode, ErrorHandler {
public:
    ......

    void attachAnimatingNode(RenderNode* animatingNode) {
        mPendingAnimatingRenderNodes.push_back(animatingNode);
    }

    ......
private:
    ......
    std::vector< sp > mPendingAnimatingRenderNodes;
};

RootRenderNode類的成員函數attachAnimatingNode將參數animatingNode描述的一個Render Node保存成員變量mPendingAnimatingRenderNodes描述的一個Vector中。保在這個Vector中的Render Node將會在應用程序窗口的下一幀被渲染時得到處理。

從前面Android應用程序UI硬件加速渲染的Display List渲染過程分析一文可以知道，Render Thread在渲染應用程序窗口的下一幀時，會調用CanvasContext類的成員函數prepareTree將應用程序窗口的Display List從Main Thread同步到Render Thread，如下所示：

void CanvasContext::prepareTree(TreeInfo& info) {
    ......

    info.renderer = mCanvas;
    ......

    mAnimationContext->startFrame(info.mode);
    mRootRenderNode->prepareTree(info);
    mAnimationContext->runRemainingAnimations(info);

    ......

    int runningBehind = 0;
    // TODO: This query is moderately expensive, investigate adding some sort
    // of fast-path based off when we last called eglSwapBuffers() as well as
    // last vsync time. Or something.
    mNativeWindow->query(mNativeWindow.get(),
            NATIVE_WINDOW_CONSUMER_RUNNING_BEHIND, &runningBehind);
    info.out.canDrawThisFrame = !runningBehind;

    if (info.out.hasAnimations || !info.out.canDrawThisFrame) {
        if (!info.out.requiresUiRedraw) {
            // If animationsNeedsRedraw is set don't bother posting for an RT anim
            // as we will just end up fighting the UI thread.
            mRenderThread.postFrameCallback(this);
        }
    }
}

CanvasContext類的成員函數prepareTree的詳細實現分析可以參考前面Android應用程序UI硬件加速渲染的Display List渲染過程分析一文，這裡我們主要關注與動畫相關的兩個操作：

1. 第一個操作是在調用RenderNode類的成員函數prepareTree同步應用程序窗口的Display List之前，調用成員變量mAnimationContext描述的一個AnimationContext對象的成員函數startFrame執行一些動畫顯示的准備工作。

2. 第二個操作是在調用RenderNode類的成員函數prepareTree同步應用程序窗口的Display List之後，調用成員變量mAnimationContext描述的一個AnimationContext對象的成員函數runRemainingAnimations更新剩下的還未完成的動畫。

接下來我們就分別分析這兩個操作的執行過程，即分析AnimationContext類的成員函數startFrame和runRemainingAnimations的實現。不過，在分析這兩個函數的實現之前，我們首先要了解CanvasContext類的成員變量mAnimationContext的初始化過程。

從前面Android應用程序UI硬件加速渲染環境初始化過程分析一文可以知道，在Android應用程序的硬件加速渲染環境的初始化過程中，會創建一個RenderProxy對象，如下所示：

static jlong android_view_ThreadedRenderer_createProxy(JNIEnv* env, jobject clazz,
        jboolean translucent, jlong rootRenderNodePtr) {
    RootRenderNode* rootRenderNode = reinterpret_cast(rootRenderNodePtr);
    ContextFactoryImpl factory(rootRenderNode);
    return (jlong) new RenderProxy(translucent, rootRenderNode, &factory);
}

在調用RenderProxy類的構造函數創建一個RenderProxy對象的時候，傳遞進去的第三個參數是一個ContextFactoryImpl對象。

我們繼續看RenderProxy類的構造函數的實現，如下所示：

CREATE_BRIDGE4(createContext, RenderThread* thread, bool translucent,
        RenderNode* rootRenderNode, IContextFactory* contextFactory) {
    return new CanvasContext(*args->thread, args->translucent,
            args->rootRenderNode, args->contextFactory);
}

RenderProxy::RenderProxy(bool translucent, RenderNode* rootRenderNode, IContextFactory* contextFactory)
        : mRenderThread(RenderThread::getInstance())
        , mContext(0) {
    SETUP_TASK(createContext);
    args->translucent = translucent;
    args->rootRenderNode = rootRenderNode;
    args->thread = &mRenderThread;
    args->contextFactory = contextFactory;
    mContext = (CanvasContext*) postAndWait(task);
    mDrawFrameTask.setContext(&mRenderThread, mContext);
}

RenderProxy類的構造函數首先是向Render Thread的Task Queue發送一個Task，並且等待該Task執行完成。上述Task在執行的時候，會調用由宏CREATE_BRIDGE4聲明的函數createContext。該函數所做的事情就是創建一個CanvasContext對象。該CanvasContext對象最終保存在RenderProxy類的成員變量mContext中。

在調用CanvasContext類的構造函數創建一個CanvasContext對象的時候，傳遞進去的第四個參數就是在前面分析的函數android_view_ThreadedRenderer_createProxy聲明的一個ContextFactoryImpl對象。

CanvasContext類的構造函數的實現如下所示：

CanvasContext::CanvasContext(RenderThread& thread, bool translucent,
        RenderNode* rootRenderNode, IContextFactory* contextFactory)
        :...... {
    mAnimationContext = contextFactory->createAnimationContext(mRenderThread.timeLord());
    ......
}

從這裡就可以看出，CanvasContext的成員變量mAnimationContext指向的一個AnimationContext對象是由參數contextFactory描述的一個IContextFactory接口的成員函數createAnimationContext創建的。

從前面的調用過程可以知道，參數contextFactory指向的實際上是一個ContextFactoryImpl對象，它的成員函數createAnimationContext的實現如下所示：

class ContextFactoryImpl : public IContextFactory {
public:
    ContextFactoryImpl(RootRenderNode* rootNode) : mRootNode(rootNode) {}

    virtual AnimationContext* createAnimationContext(renderthread::TimeLord& clock) {
        return new AnimationContextBridge(clock, mRootNode);
    }

private:
    RootRenderNode* mRootNode;
};

ContextFactoryImpl類的成員函數createAnimationContext創建的是一個AnimationContextBridge對象，由此就可見，CanvasContext的成員變量mAnimationContext實際指向的一個AnimationContextBridge對象。

明白了這一點之後，回到前面分析的CanvasContext類的成員函數prepareTree中，它在同步應用程序窗口的Display List之前，調用了AnimationContextBridge類的成員函數startFrame執行一些動畫顯示的准備工作。

AnimationContextBridge類的成員函數startFrame的實現如下所示：

class AnimationContextBridge : public AnimationContext {
public:
    ......

    // Marks the start of a frame, which will update the frame time and move all
    // next frame animations into the current frame
    virtual void startFrame(TreeInfo::TraversalMode mode) {
        if (mode == TreeInfo::MODE_FULL) {
            mRootNode->doAttachAnimatingNodes(this);
        }
        AnimationContext::startFrame(mode);
    }

    ......
private:
    sp mRootNode;
    ......
};

參數mode的值等於TreeInfo::MODE_FULL，表示目前Render Thread是處於同步應用程序窗口的Display List的過程中。在這種情況下，AnimationContextBridge類的成員函數startFrame執行兩個操作：

1. 調用成員變量mRootNode描述的一個RootRenderNode對象的成員函數doAttachAnimatingNodes處理它內部保存的有動畫顯示的Render Node。

2. 調用父類AnimationContext的成員函數startFrame繼續執行一些動畫顯示之前的准備工作。

接下來，我們就先分析RootRenderNode類的成員函數doAttachAnimatingNodes的實現，再分析AnimationContext類的成員函數startFrame的實現。

RootRenderNode類的成員函數doAttachAnimatingNodes的實現如下所示：

class RootRenderNode : public RenderNode, ErrorHandler {
public:
    ......

    void doAttachAnimatingNodes(AnimationContext* context) {
        for (size_t i = 0; i < mPendingAnimatingRenderNodes.size(); i++) {
            RenderNode* node = mPendingAnimatingRenderNodes[i].get();
            context->addAnimatingRenderNode(*node);
        }
        mPendingAnimatingRenderNodes.clear();
    }

private:
    ......
    std::vector< sp > mPendingAnimatingRenderNodes;
};

RootRenderNode類的成員函數doAttachAnimatingNodes遍歷保存在成員變量mPendingAnimatingRenderNodes描述的一個Vector中的每一個RenderNode對象，並且分別調用參數context描述的一個AnimationContextBridge對象的成員函數addAnimatingRenderNode對它們進行處理。

AnimationContextBridge類的成員函數addAnimatingRenderNode是從父類AnimationContext繼承下來的，它的實現如下所示：

void AnimationContext::addAnimatingRenderNode(RenderNode& node) {
    if (!node.animators().hasAnimationHandle()) {
        AnimationHandle* handle = new AnimationHandle(node, *this);
        addAnimationHandle(handle);
    }
}

參數node指向的是一個RenderNode對象，調用它的成員函數animators可以獲得它內部的一個AnimatorManager對象。如果該AnimatorManager對象還沒有設置過一個AnimationHandle對象，那麼AnimationContext類的成員函數addAnimatingRenderNode就為其設置一個AnimationHandle對象，並且這個AnimationHandle對象會通過AnimationContext類的成員函數addAnimationHandle保存在當前正在處理的一個AnimationContext對象的內部。

AnimationContext類的成員函數addAnimationHandle的實現如下所示：

void AnimationContext::addAnimationHandle(AnimationHandle* handle) {
    handle->insertAfter(&mNextFrameAnimations);
}

AnimationContext類的成員函數addAnimationHandle所做的事情就是將參數handle描述的一個AnimationHandle對象插入成員變量mNextFrameAnimations描述的一個AnimationHandle列表中。

由此我們就可以推斷出，只要AnimationContext類的成員變量NextFrameAnimations描述的一個AnimationHandle列表不為空，那麼就意味著Render Thread在渲染應用程序窗口的下一幀的時候，有Render Node需要顯示動畫。

這一步執先完成之後，返回到AnimationContextBridge類的成員函數startFrame中，接下來它所做的事情就是調用父類AnimationContext的成員函數startFrame繼續執行一些動畫顯示之前的准備工作。

AnimationContext的成員函數startFrame的實現如下所示：

void AnimationContext::startFrame(TreeInfo::TraversalMode mode) {
    ......
    AnimationHandle* head = mNextFrameAnimations.mNextHandle;
    if (head) {
        mNextFrameAnimations.mNextHandle = NULL;
        mCurrentFrameAnimations.mNextHandle = head;
        head->mPreviousHandle = &mCurrentFrameAnimations;
    }
    ......
}

AnimationContext的成員函數startFrame所做的事情就是將成員變量mNextFrameAnimations描述的一個AnimationHandle列表轉移到另外一個成員變量mCurrentFrameAnimations中。

由此我們就可以推斷出，只要AnimationContext類的成員變量mCurrentFrameAnimations描述的一個AnimationHandle列表不為空，那麼就意味著Render Thread在渲染應用程序窗口的當前幀的時候，有Render Node需要顯示動畫。

這一步執行完成之後，返回到CanvasContext類的成員函數prepareTree中，當它同步同步應用程序窗口的Display List之後，就調用成員變量mAnimationContext描述的一個AnimationContextBridge對象的成員函數runRemainingAnimations更新剩下的還未完成的動畫。

AnimationContextBridge類的成員函數runRemainingAnimations的實現如下所示：

class AnimationContextBridge : public AnimationContext {
public:
    ......

    // Runs any animations still left in mCurrentFrameAnimations
    virtual void runRemainingAnimations(TreeInfo& info) {
        AnimationContext::runRemainingAnimations(info);
        ......
    }

    ......
};

AnimationContextBridge類的成員函數runRemainingAnimations主要是通過調用父類AnimationContext的成員函數runRemainingAnimations更新剩下的還未完成的動畫。

AnimationContext類的成員函數runRemainingAnimations的實現如下所示：

void AnimationContext::runRemainingAnimations(TreeInfo& info) {
    while (mCurrentFrameAnimations.mNextHandle) {
        AnimationHandle* current = mCurrentFrameAnimations.mNextHandle;
        AnimatorManager& animators = current->mRenderNode->animators();
        animators.pushStaging();
        animators.animateNoDamage(info);
        ......
    }
}

前面提到，應用程序窗口當前幀要顯示動畫都記錄在AnimationContext類的成員mCurrentFrameAnimations描述的一個AnimationHandle列表中。因此，AnimationContext類的成員函數runRemainingAnimations就遍歷這個列表中的每一個AnimationHandle，並且獲得與其關聯的一個AnimatorManager。有了這些AnimatorManager之的，就可以調用它們的成員函數pushStaging和animateNoDamage來執行動畫，其實就是計算動畫的下一幀參數，以便應用在目標Render Node上。

AnimatorManager類的成員函數pushStaging的實現如下所示：

void AnimatorManager::pushStaging() {
    if (mNewAnimators.size()) {
        ......
        move_all(mNewAnimators, mAnimators);
    }
    for (vector::iterator it = mAnimators.begin(); it != mAnimators.end(); it++) {
        (*it)->pushStaging(mAnimationHandle->context());
    }
}

void AnimatorManager::animateNoDamage(TreeInfo& info) {
    if (!mAnimators.size()) return;

    animateCommon(info);
}

uint32_t AnimatorManager::animateCommon(TreeInfo& info) {
    AnimateFunctor functor(info, mAnimationHandle->context());
    std::vector< BaseRenderNodeAnimator* >::iterator newEnd;
    newEnd = std::remove_if(mAnimators.begin(), mAnimators.end(), functor);
    mAnimators.erase(newEnd, mAnimators.end());
    mAnimationHandle->notifyAnimationsRan();
    return functor.dirtyMask;
}

class AnimateFunctor {
public:
    AnimateFunctor(TreeInfo& info, AnimationContext& context)
            : dirtyMask(0), mInfo(info), mContext(context) {}

    bool operator() (BaseRenderNodeAnimator* animator) {
        dirtyMask |= animator->dirtyMask();
        bool remove = animator->animate(mContext);
        if (remove) {
            animator->decStrong(0);
        } else {
            if (animator->isRunning()) {
                mInfo.out.hasAnimations = true;
            }
            if (CC_UNLIKELY(!animator->mayRunAsync())) {
                mInfo.out.requiresUiRedraw = true;
            }
        }
        return remove;
    }

    uint32_t dirtyMask;

private:
    TreeInfo& mInfo;
    AnimationContext& mContext;
};

void AnimationHandle::notifyAnimationsRan() {
    removeFromList();
    if (mRenderNode->animators().hasAnimators()) {
        mContext.addAnimationHandle(this);
    } else {
        release();
    }
}

public class RenderNodeAnimator extends Animator {
    ......

    @Override
    public void setAllowRunningAsynchronously(boolean mayRunAsync) {
        checkMutable();
        nSetAllowRunningAsync(mNativePtr.get(), mayRunAsync);
    }

    ......
}

static void setAllowRunningAsync(JNIEnv* env, jobject clazz, jlong animatorPtr, jboolean mayRunAsync) {
    BaseRenderNodeAnimator* animator = reinterpret_cast(animatorPtr);
    animator->setAllowRunningAsync(mayRunAsync);
}

class BaseRenderNodeAnimator : public VirtualLightRefBase {
    ......
public:
    ......

    ANDROID_API void setAllowRunningAsync(bool mayRunAsync) {
        mMayRunAsync = mayRunAsync;
    }
    bool mayRunAsync() { return mMayRunAsync; }

    ......
};

void CanvasContext::prepareTree(TreeInfo& info) {
    ......

    info.renderer = mCanvas;
    ......

    mAnimationContext->startFrame(info.mode);
    mRootRenderNode->prepareTree(info);
    mAnimationContext->runRemainingAnimations(info);

    ......

    if (info.out.hasAnimations || !info.out.canDrawThisFrame) {
        if (!info.out.requiresUiRedraw) {
            // If animationsNeedsRedraw is set don't bother posting for an RT anim
            // as we will just end up fighting the UI thread.
            mRenderThread.postFrameCallback(this);
        }
    }
}

void CanvasContext::doFrame() {
    ......

    TreeInfo info(TreeInfo::MODE_RT_ONLY, mRenderThread.renderState());
    prepareTree(info);
    if (info.out.canDrawThisFrame) {
        draw();
    }
}