Android知识笔记：记录 2 个 “容易误解” 的Android 知识点

原创

Android技术干货分享

修改于 2020-03-23 18:17:45

9310

修改于 2020-03-23 18:17:45

文章被收录于专栏：Android技术分享

今天分享两个之前我们可能都搞错的Android知识点，我们还是要追求极致，把不懂的问题搞懂的~

1. 事件到底是先到DecorView还是先到Window的？

有天早上看到事件分发的一个讨论：

那么事件到底是先到DecorView还是先到Window(Activity，Dialog)的呢，引发出两个问题：

1. touch相关事件在DecorView，PhoneWindow，Activity/Dialog之间传递的顺序是什么样子的？

2. 为什么要按照1这么设计？

答：事件先到DecorView

Input系统

当用户触摸屏幕或者按键操作，首次触发的是硬件驱动，驱动收到事件后，将该相应事件写入到输入设备节点，这便产生了最原生态的内核事件。

接着，输入系统取出原生态的事件，经过层层封装后成为KeyEvent或者MotionEvent ；

最后，交付给相应的目标窗口(Window)来消费该输入事件。

1、当屏幕被触摸，Linux内核会将硬件产生的触摸事件包装为Event存到/dev/input/event[x]目录下。

2、Input系统—InputReader线程：loop起来让EventHub调用getEvent()不断的从/dev/input/文件夹下读取输入事件。然后转换成EventEntry事件加入到InputDispatcher的mInboundQueue。

3、Input系统—InputDispatcher线程：从mInboundQueue队列取出事件，转换成DispatchEntry事件加入到connection的outboundQueue队列。再然后开始处理分发事件（比如分发到ViewRootImpl的WindowInputEventReceiver中），取出outbound队列，放入waitQueue.

4、Input系统—UI线程：创建socket pair，分别位于”InputDispatcher”线程和focused窗口所在进程的UI主线程，可相互通信。

这里只说大概，详情请看gityuan的这篇文章Input系统—事件处理全过程，文章3.3.3小节讲的是input系统事件从Native层分发Framework层的InputEventReceiver.dispachInputEvent()。

http://gityuan.com/2016/12/31/input-ipc/

Framework层

//InputEventReceiver.dispachInputEvent()
private void dispatchInputEvent(int seq, InputEvent event) {
    mSeqMap.put(event.getSequenceNumber(), seq);
    onInputEvent(event); 
}

ViewRootImpl.WindowInputEventReceiver

Native层通过JNI执行Framework层的InputEventReceiver.dispachInputEvent()，而真正调用的是继承了InputEventReceiver的ViewRootImpl.WindowInputEventReceiver。

所以这里执行的WindowInputEventReceiver的dispachInputEvent()：

final class WindowInputEventReceiver extends InputEventReceiver {
    public void onInputEvent(InputEvent event) {
       enqueueInputEvent(event, this, 0, true);
    }
    ...
}

ViewRootImpl

 void enqueueInputEvent(InputEvent event,
            InputEventReceiver receiver, int flags, boolean processImmediately) {
        ...
        if (processImmediately) {
            //关键点：执行Input事件
            doProcessInputEvents();
        } else {
            //走一遍Handler延迟处理事件
            scheduleProcessInputEvents();
        }
    }

    void doProcessInputEvents() {
        while (mPendingInputEventHead != null) {
            QueuedInputEvent q = mPendingInputEventHead;
            mPendingInputEventHead = q.mNext;
            if (mPendingInputEventHead == null) {
                mPendingInputEventTail = null;
            }
            q.mNext = null;

            mPendingInputEventCount -= 1;
            Trace.traceCounter(Trace.TRACE_TAG_INPUT, mPendingInputEventQueueLengthCounterName,
                    mPendingInputEventCount);

            long eventTime = q.mEvent.getEventTimeNano();
            long oldestEventTime = eventTime;
            if (q.mEvent instanceof MotionEvent) {
                MotionEvent me = (MotionEvent)q.mEvent;
                if (me.getHistorySize() > 0) {
                    oldestEventTime = me.getHistoricalEventTimeNano(0);
                }
            }
            mChoreographer.mFrameInfo.updateInputEventTime(eventTime, oldestEventTime);
            //关键点：进一步派发事件处理
            deliverInputEvent(q);
        }
        ...
    }

    private void deliverInputEvent(QueuedInputEvent q) {
        Trace.asyncTraceBegin(Trace.TRACE_TAG_VIEW, "deliverInputEvent",
                q.mEvent.getSequenceNumber());
        if (mInputEventConsistencyVerifier != null) {
            mInputEventConsistencyVerifier.onInputEvent(q.mEvent, 0);
        }

        InputStage stage;
        if (q.shouldSendToSynthesizer()) {
            stage = mSyntheticInputStage;
        } else {
            stage = q.shouldSkipIme() ? mFirstPostImeInputStage : mFirstInputStage;
        }

        if (stage != null) {
            //关键点:上面决定将事件派发到那个InputStage中处理
            stage.deliver(q);
        } else {
            finishInputEvent(q);
        }
    }

