关于android:能否让APP永不崩溃小光和我的对决

前言

对于拦挡异样，想必大家都晓得能够通过Thread.setDefaultUncaughtExceptionHandler来拦挡App中产生的异样，而后再进行解决。

于是，我有了一个不成熟的想法。。。

让我的APP永不解体

既然咱们能够拦挡解体，那咱们间接把APP中所有的异样拦挡了，不杀死程序。这样一个不会解体的APP用户体验不是杠杠的？

有人听了摇摇头示意不同意，这不小光跑来问我了：

“老铁，呈现解体是要你解决它不是覆盖它！！”

我拿把扇子扇了几下，有点冷然而故作镇定的说：

“这位老哥，你能够把异样上传到本人的服务器解决啊，你能拿到你的解体起因，用户也不会因为异样导致APP解体，这不挺好?”

小光有点怄气的说：

“这样必定有问题，听着就不靠谱，哼，我去试试看”

小光的试验

于是小光依照网上一个小博主—积木的文章，写出了以下捕捉异样的代码：

//定义CrashHandlerclass 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了”

<figcaption style="margin: 5px 0px 0px; padding: 0px; outline: 0px; max-width: 100%; box-sizing: border-box !important; overflow-wrap: break-word !important; text-align: center; color: rgb(136, 136, 136); font-size: 14px;">主线程解体</figcaption>

“果然有问题，然而为啥主线程会出问题呢？我得先搞懂再去找老铁相持。”

小光的思考（异样源码剖析）

首先科普下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或者间接杀死过程。

可能有的敌人会问，为什么要让程序不解体呢？会有哪些状况须要咱们进行这样操作呢？

其实还是有很多时候，有些异样咱们无奈意料或者给用户带来简直是无感知的异样，比方：

零碎的一些bug
第三方库的一些bug
不同厂商的手机带来的一些bug

等等这些状况，咱们就能够通过这样的操作来让APP就义掉这部分的性能来保护零碎的稳定性。

我的库存，须要的小伙伴请点击我的GitHub收费支付