編譯帶符號表的so

① 如何定位android NDK開發中遇到的錯誤

Android NDK是什麼，為什麼我們要用NDK？
Android NDK 是在SDK前面又加上了「原生」二字，即Native Development Kit，因此又被Google稱為「NDK」。眾所周知，Android程序運行在Dalvik虛擬機中，NDK允許用戶使用類似C / C++之類的原生代碼語言執行部分程序。NDK包括了：

從C / C++生成原生代碼庫所需要的工具和build files。
將一致的原生庫嵌入可以在Android設備上部署的應用程序包文件（application packages files，即.apk文件）中。
支持所有未來Android平台的一些列原生系統頭文件和庫
為何要用到NDK？概括來說主要分為以下幾種情況：

代碼的保護，由於apk的java層代碼很容易被反編譯，而C/C++庫反匯難度較大。
在NDK中調用第三方C/C++庫，因為大部分的開源庫都是用C/C++代碼編寫的。
便於移植，用C/C++寫的庫可以方便在其他的嵌入式平台上再次使用。

Android JNI是什麼？和NDK是什麼關系？
Java Native Interface(JNI)標準是java平台的一部分，它允許Java代碼和其他語言寫的代碼進行交互。JNI是本地編程介面，它使得在 Java 虛擬機(VM) 內部運行的 Java 代碼能夠與用其它編程語言(如 C、C++和匯編語言)編寫的應用程序和庫進行交互操作。

簡單來說，可以認為NDK就是能夠方便快捷開發.so文件的工具。JNI的過程比較復雜，生成.so需要大量操作，而NDK就是簡化了這個過程。

NDK的異常會不會導致程序Crash，NDK的常見的有哪些類型異常？
NDK編譯生成的.so文件作為程序的一部分，在運行發生異常時同樣會造成程序崩潰。不同於Java代碼異常造成的程序崩潰，在NDK的異常發生時，程序在Android設備上都會立即退出，即通常所說的閃退，而不會彈出「程序xxx無響應，是否立即關閉」之類的提示框。

NDK是使用C/C++來進行開發的，熟悉C/C++的程序員都知道，指針和內存管理是最重要也是最容易出問題的地方，稍有不慎就會遇到諸如內存無效訪問、無效對象、內存泄露、堆棧溢出等常見的問題，最後都是同一個結果：程序崩潰。例如我們常說的空指針錯誤，就是當一個內存指針被置為空（NULL）之後再次對其進行訪問；另外一個經常出現的錯誤是，在程序的某個位置釋放了某個內存空間，而後在程序的其他位置試圖訪問該內存地址，這就會產生一個無效地址錯誤。常見的錯誤類型如下：

初始化錯誤
訪問錯誤
數組索引訪問越界
指針對象訪問越界
訪問空指針對象
訪問無效指針對象
迭代器訪問越界
內存泄露
參數錯誤
堆棧溢出
類型轉換錯誤
數字除0錯誤
NDK錯誤發生時，我們能拿到什麼信息？
利用Android NDK開發本地應用的時候，幾乎所有的程序員都遇到過程序崩潰的問題，但它的崩潰會在logcat中列印一堆看起來類似天書的堆棧信息，讓人舉足無措。單靠添加一行行的列印信息來定位錯誤代碼做在的行數，無疑是一件令人崩潰的事情。在網上搜索「Android NDK崩潰」，可以搜索到很多文章來介紹如何通過Android提供的工具來查找和定位NDK的錯誤，但大都晦澀難懂。下面以一個實際的例子來說明，首先生成一個錯誤，然後演示如何通過兩種不同的方法，來定位錯誤的函數名和代碼行。

首先，看我們在hello-jni程序的代碼中做了什麼（有關如何創建或導入工程，此處略），看下圖：在JNI_OnLoad()的函數中，即so載入時，調用willCrash()函數，而在willCrash()函數中， std::string的這種賦值方法會產生一個空指針錯誤。這樣，在hello-jni程序載入時就會閃退。我們記一下這兩個行數：在61行調用了willCrash()函數；在69行發生了崩潰。

下面來看看發生崩潰（閃退）時系統列印的logcat日誌：