ViewRootImpl.ViewPostImeInputStage

前面事件会派发到ViewRootImpl.ViewPostImeInputStage中处理，它的父类InputStage.deliver()方法会调用apply()来处理Touch事件：

@Override
protected int onProcess(QueuedInputEvent q) {
    if (q.mEvent instanceof KeyEvent) {
        return processKeyEvent(q);
    } else {
        final int source = q.mEvent.getSource();
        if ((source & InputDevice.SOURCE_CLASS_POINTER) != 0) {
            //关键点：执行分发touch事件
            return processPointerEvent(q);
        } else if ((source & InputDevice.SOURCE_CLASS_TRACKBALL) != 0) {
            return processTrackballEvent(q);
        } else {
            return processGenericMotionEvent(q);
        }
    }
}

private int processPointerEvent(QueuedInputEvent q) {
    final MotionEvent event = (MotionEvent)q.mEvent;
    ...
    //关键点：mView分发Touch事件，mView就是DecorView
    boolean handled = mView.dispatchPointerEvent(event);
    maybeUpdatePointerIcon(event);
    maybeUpdateTooltip(event);
    ...
}

DecorView

如果你熟悉安卓的Window，Activity和Dialog对应的ViewRootImpl成员mView就是DecorView，View的dispatchPointerEvent()代码如下：

//View.java
public final boolean dispatchPointerEvent(MotionEvent event) {
    if (event.isTouchEvent()) {
        //分发Touch事件
        return dispatchTouchEvent(event);
    } else {
        return dispatchGenericMotionEvent(event);
    }
}

因为DecorView继承FrameLayout，上面所以会调用DecorView的dispatchTouchEvent()：

@Override
public boolean dispatchTouchEvent(MotionEvent ev) {
    final Window.Callback cb = mWindow.getCallback();
    return cb != null && !mWindow.isDestroyed() && mFeatureId < 0
            ? cb.dispatchTouchEvent(ev) : super.dispatchTouchEvent(ev);
}

上面Window.Callback都被Activity和Dialog实现，所以变量cb可能就是Activity和Dialog。

Activity

当上面cb是Activity时，执行Activity的dispatchTouchEvent():

public boolean dispatchTouchEvent(MotionEvent ev) {
    if (ev.getAction() == MotionEvent.ACTION_DOWN) {
        onUserInteraction();
    }
    if (getWindow().superDispatchTouchEvent(ev)) {//关键点：getWindow().superDispatchTouchEvent(ev)
        return true;
    }
    return onTouchEvent(ev);
}

如果你熟悉安卓的Window，Activity的getWindow()拿到的就是PhoneWindow，下面是PhoneWindow的代码：

//PhoneWindow.java
@Override
public boolean superDispatchTouchEvent(MotionEvent event) {
    //调用DecorView的superDispatchTouchEvent
    return mDecor.superDispatchTouchEvent(event);
}

下面是DecorView.superDispatchTouchEvent()代码:

//DecorView.java
public boolean superDispatchTouchEvent(MotionEvent event) {
    //调用ViewGroup的dispatchTouchEvent()开始我们常见的分发Touch事件
    return super.dispatchTouchEvent(event);
}

流程图

答：为什么要DecorView -> Activity -> PhoneWindow -> DecorView传递事件？

解耦！

ViewRootImpl并不知道有Activity这种东西存在！它只是持有了DecorView。

