在Android開發(fā)中自沧，程序Crash分三種情況：未捕獲的異常坟奥、ANR（Application Not Responding）和閃退（NDK引發(fā)錯(cuò)誤）。其中未捕獲的異常根據(jù)logcat打印的堆棧信息很容易定位錯(cuò)誤。ANR錯(cuò)誤也好查爱谁，Android規(guī)定晒喷，應(yīng)用與用戶進(jìn)行交互時(shí)，如果5秒內(nèi)沒有響應(yīng)用戶的操作访敌，則會(huì)引發(fā)ANR錯(cuò)誤凉敲，并彈出一個(gè)系統(tǒng)提示框，讓用戶選擇繼續(xù)等待或立即關(guān)閉程序寺旺。并會(huì)在/data/anr目錄下生成一個(gè)traces.txt文件爷抓，記錄系統(tǒng)產(chǎn)生anr異常的堆棧和線程信息。如果是閃退迅涮，這問題比較難查废赞，通常是項(xiàng)目中用到了NDK引發(fā)某類致命的錯(cuò)誤導(dǎo)致閃退。因?yàn)镹DK是使用C/C++來(lái)進(jìn)行開發(fā)叮姑，熟悉C/C++的程序員都知道唉地，指針和內(nèi)存管理是最重要也是最容易出問題的地方，稍有不慎就會(huì)遇到諸如內(nèi)存地址訪問錯(cuò)誤传透、使用野針對(duì)耘沼、內(nèi)存泄露、堆棧溢出朱盐、初始化錯(cuò)誤群嗤、類型轉(zhuǎn)換錯(cuò)誤、數(shù)字除0等常見的問題兵琳，導(dǎo)致最后都是同一個(gè)結(jié)果：程序崩潰狂秘。不會(huì)像在Java層產(chǎn)生的異常時(shí)彈出“xxx程序無(wú)響應(yīng)，是否立即關(guān)閉”之類的提示框躯肌。當(dāng)發(fā)生NDK錯(cuò)誤后者春，logcat打印出來(lái)的那堆日志根據(jù)看不懂，更別想從日志當(dāng)中定位錯(cuò)誤的根源清女，讓我時(shí)常有點(diǎn)抓狂钱烟，火冒三丈，喝多少加多寶都不管用嫡丙。當(dāng)時(shí)嘗試過(guò)在各個(gè)jni函數(shù)中打印日志來(lái)跟蹤問題拴袭，那效率實(shí)在是太低了，而且還定位不到問題曙博。還好老天有眼拥刻，讓我找到了NDK提供的幾款調(diào)試工具，能夠精確的定位到產(chǎn)生錯(cuò)誤的根源羊瘩。

   NDK安裝包中提供了三個(gè)調(diào)試工具：addr2line泰佳、objdump和ndk-stack盼砍，其中ndk-stack放在$NDK_HOME目錄下，與ndk-build同級(jí)目錄逝她。addr2line和objdump在ndk的交叉編譯器工具鏈目錄下浇坐，下面是我本機(jī)NDK交叉編譯器工具鏈的目錄結(jié)構(gòu)：

image.png

從上圖的目錄結(jié)構(gòu)中可以看出來(lái)，NDK針對(duì)不同的CPU架構(gòu)實(shí)現(xiàn)了多套相同的工具黔宛。所以在選擇addr2line和objdump工具的時(shí)候近刘，要根據(jù)你目標(biāo)機(jī)器的CPU架構(gòu)來(lái)選擇。如果是arm架構(gòu)臀晃，選擇arm-linux-androidabi-4.6/4.8（一般選擇高版本）觉渴。x86架構(gòu)，選擇x86-4.6/4.8徽惋。mipsel架構(gòu)案淋，選擇mipsel-linux-android-4.6/4.8。如果不知道目標(biāo)機(jī)器的CPU架構(gòu)险绘，把手機(jī)連上電腦踢京，用adb shell cat /proc/cpuinfo可以查看手機(jī)的CPU信息。下圖是我本機(jī)的arm架構(gòu)工具鏈目錄結(jié)構(gòu)：

image.png

