一个不一样的 ANR
最近碰到一个 ANR 问题，拿到 traces 文件后，显示主线程的堆栈是下面这样的：
1 2 3 4 5 6 7 |
at android.os.MessageQueue.nativePollOnce(Native method) at android.os.MessageQueue.next(MessageQueue.java:323) at android.os.Looper.loop(Looper.java:135) at android.app.ActivityThread.main(ActivityThread.java:5417) at java.lang.reflect.Method.invoke!(Native method) at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:726) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:616) |
这样一段堆栈，在很多情况下表明主线程是正常的，即处在等待区下一条主线程消息的过程中，而不是陷在某个耗时特别长的消息中。
经过反复测试，最后确认这个 ANR 和设置了 Default UncaughtExceptionHandler 有关，问题代码可以简化成下面的样子：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
public class MainActivity extends AppCompatActivity {
static {
Thread.setDefaultUncaughtExceptionHandler(new Thread.UncaughtExceptionHandler() {
@Override
public void uncaughtException(final Thread t, Throwable e) {
Log.i("uncaught", Thread.currentThread().toString());
Log.i("uncaught", t.toString());
}
});
}
private Thread thread;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
findViewById(R.id.btn).setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
new Thread(new Runnable() {
@Override
public void run() {
throw new RuntimeException("hello world");
}
}).start();
//throw new RuntimeException("hello world!!");
}
});
}
}
|
上面的代码的表现是，如果只让第 26 行抛出异常，那么一切看起来都正常，但是如果让第 29 行抛出异常，那么应用直接就无响应了。
经过一番查找与验证，我发现原因大致是，当一个 Java 线程抛出了未捕获的异常时，JVM 先会调用到 UncaughtExceptionHandler，然后再会把此线程停止掉。所以这段代码中，如果主线程抛出异常，那么第 6 行的方法结束后，主线程就会被 JVM 给停止掉，既然主线程都停止掉了，那自然就无响应了，也就会发生 ANR 了。
事实上，一般我们设置自定义 UncaughtExceptionHandler 时，都会在自定义的 uncaughtException 方法最后再调用一遍被我们顶替掉的系统默认的 UncaughtExceptionHandler，以便把应用 kill 掉，而这个例子，充分的显示了，当未捕获异常发生后，就算赖着不 kill 掉应用也是不行的，因为可能主线程都已经被停掉了。
关于 JVM 先调用 UncaughtExceptionHandler 然后把发生未捕获异常的线程停止掉的说法，见于 Java Language Specification 11.3，如下所示的片段：
那么主线程被停止掉，是个什么样的状态呢，我用下面的代码，把主线程的状态给输出来：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 |
public class MainActivity extends AppCompatActivity {
static {
Thread.setDefaultUncaughtExceptionHandler(new Thread.UncaughtExceptionHandler() {
@Override
public void uncaughtException(final Thread t, Throwable e) {
Log.i("uncaught", Thread.currentThread().toString());
Log.i("uncaught", t.toString());
}
});
}
private Thread thread;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
findViewById(R.id.btn).setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
final Thread mainThread = Thread.currentThread();
Log.i("<<<", mainThread.getState().toString());
if (thread == null) {
thread = new Thread(new Runnable() {
@Override
public void run() {
for (int i = 0; i < 3; ++i) {
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
Log.i("<<<", mainThread.getState().toString());
}
}
});
thread.start();
}
throw new RuntimeException("hello world!!");
}
});
}
}
|
上面代码的第 24 行和第 35 行一共会 4 此输出主线程的状态，结果如下面所示：
1 2 3 4 |
01-18 21:00:24.308 14533 14533 I <<< : RUNNABLE 01-18 21:00:25.309 14533 14570 I <<< : NEW 01-18 21:00:26.310 14533 14570 I <<< : NEW 01-18 21:00:27.311 14533 14570 I <<< : NEW |
从上面代码可知，主线程从 RUNNABLE 状态变成了 NEW 状态，为什么是 NEW 状态，我也不清楚，也许将来对 JVM 了解更多了，会清除吧。
回到这个 ANR 来，这个例子说明，我们如果使用自定义的 UncaughtExceptionHandler，记得要把应用 kill 掉，还有 default 的 UncaughtExceptionHandler 是全局公用的，很容易会出现被顶替 (覆盖)，所以切记别随意调用，免得出现意料之外的问题。
修复这样的 ANR，分成两部分，第一部分是先移除或者修改不恰当的设置 UncaughtExceptionHandler 的代码，先消除 ANR，然后还需要把引发 ANR 的另一个原因，也就是未捕获的异常给修复掉，不然应用不会 ANR 了但是会 Crash。
原文地址：http://tao93.top/2019/01/18/%E4%B8%80%E4%B8%AA%E4%B8%8D%E4%B8%80%E6%A0%B7%E7%9A%84%20ANR/