那接下來我們來看一下breakpad的整合吧。本例採用eclipse工程的方式，為啥不用Android Studio？因為breakpad給android提供的編譯方式就是使用mk檔案來編譯的，而且個人感覺用eclipse來做NDK開發更方便。

先看一下jni目錄的結構

google-breakpad-master中有提供一個android的例子，先不管那麼多，直接進入到例子的目錄，ndk-build一下再說，什麼？編譯不過，怎麼可能，google一下為什麼，好吧，真的是編譯不過，為什麼，因為谷歌的工程師在寫breakpad的mk檔案得時候居然漏了一些東西，好吧，我們都給補上。修改google-breakpad-master/android/google-breakpad/Android.mk，把LOCAL_SRC_FILES修改為

LOCAL_SRC_FILES := \
    src/client/linux/crash_generation/crash_generation_client.cc \
    src/client/linux/handler/exception_handler.cc \
    src/client/linux/handler/minidump_descriptor.cc \
    src/client/linux/log/log.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/linux/microdump_writer/microdump_writer.cc \
    src/client/linux/dump_writer_common/ucontext_reader.cc \
    src/client/linux/dump_writer_common/seccomp_unwinder.cc \
    src/client/linux/dump_writer_common/thread_info.cc \
    src/client/minidump_file_writer.cc \
    src/common/android/breakpad_getcontext.S \
    src/common/convert_UTF.c \
    src/common/md5.cc \
    src/common/string_conversion.cc \
    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

APP_STL := stlport_static
APP_ABI := armeabi

Android.mk

LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)

LOCAL_MODULE    := ErrorReport
LOCAL_SRC_FILES := ErrorReport.cpp
LOCAL_STATIC_LIBRARIES += breakpad_client
LOCAL_LDLIBS := -L$(SYSROOT)/usr/lib -llog
LOCAL_STATIC_LIBRARIES += libgcc

include $(BUILD_SHARED_LIBRARY)

ifneq ($(NDK_MODULE_PATH),)
  $(call import-module,google_breakpad)
else
  include $(LOCAL_PATH)/google-breakpad-master/android/google_breakpad/Android.mk
endif

ErrorReport.cpp

#include <jni.h>
#include <stdio.h>
#include <android/log.h>

#include "google-breakpad-master/src/client/linux/handler/exception_handler.h"
#include "google-breakpad-master/src/client/linux/handler/minidump_descriptor.h"

#define LOGD(...) __android_log_print(ANDROID_LOG_DEBUG, "ErrorReport", __VA_ARGS__)

extern "C" {
	JNIEXPORT jint JNICALL Java_com_openflight_errorreport_CrashHandler_nativeCrash(
			JNIEnv* env, jobject thiz);
	JNIEXPORT jint JNICALL Java_com_openflight_errorreport_CrashHandler_setNativeCrashDir(
			JNIEnv* env, jobject thiz, jstring path);
}

static google_breakpad::ExceptionHandler *handler = NULL;
bool DumpCallback(const google_breakpad::MinidumpDescriptor& descriptor,
                  void* context,
                  bool succeeded) {
	LOGD("Dump path: %s", descriptor.path());
	return succeeded;
}

void crash(){
	volatile int* a = reinterpret_cast<volatile int*>(NULL);
	*a = 1;
}

JNIEXPORT jint Java_com_openflight_errorreport_CrashHandler_nativeCrash(
			JNIEnv* env, jobject thiz){
	crash();
}

// 設定dmp檔案儲存路徑
JNIEXPORT jint JNICALL Java_com_openflight_errorreport_CrashHandler_setNativeCrashDir(
		JNIEnv* env, jobject thiz, jstring path){
	const char *filePath = env->GetStringUTFChars(path, 0);
	google_breakpad::MinidumpDescriptor descriptor(filePath);
	handler = new google_breakpad::ExceptionHandler(descriptor, NULL, DumpCallback, NULL, true, -1);
}

