監控Java層和JNI Native層Crash，分析.so庫報錯的堆疊資訊

監控Java層和JNI Native層Crash，分析.so庫報錯的堆疊資訊

Crash（應用崩潰）是由于代碼例外而導致 App 非正常退出，導致應用程式無法繼續使用，所有作業都停止的現象，發生 Crash 后需要重新啟動應用（有些情況會自動重啟），而且不管應用在開發階段做得多么優秀，也無法避免 Crash 發生，特別是在Android 系統中，系統碎片化嚴重、各 ROM 之間的差異，甚至系統Bug，都可能會導致Crash的發生，在 Android 應用中發生的 Crash 有兩種型別，Java 層的 Crash 和 Native 層 Crash，這兩種Crash 的監控和獲取堆疊資訊有所不同，

1、Java Crash

Java的Crash監控非常簡單，Java中的Thread定義了一個介面： UncaughtExceptionHandler ；用于處理未捕獲的例外導致執行緒的終止（注意：catch了的是捕獲不到的），當我們的應用crash的時候，就會走UncaughtExceptionHandler.uncaughtException ，在該方法中可以獲取到例外的資訊，我們通過Thread.setDefaultUncaughtExceptionHandler 該方法來設定執行緒的默認例外處理器，我們可以將例外資訊保存到本地或者是上傳到服務器，方便我們快速的定位問題，

public class JavaCrashHandler implements Thread.UncaughtExceptionHandler {

    private static final String FILE_NAME_SUFFIX = ".log";
    private static Thread.UncaughtExceptionHandler mDefaultCrashHandler;
    private static Context mContext;

    private JavaCrashHandler() {
    }

    public static void init(@NonNull Context context) {
        // 默認為：RuntimeInit#KillApplicationHandler
        mDefaultCrashHandler = Thread.getDefaultUncaughtExceptionHandler();
        mContext = context.getApplicationContext();
        Thread.setDefaultUncaughtExceptionHandler(new JavaCrashHandler());
    }

    @Override
    public void uncaughtException(@NonNull Thread thread, @NonNull Throwable throwable) {
        try {
            // 自行處理：保存本地
            File file = dealException(thread, throwable);
            // 上傳服務器
            // ......
        } catch (Exception e1) {
            e1.printStackTrace();
        } finally {
            // 交給系統默認程式處理
            if (mDefaultCrashHandler != null) {
                mDefaultCrashHandler.uncaughtException(thread, throwable);
            }
        }
    }

    private File dealException(Thread thread, Throwable throwable) {
        String time = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss").format(new Date());
        File crashFolder = new File(mContext.getExternalCacheDir().getAbsoluteFile(), CrashMonitor.DEFAULT_JAVA_CRASH_FOLDER_NAME);
        if (!crashFolder.exists()) {
            crashFolder.mkdirs();
        }
        File crashFile = new File(crashFolder, time + FILE_NAME_SUFFIX);
        try {
            // 往檔案中寫入資料
            PrintWriter pw = new PrintWriter(new BufferedWriter(new FileWriter(crashFile)));
            pw.println(time);
            pw.println(thread);
            pw.println(getPhoneInfo());
            throwable.printStackTrace(pw);
            // 寫入crash堆疊
            pw.close();
        } catch (IOException ex) {
            ex.printStackTrace();
        }
        return crashFile;
    }

    private String getPhoneInfo() {
        PackageManager pm = mContext.getPackageManager();
        PackageInfo pi = null;
        StringBuilder sb = new StringBuilder();

        try {
            pi = pm.getPackageInfo(mContext.getPackageName(), PackageManager.GET_ACTIVITIES);

            // App版本
            sb.append("App Version: ");
            sb.append(pi.versionName);
            sb.append("_");
            sb.append(pi.versionCode + "\n");
        } catch (PackageManager.NameNotFoundException e) {
            e.printStackTrace();
        }

        // Android版本號
        sb.append("OS Version: ");
        sb.append(Build.VERSION.RELEASE);
        sb.append("_");
        sb.append(Build.VERSION.SDK_INT + "\n");

        // 手機制造商
        sb.append("Vendor: ");
        sb.append(Build.MANUFACTURER + "\n");

        // 手機型號
        sb.append("Model: ");
        sb.append(Build.MODEL + "\n");

        // CPU架構
        sb.append("CPU: ");
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) {
            sb.append(Arrays.toString(Build.SUPPORTED_ABIS));
        } else {
            sb.append(Build.CPU_ABI);
        }

