Android系统构架及Native Crash

一、引言

   Android系统非常庞大、错综复杂,其底层是采用Linux作为基底,上层采用包含虚拟机的Java层以及Native层,通过系统调用(Syscall)连通系统的内核空间与用户空间。用户空间主要采用C++Java代码,通过JNI技术打通用户空间的Java层和Native(C++/C),从而融为一体。

   Google官方提供了一张经典的四层架构图,从下往上依次分为Linux内核、系统库和Android运行时

环境、框架层以及应用层这4层架构,其中每一层都包含大量的子模块或子系统。这只是如垒砖般地分层,并没有表达Android整个系统的内部架构、运行机理,以及各个模块之间是如何衔接与配合工作的。为了更深入地掌握Android整个架构思想以及各个模块在Android系统所处的地位与价值,计划以Android系统启动过程为主线,以进程的视角来诠释Android M系统全貌,全方位的深度剖析各个模块功能,争取各个击破。这样才能犹如庖丁解牛,解决、分析问题则能游刃有余。


Android系统构架及Native Crash_第1张图片

二、Android架构

   图解:Android系统启动过程由上图从下往上的一个过程:Loader->Kernel->Native ->Framework->App,接来下简要说说每个过程:


Android系统构架及Native Crash_第2张图片

2.1 Loader层

  •  Boot ROM: 当手机处于关机状态时,长按Power键开机,引导芯片开始从固化在ROM里的预设出代码开始执行,然后加载引导程序到RAM
  • Boot Loader:这是启动Android系统之前的引导程序,主要是检查RAM,初始化硬件参数等功能。

2.2 Kernel层

    Kernel层是指Android内核层,到这里才刚刚开始进入Android系统。

  • 启动Kernel的swapper进程(pid=0):该进程又称为idle进程, 系统初始化过程Kernel由无到有开创的第一个进程, 用于初始化进程管理、内存管理,加载Display,Camera Driver,Binder Driver等相关工作;
  • 启动kthreadd进程(pid=2):是Linux系统的内核进程,会创建内核工作线程kworkder,软中断线程ksoftirqd,thermal等内核守护进程。kthreadd进程是所有内核进程的鼻祖

2.3 Native层

  这里的Native层主要包括init孵化来的用户空间的守护进程、HAL层以及开机动画等。启动init进程(pid=1),是Linux系统的用户进程,init进程是所有用户进程的鼻祖

  • init进程会孵化出ueventd、logd、healthd、installd、adbd、lmkd等用户守护进程;
  • init进程还启动servicemanager(binder服务管家)、bootanim(开机动画)等重要服务
  • init进程孵化出Zygote进程,Zygote进程是Android系统的第一个Java进程(即虚拟机进程),Zygote是所有Java进程的父进程,Zygote进程本身是由init进程孵化而来的。

2.4 Framework层

· Zygote进程,是由init进程通过解析init.rc文件后fork生成的,Zygote进程主要包含:

    • 加载ZygoteInit类,注册Zygote Socket服务端套接字;
    • 加载虚拟机;
    • preloadClasses;
    • preloadResouces。
  • System Server进程,是由Zygote进程fork而来,System ServerZygote孵化的第一个进程System Server负责启动和管理整个Java framework,包含ActivityManager,PowerManager等服务。
  • Media Server进程,是由init进程fork而来,负责启动和管理整个C++ framework,包含AudioFlinger,Camera Service,等服务。

2.5 APP 层

  • Zygote进程孵化出的第一个App进程是Launcher,这是用户看到的桌面App;
  • Zygote进程还会创建Browser,Phone,Email等App进程,每个App至少运行在一个进程上。
  • 所有的App进程都是由Zygote进程fork生成的。

2.6 Syscall && JNI

  • Native与Kernel之间有一层系统调用(SysCall)层,见Linux系统调用(Syscall)原理;
  • Java层与Native(C/C++)层之间的纽带JNI,见Android JNI原理分析

三、应用组件

    Android开发四大组件分别是:活动(Activity):用于表现功能。服务(Service): 后台运行服务,不提供界面呈现。广播接收器(BroadcastReceiver):用于接收广播。内容提供商(ContentProvider): 支持在多个应用中存储和读取数据,相当于数据库。