下面通過(guò)NDK自帶的例子hello-jni項(xiàng)目來(lái)演示一下如何精確的定位錯(cuò)誤

    #include <string.h>
    #include <jni.h>
    // hell-jni.c
    #ifdef __cplusplus
    extern "C" {
    #endif
        void willCrash()
        {
            int i = 10;
            int y = i / 0;
        }
        JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM* vm, void* reserved)
        {
            willCrash();
            return JNI_VERSION_1_4;
        }
        jstring
        Java_com_example_hellojni_HelloJni_stringFromJNI( JNIEnv* env,
                                                          jobject thiz )
        {
        // 此處省略實(shí)現(xiàn)邏輯宦棺。瓣距。。
        }
    #ifdef __cplusplus
    }
    #endif

第7行定義了一個(gè)willCrash函數(shù)代咸，函數(shù)中有一個(gè)除0的非法操作蹈丸，會(huì)造成程序崩潰。第13行JNI_OnLoad函數(shù)中調(diào)用了willCrash呐芥，這個(gè)函數(shù)會(huì)在Java加載完.so文件之后回調(diào)逻杖，也就是說(shuō)程序一啟動(dòng)就會(huì)崩潰。下面是運(yùn)行程序后打印的log：

    01-01 17:59:38.246: D/dalvikvm(20794): Late-enabling CheckJNI
    01-01 17:59:38.246: I/ActivityManager(1185): 
    Start proc com.example.hellojni for activity com.example.hellojni/.HelloJni: pid=20794 uid=10351 gids={50351, 1028, 1015}
    01-01 17:59:38.296: I/dalvikvm(20794): Enabling JNI app bug workarounds for target SDK version 3...
    01-01 17:59:38.366: D/dalvikvm(20794): Trying to load lib /data/app-lib/com.example.hellojni-1/libhello-jni.so 0x422a4f58
    01-01 17:59:38.366: D/dalvikvm(20794): Added shared lib /data/app-lib/com.example.hellojni-1/libhello-jni.so 0x422a4f58
    01-01 17:59:38.366: A/libc(20794): Fatal signal 8 (SIGFPE) at 0x0000513a (code=-6), thread 20794 (xample.hellojni)
    01-01 17:59:38.476: I/DEBUG(253): pid: 20794, tid: 20794, name: xample.hellojni  >>> com.example.hellojni <<<
    01-01 17:59:38.476: I/DEBUG(253): signal 8 (SIGFPE), code -6 (SI_TKILL), fault addr 0000513a
    01-01 17:59:38.586: I/DEBUG(253):     r0 00000000  r1 0000513a  r2 00000008  r3 00000000
    01-01 17:59:38.586: I/DEBUG(253):     r4 00000008  r5 0000000d  r6 0000513a  r7 0000010c
    01-01 17:59:38.586: I/DEBUG(253):     r8 75226d08  r9 00000000  sl 417c5c38  fp bedbf134
    01-01 17:59:38.586: I/DEBUG(253):     ip 41705910  sp bedbf0f0  lr 4012e169  pc 4013d10c  cpsr 000f0010
                                                // 省略部份日志 思瘟。弧腥。。潮太。。虾攻。
    01-01 17:59:38.596: I/DEBUG(253): backtrace:
    01-01 17:59:38.596: I/DEBUG(253):     #00  pc 0002210c  /system/lib/libc.so (tgkill+12)
    01-01 17:59:38.596: I/DEBUG(253):     #01  pc 00013165  /system/lib/libc.so (pthread_kill+48)
    01-01 17:59:38.596: I/DEBUG(253):     #02  pc 00013379  /system/lib/libc.so (raise+10)
    01-01 17:59:38.596: I/DEBUG(253):     #03  pc 00000e80  /data/app-lib/com.example.hellojni-1/libhello-jni.so (__aeabi_idiv0+8)
    01-01 17:59:38.596: I/DEBUG(253):     #04  pc 00000cf4  /data/app-lib/com.example.hellojni-1/libhello-jni.so (willCrash+32)
    01-01 17:59:38.596: I/DEBUG(253):     #05  pc 00000d1c  /data/app-lib/com.example.hellojni-1/libhello-jni.so (JNI_OnLoad+20)
    01-01 17:59:38.596: I/DEBUG(253):     #06  pc 00052eb1  /system/lib/libdvm.so (dvmLoadNativeCode(char const*, Object*, char**)+468)
    01-01 17:59:38.596: I/DEBUG(253):     #07  pc 0006a62d  /system/lib/libdvm.so
    01-01 17:59:38.596: I/DEBUG(253):          // 省略部份日志 铡买。。霎箍。奇钞。。漂坏。
    01-01 17:59:38.596: I/DEBUG(253): stack:
    01-01 17:59:38.596: I/DEBUG(253):          bedbf0b0  71b17034  /system/lib/libsechook.so
    01-01 17:59:38.596: I/DEBUG(253):          bedbf0b4  7521ce28  
    01-01 17:59:38.596: I/DEBUG(253):          bedbf0b8  71b17030  /system/lib/libsechook.so
    01-01 17:59:38.596: I/DEBUG(253):          bedbf0bc  4012c3cf  /system/lib/libc.so (dlfree+50)
    01-01 17:59:38.596: I/DEBUG(253):          bedbf0c0  40165000  /system/lib/libc.so
    01-01 17:59:38.596: I/DEBUG(253):          // 省略部份日志 景埃。媒至。。谷徙。拒啰。。
    01-01 17:59:38.736: W/ActivityManager(1185):   Force finishing activity com.example.hellojni/.HelloJni

