一、背景
在做项目时，我们有一个相机界面，这个界面包括相机和一些浮层，其中有一个浮层是一个自定义的 View，负责在手机横竖屏变化时展示一个提示，本来很简单的一个界面，但是这个界面在使用一段时间后会偶现一种“假死状态”，假死出现时，相机预览可以正常绘制，但是界面所有的点击事件、回调事件全部消失，而且界面在过了 ANR 的时间后也不会出现崩溃，十分诡异，下面我就说下我们是怎么解决问题和分析问题的。
二、解决问题
我们首先排除了主线程被阻塞的可能性，因为虽然页面的 onBackClicked、onClick、EventBus 等回调完全无效，但是其 onTouch 事件是可以正常回调的，问题好像变的无解了。
对于这种看似无解的问题，我们只能通过重复其复现步骤，观察规律，来寻求突破了。我们发现，当上文提到的我们的自定义 View 刷新频率很快的时候，页面很容易进入假死状态，于是我们开始 review 这块的代码，然后看到了这个代码块：
@Subscribe
override fun onScreenOrientationChanged(event: ScreenOrientationEvent) {
if (mOrientation != event.getOrientationType()) {
mOrientation = event.getOrientationType()
invalidate()
}
}
这个界面通过 EventBus 监听屏幕方向变化，然后重新绘制自身，展示特殊的提示，但是这个事件的产生者是在一个异步线程分发的事件，所以这个 invalidate() 函数也是在异步线程回调的，但是诡异的是这里并没有抛出我们熟悉的“Only the original thread that created a view hierarchy can touch its views.” 异常信息，而是平静正常的运转下去了，什么时候非 UI 线程也可以刷新界面了？当然先解决问题，看看是不是这里的影响，我们修改代码如下：
@Subscribe(threadMode = ThreadMode.MAIN)
override fun onScreenOrientationChanged(event: ScreenOrientationEvent) {
if (mOrientation != event.getOrientationType()) {
mOrientation = event.getOrientationType()
invalidate()
}
}
果然页面再也没有出现假死了，当然我们也很好理解为什么页面会进入假死，因为 View 并没有做同步处理，所以里面的一些标志位在多线程竞争的时候就很容易出现错乱，导致 View 的状态出现异常，从而可能会出现各种各样的页面假死，但是为什么我们可以在非 UI 线程刷新界面而且不抛出异常呢？这完全和我们的认知相违背啊，下面我们就来剖析一下问题。
三、剖析问题
要了解为什么会出现问题的最好的办法当然就是 Read The Fucking Source Code 咯，首先我们看 invalidate 函数：
/**
* Mark the area defined by dirty as needing to be drawn. If the view is
* visible, {@link #onDraw(android.graphics.Canvas)} will be called at some
* point in the future.
* <p>
* This must be called from a UI thread. To call from a non-UI thread, call
* {@link #postInvalidate()}.
* <p>
* <b>WARNING:</b> In API 19 and below, this method may be destructive to
* {@code dirty}.
*
* @param dirty the rectangle representing the bounds of the dirty region
*/
public void invalidate(Rect dirty) {
final int scrollX = mScrollX;
final int scrollY = mScrollY;
invalidateInternal(dirty.left - scrollX, dirty.top - scrollY,
dirty.right - scrollX, dirty.bottom - scrollY, true, false);
}
我们可以看到函数注释中明确写明了我们必须在 UI 线程调用这个函数，我们再往下跟：
void invalidateInternal(int l, int t, int r, int b, boolean invalidateCache,
boolean fullInvalidate) {
//...
// Propagate the damage rectangle to the parent view.
final AttachInfo ai = mAttachInfo;
final ViewParent p = mParent;
if (p != null && ai != null && l < r && t < b) {
final Rect damage = ai.mTmpInvalRect;
damage.set(l, t, r, b);
p.invalidateChild(this, damage);
}
//...
}
这个函数会构建一个脏区域，然后通过父 View 去刷新自己，我们继续跟 invalidateChild() 这个函数，它的实现在 ViewGroup 中：
public final void invalidateChild(View child, final Rect dirty) {
//...
do {
View view = null;
if (parent instanceof View) {
view = (View) parent;
}
if (drawAnimation) {
if (view != null) {
view.mPrivateFlags |= PFLAG_DRAW_ANIMATION;
} else if (parent instanceof ViewRootImpl) {
((ViewRootImpl) parent).mIsAnimating = true;
}
}
// If the parent is dirty opaque or not dirty, mark it dirty with the opaque
// flag coming from the child that initiated the invalidate
if (view != null) {
if ((view.mViewFlags & FADING_EDGE_MASK) != 0 &&
view.getSolidColor() == 0) {
opaqueFlag = PFLAG_DIRTY;
}
if ((view.mPrivateFlags & PFLAG_DIRTY_MASK) != PFLAG_DIRTY) {
view.mPrivateFlags = (view.mPrivateFlags & ~PFLAG_DIRTY_MASK) | opaqueFlag;
}
}
parent = parent.invalidateChildInParent(location, dirty);
if (view != null) {
// Account for transform on current parent
Matrix m = view.getMatrix();
if (!m.isIdentity()) {
RectF boundingRect = attachInfo.mTmpTransformRect;
boundingRect.set(dirty);
m.mapRect(boundingRect);
dirty.set((int) Math.floor(boundingRect.left),
(int) Math.floor(boundingRect.top),
(int) Math.ceil(boundingRect.right),
(int) Math.ceil(boundingRect.bottom));
}
}
} while (parent != null);
//...
}
这里我们发现，函数在 while 循环里逐渐向上寻找最终的父节点，然后每一个父节点都会调用 invalidateChildInParent() 进行刷新，这里也比较好理解，因为父 View 的宽高可能会依赖与子 View 的宽高来计算，所以这里需要倒着逐层去算。然后我们知道界面的最终的父节点是 ViewRootImpl，当然它不是一个 View，只是一个中间层，我们直接走到 ViewRootImpl.invalidateChildInParent() 中去，我们发现：
@Override
public ViewParent invalidateChildInParent(int[] location, Rect dirty) {
checkThread();
//...
}
void checkThread() {
if (mThread != Thread.currentThread()) {
throw new CalledFromWrongThreadException(
"Only the original thread that created a view hierarchy can touch its views.");
}
}
在这里我们发现了我们熟悉的异常，也就是说我们不能在非 UI 线程更新界面的线程检查是在这里做的（默认 ViewRootImpl 在主线程创建），但是走到这里我们依然没有发现为什么我们可以在非 UI 线程刷新界面，因为线程检查就在函数开始，不可能逃脱掉，那我们在向上走一走，我们看上方倒数第二个代码块，如果在 invalidateChild() 中的循环里，invalidateChildInParent() 返回了空，那循环就会被中断，这样才不会走到 ViewRootImpl 中去，从而逃脱掉线程检查，也就是说，在逐层查找父节点时，有一个 ViewGroup 的 invalidateChildInParent() 返回了空，那我们看看 ViewGroup.invalidateChildInParent() 这个函数什么时候会返回空：
/**
* Don't call or override this method. It is used for the implementation of
* the view hierarchy.
*
* This implementation returns null if this ViewGroup does not have a parent,
* if this ViewGroup is already fully invalidated or if the dirty rectangle
* does not intersect with this ViewGroup's bounds.
*
* @deprecated Use {@link #onDescendantInvalidated(View, View)} instead to observe updates to
* draw state in descendants.
*/
@Deprecated
@Override
public ViewParent invalidateChildInParent(final int[] location, final Rect dirty) {
//...
}
这里我们直接看函数注释：
如果此ViewGroup没有父类，如果此ViewGroup已经完全无效，或者如果脏矩形没有与此ViewGroup的边界相交，则此实现返回空。
看到这里我们其实也大概就可以理解作者的设计思路了，在 View 刷新时，为了保证效率，我们只需要刷新那些受这个 View 变化影响的 View 就可以了，所以当我们判断到脏区域不会再对外层 View 产生影像时我们就没必要再去传递和刷新了，也就是说，我们自定义 View 刷新时因为没有一些特殊的变化（如宽、高），仅仅是自身绘制发生了变化，所以 invalidate 并不会传递到 ViewRootImpl 中去，也就没有线程检查这一说，所以在非 UI 线程中调用也不会抛出异常，虽然这是非法的。
四、总结
如果没有遇到这个问题可能我永远都不会知道 invalidate 的这个秘密，也希望这个问题的解决方案能帮大家解决自己项目中出现的一些诡异问题。
网友评论