3.1.活动

    Android 中,Activity是所有程序的根本,所有程序的流程都运行在Activity 之中,Activity可以算是开发者遇到的最频繁,也是Android 当中最基本的模块之一。在Android的程序当中,Activity 一般代表手机屏幕的一屏。如果把手机比作一个浏览器,那么Activity就相当于一个网页。在Activity 当中可以添加一些Button、Check box 等控件。可以看到Activity 概念和网页的概念相当类似。

    一般一个Android 应用是由多个Activity 组成的。这多个Activity 之间可以进行相互跳转,例如,按下一个Button按钮后,可能会跳转到其他的Activity。和网页跳转稍微有些不一样的是,Activity 之间的跳转有可能返回值,例如,从Activity A 跳转到Activity B,那么当Activity B 运行结束的时候,有可能会给Activity A 一个返回值。这样做在很多时候是相当方便的。

    当打开一个新的屏幕时,之前一个屏幕会被置为暂停状态,并且压入历史堆栈中。用户可以通过回退操作返回到以前打开过的屏幕。可以选择性的移除一些没有必要保留的屏幕,因为Android会把每个应用的开始到当前的每个屏幕保存在堆栈中。

3.2.服务

      Service 是android 系统中的一种组件,它跟Activity 的级别差不多,但是他不能自己运行,只能后台运行,并且可以和其他组件进行交互。Service是没有界面的长生命周期的代码。Service是一种程序,它可以运行很长时间,但是它却没有用户界面。这么说有点枯燥,来看个例子。打开一个音乐播放器的程序,这个时候若想上网了,那么,打开Android浏览器,这个时候虽然已经进入了浏览器这个程序,但是,歌曲播放并没有停止,而是在后台继续一首接着一首的播放。其实这个播放就是由播放音乐的Service进行控制。当然这个播放音乐的Service也可以停止,例如,当播放列表里边的歌曲都结束,或者用户按下了停止音乐播放的快捷键等。Service 可以在和多场合的应用中使用,比如播放多媒体的时候用户启动了其他Activity这个时候程序要在后台继续播放,比如检测SD 卡上文件的变化,再或者在后台记录地理信息位置的改变等等,总之服务嘛,总是藏在后头的。

      开启Service有两种方式:

      (1) Context.startService():Service会经历onCreate -> onStart(如果Service还没有运行,则android先调用onCreate()然后调用onStart();如果Service已经运行,则只调用onStart(),所以一个Service的onStart方法可能会重复调用多次 );StopService的时候直接onDestroy,如果是调用者自己直接退出而没有调用StopService的话,Service会一直在后台运行。该Service的调用者再启动起来后可以通过stopService关闭Service。 注意,多次调用Context.startservice()不会嵌套(即使会有相应的onStart()方法被调用),所以无论同一个服务被启动了多少次,一旦调用Context.stopService()或者StopSelf(),他都会被停止。补充说明:传递给StartService(0的Intent对象会传递给onStart()方法。调用顺序为:onCreate --> onStart(可多次调用) --> onDestroy。

      (2) Context.bindService():Service会经历onCreate() -->onBind(),onBind将返回给客户端一个IBind接口实例,IBind允许客户端回调服务的方法,比如得到Service运行的状态或其他操作。这个时候把调用者(Context,例如Activity)会和Service绑定在一起,Context退出了,Srevice就会调用onUnbind --> onDestroyed相应退出,所谓绑定在一起就共存亡了。

3.3.广播接收器

     在Android 中,Broadcast是一种广泛运用的在应用程序之间传输信息的机制。而BroadcastReceiver 是对发送出来的Broadcast进行过滤接受并响应的一类组件。可以使用BroadcastReceiver 来让应用对一个外部的事件做出响应。这是非常有意思的,例如,当电话呼入这个外部事件到来的时候,可以利用BroadcastReceiver 进行处理。例如,当下载一个程序成功完成的时候,仍然可以利用BroadcastReceiver 进行处理。BroadcastReceiver不能生成UI,也就是说对于用户来说不是透明的,用户是看不到的。BroadcastReceiver通过NotificationManager 来通知用户这些事情发生了。BroadcastReceiver 既可以在AndroidManifest.xml 中注册,也可以在运行时的代码中使用Context.registerReceiver()进行注册。只要是注册了,当事件来临的时候,即使程序没有启动,系统也在需要的时候启动程序。各种应用还可以通过使用Context.sendBroadcast () 将它们自己的Intent Broadcasts广播给其他应用程序。

3.4内容提供

    Content Provider 是Android提供的第三方应用数据的访问方案。

    在Android  中,对数据的保护是很严密的,除了放在SD卡中的数据,一个应用所持有的数据库、文件等内容,都是不允许其他直接访问的。Andorid当然不会真的把每个应用都做成一座孤岛,它为所有应用都准备了一扇窗,这就是Content Provider。应用想对外提供的数据,可以通过派生Content Provider类, 封装成一枚Content Provider,每个Content Provider都用一个uri作为独立的标识,形如:content://com.xxxxx。所有东西看着像REST的样子,但实际上,它比REST 更为灵活。和REST类似,uri也可以有两种类型,一种是带id的,另一种是列表的,但实现者不需要按照这个模式来做,给id的uri也可以返回列表类型的数据,只要调用者明白,就无妨,不用苛求所谓的REST。

 

四、Android常见Crash原因总结

4.1ANR(可见ANR):

发生场景:应用发生ANR。

崩溃症状:系统弹出窗口询问用户选择“Force Close”或者“Wait”。

“Force Close”将杀掉发生ANR的应用进程。“Wait”将会等待系统择机恢复此应用进程。

发生原因:

  (1)应用主线程卡住,对其他请求响应超时。

  (2)死锁。

  (3)系统反应迟钝。

  (4)CPU负载过重。

4.2.Force Close (FC):

发生场景:应用进程崩溃。

崩溃症状:系统弹出窗口提示用户某进程崩溃。

发生原因:空指向异常或者未捕捉的异常。

4.3.Tombstones:

发生场景:Native层崩溃

崩溃症状:如果发生崩溃的native层和UI有关联(比如Browser),我们可以在UI上发现这个崩溃。

如果发生崩溃的native层是在后台并且和UI没有直接联系,那么对于用户来说是不可见的,如果是debug版本可能会有Log打印出当时的底层现场。
发生原因:各种各样,需要具体情况具体分析。

4.4.系统服务崩溃(System Server Crash):

发生场景:系统服务是Android核心进程,此服务进程发生崩溃。

崩溃症状:手机重启到Android启动界面

发生原因:

  1)系统服务看门狗发现异常。

  2)系统服务发生未捕获异常。

  3OOM

  4)系统服务Native发生Tombstone