[plain] view plain
*** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
Build fingerprint: 'vivo/bbk89_cmcc_jb2/bbk89_cmcc_jb2:4.2.1/JOP40D/1372668680:user/test-keys'
pid: 32607, tid: 32607, name: xample.hellojni >>> com.example.hellojni <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000000
r0 00000000 r1 beb123a8 r2 80808080 r3 00000000
r4 5d635f68 r5 5cdc3198 r6 41efcb18 r7 5d62df44
r8 4121b0c0 r9 00000001 sl 00000000 fp beb1238c
ip 5d635f7c sp beb12380 lr 5d62ddec pc 400e7438 cpsr 60000010

backtrace:
#00 pc 00023438 /system/lib/libc.so
#01 pc 00004de8 /data/app-lib/com.example.hellojni-2/libhello-jni.so
#02 pc 000056c8 /data/app-lib/com.example.hellojni-2/libhello-jni.so
#03 pc 00004fb4 /data/app-lib/com.example.hellojni-2/libhello-jni.so
#04 pc 00004f58 /data/app-lib/com.example.hellojni-2/libhello-jni.so
#05 pc 000505b9 /system/lib/libdvm.so
#06 pc 00068005 /system/lib/libdvm.so
#07 pc 000278a0 /system/lib/libdvm.so
#08 pc 0002b7fc /system/lib/libdvm.so
#09 pc 00060fe1 /system/lib/libdvm.so
#10 pc 0006100b /system/lib/libdvm.so
#11 pc 0006c6eb /system/lib/libdvm.so
#12 pc 00067a1f /system/lib/libdvm.so
#13 pc 000278a0 /system/lib/libdvm.so
#14 pc 0002b7fc /system/lib/libdvm.so
#15 pc 00061307 /system/lib/libdvm.so
#16 pc 0006912d /system/lib/libdvm.so
#17 pc 000278a0 /system/lib/libdvm.so
#18 pc 0002b7fc /system/lib/libdvm.so
#19 pc 00060fe1 /system/lib/libdvm.so
#20 pc 00049ff9 /system/lib/libdvm.so
#21 pc 0004d419 /system/lib/libandroid_runtime.so
#22 pc 0004e1bd /system/lib/libandroid_runtime.so
#23 pc 00001d37 /system/bin/app_process
#24 pc 0001bd98 /system/lib/libc.so
#25 pc 00001904 /system/bin/app_process

stack:
beb12340 012153f8
beb12344 00054290
beb12348 00000035
beb1234c beb123c0 [stack]

……

如果你看過logcat列印的NDK錯誤時的日誌就會知道，我省略了後面很多的內容，很多人看到這么多密密麻麻的日誌就已經頭暈腦脹了，即使是很多資深的Android開發者，在面對NDK日誌時也大都默默的選擇了無視。

「符號化」NDK錯誤信息的方法
其實，只要你細心的查看，再配合Google 提供的工具，完全可以快速的准確定位出錯的代碼位置，這個工作我們稱之為「符號化」。需要注意的是，如果要對NDK錯誤進行符號化的工作，需要保留編譯過程中產生的包含符號表的so文件，這些文件一般保存在$PROJECT_PATH/obj/local/目錄下。

第一種方法：ndk-stack

這個命令行工具包含在NDK工具的安裝目錄，和ndk-build和其他一些常用的NDK命令放在一起，比如在我的電腦上，其位置是/android-ndk-r9d/ndk-stack。根據Google官方文檔，NDK從r6版本開始提供ndk-stack命令，如果你用的之前的版本，建議還是盡快升級至最新的版本。使用ndk –stack命令也有兩種方式

使用ndk-stack實時分析日誌
在運行程序的同時，使用adb獲取logcat日誌，並通過管道符輸出給ndk-stack，同時需要指定包含符號表的so文件位置；如果你的程序包含了多種CPU架構，在這里需求根據錯誤發生時的手機CPU類型，選擇不同的CPU架構目錄，如：

[plain] view plain
adb shell logcat | ndk-stack -sym $PROJECT_PATH/obj/local/armeabi

當崩潰發生時，會得到如下的信息：

