在onBindViewHolder设置View的translation失败或错乱的问题

这个问题，可以换成“为什么在onCreate里面修改一些子View不生效，错位，乱”等问题。
本质原因肯定是在没有把整个ViewGroup渲染完成之前，操作了部分子View，导致了位置偏移等。

解决办法也很简单，通过调用View.post(), 注意是View的post。
这样就延迟了我们执行的动作，到了渲染完成之后，才进行操作，避免的错乱的产生。

流程分析

渲染完成，换成代码上是什么意思？
就是三大流程走完成。
在没完成之前，调用任何的translation等操作，就可能导致测量显示错误，错位。

Activity：

1. handleResumeActivity（该方法内使用Context.getWindowManager创建WindowManager对象）
   WindowManager：
2. addView（该方法内WindowManager委托代理给一个WindowManagerGLobal对象）
   WindowManagerGLobal：
3. addView（该方法内创建了ViewRootImpl对象）
   ViewRootImpl：setView→requestLayout→scheduleTraversals→doTraversal→performTraversals（最终到达绘制的入口）
   3.1 performTraversals里面会往所有子View dispatchAttachedToWindow, 并设定mAttachInfo，即有了handler。
   其中从WindowManager.addView开始就是Activity创建Window的过程，最终在ViewRootImpl对象的performTraversals中完成View的绘制（一个Window对象对应了一个ViewViewRootImpl对象也对应了一个View对象，即DecorView）
   performTraversals()是绘制的入口，
   它依次调用
4. performMeasure()、performLayout()和 performDraw()三个方法，
   三个方法内部分别调用了DecorView的measure()、layout()和draw方法。
5. 最后，传导到我们每一个View的mesaure()，onMeasure()（可能多次调用）, layout()，onLayout(), draw() onDraw()函数。

为什么post就能确保是渲染之后呢？

1. Handler的由来

在dispatchAttachedToWindow(无法继承)被回调之前，拿不到handler，就往RunQueue里存储。

    public boolean post(Runnable action) {
        final AttachInfo attachInfo = mAttachInfo;
        if (attachInfo != null) {
            return attachInfo.mHandler.post(action);
        }

        // Postpone the runnable until we know on which thread it needs to run.
        // Assume that the runnable will be successfully placed after attach.
        getRunQueue().post(action);
        return true;
    }

直到：

    void dispatchAttachedToWindow(AttachInfo info, int visibility) {
        mAttachInfo = info;
        ...
        // Transfer all pending runnables.
        if (mRunQueue != null) {
            mRunQueue.executeActions(info.mHandler);
            mRunQueue = null;
        }

才把我们的消息post出去，执行。

2. post的消息，又是如何保证在三大流程之后执行呢？

阅读系统源码：

scheduleTraversals {
	postRunnable { //发送消息执行的
		doTraversal{
			performTraversals { 2510 ~ 3333行
					2613 dispatchAttachedToWindow
					2677 2717 3706 measureHierarchy | 3082 3108 performMeasure
					3140 performLayout
					3306 performDraw
			}
		}
	}
}

另外，也有其他情况，会导致多次执行scheduleTraversals：

        if (!cancelDraw) {
             xxx
            performDraw();
        } else {
            if (isViewVisible) {
                // Try again
                scheduleTraversals();
            } else {
                xxxx

即变成了

scheduleTraversals {
	postRunnable { //发送消息执行的
		performTraversals { 2510 ~ 3333行
			2613 dispatchAttachedToWindow   
					追加：post我们的任务
				2677 2717 3706 measureHierarchy | 3082 3108 performMeasure
				3140 performLayout
				3306 performDraw
					追加：scheduleTraversals  先发送屏障；又通过mChoreographer.postCallback 发送一个异步消息。
		}			

这里看出，三大流程，其实是跑在一个函数里面！

1. 我们知道，函数又是跑在handler里面，所以一般情况，我们的post的任务，在handler MessageQueue需要等待下一个next取出消息再执行，自然而然在三个流程之后。
2. 即使有额外逻辑导致了触发二次scheduleTraversals ，

    void scheduleTraversals() {
        if (!mTraversalScheduled) {
            mTraversalScheduled = true;
            mTraversalBarrier = mHandler.getLooper().getQueue().postSyncBarrier();
            mChoreographer.postCallback(
                    Choreographer.CALLBACK_TRAVERSAL, mTraversalRunnable, null);
                    	内部是post(异步消息) setAsynchronous(true);
            notifyRendererOfFramePending();
            pokeDrawLockIfNeeded();
        }
    }

它会通过消息屏障和异步消息，framework通过handler这个机制，当下次next取出msg的时候，保证取出渲染的消息优先完成。