4.5.KernelPanics

发生场景:Linux内核发生严重错误

崩溃症状:手机从bootloader开始完全重启

发生原因:

  1Linux内核内存空间发生内存崩溃。

  2)内核看门狗发现异常。

  3)空指针操作内核。

五、常见Android常见崩溃捕获机制

  常见的Android崩溃有两类,一类是Java Exception异常,一类是Native Signal异常。

5.1Exception的分类及捕获

  Java的异常可以分为两类:Checked ExceptionUnChecked Exception。所有RuntimeException类及其子类的实例被称为Runtime异常,即UnChecked Exception,不是RuntimeException类及其子类的异常实例则被称为Checked Exception。

  Checked异常又称为编译时异常,即在编译阶段被处理的异常。编译器会强制程序处理所有的Checked异常,也就是用try…catch显式的捕获并处理,因为Java认为这类异常都是可以被处理(修复)的。在Java API文档中,方法说明时,都会添加是否throw某个exception,这个exception就是Checked异常。如果没有try…catch这个异常,则编译出错,错误提示类似于“Unhandled exception type xxxxx”。

  该类异常捕获的流程是:

  • 执行try块中的代码出现异常,系统会自动生成一个异常对象,并将该异常对象提交给Java运行环境,这个就是异常抛出(throw)阶段;
  • 当Java运行环境收到异常对象时,会寻找最近的能够处理该异常对象的catch块,找到之后把该异常对象交给catch块处理,这个就是异常捕获(catch)阶段。

  Checked异常一般是不引起Android App Crash的,注意是“一般”,这里之所以介绍,有两个原因:

  • 形成系统的了解,更好地对比理解UnCheckedException;
  • 对于一些Checked Exception,虽然我们在程序里面已经捕获并处理了,但是如果能同时将该异常收集并发送到后台,将有助于提升App的健壮性。比如修改代码逻辑回避该异常,或者捕获后采用更好的方法去处理该异常。至于应该收集哪些Checked Exception,则取决于App的业务逻辑和开发者的经验了。

  UnChecked异常又称为运行时异常,即Runtime-Exception,最常见的莫过于NullPointerException。UnChecked异常发生时,由于没有相应的try…catch处理该异常对象,所以Java运行环境将会终止,程序将退出,也就是我们所说的Crash。当然,你可能会说,那我们把这些异常也try…catch住不就行了。理论上确实是可以的,但有两点会导致这种方案不可行:

  •  无法将所有的代码都加上try…catch,这样对代码的效率和可读性将是毁灭性的;
  •  UnChecked异常通常都是较为严重的异常,或者说已经破坏了运行环境的。比如内存地址,即使我们try…catch住了,也不能明确知道如何处理该异常,才能保证程序接下来的运行是正确的。

  没有try…catch住的异常,即Uncaught异常,都会导致应用程序崩溃。那么面对崩溃,我们是否可以做些什么呢?比如程序退出前,弹出个性化对话框,而不是默认的强制关闭对话框,或者弹出一个提示框安慰一下用户,甚至重启应用程序等。

  其实Java提供了一个接口给我们,可以完成这些,这就是UncaughtExceptionHandler,该接口含有一个纯虚函数:public abstract void uncaughtException(Thread thread, Throwableex)。

  Uncaught异常发生时会终止线程,此时,系统便会通知UncaughtExceptionHandler,告诉它被终止的线程以及对应的异常,然后便会调用uncaughtException函数。如果该handler没有被显式设置,则会调用对应线程组的默认handler。如果我们要捕获该异常,必须实现我们自己的handler,并通过以下函数进行设置:

  public static voidsetDefaultUncaughtExceptionHandler(Thread.UncaughtExceptionHandler handler)