[plain] view plain
********** Crash mp: **********
Build fingerprint: 'vivo/bbk89_cmcc_jb2/bbk89_cmcc_jb2:4.2.1/JOP40D/1372668680:user/test-keys'
pid: 32607, tid: 32607, name: xample.hellojni >>> com.example.hellojni <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000000
Stack frame #00 pc 00023438 /system/lib/libc.so (strlen+72)
Stack frame #01 pc 00004de8 /data/app-lib/com.example.hellojni-2/libhello-jni.so (std::char_traits<char>::length(char const*)+20): Routine std::char_traits<char>::length(char const*) at /android-ndk-r9d/sources/cxx-stl/stlport/stlport/stl/char_traits.h:229
Stack frame #02 pc 000056c8 /data/app-lib/com.example.hellojni-2/libhello-jni.so (std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&)+44): Routine basic_string at /android-ndk-r9d/sources/cxx-stl/stlport/stlport/stl/_string.c:639
Stack frame #03 pc 00004fb4 /data/app-lib/com.example.hellojni-2/libhello-jni.so (willCrash()+68): Routine willCrash() at /home/testin/hello-jni/jni/hello-jni.cpp:69
Stack frame #04 pc 00004f58 /data/app-lib/com.example.hellojni-2/libhello-jni.so (JNI_OnLoad+20): Routine JNI_OnLoad at /home/testin/hello-jni/jni/hello-jni.cpp:61
Stack frame #05 pc 000505b9 /system/lib/libdvm.so (dvmLoadNativeCode(char const*, Object*, char**)+516)
Stack frame #06 pc 00068005 /system/lib/libdvm.so
Stack frame #07 pc 000278a0 /system/lib/libdvm.so
Stack frame #08 pc 0002b7fc /system/lib/libdvm.so (dvmInterpret(Thread*, Method const*, JValue*)+180)
Stack frame #09 pc 00060fe1 /system/lib/libdvm.so (dvmCallMethodV(Thread*, Method const*, Object*, bool, JValue*, std::__va_list)+272)
……（後面略）
我們重點看一下#03和#04，這兩行都是在我們自己生成的libhello-jni.so中的報錯信息，那麼會發現如下關鍵信息：

[plain] view plain
#03 (willCrash()+68): Routine willCrash() at /home/testin/hello-jni/jni/hello-jni.cpp:69
#04 (JNI_OnLoad+20): Routine JNI_OnLoad at /home/testin/hello-jni/jni/hello-jni.cpp:61

回想一下我們的代碼，在JNI_OnLoad()函數中（第61行），我們調用了willCrash()函數；在willCrash()函數中（第69行），我們製造了一個錯誤。這些信息都被准確無誤的提取了出來！是不是非常簡單？

先獲取日誌，再使用ndk-stack分析
這種方法其實和上面的方法沒有什麼大的區別，僅僅是logcat日誌獲取的方式不同。可以在程序運行的過程中將logcat日誌保存到一個文件，甚至可以在崩潰發生時，快速的將logcat日誌保存起來，然後再進行分析，比上面的方法稍微靈活一點，而且日誌可以留待以後繼續分析。

[plain] view plain
adb shell logcat > 1.log
ndk-stack -sym $PROJECT_PATH/obj/local/armeabi –mp 1.log
第二種方法：使用addr2line和objmp命令

這個方法適用於那些，不滿足於上述ndk-stack的簡單用法，而喜歡刨根問底的程序員們，這兩個方法可以揭示ndk-stack命令的工作原理是什麼，盡管用起來稍微麻煩一點，但是可以滿足一下程序員的好奇心。

先簡單說一下這兩個命令，在絕大部分的linux發行版本中都能找到他們，如果你的操作系統是linux，而你測試手機使用的是Intel x86系列，那麼你使用系統中自帶的命令就可以了。然而，如果僅僅是這樣，那麼絕大多數人要絕望了，因為恰恰大部分開發者使用的是Windows，而手機很有可能是armeabi系列。

別急，在NDK中自帶了適用於各個操作系統和CPU架構的工具鏈，其中就包含了這兩個命令，只不過名字稍有變化，你可以在NDK目錄的toolchains目錄下找到他們。以我的Mac電腦為例，如果我要找的是適用於armeabi架構的工具，那麼他們分別為arm-linux-androideabi-addr2line和arm-linux-androideabi-objmp；位置在下面目錄中，後續介紹中將省略此位置：