        return sb.toString();
    }
}

2、NDK Crash (Native、JNI)

相對于Java的Crash，NDK的錯誤無疑更加讓人頭疼，特別是對初學NDK的同學，不說監控，就算是錯誤堆疊都不知道怎么看，

2.1、Linux信號機制

信號機制是Linux行程間通信的一種重要方式，Linux信號一方面用于正常的行程間通信和同步，另一方面它還負責監控系統例外及中斷，當應用程式運行例外時，Linux內核將產生錯誤信號并通知當前行程，當前行程在接收到該錯誤信號后，可以有三種不同的處理方式，

• 忽略該信號；
• 捕捉該信號并執行對應的信號處理函式（信號處理程式）；
• 執行該信號的預設操作（如終止行程）；

當Linux應用程式在執行時發生嚴重錯誤，一般會導致程式崩潰，其中，Linux專門提供了一類crash信號，在程式接收到此類信號時，預設操作是將崩潰的現場資訊記錄到核心檔案，然后終止行程，
常見崩潰信號串列：

一般的出現崩潰信號，Android系統默認預設操作是直接退出我們的程式，但是系統允許我們給某一個行程的某一個特定信號注冊一個相應的處理函式（signal），即對該信號的默認處理動作進行修改，因此NDK Crash的監控可以采用這種信號機制，捕獲崩潰信號執行我們自己的信號處理函式從而捕獲NDK Crash，

2.2、墓碑檔案(tombstones)

Android本機程式本質上就是一個Linux程式，當它在執行時發生嚴重錯誤，也會導致程式崩潰，然后產生一個記錄崩潰的現場資訊的檔案，而這個檔案在Android系統中就是 tombstones 墓碑檔案，

此處了解即可，普通應用無權限讀取墓碑檔案，墓碑檔案位于路徑/data/tombstones/下，決議墓碑檔案與后面的breakpad都可使用 addr2line 工具，

2.3、BreakPad

Google breakpad是一個跨平臺的崩潰轉儲和分析框架和工具集合，其開源地址是：https://github.com/google/breakpad，breakpad在Linux中的實作就是借助了Linux信號捕獲機制實作的，因為其實作為C++，因此在Android中使用，必須借助NDK工具，

2.4、Native Crash監控

將Breakpad原始碼下載解壓，首先查看README.ANDROID檔案，

按照檔案中的介紹，如果我們使用Android.mk 非常簡單就能夠引入到我們工程中，但是目前NDK默認的構建工具為：CMake，因此我們做一次移植，查看android/google_breakpad/Android.mk

include $(CLEAR_VARS)

# 最后編譯出 libbreakpad_client.a
LOCAL_MODULE := breakpad_client

# 指定c++源檔案后綴名
LOCAL_CPP_EXTENSION := .cc

# 強制構建系統以 32 位 arm 模式生成模塊的物件檔案
LOCAL_ARM_MODE := arm

# 需要編譯的原始碼
LOCAL_SRC_FILES := \
    src/client/linux/crash_generation/crash_generation_client.cc \
    src/client/linux/dump_writer_common/thread_info.cc \
    src/client/linux/dump_writer_common/ucontext_reader.cc \
    src/client/linux/handler/exception_handler.cc \
    src/client/linux/handler/minidump_descriptor.cc \
    src/client/linux/log/log.cc \
    src/client/linux/microdump_writer/microdump_writer.cc \
    src/client/linux/minidump_writer/linux_dumper.cc \
    src/client/linux/minidump_writer/linux_ptrace_dumper.cc \
    src/client/linux/minidump_writer/minidump_writer.cc \
    src/client/minidump_file_writer.cc \
    src/common/convert_UTF.cc \
    src/common/md5.cc \
    src/common/string_conversion.cc \
    src/common/linux/breakpad_getcontext.S \
    src/common/linux/elfutils.cc \
    src/common/linux/file_id.cc \
    src/common/linux/guid_creator.cc \
    src/common/linux/linux_libc_support.cc \
    src/common/linux/memory_mapped_file.cc \
    src/common/linux/safe_readlink.cc