实现自定义的handler,只需要继承UncaughtExceptionHandler该接口,并实现uncaughtException方法即可。

  static class MyCrashHandler implementsUncaughtExceptionHandler{ 

    @Override 

    public voiduncaughtException(Thread thread, final Throwable throwable) { 

        // Deal thisexception

    }

}

  在任何线程中,都可以通过setDefaultUncaughtExceptionHandler来设置handler,但在Android应用程序中,全局的Application和Activity、Service都同属于UI主线程,线程名称默认为“main”。所以,在Application中应该为UI主线程添加UncaughtExceptionHandler,这样整个程序中的Activity、Service中出现的UncaughtException事件都可以被处理。

  如果多次调用setDefaultUncaughtExceptionHandler设置handler,以最后一次为准。这也就是为什么多个抓崩溃的SDK同时使用,总会有一些SDK工作不正常。某些情况下,用户会既想利用第三方SDK收集崩溃,又想根据崩溃类型做出业务相关的处理。此时有两种方案:

  •   SDK提供了一个接口,允许用户传递自己handler给SDK。当执行uncaughtException的时候,SDK只负责采集崩溃信息,之后便调用用户的handler来处理崩溃了。这儿其实类似于多了一层setDefaultUncaughtExceptionHandler,只是不能和标准库用同样的名称,因为会覆盖。
  •   用户先通过setDefaultUncaughtExceptionHandler设置自己的handler,然后SDK再次通过setDefaultUncaughtExceptionHandler设自handler前,先保存之前的handler,在SDK handler逻辑处理完成之后,再调用之前的handler处理该异常。

  static class MyCrashHandlerimplements UncaughtExceptionHandler {

  privateUncaughtExceptionHandler originalHandler;

  private MyCrashHandler(Contextcontext) { originalHandler = Thread.getDefaultUncaughtExceptionHandler(); }

   @Override

   public void uncaughtException(Thread thread,final Throwable throwable) {

  // Deal this exception

   if (originalHandler != null) { originalHandler.uncaughtException(thread,throwable);

  }

  }

  }