[plain] view plain
/Developer/android_sdk/android-ndk-r9d/toolchains/arm-linux-androideabi-4.8/prebuilt/darwin-x86_64/bin/
假設你的電腦是windows， CPU架構為mips，那麼你要的工具可能包含在這個目錄中：

[plain] view plain
D:\ android-ndk-r9d\toolchains\mipsel-linux-android-4.8\prebuilt\windows-x86_64\bin\

好了言歸正傳，如何使用這兩個工具，下面具體介紹：

1. 找到日誌中的關鍵函數指針
其實很簡單，就是找到backtrace信息中，屬於我們自己的so文件報錯的行。

首先要找到backtrace信息，有的手機會明確列印一行backtrace（比如我們這次使用的手機），那麼這一行下面的一系列以「#兩位數字 pc」開頭的行就是backtrace信息了。有時可能有的手機並不會列印一行backtrace，那麼只要找到一段以「#兩位數字 pc 」開頭的行，就可以了。

其次要找到屬於自己的so文件報錯的行，這就比較簡單了。找到這些行之後，記下這些行中的函數地址

2. 使用addr2line查找代碼位置
執行如下的命令，多個指針地址可以在一個命令中帶入，以空格隔開即可

[plain] view plain
arm-linux-androideabi-addr2line –e obj/local/armeabi/libhello-jni.so 00004de8 000056c8 00004fb4 00004f58

結果如下
[plain] view plain
/android-ndk-r9d/sources/cxx-stl/stlport/stlport/stl/char_traits.h:229
/android-ndk-r9d/sources/cxx-stl/stlport/stlport/stl/_string.c:639
/WordSpaces/hello-jni/jni/hello-jni.cpp:69
/WordSpaces hello-jni/jni/hello-jni.cpp:6

從addr2line的結果就能看到，我們拿到了我們自己的錯誤代碼的調用關系和行數，在hello-jni.cpp的69行和61行（另外兩行因為使用的是標准函數，可以忽略掉），結果和ndk-stack是一致的，說明ndk-stack也是通過addr2line來獲取代碼位置的。

3. 使用objmp獲取函數信息
通過addr2line命令，其實我們已經找到了我們代碼中出錯的位置，已經可以幫助程序員定位問題所在了。但是，這個方法只能獲取代碼行數，並沒有顯示函數信息，顯得不那麼「完美」，對於追求極致的程序員來說，這當然是不夠的。下面我們就演示怎麼來定位函數信息。

使用如下命令導出函數表：

[plain] view plain
arm-linux-androideabi-objmp –S obj/local/armeabi/libhello-jni.so > hello.asm

在生成的asm文件中查找剛剛我們定位的兩個關鍵指針00004fb4和00004f58

從這兩張圖可以清楚的看到（要注意的是，在不同的NDK版本和不同的操作系統中，asm文件的格式不是完全相同，但都大同小異，請大家仔細比對），這兩個指針分別屬於willCrash()和JNI_OnLoad()函數，再結合剛才addr2line的結果，那麼這兩個地址分別對應的信息就是：

[plain] view plain
00004fb4: willCrash() /WordSpaces/hello-jni/jni/hello-jni.cpp:69
00004f58: JNI_OnLoad()/WordSpaces/hello-jni/jni/hello-jni.cpp:61

相當完美，和ndk-stack得到的信息完全一致！

使用Testin崩潰分析服務定位NDK錯誤
以上提到的方法，只適合在開發測試期間，如果你的應用或者游戲已經發布上線，而用戶經常反饋說崩潰、閃退，指望用戶幫你收集信息定位問題，幾乎是不可能的。這個時候，我們就需要用其他的手段來捕獲崩潰信息。

目前業界已經有一些公司推出了崩潰信息收集的服務，通過嵌入SDK，在程序發生崩潰時收集堆棧信息，發送到雲服務平台，從而幫助開發者定位錯誤信息。在這方面，處於領先地位的是國內的Testin和國外的crittercism，其中crittercism需要付費，而且沒有專門的中國開發者支持，我們更推薦Testin，其崩潰分析服務是完全免費的。

