Android(安卓)解决崩溃后重启的问题
在开发过程中,想必你也一定遇到过这样的问题,当我们的应用发生Crash时异常退出,然后又自动启动跳转到未知页面,此时应用在崩溃前保存的全局变量被重置,用户状态丢失,显示数据错乱。更让我们头疼的是,这种崩溃后重启的情况,并不是每次都会遇到,那么究竟是因为什么呢?
经测试,在 Android 的 API 21 ( Android 5.0 ) 以下,Crash 会直接退出应用,但是在 API 21 ( Android 5.0 ) 以上,系统会遵循以下原则进行重启:
- 包含 Service,如果应用 Crash 的时候,运行着Service,那么系统会重新启动 Service。
- 不包含 Service,只有一个 Activity,那么系统不会重新启动该 Activity。
- 不包含 Service,但当前堆栈中存在两个 Activity:Act1 -> Act2,如果 Act2 发生了 Crash ,那么系统会重启 Act1。
- 不包含 Service,但是当前堆栈中存在三个 Activity:Act1 -> Act2 -> Act3,如果 Act3 崩溃,那么系统会重启 Act2,并且 Act1 依然存在,即可以从重启的 Act2 回到 Act1。
看了上述解释,我们终于知道应用在什么种情况下才会重启。
面对这样的问题,我们提供两种解决思路,一是允许应用自动重启,并在重启时恢复应用在崩溃前的运行状态。二是禁止应用自动重启,而是让用户在应用发生崩溃后自己手动重启应用。
本文主要提供禁止应用自动启动的思路和代码实现。
网上有很多开源的库供大家选择,但个人觉得一个类就可以解决的问题,没必要再引入依赖到项目中。
获取应用Crash时的回调
Android提供一个UncaughtExceptionHandler
的接口,该接口在应用发生Crash时,会回调接口中的uncaughtException
方法。
因此我们可以构建一个类,继承UncaughtExceptionHandler
接口,并覆写uncaughtException
方法,在覆盖方法中处理Crash异常问题并退出应用。
class CrashCollectHandler : Thread.UncaughtExceptionHandler { //当UncaughtException发生时会转入该函数来处理 override fun uncaughtException(t: Thread?, e: Throwable?) { if (!handleException(e) && mDefaultHandler!=null){ //如果用户没有处理则让系统默认的异常处理器来处理 mDefaultHandler?.uncaughtException(t,e) }else{ try { //给Toast留出时间 Thread.sleep(2000) } catch (e: InterruptedException) { e.printStackTrace() } //退出程序 android.os.Process.killProcess(android.os.Process.myPid()) System.exit(0) } }}
handleException
方法主要是为了弹出Toast和收集crash信息
fun handleException(ex: Throwable?):Boolean { if (ex == null){ return false } Thread{ Looper.prepare() toast("很抱歉,程序出现异常,即将退出") Looper.loop() }.start() //收集设备参数信息 collectDeviceInfo(mContext); //保存日志文件 saveCrashInfo2File(ex); // 注:收集设备信息和保存日志文件的代码就没必要在这里贴出来了 //文中只是提供思路,并不一定必须收集信息和保存日志 //因为现在大部分的项目里都集成了第三方的崩溃分析日志,如`Bugly` 或 `啄木鸟等` //如果自己定制化处理的话,反而比较麻烦和消耗精力,毕竟开发资源是有限的 return true }
设置程序的默认处理器
fun init(pContext: Context) { this.mContext = pContext // 获取系统默认的UncaughtException处理器 mDefaultHandler = Thread.getDefaultUncaughtExceptionHandler() // 设置该CrashHandler为程序的默认处理器 Thread.setDefaultUncaughtExceptionHandler(this) }
最后在Application中调用并初始化
class APP:Application{ override fun onCreate() { super.onCreate() /**捕获Crash,解决程序崩溃后启动的问题*/ CrashCollectHandler.instance.init(this) } }
如果按照上边的代码执行,你会发现应用依然会在崩溃时重启。 (看到这里,心里已经开始骂娘了,写的什么鸟博客,完全解决不了我的问题啊。 )
别急,此刻你的内心和当初的我是一模一样的。
为了让你印象深刻, 请继续往下边看。
退出栈内所有的Acitvity
如果应用在发生崩溃时,回退栈内依然存在没有退出的Activity,即使调用了System.exit(0)
方法,应用依然会自动重启。因此我们就需要在应用退出之前,先清除栈内所有的Activity。
在Application中定义一个存储Activity的list,并定义三个管理Activity集合的方法。
class App:Application{ fun addActivity(activity: Activity) { if (!activityList.contains(activity)) { activityList.add(activity) } } fun removeActivity(activity: Activity) { if (activityList.contains(activity)) { activityList.remove(activity) } } fun removeAllActivity() { activityList.forEach { if (it != null) { it.finish() } } }}
在BaseActivity中执行管理Activity集合的方法。
open class BaseActivity : AppCompatActivity(){ override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) App.i.addActivity(this) } override fun onDestroy() { super.onDestroy() App.i.removeActivity(this) }}
在上边我们已经学习过的方法uncaughtException
中添加退出所有Activity的方法
class CrashCollectHandler : Thread.UncaughtExceptionHandler { //当UncaughtException发生时会转入该函数来处理 override fun uncaughtException(t: Thread?, e: Throwable?) { ... //退出程序 App.i.removeAllActivity() android.os.Process.killProcess(android.os.Process.myPid()) System.exit(0) ... } }}
OK,大功告成,跑一下程序试试,果然在应用崩溃后不会发生再次启动应用的情况。
文中使用的是Kotlin语言,如果你使用的编译语言是Java,把上述代码转化为java执行即可。
最后
最后再贴一下完整的CrashCollectHandler
类:
class CrashCollectHandler : Thread.UncaughtExceptionHandler { var mContext: Context? = null var mDefaultHandler:Thread.UncaughtExceptionHandler ?=null companion object { val instance by lazy(mode = LazyThreadSafetyMode.SYNCHRONIZED) { CrashCollectHandler() } } fun init(pContext: Context) { this.mContext = pContext // 获取系统默认的UncaughtException处理器 mDefaultHandler = Thread.getDefaultUncaughtExceptionHandler() // 设置该CrashHandler为程序的默认处理器 Thread.setDefaultUncaughtExceptionHandler(this) } //当UncaughtException发生时会转入该函数来处理 override fun uncaughtException(t: Thread?, e: Throwable?) { if (!handleException(e) && mDefaultHandler!=null){ //如果用户没有处理则让系统默认的异常处理器来处理 mDefaultHandler?.uncaughtException(t,e) }else{ try { //给Toast留出时间 Thread.sleep(2000) } catch (e: InterruptedException) { e.printStackTrace() } //退出程序 App.i.removeAllActivity() android.os.Process.killProcess(android.os.Process.myPid()) System.exit(0) } } fun handleException(ex: Throwable?):Boolean { if (ex == null){ return false } Thread{ Looper.prepare() toast("很抱歉,程序出现异常,即将退出") Looper.loop() }.start() //收集设备参数信息 //collectDeviceInfo(mContext); //保存日志文件 //saveCrashInfo2File(ex); // 注:收集设备信息和保存日志文件的代码就没必要在这里贴出来了 //文中只是提供思路,并不一定必须收集信息和保存日志 //因为现在大部分的项目里都集成了第三方的崩溃分析日志,如`Bugly` 或 `啄木鸟等` //如果自己定制化处理的话,反而比较麻烦和消耗精力,毕竟开发资源是有限的 return true }}
一起进步
更多相关文章
- Android应用在不同版本间兼容性处理
- TestFlight被苹果收购,将停止对Android的支持
- 如何判断是否可以使用某个Intent
- Android(安卓)Socket 通信实例...【Pnoker】
- Android中AVD的使用以及错误处理方法
- Android(安卓)Studio混淆相关总结
- Nexus6 Android原生系统刷机方法
- [Kotlin Tutorials 14] Kotlin Coroutines在Android中的实践
- 实现Android中TextView的跑马灯效果