5.1.1获取Exception崩溃堆栈

  捕获Exception之后,我们还需要知道崩溃堆栈的信息,这样有助于我们分析崩溃的原因,查找代码的Bug。异常对象的printStackTrace方法用于打印异常的堆栈信息,根据printStackTrace方法的输出结果,我们可以找到异常的源头,并跟踪到异常一路触发的过程。

 

public static StringgetStackTraceInfo(final Throwable throwable) {

   String trace = "";

   try {

       Writer writer = new StringWriter();

       PrintWriter pw = new PrintWriter(writer);

       throwable.printStackTrace(pw);

       trace = writer.toString();

       pw.close();

   } catch (Exception e) {

       return "";

   }

   return trace;

}

 

5.2 Native代码的崩溃机制及实现

    Android平台除了使用Java语言开发以外,还提供了对C/C++的支持。对于一些高CPU消耗的应用程序,Java语言很难满足对性能的要求,这时就需要使用C/C++进行开发,比如游戏引擎、信号处理等。但是Native代码只能开发动态链接库(so),然后Java通过JNI来调用so库。

5.2.1Native崩溃分析与捕获

    C++也可以通过try…catch去处理一些异常,但如果出现了Uncaught异常,so库就会引起崩溃。此时肯定无法通过JavaUncaught-ExceptionHandler来处理,那么我们应该如何捕获Native代码的崩溃呢?熟悉Linux开发的人都知道,so库一般通过gcc/g++编译,崩溃时会产生信号异常。Android底层是Linux系统,所以so库崩溃时也会产生信号异常。那么如果我们能够捕获信号异常,就相当于捕获了AndroidNative崩溃。

    信号其实是一种软件层面的中断机制,当程序出现错误,比如除零、非法内存访问时,便会产生信号事件。那么进程如何获知并响应该事件呢?Linux的进程是由内核管理的,内核会接收信号,并将其放入到相应的进程信号队列里面。当进程由于系统调用、中断或异常而进入内核态以后,从内核态回到用户态之前会检测信号队列,并查找到相应的信号处理函数。内核会为进程分配默认的信号处理函数,如果你想要对某个信号进行特殊处理,则需要注册相应的信号处理函数(如图1所示)。

Android系统构架及Native Crash_第3张图片


图1 信号检测与处理流程(原图出自《Linux内核源代码情景分析》)

 

  进程对信号异常的响应可以归结为以下几类:

  • 忽略信号:对信号不做任何处理,除了SIGKILL及SIGSTOP以外(超级用户杀掉进程时产生),其他都可以忽略;
  • 捕获信号:注册信号处理函数,当信号发生时,执行相应的处理函数;
  • 默认处理:执行内核分配的默认信号处理函数,大多数我们遇到的信号异常,默认处理是终止程序并生成core文件。

    对Native代码的崩溃,可以通过调用sigaction()注册信号处理函数来完成。

  #include

  int sigaction(int signum,conststruct sigaction *act,struct sigaction *oldact));

 

  •  signum:代表信号编码,可以是除SIGKILLSIGSTOP外的任何一个特定有效的信号,如果为这两个信号定义自己的处理函数,将导致信号安装错误。
  • ·act:指向结构体sigaction的一个实例的指针,该实例指定了对特定信号的处理,如果设置为空,进程会执行默认处理。
  • ·    oldact:和参数act类似,只不过保存的是原来对相应信号的处理,也可设置为NULL

  sigaction函数用于改变进程接收到特定信号后的行为。如果把第二、第三个参数都设为NULL,那么该函数可用于检查信号的有效性。

  结构体sigaction包含了对特定信号的处理、信号所传递的信息、信号处理函数执行过程中应屏蔽掉哪些函数等等。

struct sigaction {

    void     (*sa_handler)(int);

    void     (*sa_sigaction)(int, siginfo_t *, void *);

    sigset_t   sa_mask;

    int        sa_flags;

    void     (*sa_restorer)(void);

}

 

  在一些体系上,sa_handler和sa_sigaction共用一个联合体(union),所以不要同时指定两个字段的值。

  •  sa_handler: 指定对signum信号的处理函数,可以是SIG_DFL默认行为,SIG_IGN忽略接送到的信号,或者一个信号处理函数指针。这个函数只有信号编码一个参数。
  • sa_sigaction: 当sa_flags中存在SA_SIGINFO标志时,sa_sigaction将作为signum信号的处理函数。
  •  sa_mask:指定信号处理函数执行的过程中应被阻塞的信号。
  •  sa_flags:指定一系列用于修改信号处理过程行为的标志,由0个或多个标志通过or运算组合而成,比如SA_RESETHAND,SA_ONSTACK | SA_SIGINFO。
  •  sa_restorer: 已经废弃,不再使用。