Testin從1.4版本開始支持NDK的崩潰分析，其最新版本已經升級到1.7。當程序發生NDK錯誤時，其內嵌的SDK會收集程序在用戶手機上發生崩潰時的堆棧信息（主要就是上面我們通過logcat日誌獲取到的函數指針）、設備信息、線程信息等等，SDK將這些信息上報至Testin雲服務平台，只要登陸到Testin平台，就可以看到所有用戶上報的崩潰信息，包括NDK；並且這些崩潰做過歸一化的處理，在不同系統和ROM的版本上列印的信息會略有不同，但是在Testin的網站上這些都做了很好的處理，避免了我們一些重復勞動。

上圖的紅框部分，就是從用戶手機上報的，我們自己的so中報錯的函數指針地址堆棧信息，就和我們開發時從logcat讀到的日誌一樣，是一些晦澀難懂的指針地址，Testin為NDK崩潰提供了符號化的功能，只要將我們編譯過程中產生的包含符號表的so文件上傳（上文我們提到過的obj/local/目錄下的適用於各個CPU架構的so），就可以自動將函數指針地址定位到函數名稱和代碼行數。符號化之後，看起來就和我們前面在本地測試的結果是一樣的了，一目瞭然。

而且使用這個功能還有一個好處：這些包含符號表的so文件，在每次我們自己編譯之後都會改變，很有可能我們剛剛發布一個新版本，這些目錄下的so就已經變了，因為開發者會程序的修改程序；在這樣的情況下，即使我們拿到了崩潰時的堆棧信息，那也無法再進行符號化了。所以我們在編譯打包完成後記得備份我們的so文件。這時我們可以將這些文件上傳到Testin進行符號化的工作，Testin會為我們保存和管理不同版本的so文件，確保信息不會丟失。來看一下符號化之後的顯示：

② 如何獲取libunity.so的符號表