# 匯入頭檔案
LOCAL_C_INCLUDES        := $(LOCAL_PATH)/src/common/android/include \
                           $(LOCAL_PATH)/src \
                           $(LSS_PATH) # 注意這個目錄

# 匯出頭檔案
LOCAL_EXPORT_C_INCLUDES := $(LOCAL_C_INCLUDES)

# 使用android ndk中的日志庫log
LOCAL_EXPORT_LDLIBS     := -llog

# 編譯static靜態庫-》類似java的jar包
include $(BUILD_STATIC_LIBRARY)

注意：mk檔案中 LOCAL_C_INCLUDES 的 LSS_PATH 是個坑

對照Android.mk檔案，我們在自己專案的cpp(工程中C/C++原始碼)目錄下創建breakpad目錄，并將下載的breakpad原始碼根目錄下的src目錄全部復制到我們的專案中：

接下來在breakpad目錄下創建CMakeLists.txt檔案:

cmake_minimum_required(VERSION 3.4.1)

#引入breakpad的頭檔案（api的定義）
include_directories(breakpad/src breakpad/src/common/android/include)

#引入breakpad的cmakelist，執行并生成libbreakpad.a (api的實作，類似java的jar包)
add_subdirectory(breakpad)

add_library(crash_monitor SHARED native_crash_monitor.cpp)

target_link_libraries(crash_monitor
        breakpad #引入breakpad的庫檔案(api的實作)
        log)

在cpp目錄下（breakpad同級）還有一個CMakeList.txt檔案，它的內容是：

cmake_minimum_required(VERSION 3.4.1)

#引入breakpad的頭檔案（api的定義）
include_directories(breakpad/src breakpad/src/common/android/include)

#引入breakpad的cmakelist，執行并生成libbreakpad.a (api的實作，類似java的jar包)
add_subdirectory(breakpad)

add_library(crash_monitor SHARED native_crash_monitor.cpp)

target_link_libraries(crash_monitor
        breakpad #引入breakpad的庫檔案(api的實作)
        log)

此時執行編譯，會在 #include “third_party/lss/linux_syscall_support.h” 報錯，無法找到頭檔案，此檔案從：https://chromium.googlesource.com/external/linux-syscall-support/+/refs/heads/master 下載（需要翻墻）放到工程對應目錄即可，

native_crash_monitor.cpp 源檔案中的實作為：

#include <jni.h>
#include <android/log.h>
#include <client/linux/handler/minidump_descriptor.h>
#include <client/linux/handler/exception_handler.h>

extern "C"
JNIEXPORT void JNICALL
Java_com_aaa_crashmonitor_CrashMonitor_testNativeCrash(JNIEnv *env, jclass clazz) {
    __android_log_print(ANDROID_LOG_ERROR, "testNativeCrash", "往指向空地址的指標里存值");
    int *p = NULL;
    *p = 10;
}

bool
DumpCallback(const google_breakpad::MinidumpDescriptor &descriptor, void *context, bool succeeded) {
    __android_log_print(ANDROID_LOG_ERROR, "ndk_crash", "Dump path: %s", descriptor.path());
    // 如果回呼回傳true，Breakpad將把例外視為已完全處理，禁止任何其他處理程式收到例外通知，
    // 如果回呼回傳false，Breakpad會將例外視為未處理，并允許其他處理程式處理它，
    return false;
}

extern "C"
JNIEXPORT void JNICALL
Java_com_aaa_crashmonitor_CrashMonitor_initNativeCrashMonitor(JNIEnv *env, jclass clazz,
                                                              jstring path_) {
    const char *path = env->GetStringUTFChars(path_, 0);
    __android_log_print(ANDROID_LOG_DEBUG, "initNativeCrashMonitor", "crash堆疊保存路徑=%s ", path);
    // 開啟crash監控
    google_breakpad::MinidumpDescriptor descriptor(path);
    static google_breakpad::ExceptionHandler eh(descriptor, NULL, DumpCallback, NULL, true, -1);
    __android_log_print(ANDROID_LOG_DEBUG, "initNativeCrashMonitor", "breakpad已開啟");
    env->ReleaseStringUTFChars(path_, path);
}

