春节最后一天上班，总结下自定义系统Anr/Crash弹框的流程
-
本篇文章从系统层面基于google源码分析，并在应用异常退出、无响应必经之路根据需要弹出d自定义dialog
1、首先应用无论是报错了，还是被系统kill了必经过
services/core/java/com/android/server/am/ActivityManagerService.java
@GuardedBy("this")
final void appDiedLocked(ProcessRecord app, int pid, IApplicationThread thread,
boolean fromBinderDied) {
//TODO
}
2、就是我们经常看到了XXX应用报错了、XXX应用无响应了 弹出的地方
有两个方法，分别弹出无响应和报错框，这些方法内部都有判断应用是不是crash、anr 是不是Silenced，就是说有报错也不会通知用户，可能表现为闪退。
services/core/java/com/android/server/am/AppErrors.java
//应用anr弹出的地方
(1)void handleShowAnrUi(Message msg) {
synchronized (mService) {
AppNotRespondingDialog.Data data = (AppNotRespondingDialog.Data) msg.obj;
final ProcessRecord proc = data.proc;
}
//应用crash弹出的地方
(2)void handleShowAppErrorUi(Message msg) {
AppErrorDialog.Data data = (AppErrorDialog.Data) msg.obj;
boolean showBackground = Settings.Secure.getInt(mContext.getContentResolver(),
Settings.Secure.ANR_SHOW_BACKGROUND, 0) != 0;
}
-
我们以应用ANR的dialog为例，AppNotRespondingDialog为例
services/core/java/com/android/server/am/AppNotRespondingDialog.java 继承了 BaseErrorDialog ， 构造方法里接收AMS 和 应用进程信息
final class AppNotRespondingDialog extends BaseErrorDialog implements View.OnClickListener
所以我们自定义的dialog就可以在AppErrors 里替换我们自定义的系统dialog ：TYPE_SYSTEM_ALERT
-
以Anr为例我们往前推下流程：
以绑定一个服务为起点，最后如果服务超时启动，会走到mAppErrors.handleShowAnrUi(msg)，就是我们上面的代码
image-20220126162633971.png
- 我们经常看到的Anr in XXX 就是在ProcessRecord.java 的appNotResponding 方法中打印出来的
04-0113:12:15.872 E/ActivityManager( 220): ANR in com.android.email(com.android.email/.activity.SplitScreenActivity)
04-0113:12:15.872 E/ActivityManager( 220): Reason:keyDispatchingTimedOut
04-0113:12:15.872 E/ActivityManager( 220): Load: 8.68 / 8.37 / 8.53
04-0113:12:15.872 E/ActivityManager( 220): CPUusage from 4361ms to 699ms ago
04-0113:12:15.872 E/ActivityManager( 220): 5.5%21404/com.android.email: 1.3% user + 4.1% kernel / faults: 10 minor
04-0113:12:15.872 E/ActivityManager( 220): 4.3%220/system_server: 2.7% user + 1.5% kernel / faults: 11 minor 2 major
04-0113:12:15.872 E/ActivityManager( 220): 0.9%52/spi_qsd.0: 0% user + 0.9% kernel</pre>
这个方法里除了打印这个还会调用ActivityManagerService 的dumpStackTraces ->dumpJavaTracesTombstoned 保存trace log到anr 目录和 tombstones 目录
- 再深入一点就是应用进程内部的trace是如何打印的
art\runtime\signal_catcher.cc 这里对于每个应用进程都会启动一个SignalCatcher 接收signal信号的，收到后会去dump其他线程信息
void* SignalCatcher::Run(void* arg) {
SignalCatcher* signal_catcher = reinterpret_cast<SignalCatcher*>(arg);
CHECK(signal_catcher != nullptr);
Runtime* runtime = Runtime::Current();
CHECK(runtime->AttachCurrentThread("Signal Catcher", true, runtime->GetSystemThreadGroup(),
!runtime->IsAotCompiler()));
Thread* self = Thread::Current();
DCHECK_NE(self->GetState(), kRunnable);
{
MutexLock mu(self, signal_catcher->lock_);
signal_catcher->thread_ = self;
signal_catcher->cond_.Broadcast(self);
}
// Set up mask with signals we want to handle.
SignalSet signals;
signals.Add(SIGQUIT);
signals.Add(SIGUSR1);
while (true) {
int signal_number = signal_catcher->WaitForSignal(self, signals);
if (signal_catcher->ShouldHalt()) {
runtime->DetachCurrentThread();
return nullptr;
}
switch (signal_number) {
case SIGQUIT:
signal_catcher->HandleSigQuit();
break;
case SIGUSR1:
signal_catcher->HandleSigUsr1();
break;
default:
LOG(ERROR) << "Unexpected signal %d" << signal_number;
break;
}
}</pre>