加密原理(無需Unity源碼): 1. IDA Pro打開libmono.so, 修改mono_image_open_from_data_with_name為 mono_image_open_from_data_with_name_0, 2. 替換實現mono_image_open_from_data_with_name, extern mono_image_open_from_data_with_name_0(...); mono_image_open_from_data_with_name(...) { MonoImage *img = mono_image_open_from_data_with_name_0(...); //發現數據文件頭不是DLL前綴則解密 img->raw_data, 相應修改img->raw_data_len return img; } 3. 重新打包libmono.so; 替換Unity3D中的android下的版本. 4. 另外寫個加密的工具，植入構建環境(MonoDeveloper或VS，添加一個打包後Build Phase來加密DLL); (IOS下禁用JIT固採用AOT編譯，DLL中沒有邏輯代碼，所以無需操心); 從AndroidManifest.xml中可以看出，騰訊的改造應該是修改並替換了入口的classes.dex，把以前的入口 UnityPlayerProxyActivity替換為com.tencent.tauth.AuthActivity. 然後去載入了自定義的幾個so: libNativeRQD.so. 周全考慮，為了防止第三方委託libmono去做解密而做了防護措施. 具體實現我還沒做深入分析, 應該也是老套路. libmono.so中的mono_image_open_from_data_with_name也被替換成了mono_image_open_from_data_with_name_0. 解密(android): 方法一: ROOT android系統(最好是一部手機，別搞模擬器，慢死), 掛載LD_PRELOAD的API hook來實現. 方法二: 內存特徵碼提取，簡單高效無敵; 機器能讀，你就能讀;

③ linux下c語言編譯so問題

不需要在自己的.so中調用別人的.so，只需要編譯自己的，編譯.so時，系統不會檢查未定義的函數。
直接在編譯自己的應用程序時鏈接這兩個.so就可以了！

gcc -o exec_file mysrc.c -L./ -lXXX -L/usr/lib -lmysqlclient

④ 在編譯的整個過程中對符號表做的操作有哪些

符號表在編譯程序工作的過程中需要不斷收集、記錄和使用源程序中一些語法符號的類型和特徵等相關信息。這些信息一般以表格形式存儲於系統中。如常數表、變數名表、數組名表、過程名表、標號表等等，統稱為符號表。對於符號表組織、構造和管理方法的好壞會直接影響編譯系統的運行效率。

⑤ so最後的buildid not stripped是什麼意思

not stripped 表示這個so沒有被剔除符號表
你可以使用 編譯工具鏈中的 strip xx.so 來剔除這個so的符號表
這個時候你再file 這個so你會看到 這個so顯示 stripped
符號表中的內容是用來方便代碼調試的, 一般項目最終發布的時候會統一剔除符號表

⑥ 如何查看ndk編譯的動態庫符號表

$ /path/to/ndk/buid/prebuilt/windows/arm-eabi-4.4.0/bin/arm-eabi-nm libs/armeabi/libsanangeles.so

00003600 T Java_com_example_SanAngeles_DemoGLSurfaceView_nativePause

00003638 T Java_com_example_SanAngeles_DemoRenderer_nativeDone

0000367c T Java_com_example_SanAngeles_DemoRenderer_nativeInit

000035b4 T Java_com_example_SanAngeles_DemoRenderer_nativeRender

00003644 T Java_com_example_SanAngeles_DemoRenderer_nativeResize

00007334 a _DYNAMIC

0000740c a _GLOBAL_OFFSET_TABLE_

復制代碼

這里可以看到幾乎所有的函數名全局變數名都會被導出。其中有Java_com_example_SanAngeles_為前綴的JNI介面函數，有importGLInit這些普通函數，有freeGLObject這些局部（static）函數，還有sStartTick等全局變數名。其實在這個動態發布的時候，只需要導出java_com_開頭的jni函數就可以了，裡面這些細節函數名完全不需要暴露出來。
如何做到這一點呢？首先，我們需要了解gcc新引進的選項-fvisibility=hidden，這個編譯選項可以把所有的符號名（包括函數名和全局變數名）都強制標記成隱藏屬性。我們可以在Android.mk中可以通過修改LOCAL_CFLAGS選項加入-fvisibility=hidden來做到這一點，這樣編譯之後的.so看到的符號表為：

000033d0 t Java_com_example_SanAngeles_DemoGLSurfaceView_nativePause

00003408 t Java_com_example_SanAngeles_DemoRenderer_nativeDone

0000344c t Java_com_example_SanAngeles_DemoRenderer_nativeInit

00003384 t Java_com_example_SanAngeles_DemoRenderer_nativeRender

00003414 t Java_com_example_SanAngeles_DemoRenderer_nativeResize

00007104 a _DYNAMIC

⑦ 如何用make命令手動編譯帶符號表的vxWorks.st images

步驟：
1. run torvars.bat
2. cd <BASE>/target/config/pcPentium4
3. make vxWorks.st //注意大小寫

將2中的路徑換為你的工程路徑即可。

⑧ 如何定位Android NDK開發中遇到的錯誤

利用Android NDK開發本地應用時，幾乎所有的程序員都遇到過程序崩潰的問題，但它的崩潰會在logcat中列印一堆看起來類似天書的堆棧信息，讓人舉足無措。單靠添加一行行的列印信息來定位錯誤代碼做在的行數，無疑是一件令人崩潰的事情。在網上搜索「Android NDK崩潰」，可以搜索到很多文章來介紹如何通過Android提供的工具來查找和定位NDK的錯誤，但大都晦澀難懂。下面以一個實際的例子來說明，如何通過兩種不同的方法，來定位錯誤的函數名和代碼行。

首先，來看看我們在hello-jni程序的代碼中做了什麼（有關如何創建或導入工程，此處略），下面代碼中：在JNI_OnLoad()的函數中，即so載入時，調用willCrash()函數，而在willCrash()函數中， std::string的這種賦值方法會產生一個空指針錯誤。這樣，在hello-jni程序載入時就會閃退。我們記一下這兩個行數：在61行調用了willCrash()函數；在69行發生了崩潰。

下面我們來看看發生崩潰（閃退）時系統列印的logcat日誌：

如果你看過logcat列印的NDK錯誤的日誌就會知道，我省略了後面很多的內容，很多人看到這么多密密麻麻的日誌就已經頭暈腦脹了，即使是很多資深的Android開發者，在面對NDK日誌時也大都默默地選擇了無視。

其實，只要你細心的查看，再配合Google 提供的工具，完全可以快速地准確定位出錯的代碼位置，這個工作我們稱之為「符號化」。需要注意的是，如果要對NDK錯誤進行符號化的工作，需要保留編譯過程中產生的包含符號表的so文件，這些文件一般保存在$PROJECT_PATH/obj/local/目錄下。

第一種方法：ndk-stack

這個命令行工具包含在NDK工具的安裝目錄，和ndk-build及其他常用的一些NDK命令放在一起，比如在我的電腦上，其位置是/android-ndk-r9d/ndk-stack。根據Google官方文檔，NDK從r6版本開始提供ndk-stack命令，如果你用的之前的版本，建議還是盡快升級至最新的版本。使用ndk –stack命令也有兩種方式

實時分析日誌

在運行程序的同時，使用adb獲取logcat日誌，並通過管道符輸出給ndk-stack，同時需要指定包含符號表的so文件位置；如果你的程序包含了多種CPU架構，在這里需求根據錯誤發生時的手機CPU類型，選擇不同的CPU架構目錄，如：

當崩潰發生時，會得到如下的信息：

我們重點看一下#03和#04，這兩行都是在我們自己生成的libhello-jni.so中的報錯信息，因此會發現如下關鍵信息：

回想一下我們的代碼，在JNI_OnLoad()函數中（第61行），我們調用了willCrash()函數；在willCrash()函數中（第69行），我們製造了一個錯誤。這些信息都被准確無誤的提取了出來！是不是非常簡單？

先獲取日誌再分析

這種方法其實和上面的方法沒有什麼大的區別，僅僅是logcat日誌獲取的方式不同。可以在程序運行的過程中將logcat日誌保存到一個文件，甚至可以在崩潰發生時，快速的將logcat日誌保存起來，然後再進行分析，比上面的方法稍微靈活一點，而且日誌可以留待以後繼續分析。

第二種方法：使用addr2line和objmp命令

這個方法適用於那些不滿足於上述ndk-stack的簡單用法，而喜歡刨根問底的程序員們，這兩個方法可以揭示ndk-stack命令的工作原理是什麼，盡管用起來稍微麻煩一點，但可以稍稍滿足一下程序員的好奇心。

先簡單說一下這兩個命令，在絕大部分的Linux發行版本中都能找到他們，如果你的操作系統是Linux，而你測試手機使用的是Intel x86系列，那麼你使用系統中自帶的命令就可以了。然而，如果僅僅是這樣，那麼絕大多數人要絕望了，因為恰恰大部分開發者使用的是Windows，而手機很有可能是armeabi系列。

在NDK中自帶了適用於各個操作系統和CPU架構的工具鏈，其中就包含了這兩個命令，只不過名字稍有變化，你可以在NDK目錄的toolchains目錄下找到他們。以我的Mac電腦為例，如果我要找的是適用於armeabi架構的工具，那麼他們分別為arm-linux-androideabi-addr2line和arm-linux-androideabi-objmp；位置在下面目錄中，後續介紹中將省略此位置：

假設你的電腦是Windows系統，CPU架構為mips，那麼你要的工具可能包含在一下目錄中：

接下來就讓我們來看看如何使用這兩個工具，下面具體介紹。

找到日誌中的關鍵函數指針

其實很簡單，就是找到backtrace信息中，屬於我們自己的so文件報錯的行。

首先要找到backtrace信息，有的手機會明確列印一行backtrace（比如我們這次使用的手機），那麼這一行下面的一系列以「#兩位數字 pc」開頭的行就是backtrace信息了。有時可能有的手機並不會列印一行backtrace，那麼只要找到一段以「#兩位數字 pc 」開頭的行，就可以了。

其次要找到屬於自己的so文件報錯的行，這就比較簡單了。找到這些行之後，記下這些行中的函數地址。

使用addr2line查找代碼位置

執行如下的命令，多個指針地址可以在一個命令中帶入，以空格隔開即可

結果如下：

從addr2line的結果就能看到，我們拿到了我們自己的錯誤代碼的調用關系和行數，在hello-jni.cpp的69行和61行（另外兩行因為使用的是標准函數，可以忽略掉），結果和ndk-stack是一致的，說明ndk-stack也是通過addr2line來獲取代碼位置的。

使用objmp獲取函數信息

通過addr2line命令，其實我們已經找到了我們代碼中出錯的位置，已經可以幫助程序員定位問題所在了。但是，這個方法只能獲取代碼行數，並沒有顯示函數信息，顯得不那麼「完美」，對於追求極致的程序員來說，這當然是不夠的。下面我們就演示一下怎麼來定位函數信息。

首先使用如下命令導出函數表：

在生成的asm文件中查找剛剛我們定位的兩個關鍵指針00004fb4和00004f58：

從這兩張圖可以清楚的看到（要注意的是，在不同的NDK版本和不同的操作系統中，asm文件的格式不是完全相同，但都大同小異，請大家仔細比對），這兩個指針分別屬於willCrash()和JNI_OnLoad()函數，再結合剛才addr2line的結果，那麼這兩個地址分別對應的信息就是：

相當完美，和ndk-stack得到的信息完全一致！

Testin崩潰分析如何幫開發者發現NDK錯誤

以上提到的方法，只適合在開發測試期間，如果你的應用或游戲已經上線，而用戶經常反饋說崩潰、閃退，指望用戶幫你收集信息定位問題幾乎是不可能的。這個時候，我們就需要用其他的手段來捕獲崩潰信息。

目前業界已經有一些公司推出了崩潰信息收集的服務，通過嵌入SDK，在程序發生崩潰時收集堆棧信息，發送到雲服務平台，從而幫助開發者定位錯誤信息。在這方面，國內的Testin和國外的crittercism都可以提供類似服務。

Testin從1.4版本開始支持NDK的崩潰分析，其最新版本已升級到1.7。當程序發生NDK錯誤時，其內嵌的SDK會收集程序在用戶手機上發生崩潰時的堆棧信息（主要就是上面我們通過logcat日誌獲取到的函數指針）、設備信息、線程信息等，SDK將這些信息上報至Testin雲服務平台，在平台進行唯一性的處理、並可以自定義時段進行詳盡的統計分析，從多維度展示程序崩潰的信息和嚴重程度；最新版本還支持用戶自定義場景，方便開發者定位問題所在。

從用戶手機上報的堆棧信息，Testin為NDK崩潰提供了符號化的功能，只要將我們編譯過程中產生的包含符號表的so文件上傳，就可以自動將函數指針地址定位到函數名稱和代碼行數。符號化之後，看起來就和我們前面在本地測試的結果是一樣的了，一目瞭然。而且使用這個功能還有一個好處：這些包含符號表的so文件，在每次開發者編譯之後都會改變，很有可能我們發布之後就已經變了，因為開發者會修改程序。在這樣的情況下，即使我們拿到了崩潰時的堆棧信息，那也無法再進行符號化了。我們可以將這些文件上傳到Testin進行符號化的工作，Testin會為我們保存和管理不同版本的so文件，確保信息不會丟失。

⑨ 請問我有一個.so文件，如何在Linux下編程使用呢

-lxx

xx是你的.so文件名

其實使用方法和你使用數學庫函數是一樣的，源代碼中添加

#include <math.h>，編譯的時候，加上-lm參數。

註：linux下的.so文件為共享庫，相當於windows下的dll文件。

(9)編譯帶符號表的so擴展閱讀：

linux下編寫調用so文件實例

.so是Linux(Unix)下的動態鏈接庫. 和.dll類似.

比如：

文件有: a.c, b.c, c.c

gcc -c a.c

gcc -c b.c

gcc -c c.c

gcc -shared libXXX.so a.o b.o c.o

要使用的話也很簡單. 比如編譯d.c, 使用到libXXX.so中的函數, libXXX.so地址是MYPATH
gcc d.c -o d -LMYPATH -lXXX

注意不是-llibXXX

test.c文件和一個test.h，這兩個文件要生成libsotest.so文件。然後我還有一個testso.c文件，在這個文件裡面調用libsotest.so中的函數。

編寫的過程中，首先是編譯so文件，我沒有編寫makefile文件，而是參考的2裡面說的直接寫的gcc命令。

因為so文件裡面沒有main函數，所以是不可執行的，所以編譯的時候要加上-c，只生成目標文件。