注意JNI方法的方法名對應了java類，創建Java源檔案：

public class CrashMonitor {

    public static final String DEFAULT_JAVA_CRASH_FOLDER_NAME = "java_crash";
    public static final String DEFAULT_NATIVE_CRASH_FOLDER_NAME = "native_crash";

    static {
        System.loadLibrary("crash_monitor");
    }

    public static void initAll(Context context) {
        initJavaCrashMonitor(context);
        initNativeCrashMonitor(context);
    }

    public static void initJavaCrashMonitor(Context context) {
        JavaCrashHandler.init(context.getApplicationContext());
    }

    public static void initNativeCrashMonitor(Context context) {
        Context appContext = context.getApplicationContext();
        File crashFile = new File(appContext.getExternalCacheDir(), DEFAULT_NATIVE_CRASH_FOLDER_NAME);
        if (!crashFile.exists()) {
            crashFile.mkdirs();
        }
        initNativeCrashMonitor(crashFile.getAbsolutePath());
    }

    public static native void initNativeCrashMonitor(String path);

    public static native void testNativeCrash();

    public static void testJavaCrash() {
        int a = 1 / 0;
    }
}

此時，如果出現NDK Crash，會在我們指定的目錄：/sdcard/Android/data/com.aaa.crashmonitor/cache/native_crash 下生成NDK Crash資訊檔案，

2.5、Native Crash分析

采集到的Crash資訊記錄在minidump檔案中，minidump是由微軟開發的用于崩潰上傳的檔案格式，我們可以將此檔案上傳到服務器完成上報，但是此檔案沒有可讀性可言，要將檔案決議為可讀的崩潰堆疊需要按照breakpad檔案編譯 minidump_stackwalk 工具，而Windows系統編譯個人不會，不過好在，無論你是 Mac、windows還是ubuntu在 Android Studio 的安裝目錄下的 bin\lldb\bin 里面就存在一個對應平臺的 minidump_stackwalk ，

使用這里的工具執行：

minidump_stackwalk xxxx.dump > native_crash.txt

打開 native_crash.txt 內容為：

Operating system: Android
                  0.0.0 Linux 4.14.112+ #1 SMP PREEMPT Fri Sep 13 21:20:42 UTC 2019 i686
CPU: x86 // abi型別
     GenuineIntel family 6 model 31 stepping 1
     4 CPUs

GPU: UNKNOWN

Crash reason:  SIGSEGV // 記憶體參考無效信號
Crash address: 0x0
Process uptime: not available

Thread 0 (crashed) // crashed：出現crash的執行緒
 0  libcrash_monitor.so + 0x1e944 // crash的so與暫存器資訊
    eip = 0xc7b26944   esp = 0xffbfdaf0   ebp = 0xffbfdb28   ebx = 0xc7ba04b8
    esi = 0xc7b8123c   edi = 0xc7b8124c   eax = 0x00000036   ecx = 0x00000000
    edx = 0x00000004   efl = 0x00010246
    Found by: given as instruction pointer in context
 1  libart.so + 0x144f68
    eip = 0xed51af68   esp = 0xffbfdb30   ebp = 0xffbfdb50
    Found by: previous frame's frame pointer

接下來使用 Android NDK 里面提供的 addr2line 工具將暫存器地址轉換為對應符號，addr2line 要用和自己 so 的 ABI 匹配的目錄，同時需要使用有符號資訊的so(一般debug的就有)，

因為我使用的是模擬器x86架構，因此addr2line位于：Android\Sdk\ndk\20.0.5594570\toolchains\x86-4.9\prebuilt\windows-x86_64\bin\i686-linux-android-addr2line.exe

i686-linux-android-addr2line.exe -f -C -e libcrash_monitor.so 0x1e934