日志分析：
第3行開始啟動(dòng)應(yīng)用完慧，第5行嘗試加載應(yīng)用數(shù)據(jù)目錄下的so谋旦，第6行在加載so文件的時(shí)候產(chǎn)生了一個(gè)致命的錯(cuò)誤，第7行的Fatal signal 8提示這是一個(gè)致命的錯(cuò)誤屈尼，這個(gè)信號(hào)是由linux內(nèi)核發(fā)出來(lái)的册着，信號(hào)8的意思是浮點(diǎn)數(shù)運(yùn)算異常，應(yīng)該是在willCrash函數(shù)中做除0操作所產(chǎn)生的脾歧。下面重點(diǎn)看第15行backtrace的日志甲捏，backtrace日志可以看作是JNI調(diào)用的堆棧信息，以“#兩位數(shù)字 pc”開頭的都是backtrace日志鞭执。注意看第20行和21行司顿，是我們自己編譯的so文件和定義的兩個(gè)函數(shù)，在這里引發(fā)了異常蚕冬，導(dǎo)致程序崩潰免猾。

    01-01 17:59:38.596: I/DEBUG(253):     #04  pc 00000cf4  /data/app-lib/com.example.hellojni-1/libhello-jni.so (willCrash+32)
    01-01 17:59:38.596: I/DEBUG(253):     #05  pc 00000d1c  /data/app-lib/com.example.hellojni-1/libhello-jni.so (JNI_OnLoad+20)

開始有些眉目了，但具體崩在這兩個(gè)函數(shù)的哪個(gè)位置囤热，我們是不確定的猎提，如果函數(shù)代碼比較少還好查，如果比較復(fù)雜的話旁蔼，查起來(lái)也費(fèi)勁锨苏。這時(shí)候就需要靠NDK為我們提供的工具來(lái)精確定位了。在這之前棺聊，我們先記錄下讓程序崩潰的匯編指令地址伞租，willCrash：00000cf4，JNI_OnLoad：00000d1c

方式1：使用arm-linux-androideabi-addr2line 定位出錯(cuò)位置

以arm架構(gòu)的CPU為例限佩，執(zhí)行如下命令：

    /Users/yangxin/Documents/devToos/java/android-ndk-r9d/toolchains/arm-linux-androideabi-4.8/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-addr2line -e /Users/yangxin/Documents/devToos/java/android-ndk-r9d/samples/hello-jni/obj/local/armeabi-v7a/libhello-jni.so 00000cf4 00000d1c

是不是驚喜的看到我們想要的結(jié)果了葵诈，分別在hello-jni.c的10和15行的出的錯(cuò)，再回去看看hello-jni.c的源碼祟同，15行的Jni_OnLoad函內(nèi)調(diào)用了willCrash函數(shù)作喘，第10行做了除0的操作引發(fā)的crash。

方式2：使用arm-linux-androideabi-objdump 定位出錯(cuò)的函數(shù)信息

