做盗版影视网站,摄影网站怎么备案,网络营销的发展趋势和前景,wordpress编辑页面没用常见的Android稳定性异常#xff0c;有内核异常和Android层异常。内核异常也就是常说的“kernel panic”#xff0c;简称KE异常#xff1b;Android层异常又分为java层crash和Native层crash#xff0c;简称JE、NE异常。此外#xff0c;Android层异常还有应用ANR和system_Se… 常见的Android稳定性异常有内核异常和Android层异常。内核异常也就是常说的“kernel panic”简称KE异常Android层异常又分为java层crash和Native层crash简称JE、NE异常。此外Android层异常还有应用ANR和system_Server watchdog异常这两种异常是应用或者系统长时间无响应时触发的。本文主要介绍android层Java Exception异常的抓取机制和处理方式。下期文章里会再介绍NE异常。Java Exception1.简介 我们知道java有try-catch的异常捕获机制一份健壮的代码应该在设计和实现时考虑到各种可能遇到的exception异常捕获并做相应的处理。但并非所有的异常都是可被预知的没有捕获到的异常会被一层层的往上抛最终由虚拟机的默认异常处理机制来处理。这里会打印出异常的堆栈信息同时程序将停止运行也就是我们常见的程序崩溃。Debug版本上程序崩溃会弹框提示“xx程序停止运行”。正式用户版本上各厂商通常都修改为直接退出应用移除了弹框提示。2.异常抓取机制Java的Thread类提供了一份Java的Thread类中有一个UncaughtExceptionHandler接口该接口的作用主要是为了当Thread因未捕获的异常而突然终止时调用处理程序处理异常。//UncaughtExceptionHandler接口唯一的回调函数void uncaughtException(Thread t, Throwable e);//设置当前线程的异常处理器Thread.setUncaughtExceptionHandler//设置所有线程的默认异常处理器Thread.setDefaultUncaughtExceptionHandler//设置所有线程的默认异常预处理器Thread.setUncaughtExceptionPreHandlerAndroid中也同样利用了这种机制。虚拟机在遇到线程没有捕获的异常时会调用thread的dispatchUncaughtException分发到当前线程中。这里的java_lang_Thread_dispatchUncaughtException就是反射的java thread类的dispatchUnCaughtException方法。这里面会有两个uncaughtExceptionHandler参与处理分别是preHandler和Handler分别执行各自的unCaughtException()方法。这里preHandler可以不设置。事实上Android平台在N之前只有一个Handler并没有设置preHandler。我们知道Android系统中System_server进程和各种应用进程都是从zygote进程孵化而来zygoteInit的时候会调用Runntime.commonInit()这里就会设置进程默认的uncaughtExceptionHandler代码实现如下这里RunntimeInit初始化了两个handler一个是preHandler(LoggingHandler)一个是defaultHangler(KillApplicationHandler)。两个类都继承于Thread.UncaughtExceptionHandler实现其中的uncaughtException方法。其中:(1)LoggingHandler主要用来打印异常信息包括是否是SYSTEM_SERVER进程异常异常进程名、pid信息、异常堆栈等。我们分析问题常见的“FATAL EXCEPTION”的打印就是来自于这里。如果是SYSTEM_SERVER进程发生的JE异常打印的头部会变成”*** FATAL EXCEPTION IN SYSTEM PROCESS:”.(2)KillApplicationHandler主要用来检查和确保LoggingHandler的日志打印被调用到然后通知AMS杀掉应用进程。Android N之前只有一个defaultHandler日志打印和通知AMS杀进程都是在这个Handler中完成的。需要注意的是preHandler的设置并非对外公开api应用无法使用。但是Thread的setDefaultUncaughtExceptionHandler是公开的api应用进程可以通过重设它来实现自己捕获uncaughtException。这种情况下系统日志中虽然打印了FATAL EXCEPTION但是应用并没有死掉。应用可以通过这种方式自己捕获异常的堆栈但是通常情况下捕捉完信息后建议还是杀掉或者重启进程这种如果处理不好的话容易出现应用假死(无法运行也不会自动退出) 的情况。在log中打印完日志之后uncaughtException还会调用AMS的handleApplicationCrash对本次异常进行处理将抛出的异常throwable通过ApplicationErrorReport类转换为序列化变量再通过binder传递到AMS服务端。HandleApplicationCrash会先去获取进程名称进程名(processName)获取方式①当远程Ibinder对象为空则进程名为“system_server”②远程对象不为空时。如果processRecord能查到符合该binder对象的app记录则打印processRecord对象中相应的进程名如果processRecord为空现场可能已经不完整进程名复制为“unknown”。有了crashInfo又拿到了processRecord信息和进程名接下来继续执行crashInner处理方法。HandleApplicationCrashInner主要完成两件事情一是调用addErrorToDropBox将crashInfo的关键信息输出到dropbox文件中目录位于data/system/dropbox根据异常的进程名一般名为system_server_crash***.txtsystem_app_crash***data_app_crash***。写入的内容包括进程名、pid、uid、时间、flag、包名、前后台信息、fingerprint版本信息、crashInfo堆栈信息等厂商定制可能会再加入一些其他的打印。到这里日志已经保存完接下来AppError.crashApplication用来完成最后的收尾工作主要用来处理应用退出后带来的状态切换变化以及呈现crash弹窗给用户。该函数中主要的两段① makeAppCrashingLocked。处理应用退出后的逻辑主要完成的工作处理屏幕旋转以及旋转动作相关逻辑移除屏幕冻结的超时消息使能输入事件分发发送configuration改变的消息恢复顶部的Activity② SHOW_ERROR_UI_MSG。主要用来处理crash之后的弹框提醒阻塞并等待用户选择是否退出用户不做选择超过5min或者手机休眠的话会自动退出。至此JAVA Exception的抓取处理逻辑完成。3.抓到的日志JE异常产生后会先在logcat buffer中产生一系列打印包含刚才提到的“FATAL EXCEPTION”和“***FATAL EXCEPTION IN SYSTEM PROCESS”, 通常可以以FATAL关键字搜索定位。LOG中的JE异常格式如下另外在data/system/dropbox目录下会同步生成一份txt的日志文件需要root权限才能导出。通常根据crash的进程的不同前缀可能是“system_app_crash”、“data_app_crash”、“system_server_crash”中的一种。导出后的内容如下图4.异常堆栈由来Java exception的产生主要有两种原因 (1) 编写的程序代码内部错误产生的异常如调用对象为空(空指针异常)、数组越界异常、除0异常等。这种通常称为未检查的异常在虚拟机中执行时会集中处理这些异常。(2) 其他运行中异常通过throw语句主动抛出的异常。这类异常称为检查异常一般是程序认为自己遇到了严重的问题后续再运行可能会出问题主动告知方法调用者一些必要的信息。未检查的异常是如何让线程退出循环执行到uncaughtExceptionHandler的我们以除0异常来举例。经过编译这个触发操作最后会转化为一条div-int/lint8指令当art虚拟机需要执行这条语句时会去先解释这条语句通过字符串匹配的方式找到对应的指令代码这条语句对应的是DIV_INT_LIT8.DIV_INT_LIT8会继续调用DoIntDivide方法。DoIntDivide方法定义如下这里我们可以看到当除数divisor为0的时候虚拟机会通过hrowArithmeticExceptionDivideByZero方法抛出除零异常。接下来的调用顺序Art虚拟机对该throw异常遍历线程方法栈寄存器和PC指针寄存器, 得到函数方法调用栈等信息最终用setException方法保存在tlsPtr变量中等thread.destory调用dispatch uncaughtException的时候将exception信息传递给之前RuntimeInit中注册的handler去处理。其他的未检查的异常也是类似的逻辑。对于检查类的异常这一块逻辑会简单很多。通常检查类的异常都会由某段程序主动调用throw去抛出一个runntimeExceptionexception可以是原生的类型例如SecurityException、NullPointerException、IllegalStateException也可以是自己定义的某个集成于exception的类。无论是哪种exception还是error最终都是继承于Throwable类throwable类在构造的时候就会调用fillInStackTrace方法。这个jni方法最终会调用到art虚拟机的Thread:: CreateInternalStackTrace方法中。这就和刚才未检查异常里面获取stackTrace用到了同样的方法。这里会把exception(throwable)的堆栈环境记录下来。等需要打印的时候再通过jni方法来获取。前面提到的AMS调用handleApplicationCrash这里getStackTrace获取的就是throwable初始化时记录下来的函数运行堆栈。5.分析方法Java Exception的分析方法相对要简单很多java堆栈会保留出错的调用栈能精确到代码指定的行号。如果问题容易复现可以直接用logcat命令复现并保存日志。如果是已经发生的低概率问题机器现场还在的话可以通过导出data/system/dropbox目录下的日志文件。通常是data_app_crash、system_app_crash、system_server_crash开头以txt为后缀。通过分析日志堆栈可以快速定位到出错的代码。例如上图的异常堆栈可以明显看到指定的行号上存在代码运行空指针异常并且准确的打印了空指针的变量名称开发人员可以检查相关代码逻辑处理即可。长按关注内核工匠微信Linux 内核黑科技 | 技术文章 | 精选教程