其中有幾個需要注意的地方，大家可能看到Android.mk中加了一句LOCAL_STATIC_LIBRARIES += libgcc，這一句在例子中是沒有的，為啥呢，因為本人手上兩臺手機，N5以及Note2，如果如加這一句的話Note2一執行就崩潰。還有一點，為啥要用static google_breakpad::ExceptionHandler *handler呢，例子裡面是直接在main函式裡面宣告並初始化的，好吧，我最開始也是這麼認為的，直接放在Jni_OnLoad裡面，結果dmp檔案無法生成。那為什麼例子中可以正常生成呢？好吧，因為例子中crash是在main函式裡面的，handler的作用域是整個main函式，所以他可以生成。如果你把這段程式碼放到Jni_OnLoad中，那麼他的作用域也是Jni_OnLoad，Jni_OnLoad返回之後就沒有效果了，這顯然不是我們想要的，我們希望它的作用域跟APP的生命週期是一樣的，所以把他定義為static。

工作都做完了，拿臺手機來跑吧，呼叫crash方法會崩潰，崩潰之後我們可以看到在我們設定的目錄下面已經有一個dmp檔案生成了，那dmp檔案這麼解析呢？windows實在是太不方便了， 下面還是給出ubuntu系統的解析方法吧。

1、下載google-breakpad原始碼，編譯linux版本，找到以下兩個檔案

google-breakpad-read-only/src/tools/linux/dump_syms/dump_syms
google-breakpad-read-only/src/processor/minidump_stackwalk

2、任意位置建立一個資料夾，資料夾中包含dump_syms、minidump_stackwalk、*.dmp、所有的動態庫檔案（多個動態庫需要重複3、4步驟）

3、執行命令./dump_syms libXXX.so > libXXX.so.sym

4、建立資料夾 symbols/libgame.so/6D7D7B4FAAE9D2686CF45FA12A9E3AD30，並將生成的libXXX.so.sym拷貝到該資料夾中，6D7D7B4FAAE9D2686CF45FA12A9E3AD30為生成的libXXX.so.sym的第一行的內容

5、執行命令./minidump_stackwalk XXXXXXXXXXX.dmp symbols/ > result.txt

好了，大功告成，我們來看一下解析出來的result.txt裡面崩潰的堆疊

Thread 0 (crashed)
 0  libErrorReport.so!_Z5crashv + 0x3
     r0 = 0x41803818    r1 = 0x59600019    r2 = 0x00000001    r3 = 0x00000000
     r4 = 0x00000000    r5 = 0x57ac67b8    r6 = 0x00000000    r7 = 0x57765dac
     r8 = 0xbea0a510    r9 = 0x57765da4   r10 = 0x57765da0   r12 = 0x5e0b6555
     fp = 0xbea0a524    sp = 0xbea0a508    lr = 0x5e0b655b    pc = 0x5e0b6550
    Found by: given as instruction pointer in context

這是什麼鬼，_Z5crashv是什麼東西？應該是armv5架構的CPU，crash函式中崩潰，而且該函式的返回值是void，就這些資訊，如果NDK程式碼多的話， 還是很難定位到崩潰的地方 ，意義不是很大吶，好吧，這個是從libs中取出來的so庫，那麼我們試試obj中取出來的so去解析結果是怎麼樣的。

Thread 0 (crashed)
 0  libErrorReport.so!crash [ErrorReport.cpp : 27 + 0x4]
     r0 = 0x41803818    r1 = 0x59600019    r2 = 0x00000001    r3 = 0x00000000
     r4 = 0x00000000    r5 = 0x57ac67b8    r6 = 0x00000000    r7 = 0x57765dac
     r8 = 0xbea0a510    r9 = 0x57765da4   r10 = 0x57765da0   r12 = 0x5e0b6555
     fp = 0xbea0a524    sp = 0xbea0a508    lr = 0x5e0b655b    pc = 0x5e0b6550
    Found by: given as instruction pointer in context
 1  libErrorReport.so!Java_com_openflight_errorreport_CrashHandler_nativeCrash [ErrorReport.cpp : 32 + 0x3]
     r4 = 0x00000000    r5 = 0x57ac67b8    r6 = 0x00000000    r7 = 0x57765dac
     r8 = 0xbea0a510    r9 = 0x57765da4   r10 = 0x57765da0    fp = 0xbea0a524
     sp = 0xbea0a508    pc = 0x5e0b655b
    Found by: call frame info