各参数的详细使用说明,请参考相关资料。

 

  基于上面的分析,下面给出Native代码崩溃(即信号异常)捕获的代码片段,让大家有一个更直观的认识。

const int handledSignals[] = {

    SIGSEGV, SIGABRT, SIGFPE, SIGILL, SIGBUS

};

const int handledSignalsNum =sizeof(handledSignals) / sizeof(handledSignals[0]);

struct sigactionold_handlers[handledSignalsNum];

 

intnativeCrashHandler_onLoad(JNIEnv *env) {

    struct sigaction handler;

    memset(&handler, 0, sizeof(sigaction));

    handler.sa_sigaction = my_sigaction;

    handler.sa_flags = SA_RESETHAND;

 

    for (int i = 0; i < handledSignalsNum;++i) {

        sigaction(handledSignals[i],&handler, &old_handlers[i]);

    }

 

    return 1;

}

 

    当Android应用程序加载so库的时候,调用nativeCrashHandler_onLoad会为SIGSEGV、SIGABRT、SIGFPE、SIGILL、SIGBUS通过sigaction注册信号处理函数my_sigaction。当发生Native崩溃并且发生前面几个信号异常时,就会调用my_sigaction完成信号处理。

notifyNativeCrash = (*env)->GetMethodID(env, cls, "notifyNativeCrash", "()V");

void my_sigaction(int signal, siginfo_t *info, void*reserved) {

    // Herecatch the native crash

}

5.2.1获取Native崩溃堆栈

    Android没有提供像throwable.printStackTrace一样的接口去获取Native崩溃后堆栈信息,所以我们需要自己想办法实现。这里有两种思路可以考虑。

  • 利用LogCat日志

    在本地调试代码时,我们经常通过查看LogCat日志来分析解决问题。对于发布的应用,在代码中执行命令“logcat -d -v threadtime”也能达到同样的效果,只不过是获取到了用户手机的logcat。当Native崩溃时,Android系统同样会输出崩溃堆栈到LogCat,那么拿到了LogCat信息也就拿到了Native的崩溃堆栈。

Processprocess = Runtime.getRuntime().exec(newString[]{"logcat","-d","-v","threadtime"});String logTxt = getSysLogInfo(process.getInputStream());

    my_sigaction捕获到异常信号后,通知Java层代码,在Java层启动新的进程,并在新的进程中完成上面的操作。这里注意一定要在新的进程中完成,因为原有的进程马上就会结束。

    网络上有一些对应这种思路的代码,但是在很多手机上都无法获得Native的崩溃堆栈。原因是对崩溃堆栈产生了破坏,使得相关信息并没有输出到logcat中。研究一下Android backtrace的底层实现以及Google Breakpad的源码,会帮助你解决这个问题。

  • Google Breakpad

    Linux提供了Core Dump机制,即操作系统会把程序崩溃时的内存内容dump出来,写入一个叫做core的文件里面。Google Breakpad作为跨平台的崩溃转储和分析模块(支持WindowsOS XLinuxiOSAndroid等),便是通过类似的MiniDump机制来获取崩溃堆栈的。

    通过Google Breakpad捕获信号异常,并将堆栈信息写入你指定的本地MiniDump文件中。下次启动应用程序的时候,便可以读取该MiniDump文件进行相应的操作,比如上传到后台服务器。当然,也可以修改Google Breakpad的源码,不写MiniDump文件,而是通过dumpCallback直接获得堆栈信息,并将相关信息通知到Java层代码,做相应的处理。

    Google Breakpad是权威的捕获Native崩溃的方法,相关的使用方法可以查看官网文档。由于它跨平台,代码体量较大,所以建议大家裁剪源码,只保留Android相关的功能,保持自己APK的小巧。

http://edu.csdn.net/course/detail/1862



你可能感兴趣的:(android)