在第一種方式中晕城，通過(guò)addr2lin已經(jīng)獲取到了代碼出錯(cuò)的位置泞坦，但是不知道函數(shù)的上下文信息，顯得有點(diǎn)不是那么的“完美”，對(duì)于追求極致的我來(lái)說(shuō)抵怎，這顯然是不夠的，下面我們來(lái)看一下怎么來(lái)定位函數(shù)的信息墩虹。
首先使用如下命令導(dǎo)出so的函數(shù)表信息：

    /Users/yangxin/Documents/devToos/java/android-ndk-r9d/toolchains/arm-linux-androideabi-4.8/prebuilt/darwin-x86_64/bin/arm-linux-androideabi-objdump -S -D /Users/yangxin/Documents/devToos/java/android-ndk-r9d/samples/hello-jni/obj/local/armeabi-v7a/libhello-jni.so > Users/yangxin/Desktop/dump.log

在生成的asm文件中豌熄，找出我們開始定位到的那兩個(gè)出錯(cuò)的匯編指令地址（在文件中搜索cf4或willCrash可以找到）授嘀，如下圖所示：

image.png

通過(guò)這種方式，也可以查出這兩個(gè)出錯(cuò)的指針地址分別位于哪個(gè)函數(shù)中房轿。

方式3：ndk-stack

如果你覺得上面的方法太麻煩的話粤攒，ndk-stack可以幫你減輕操作步聚，直接定位到代碼出錯(cuò)的位置囱持。

實(shí)時(shí)分析日志：

使用adb獲取logcat的日志夯接，并通過(guò)管道輸出給ndk-stack分析，并指定包含符號(hào)表的so文件位置纷妆。如果程序包含多種CPU架構(gòu)盔几，需要根據(jù)手機(jī)的CPU類型，來(lái)選擇不同的CPU架構(gòu)目錄掩幢。以armv7架構(gòu)為例逊拍，執(zhí)行如下命令：

    adb logcat | ndk-stack -sym /Users/yangxin/Documents/devToos/java/android-ndk-r9d/samples/hello-jni/obj/local/armeabi-v7a

當(dāng)程序發(fā)生crash時(shí)，會(huì)輸出如下信息：

    pid: 22654, tid: 22654, name: xample.hellojni  >>> com.example.hellojni <<<
    signal 8 (SIGFPE), code -6 (SI_TKILL), fault addr 0000587e
    Stack frame #00  pc 0002210c  /system/lib/libc.so (tgkill+12)
    Stack frame #01  pc 00013165  /system/lib/libc.so (pthread_kill+48)
    Stack frame #02  pc 00013379  /system/lib/libc.so (raise+10)
    Stack frame #03  pc 00000e80  /data/app-lib/com.example.hellojni-1/libhello-jni.so (__aeabi_idiv0+8): Routine __aeabi_idiv0 at /s/ndk-toolchain/src/build/../gcc/gcc-4.6/libgcc/../gcc/config/arm/lib1funcs.asm:1270
    Stack frame #04  pc 00000cf4  /data/app-lib/com.example.hellojni-1/libhello-jni.so (willCrash+32): Routine willCrash at /Users/yangxin/Documents/devToos/java/android-ndk-r9d/samples/hello-jni/jni/hello-jni.c:10
    Stack frame #05  pc 00000d1c  /data/app-lib/com.example.hellojni-1/libhello-jni.so (JNI_OnLoad+20): Routine JNI_OnLoad at /Users/yangxin/Documents/devToos/java/android-ndk-r9d/samples/hello-jni/jni/hello-jni.c:15
    Stack frame #06  pc 00052eb1  /system/lib/libdvm.so (dvmLoadNativeCode(char const*, Object*, char**)+468)
    Stack frame #07  pc 0006a62d  /system/lib/libdvm.so

第7行和第8行分別打印出了在源文件中出錯(cuò)的位置际邻，和addr2line得到的結(jié)果一樣芯丧。

先獲取日志再分析：

這種方式和上面的方法差不多，只是獲取log的來(lái)源不一樣世曾。適用于應(yīng)用或游戲給測(cè)試部們測(cè)試的時(shí)候缨恒，測(cè)試人員發(fā)現(xiàn)crash，用adb logcat保存日志文件轮听，然后發(fā)給程序員通過(guò)ndk-stack命令分析骗露。操作流程如下：

adb logcat > crash.log
ndk-stack -sym       /Users/yangxin/Documents/devToos/java/android-ndk-r9d/samples/hello-jni/obj/local/armeabi-v7a -dump crash.log

得到的結(jié)果和上面的方式是一樣的