关于面试技巧:面试官Handler的runWithScissors了解吗为什么Google不让开发者用

作者：承香墨影
起源：承香墨影

runWithScissors() 是 Handler 的一个办法，被标记为 @hide，不容许一般开发者调用。

这个办法算是比拟冷门，面试中被问及时，若面试者不分明，通常面试官会换个问法：” 如何在子线程，通过 Handler 向主线程发送一个工作，并等主线程解决此工作后，再继续执行？”。

这个场景，就能够借助 runWithScissors() 来实现。

尽管该办法被标记为 @hide，然而在 Framework 中，也有不少场景应用到它。不过它也有一些隐患，正是因为这些隐患，让 Android 工程师将其标为 @hide，不容许一般开发者应用。

明天咱们就来聊聊，Handler 的这个冷门办法 runWithScissors()，以及它可能呈现的一些问题，正好也温故一下多线程通信相干的常识。

先撇开 runWithScissors() 办法，既然这里存在 2 个线程的通信，那必定须要思考多线程同步。

说到同步，首先想到的就是 Synchronized 锁和它的期待 / 告诉机制，而通过 Handler 跨线程通信时，想要发送一个「工作」，Runnable 必定比 Message 更适宜。

接下来，咱们看看 runWithScissors() 的实现是不是如咱们料想一样。

public final boolean runWithScissors(final Runnable r, long timeout) {if (r == null) {throw new IllegalArgumentException("runnable must not be null");
  }
  if (timeout < 0) {throw new IllegalArgumentException("timeout must be non-negative");
  }

  if (Looper.myLooper() == mLooper) {r.run();
    return true;
  }

  BlockingRunnable br = new BlockingRunnable(r);
  return br.postAndWait(this, timeout);
}

能够看到，runWithScissors() 承受一个 Runnable，并且能够设置超时工夫。

流程也非常简单：

先简略的对入参进行校验；
如果以后线程和 Handler 的解决线程统一，则间接运行 run() 办法；
线程不统一，则通过 BlockingRunnable 包装一下，并执行其 postAndWait() 办法；
那再持续看看 BlockingRunnable 的源码。

private static final class BlockingRunnable implements Runnable {
  private final Runnable mTask;
  private boolean mDone;

  public BlockingRunnable(Runnable task) {mTask = task;}

  @Override
  public void run() {
    try {
      // 运行在 Handler 线程
      mTask.run();} finally {synchronized (this) {
        mDone = true;
        notifyAll();}
    }
  }