哇，這個結果就比較完美了，c++中崩潰的堆疊都有了，哪個檔案哪一行都有，但是呢，跟bugly比起來還是差了一些，因為bugly中可以看到java層呼叫的堆疊。結果是比較完美了，可是可是可是，操作還是麻煩了一點，如果我的應用有很多個動態庫的話，那解析一個dmp檔案就要好久了，很不幸，我曾經開發的應用裡面包含了將近10個庫，天啊，這就算再熟練解析一個檔案也要好幾分鐘啊，而且中途還不能出錯，殺了我吧，我不幹了。我的理念是，凡是重複的工作都讓電腦去做，指令碼是個很好的東西，下面就把shell指令碼放出來吧

#!/bin/bash

#[usage]
#將本指令碼、dump_sys、minidump_stackwalk放在同級目錄下，並建立libs資料夾，所有動態庫放到libs資料夾內
#./dump2txt.sh [dmp檔案路徑] [生成的txt檔案路徑]

LIBRARY_DIRECTORY="libs"
LIBRARY_EXTENDNAME=".sym"
LIBRARY_KEYPOS=3

Check()
{
	if [ $# -ne 2 ];then
		echo please input two param,the first param is the dmp file path,the second param is txt file path
		exit
	fi

	if [ ! -f "$1" ]; then
		echo $1 is not exsit
		exit
	fi
}

DealLibrary()
{
	if [ ! -f "$LIBRARY_DIRECTORY/$1" ]; then
		echo $LIBRARY_DIRECTORY/$1 is not exsit
		return
	fi

	SYM_NAME=$1$LIBRARY_EXTENDNAME
	./dump_syms libs/$1 > $SYM_NAME
	
	cat $SYM_NAME | while read line
	do
		LIBRARY_CODE=$line
		ARR=($LIBRARY_CODE)
		LIBRARY_CODE="${ARR[$LIBRARY_KEYPOS]}"
		mkdir -p symbols/$1/$LIBRARY_CODE
		mv $SYM_NAME symbols/$1/$LIBRARY_CODE
		break
	done
}

Main()
{
	#檢查引數 $1:dmp檔案路徑;$2:生成的txt檔案的路徑
	Check $1 $2
	echo "start convert "$1" to "$2"...."

	#建立解析dmp檔案相關的目錄以及檔案
	rm -rf symbols
	for file in $LIBRARY_DIRECTORY/*
	do
		DealLibrary ${file:5}
	done

	#生成txt檔案
	./minidump_stackwalk $1 symbols/ > $2
	echo $2 is generated!!!!
}
Main $1 $2

好了，寫到這裡本文也就接近尾聲了，什麼？不知道怎麼用shell指令碼？好吧，好人做到底，送佛送到西。新建檔案xxx.sh，雙擊開啟，將指令碼內容複製進去，控制檯執行命令chmod a+x xxx.sh，然後照著腳本里面註釋的內容做吧，Good Luck！沒有Ubuntu系統怎麼辦？我是裝了個虛擬機器跑Ubuntu系統，如果你是做NDK開發的，建議你也這麼做，比Windows方便太多了，那如果你不想裝，那就用你的手機試試吧，你的手機也是linux系統的，shell指令碼也是可以跑，但是本文中提出的dump_sys和minidump_stackwalk兩個檔案就得編譯arm版本的了，這個由於我沒有需求，有這個需求的人可以研究一下。

------End------