所以，不能直接把触摸事件送到Activity.dispatchTouchEvent()；

那么，既然触摸事件已经到了Activity.dispatchTouchEvent()中了，为什么不直接分发给DecorView，而是要通过PhoneWindow来间接发送呢？

因为Activity不知道有DecorView！但是，Activity持有PhoneWindow ，而PhoneWindow当然知道自己的窗口里有些什么了，所以能够把事件派发给DecorView。

在Android中，Activity并不知道自己的Window中有些什么，这样耦合性就很低了。

我们换一个Window试试？

不管Window里面的内容如何，只要Window仍然符合Activity制定的标准，那么它就能在Activity中很好的工作。当然，这就是解耦所带来的扩展性的好处。

以上回答感谢：蔡徐坤打篮球。

2. RecyclerView卡片中持有的资源，到底该什么时候释放？

之前我们讨论过 View的onAttachedToWindow ,onDetachedFromWindow 调用时机。

这个机制在RecyclerView卡片中还适用吗？

例如我们在RecyclerView的Item的onBindViewHolder时，利用一个CountDownTimer去做一个倒计时显示 / 或者是有一个属性动画效果？

到底在什么时候可以cancel掉这个倒计时/ 动画，而不影响功能了（滑动到用户可见范围内，倒计时/动画运作正常）?

有什么方法可以和onBindViewHolder 对应吗？就像onAttachedToWindow ,onDetachedFromWindow这样。

答：

onAttachedToWindow和onDetachedFromWindow在RecyclerView中还适用吗？

在RecyclerView中，Item的这两个方法分别会在【首次出现】和【完全滑出屏幕】（即在屏幕中完全不可见）时回调（在Adapter中也可以重写同名方法，用来监听ViewHolder的出现和消失）。

至于说适不适用，还是看具体需求，比如列表中的视频播放，在onDetachedFromWindow回调时暂停/停止还是合理的。

但是像题目说的倒计时和属性动画效果，就不合适了，为什么呢？

我们先粗略地温习一下RecyclerView的回收机制：

RecyclerView在布局（自然滑动其实也是反复布局子View）时，会回收一些符合条件的ViewHolder，它会根据ViewHolder的状态来决定临时存放在哪个地方，且把这些临时存放ViewHolder的集合看作两种：

不需要经过onBindViewHolder能直接重用的（mAttachedScrap、mCachedViews）;

需要经过onBindViewHolder重新绑定数据的（mRecyclerPool.mScrap）；

mAttachedScrap，正常情况下，它会在RecyclerView每次布局时都用到：在布局子View时，会把全部子View所属的Holder，都临时放里面，计算好了每个子View的新位置后，会一个个从mAttachedScrap中取出来，当然了不一定是全部都会取出来的，因为可能本次布局，一些旧Item已经完全滑出屏幕了。

那么，这些留在mAttachedScrap中没有被取出来的ViewHolder会怎么样呢？

正常情况下，它们会被扔到mCachedViews里面去（注意从mCachedViews中取出来时也是不用重新绑定数据的，即不会经过onBindViewHolder方法）。

刚刚说过，当Item被完全滑出屏幕时，Adapter的onDetachedFromWindow和该Item的onDetachedFromWindow会被回调，也就是说，当onDetachedFromWindow被回调时，ViewHolder并没有真正被回收！如果这时候把倒计时/动画取消掉了，那么在它们再次出现在屏幕中的时候，就不会动了，因为是直接重用，不会重新绑定数据的。

那应该在什么时候取消？

Adapter中有个onViewRecycled方法，看名字就知道是当Item被回收后回调的。。。

没错了，这个方法回调时，表示这个Holder已经被扔进mRecyclerPool.mScrap里了，也就是再次取出的时候会经过onBindViewHolder方法重新绑定数据。

倒计时/动画在这里取消的话，是完全没问题的（但记得保存当前进度，以便下次恢复）。

所以与onBindViewHolder对应的方法，就是这个onViewRecycled了。

最后，以上的阐述没办法保证一定是非常严谨的，所以请抱着学习以及批判的态度学习，有问题就指出，争取把一个个技术点尽可能搞清楚，大家一起进步。

【Android进阶学习视频】、【全套Android面试秘籍】关注我【主页简介】查看免费领取方式！