  public boolean postAndWait(Handler handler, long timeout) {if (!handler.post(this)) {return false;}

    synchronized (this) {if (timeout > 0) {final long expirationTime = SystemClock.uptimeMillis() + timeout;
        while (!mDone) {long delay = expirationTime - SystemClock.uptimeMillis();
          if (delay <= 0) {return false; // timeout}
          try {wait(delay);
          } catch (InterruptedException ex) {}}
      } else {while (!mDone) {
          try {wait();
          } catch (InterruptedException ex) {}}
      }
    }
    return true;
  }
}

待执行的工作，会记入 BlockingRunnable 的 mTask，期待后续被调用执行。

postAndWait() 的逻辑也很简略，先通过 handler 尝试将 BlockingRunnable 收回去，之后进入 Synchronized 临界区，尝试 wait() 阻塞。

如果设置了 timeout，则应用 wait(timeout) 进入阻塞，若被超时唤醒，则间接返回 false，示意工作执行失败。

那么当初能够看到 postAndWait() 返回 false 有 2 个场景：

Handler post() 失败，示意 Looper 出问题了；
期待超时，工作还没有执行完结；
除了超时唤醒外，咱们还须要在工作执行完后，唤醒以后线程。

回看 BlockingRunnable 的 run() 办法，run() 被 Handler 调度并在其线程执行。在其中调用 mTask.run()，mTask 即咱们须要执行的 Runnable 工作。执行完结后，标记 mDone 并通过 notifyAll() 唤醒期待。

工作发动线程，被唤醒后，会判断 mDone，若为 true 则工作执行实现，间接返回 true 退出。

以上就是 runWithScissors() 的残缺执行流程。

runWithScissors() 被标记为 @hide，利用开发个别是用不上的，然而在 Framework 中，却有不少应用场景。

例如比拟相熟的 WMS 启动流程中，别离在 main() 和 initPolicy() 中，通过 runWithScissors() 切换到 “android.display” 和 “android.ui” 线程去做一些初始工作。

private void initPolicy() {UiThread.getHandler().runWithScissors(new Runnable() {public void run() {
      // 运行在 "android.ui" 线程
      WindowManagerPolicyThread.set(Thread.currentThread(), Looper.myLooper());
      mPolicy.init(mContext, WindowManagerService.this, WindowManagerService.this);
    }
  }, 0);
}

例如下面代码，就是从 “android.display” 线程，通过切换到 “android.ui” 线程去执行工作。

看似 runWithScissors() 通过 Synchronized 的期待告诉机制，配合 Handler 发送 Runnable 执行阻塞工作，看似没有问题，但仍然被 Android 工程师设为 @hide，必定有不容许应用的起因。

咱们持续看看它的问题。

通过 runWithScissors() 发送 Runnable 时，能够指定超时工夫。当超时唤醒时，是间接 false 退出。
那么当超时退出时，这个 Runnable 仍然还在指标线程的 MessageQueue 中，并没有被移除掉，它最终还是会被 Handler 线程调度并执行。
此时的执行，显然并不合乎咱们的业务预期。

而更重大的是，应用 runWithScissors() 可能造成调用线程进入阻塞，而得不到唤醒，如果以后持有别的锁，还会造成死锁。

咱们通过 Handler 发送的 MessageQueue 的音讯，个别都会失去执行，而当线程 Looper 通过 quit() 退出时，会清理掉还未执行的工作，此时发送线程，则永远得不到唤醒。

那么在应用 runWithScissors() 时，就要求 Handler 所在的线程 Looper，不容许退出，或者应用 quitSafely() 形式退出。

quit() 和 quitSafely() 都示意退出，会去清理对应的 MessageQueue。区别在于，qiut() 会清理 MessageQueue 中所有的音讯，而 quitSafely() 只会清理掉以后工夫点之后（when > now）的音讯，以后工夫之前的音讯，仍然会失去执行。

那么只有应用 quitSafely() 退出，通过 runWithScissors() 发送的工作，仍然会被执行。

也就是说，平安应用 runWithScissors() 要满足 2 个条件（二选一）：

Handler 的 Looper 不容许退出，例如 Android 主线程 Looper 就不容许退出；
Looper 退出时，应用平安退出 quitSafely() 形式退出；

明天咱们介绍了一个冷门的办法 runWithScissors() 以及其原理，它实现了通过阻塞的形式，向指标线程发送工作，并期待工作执行完结。

尽管被它标记为 @hide，无奈间接应用，但代码就在这里，咱们其实能够本人实现一个 BlockingRunnable 去应用。当然本来存在的问题，在应用时仍然须要留神。

我晓得就算这个办法不被标记为 @hide，应用的场景也十分的少，然而它仍然能够帮忙咱们思考一些临界问题，线程的同步、死锁，以及 Handler 的退出形式对音讯的影响。

这里给大家分享一份 BAT 大佬整顿总结进去的《2022 中高级 Android 面试题汇总 + 源码 + 视频 + 电子书》，外面蕴含了所有 Android 面试的知识点，想看看的搭档能够点击下方链接收费获取，祝你能找到一份适宜本人的好工作~！

链接：https://shimo.im/docs/R13j85m…

关于面试技巧:面试官Handler的runWithScissors了解吗为什么Google不让开发者用

二、Handler.runWithScissors()

2.1 runWithScissors()

2.2 Framework 中的应用

三、runWithScissors() 的问题

3.1 如果超时了，没有勾销的逻辑

3.2 可能造成死锁

四、总结时刻