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架构

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

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 Server是Zygote孵化的第一个进程，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）系统服务发生未捕获异常。

  （3）OOM。

  （4）系统服务Native发生Tombstone。

4.5.KernelPanics：

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

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

发生原因：

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

  （2）内核看门狗发现异常。

  （3）空指针操作内核。

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

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

5.1Exception的分类及捕获

  Java的异常可以分为两类：Checked Exception和UnChecked 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库就会引起崩溃。此时肯定无法通过Java的Uncaught-ExceptionHandler来处理，那么我们应该如何捕获Native代码的崩溃呢？熟悉Linux开发的人都知道，so库一般通过gcc/g++编译，崩溃时会产生信号异常。Android底层是Linux系统，所以so库崩溃时也会产生信号异常。那么如果我们能够捕获信号异常，就相当于捕获了AndroidNative崩溃。

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

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

 

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

• 忽略信号：对信号不做任何处理，除了SIGKILL及SIGSTOP以外（超级用户杀掉进程时产生），其他都可以忽略；

• 捕获信号：注册信号处理函数，当信号发生时，执行相应的处理函数；

• 默认处理：执行内核分配的默认信号处理函数，大多数我们遇到的信号异常，默认处理是终止程序并生成core文件。

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

  #include <signal.h>

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

 

•  signum：代表信号编码，可以是除SIGKILL及SIGSTOP外的任何一个特定有效的信号，如果为这两个信号定义自己的处理函数，将导致信号安装错误。
• ·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作为跨平台的崩溃转储和分析模块（支持Windows、OS X、Linux、iOS和Android等），便是通过类似的MiniDump机制来获取崩溃堆栈的。

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

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

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