能否让APP永不崩溃—小光与我的对决
作者:互联网
前言
关于拦截异常,想必大家都知道可以通过Thread.setDefaultUncaughtExceptionHandler
来拦截App中发生的异常,然后再进行处理。
于是,我有了一个不成熟的想法。。。
让我的APP永不崩溃
既然我们可以拦截崩溃,那我们直接把APP中所有的异常拦截了,不杀死程序。这样一个不会崩溃的APP用户体验不是杠杠的?
- 有人听了摇摇头表示不赞同,这不小光跑来问我了:
“老铁,出现崩溃是要你解决它不是掩盖它!!”
- 我拿把扇子扇了几下,有点冷但是故作镇定的说:
“这位老哥,你可以把异常上传到自己的服务器处理啊,你能拿到你的崩溃原因,用户也不会因为异常导致APP崩溃,这不挺好?”
- 小光有点生气的说:
“这样肯定有问题,听着就不靠谱,哼,我去试试看”
小光的实验
于是小光按照网上一个小博主—积木
的文章,写出了以下捕获异常的代码:
//定义CrashHandler
class CrashHandler private constructor(): Thread.UncaughtExceptionHandler {
private var context: Context? = null
fun init(context: Context?) {
this.context = context
Thread.setDefaultUncaughtExceptionHandler(this)
}
override fun uncaughtException(t: Thread, e: Throwable) {}
companion object {
val instance: CrashHandler by lazy(mode = LazyThreadSafetyMode.SYNCHRONIZED) {
CrashHandler() }
}
}
//Application中初始化
class MyApplication : Application(){
override fun onCreate() {
super.onCreate()
CrashHandler.instance.init(this)
}
}
//Activity中触发异常
class ExceptionActivity : AppCompatActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_exception)
btn.setOnClickListener {
throw RuntimeException("主线程异常")
}
btn2.setOnClickListener {
thread {
throw RuntimeException("子线程异常")
}
}
}
}
小光一顿操作,写下了整套代码,为了验证它的猜想,写了两种触发异常的情况:子线程崩溃和主线程崩溃。
- 运行,点击按钮2,触发子线程异常崩溃:
“咦,还真没啥影响,程序能继续正常运行”
- 然后点击按钮1,触发主线程异常崩溃:
“嘿嘿,卡住了,再点几下,直接ANR了”
“果然有问题,但是为啥主线程会出问题呢?我得先搞懂再去找老铁对峙。”
小光的思考(异常源码分析)
首先科普下java中的异常,包括运行时异常
和非运行时异常
:
-
运行时异常。是
RuntimeException
类及其子类的异常,是非受检异常,比如系统异常或者是程序逻辑异常,我们常遇到的有NullPointerException、IndexOutOfBoundsException
等。遇到这种异常,Java Runtime
会停止线程,打印异常,并且会停止程序运行,也就是我们常说的程序崩溃。 -
非运行时异常。是属于
Exception
类及其子类,是受检异常,RuntimeException
以外的异常。这类异常在程序中必须进行处理,如果不处理程序都无法正常编译,比如NoSuchFieldException,IllegalAccessException
这种。
ok,也就是说我们抛出一个RuntimeException
异常之后,所在的线程会被停止。如果主线程中抛出这个异常,那么主线程就会被停止,所以APP就会卡住无法正常操作,时间久了就会ANR
。而子线程崩溃了并不会影响主线程也就是UI线程的操作,所以用户还能正常使用。
这样好像就说的通了。
等等,那为什么遇到setDefaultUncaughtExceptionHandler
就不会崩溃了呢?
我们还得从异常的源码开始说起:
一般情况下,一个应用中所使用的线程都是在同一个线程组,而在这个线程组里只要有一个线程出现未被捕获异常的时候,JAVA 虚拟机就会调用当前线程所在线程组中的 uncaughtException()
方法。
// ThreadGroup.java
private final ThreadGroup parent;
public void uncaughtException(Thread t, Throwable e) {
if (parent != null) {
parent.uncaughtException(t, e);
} else {
Thread.UncaughtExceptionHandler ueh =
Thread.getDefaultUncaughtExceptionHandler();
if (ueh != null) {
ueh.uncaughtException(t, e);
} else if (!(e instanceof ThreadDeath)) {
System.err.print("Exception in thread \""
+ t.getName() + "\" ");
e.printStackTrace(System.err);
}
}
}
parent
表示当前线程组的父级线程组,所以最后还是会调用到这个方法中。接着看后面的代码,通过getDefaultUncaughtExceptionHandler
获取到了系统默认的异常处理器,然后调用了uncaughtException
方法。那么我们就去找找本来系统中的这个异常处理器——UncaughtExceptionHandler
。
这就要从APP的启动流程说起了,之前也说过,所有的Android进程
都是由zygote进程fork
而来的,在一个新进程被启动的时候就会调用zygoteInit
方法,这个方法里会进行一些应用的初始化工作:
public static final Runnable zygoteInit(int targetSdkVersion, String[] argv, ClassLoader classLoader) {
if (RuntimeInit.DEBUG) {
Slog.d(RuntimeInit.TAG, "RuntimeInit: Starting application from zygote");
}
Trace.traceBegin(Trace.TRACE_TAG_ACTIVITY_MANAGER, "ZygoteInit");
//日志重定向
RuntimeInit.redirectLogStreams();
//通用的配置初始化
RuntimeInit.commonInit();
// zygote初始化
ZygoteInit.nativeZygoteInit();
//应用相关初始化
return RuntimeInit.applicationInit(targetSdkVersion, argv, classLoader);
}
而关于异常处理器,就在这个通用的配置初始化方法当中:
protected static final void commonInit() {
if (DEBUG) Slog.d(TAG, "Entered RuntimeInit!");
//设置异常处理器
LoggingHandler loggingHandler = new LoggingHandler();
Thread.setUncaughtExceptionPreHandler(loggingHandler);
Thread.setDefaultUncaughtExceptionHandler(new KillApplicationHandler(loggingHandler));
//设置时区
TimezoneGetter.setInstance(new TimezoneGetter() {
@Override
public String getId() {
return SystemProperties.get("persist.sys.timezone");
}
});
TimeZone.setDefault(null);
//log配置
LogManager.getLogManager().reset();
//***
initialized = true;
}
找到了吧,这里就设置了应用默认的异常处理器——KillApplicationHandler
。
private static class KillApplicationHandler implements Thread.UncaughtExceptionHandler {
private final LoggingHandler mLoggingHandler;
public KillApplicationHandler(LoggingHandler loggingHandler) {
this.mLoggingHandler = Objects.requireNonNull(loggingHandler);
}
@Override
public void uncaughtException(Thread t, Throwable e) {
try {
ensureLogging(t, e);
//...
// Bring up crash dialog, wait for it to be dismissed
ActivityManager.getService().handleApplicationCrash(
mApplicationObject, new ApplicationErrorReport.ParcelableCrashInfo(e));
} catch (Throwable t2) {
if (t2 instanceof DeadObjectException) {
// System process is dead; ignore
} else {
try {
Clog_e(TAG, "Error reporting crash", t2);
} catch (Throwable t3) {
// Even Clog_e() fails! Oh well.
}
}
} finally {
// Try everything to make sure this process goes away.
Process.killProcess(Process.myPid());
System.exit(10);
}
}
private void ensureLogging(Thread t, Throwable e) {
if (!mLoggingHandler.mTriggered) {
try {
mLoggingHandler.uncaughtException(t, e);
} catch (Throwable loggingThrowable) {
// Ignored.
}
}
}
看到这里,小光欣慰一笑,被我逮到了吧。在uncaughtException
回调方法中,会执行一个handleApplicationCrash
方法进行异常处理,并且最后都会走到finally
中进行进程销毁,Try everything to make sure this process goes away
。所以程序就崩溃了。
关于我们平时在手机上看到的崩溃提示弹窗,就是在这个handleApplicationCrash
方法中弹出来的。不仅仅是java崩溃,还有我们平时遇到的native_crash、ANR
等异常都会最后走到handleApplicationCrash
方法中进行崩溃处理。
另外有的朋友可能发现了构造方法中,传入了一个LoggingHandler
,并且在uncaughtException
回调方法中还调用了这个LoggingHandler
的uncaughtException
方法,难道这个LoggingHandler
就是我们平时遇到崩溃问题,所看到的崩溃日志?进去瞅瞅:
private static class LoggingHandler implements Thread.UncaughtExceptionHandler {
public volatile boolean mTriggered = false;
@Override
public void uncaughtException(Thread t, Throwable e) {
mTriggered = true;
if (mCrashing) return;
if (mApplicationObject == null && (Process.SYSTEM_UID == Process.myUid())) {
Clog_e(TAG, "*** FATAL EXCEPTION IN SYSTEM PROCESS: " + t.getName(), e);
} else {
StringBuilder message = new StringBuilder();
message.append("FATAL EXCEPTION: ").append(t.getName()).append("\n");
final String processName = ActivityThread.currentProcessName();
if (processName != null) {
message.append("Process: ").append(processName).append(", ");
}
message.append("PID: ").append(Process.myPid());
Clog_e(TAG, message.toString(), e);
}
}
}
private static int Clog_e(String tag, String msg, Throwable tr) {
return Log.printlns(Log.LOG_ID_CRASH, Log.ERROR, tag, msg, tr);
}
这可不就是吗?将崩溃的一些信息——比如线程,进程,进程id,崩溃原因等等通过Log打印出来了。来张崩溃日志图给大家对对看:
好了,回到正轨,所以我们通过setDefaultUncaughtExceptionHandler
方法设置了我们自己的崩溃处理器,就把之前应用设置的这个崩溃处理器给顶掉了,然后我们又没有做任何处理,自然程序就不会崩溃了,来张总结图。
小光又来找我对峙了
- 搞清楚这一切的小光又来找我了:
“老铁,你瞅瞅,这是我写的Demo
和总结的资料,你那套根本行不通,主线程崩溃就GG了,我就说有问题吧”
- 我继续故作镇定:
“老哥,我上次忘记说了,只加这个UncaughtExceptionHandler
可不行,还得加一段代码,发给你,回去试试吧”
Handler(Looper.getMainLooper()).post {
while (true) {
try {
Looper.loop()
} catch (e: Throwable) {
}
}
}
“这,,能行吗”
小光再次的实验
小光把上述代码加到了程序里面(Application—onCreate),再次运行:
我去,真的没问题了
,点击主线程崩溃后,还是可以正常操作app,这又是什么原理呢?
小光的再次思考(拦截主线程崩溃的方案思想)
我们都知道,在主线程中维护着Handler
的一套机制,在应用启动时就做好了Looper
的创建和初始化,并且调用了loop
方法开始了消息的循环处理。应用在使用过程中,主线程的所有操作比如事件点击,列表滑动等等都是在这个循环中完成处理的,其本质就是将消息加入MessageQueue
队列,然后循环从这个队列中取出消息并处理,如果没有消息处理的时候,就会依靠epoll机制挂起等待唤醒。贴一下我浓缩的loop
代码:
public static void loop() {
final Looper me = myLooper();
final MessageQueue queue = me.mQueue;
for (;;) {
Message msg = queue.next();
msg.target.dispatchMessage(msg);
}
}
一个死循环,不断取消息处理消息。再回头看看刚才加的代码:
Handler(Looper.getMainLooper()).post {
while (true) {
//主线程异常拦截
try {
Looper.loop()
} catch (e: Throwable) {
}
}
}
我们通过Handler
往主线程发送了一个runnable
任务,然后在这个runnable
中加了一个死循环,死循环中执行了Looper.loop()
进行消息循环读取。这样就会导致后续所有的主线程消息都会走到我们这个loop
方法中进行处理,也就是一旦发生了主线程崩溃,那么这里就可以进行异常捕获。同时因为我们写的是while死循环,那么捕获异常后,又会开始新的Looper.loop()
方法执行。这样主线程的Looper就可以一直正常读取消息,主线程就可以一直正常运行了。
文字说不清楚的图片来帮我们:
同时之前CrashHandler
的逻辑可以保证子线程也是不受崩溃影响,所以两段代码都加上,齐活了。
但是小光还不服气,他又想到了一种崩溃情况。。。
小光又又又一次实验
class Test2Activity : AppCompatActivity() {
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
setContentView(R.layout.activity_exception)
throw RuntimeException("主线程异常")
}
}
诶,我直接在onCreate
里面给你抛出个异常,运行看看:
黑漆漆的一片~没错,黑屏了。
最后的对话(Cockroach库思想)
- 看到这一幕,我主动找到了小光:
“这种情况确实比较麻烦了,如果直接在Activity
生命周期内抛出异常,会导致界面绘制无法完成,Activity
无法被正确启动,就会白屏或者黑屏了
这种严重影响到用户体验的情况还是建议直接杀死APP
,因为很有可能会对其他的功能模块造成影响。或者如果某些Activity不是很重要,也可以只finish
这个Activity
。”
- 小光思索地问:
“那么怎么分辨出这种生命周期内发生崩溃的情况呢?”
“这就要通过反射了,借用Cockroach
开源库中的思想,由于Activity
的生命周期都是通过主线程的Handler
进行消息处理,所以我们可以通过反射替换掉主线程的Handler中的Callback
回调,也就是ActivityThread.mH.mCallback
,然后针对每个生命周期对应的消息进行trycatch捕获异常,然后就可以进行finishActivity
或者杀死进程操作了。”
主要代码:
Field mhField = activityThreadClass.getDeclaredField("mH");
mhField.setAccessible(true);
final Handler mhHandler = (Handler) mhField.get(activityThread);
Field callbackField = Handler.class.getDeclaredField("mCallback");
callbackField.setAccessible(true);
callbackField.set(mhHandler, new Handler.Callback() {
@Override
public boolean handleMessage(Message msg) {
if (Build.VERSION.SDK_INT >= 28) {
//android 28之后的生命周期处理
final int EXECUTE_TRANSACTION = 159;
if (msg.what == EXECUTE_TRANSACTION) {
try {
mhHandler.handleMessage(msg);
} catch (Throwable throwable) {
//杀死进程或者杀死Activity
}
return true;
}
return false;
}
//android 28之前的生命周期处理
switch (msg.what) {
case RESUME_ACTIVITY:
//onRestart onStart onResume回调这里
try {
mhHandler.handleMessage(msg);
} catch (Throwable throwable) {
sActivityKiller.finishResumeActivity(msg);
notifyException(throwable);
}
return true;
代码贴了一部分,但是原理大家应该都懂了吧,就是通过替换主线程Handler
的Callback
,进行声明周期的异常捕获。
接下来就是进行捕获后的处理工作了,要不杀死进程,要么杀死Activity。
- 杀死进程,这个应该大家都熟悉
Process.killProcess(Process.myPid())
exitProcess(10)
- finish掉Activity
这里又要分析下Activity的finish
流程了,简单说下,以android29
的源码为例。
private void finish(int finishTask) {
if (mParent == null) {
if (false) Log.v(TAG, "Finishing self: token=" + mToken);
try {
if (resultData != null) {
resultData.prepareToLeaveProcess(this);
}
if (ActivityTaskManager.getService()
.finishActivity(mToken, resultCode, resultData, finishTask)) {
mFinished = true;
}
}
}
}
@Override
public final boolean finishActivity(IBinder token, int resultCode, Intent resultData,
int finishTask) {
return mActivityTaskManager.finishActivity(token, resultCode, resultData, finishTask);
}
从Activity的finish源码
可以得知,最终是调用到ActivityTaskManagerService
的finishActivity
方法,这个方法有四个参数,其中有个用来标识Activity
的参数也就是最重要的参数——token
。所以去源码里面找找token~
由于我们捕获的地方是在handleMessage
回调方法中,所以只有一个参数Message
可以用,那我么你就从这方面入手。回到刚才我们处理消息的源码中,看看能不能找到什么线索:
class H extends Handler {
public void handleMessage(Message msg) {
switch (msg.what) {
case EXECUTE_TRANSACTION:
final ClientTransaction transaction = (ClientTransaction) msg.obj;
mTransactionExecutor.execute(transaction);
break;
}
}
}
public void execute(ClientTransaction transaction) {
final IBinder token = transaction.getActivityToken();
executeCallbacks(transaction);
executeLifecycleState(transaction);
mPendingActions.clear();
log("End resolving transaction");
}
可以看到在源码中,Handler是怎么处理EXECUTE_TRANSACTION
消息的,获取到msg.obj
对象,也就是ClientTransaction
类实例,然后调用了execute
方法。而在execute
方法中。。。咦咦咦,这不就是token吗?
(找到的过于快速了哈,主要是activity
启动销毁这部分的源码解说并不是今天的重点,所以就一笔带过了)
找到token
,那我们就通过反射进行Activity的销毁就行啦:
private void finishMyCatchActivity(Message message) throws Throwable {
ClientTransaction clientTransaction = (ClientTransaction) message.obj;
IBinder binder = clientTransaction.getActivityToken();
Method getServiceMethod = ActivityManager.class.getDeclaredMethod("getService");
Object activityManager = getServiceMethod.invoke(null);
Method finishActivityMethod = activityManager.getClass().getDeclaredMethod("finishActivity", IBinder.class, int.class, Intent.class, int.class);
finishActivityMethod.setAccessible(true);
finishActivityMethod.invoke(activityManager, binder, Activity.RESULT_CANCELED, null, 0);
}
啊,终于搞定了,但是小光还是一脸疑惑的看着我:
“我还是去看Cockroach
库的源码吧~”
“我去,,”
总结
今天主要就说了一件事:如何捕获程序中的异常不让APP崩溃,从而给用户带来最好的体验。主要有以下做法:
- 通过在主线程里面发送一个消息,捕获主线程的异常,并在异常发生后继续调用
Looper.loop
方法,使得主线程继续处理消息。 - 对于子线程的异常,可以通过
Thread.setDefaultUncaughtExceptionHandler
来拦截,并且子线程的停止不会给用户带来感知。 - 对于在生命周期内发生的异常,可以通过替换
ActivityThread.mH.mCallback
的方法来捕获,并且通过token
来结束Activity或者直接杀死进程。但是这种办法要适配不同SDK版本的源码才行,所以慎用,需要的可以看文末Cockroach库源码。
可能有的朋友会问,为什么要让程序不崩溃呢?会有哪些情况需要我们进行这样操作呢?
其实还是有很多时候,有些异常我们无法预料
或者给用户带来几乎是无感知
的异常,比如:
- 系统的一些bug
- 第三方库的一些bug
- 不同厂商的手机带来的一些bug
等等这些情况,我们就可以通过这样的操作来让APP
牺牲掉这部分的功能来维护系统的稳定性。
参考
Cockroach
一文读懂 Handler 机制全家桶
zyogte进程(Java篇)
wanAndroid
拜拜
好了,到了说再见的时候了。
最后给大家推荐一个剧—棋魂,嘿嘿,小光就是里面的主角。
这些优秀的开源库又何尝不是指引我们前行进步的光呢~
有一起学习的小伙伴可以关注下❤️我的公众号——码上积木,每天剖析一个知识点,我们一起积累知识。公众号回复111可获得面试题《思考与解答》以往期刊。
标签:小光,APP,主线,线程,msg,对决,异常,崩溃 来源: https://www.cnblogs.com/jimuzz/p/14113556.html