android符号表

❶ 如何使用android+NDK进行真正意义的开发

1，首先，来看看在hello-jni程序的代码中做了什么（有关如何创建或导入工程，此处略），下面代码中：在JNI_OnLoad()的函数中，即so加载时，调用willCrash()函数，而在willCrash()函数中， std::string的这种赋值方法会产生一个空指针错误。这样，在hello-jni程序加载时就会闪退。记一下这两个行数：在61行调用了willCrash()函数；在69行发生了崩溃 2 看看发生崩溃（闪退）时系统打印的logcat日志： 、只要细心的查看，再配合Google 提供的工具，完全可以快速地准确定位出错的代码位置，这个工作我们称之为“符号化”。需要注意的是，如果要对NDK错误进行符号化的工作，需要保留编译过程中产生的包含符号表的so文件，这些文件一般保存在$PROJECT_PATH/obj/local/目录下。 3 方法：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行），制造了一个错误。 4 先获取日志再分析 这种方法其实和上面的方法没有什么大的区别，仅仅是logcat日志获取的方式不同。可以在程序运行的过程中将logcat日志保存到一个文件，甚至可以在崩溃发生时，快速的将logcat日志保存起来，然后再进行分析，比上面的方法稍微灵活一点，而且日志可以留待以后继续分析。

❷ 如何定位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架构目录，如：

当崩溃发生时，会得到如下的信息：

❸ 如何查看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

❹ 如何定位Android NDK开发中遇到的错误

Android NDK中的错误定位对很多开发者来说是一件头疼的事，本文通过一个Demo程序详细讲解了NDK的错误是如何产生的，以及如何通过命令行工具定位NDK的问题所在。

Android 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编译生成的.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日志：

如果你看过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架构目录，如：

❺ QQ输入法手机版如何打开符号表

QQ输入法手机版打开符号表的方法如下：【Symbian S60 V2V3平台】 九宫格键盘手机mdash;mdash;通过短按【*】键打开符号表。打开符号表后，继续短按【*】键或者通过方向键进行不同类别符号表的轮换切换;通过短按【#】键进行锁定(或解锁)符号表。 全键盘手机mdash;mdash;通过短按【Chr】键打开符号表。打开符号表后，继续短按【Chr】键进行不同类别符号表的轮换切换;通过短按【shift】键进行锁定(或解锁)符号表。 锁定符号表后，符号表右上角会出现ldquo;锁rdquo;的小图标，表示此时可以连续输入多个符号，再点击一次按键，即可解锁。无论是否锁定，点击右软件【取消】都可关闭符号表。【PPC amp; Android 平台】 点击【符】键即可打开符号表。打开符号表后，可以通过左边的【上翻页】和【下翻页】按键选择不同类别符号表、通过【锁定】(或【解锁】)按键对符号表进行锁定(或解锁)。符号表锁定后，可以连续输入多个符号。nbsp; QQ输入法手机版由腾讯公司自主研发的新一代免费手机输入法。它不仅占用内存少、输入速度快、皮肤自适应，还可以进行笔画输入，并提供标准版和增强版让用户ldquo;量机而行rdquo;。 QQ输入法手机版的输入界面与大多数手机自带输入法的界面有所不同。在按下按键时，QQ输入法手机版的字词候选框并非出现在屏幕底部，而是可以跟随光标，这与电脑输入法的界面更加接近。而候选字词是横向排列，这与紫光拼音、搜狗拼音等电脑输入法的默认设置也相同。 在使用QQ输入法手机版进行输入时，跟随输入焦点显示的悬浮框会以上下两行分别显示候选字词和拼音选项。默认设置下，可以通过ldquo;#rdquo;键进入到拼音选择，通过ldquo;*rdquo;键进入候选字词的选择。进入拼音或候选字词选择后，每一个选项上都会以数字标示，这时便可通过数字按键或者导航键选择相应的字词或拼音。 QQ输入法手机版的输入框拥有清爽简洁的皮肤、可以智能调节长度，最大限度的减小了手机界面占用率，用户可以一次性输入多个词语、自由混输中文和英文、体验标点联想的畅快。QQ输入法手机版还为用户提供了打造个性词库的功能，用户可以随心导入喜爱的分类词库及通信录人名。 查看原帖>>

记得采纳啊

❻ 搜狗手机输入法android版从1.6升级到1.6.1以后。无法输入符号。原来的1.6可以输入

如果你手机的搜狗安装没问题的，这个功能是可以正常使用的，进入符号表输入。短按键盘上的【符号】键可进入符号表界面。符号表界面下方有符号类别选择区，可选择：中文符号、英文符号、表情、网址邮箱、图形符号、数学序号、数学单位、希腊字母、拼音注音、平假名、片假名、部首偏旁等18种不同的符号和表情。要是不行的建议先卸载去搜狗官网重下载安装吧

❼ 如何分析Android的Log

首先，让我们看一看AndroidLog的格式。下面这段log是以所谓的long格式打印出来的。从前面Logcat的介绍中可以知道，long格式会把时间，标签等作为单独的一行显示。

这个log就不那么容易懂了，但是还是能从中看出很多信息，让我们一起来学习如何分析这种log。首先看下面这行：

pid: 2102, tid: 2102,name: testapp >>>./testapp <<<

从这一行我们可以知道crash进程的pid和tid，前文我们已经提到过，Android调用gettid函数得到的实际是进程Id号，所以这里的pid和tid相同。知道进程号后我们可以往前翻翻log，看看该进程最后一次打印的log是什么，这样能缩小一点范围。

接下来内容是进程名和启动参数。再接下来的一行比较重要了，它告诉了我们从系统角度看，出错的原因：

signal 11 (SIGSEGV), code 1(SEGV_MAPERR), fault addr 00000000

signal11是linux定义的信号之一，含义是Invalidmemory reference，无效的内存引用。加上后面的“faultaddr
00000000”我们基本可以判定这是一个空指针导致的crash。当然这是笔者为了讲解而特地制造的一个Crash的例子，比较容易判断，大部分实际的例子可能就没有那么容易了。

再接下来的log打印出了cpu的所有寄存器的信息和堆栈的信息，这里面最重要的是从堆栈中得到的backtrace信息：

I/DEBUG ( 127):backtrace:

I/DEBUG ( 127): #00 pc0000045e /system/bin/testapp

I/DEBUG ( 127): #01 pc0000046b /system/bin/testapp

I/DEBUG ( 127): #02 pc0001271f /system/lib/libc.so (__libc_init+38)

I/DEBUG ( 127): #03 pc00000400 /system/bin/testapp

因为实际的运行系统里没有符号信息，所以打印出的log里看不出文件名和行数。这就需要我们借助编译时留下的符号信息表来翻译了。Android提供了一个工具可以来做这种翻译工作：arm-eabi-addr2line，位于prebuilts/gcc/linux-x86/arm/arm-eabi-4.6/bin目录下。用法很简单：

#./arm-eabi-addr2line -f
-eout/target/proct/hammerhead/symbols/system/bin/testapp0x0000045e

参数-f表示打印函数名；参数-e表示带符号表的模块路径；最后是要转换的地址。这条命令在笔者的编译环境中得到的结果是：

memcpy
/home/rd/compile/android-4.4_r1.2/bionic/libc/include/string.h:108

剩余三个地址翻译如下：

main
/home/rd/compile/android-4.4_r1.2/packages/apps/testapp/app_main.cpp:38

out_vformat
/home/rd/compile/android-4.4_r1.2/bionic/libc/bionic/libc_logging.cpp:361

_start libgcc2.c:0

利用这些信息我们很快就能定位问题了。不过这样手动一条一条的翻译比较麻烦，笔者使用的是从网上找到的一个脚本，可以一次翻译所有的行，有需要的读者可以在网上找一找。

❽ 在Android设备上怎么调试守护进程

其实网上有很多类似的文章，但是你会发现几乎都不可重现，要么是细节没讲清楚，要么是压根自己没有真正去试过。这里，我仅给出自己用gdb和gdbserver调试android native code的实际过程，希望对大家有用。

注：以调试mediaserver进程为例.

第一步：你需要下载android，以debug方式编译，并以生成的image起模拟器或者设备。

第二步：你需要从“http://developer.download.nvidia.com/tegra/files/tegra-gdb-20100430.zip”下载一个gdb，覆盖到android源码中gdb对应的位置。

第三步：adb shell到设备,并起gdbserver侦听目标进程:

adb shell

gdbserver :5039 /system/bin/mediaserver

第四步: 建立pc机和设备的消息连接:

adb forward tcp:5039 tcp:5039

第五步: 使用gdb调试目标进程:

cd android_src

prebuilt/linux-x86/toolchain/arm-eabi-4.2.1/bin/arm-eabi-gdb out/debug/target/proct/generic/symbols/system/bin/mediaserver

第六步: 设置符号表:

set solib-absolute-prefix /your_android_src_path/out/debug/target/proct/generic/symbols

set solib-search-path /your_android_src_path/out/debug/target/proct/generic/symbols/system/lib

第七步: 使gdb和gdb server建立连接:

target remote :5039

第八步: ok. 现在可以使用gdb的命令进行调试,譬如next\break\step\info thread等.

❾ 如何定位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文件，确保信息不会丢失。

❿ 如何实现一个android的log自动化分析工具

首先，让我们看一看AndroidLog的格式。下面这段log是以所谓的long格式打印出来的。从前面Logcat的介绍中可以知道，long格式会把时间，标签等作为单独的一行显示。

[ 12-09 21:39:35.510 396: 416 I/ActivityManager ]

Start procnet.coollet.infzmreader:umengService_v1 for service
net.coollet.infzmreader/com.umeng.message.

UmengService:pid=21745 uid=10039 gids={50039, 3003, 1015,1028}

[ 12-09 21:39:35.518 21745:21745I/dalvikvm ]

Turning on JNI app bug workarounds fortarget SDK version 8...

[ 12-09 21:39:35.611 21745:21745D/AgooService ]

onCreate()

我们以第一行为例：12-09 是日期，21:39:35.510是时间396是进程号，416是线程号；I代表log优先级，ActivityManager是log标签。

在应用开发中，这些信息的作用可能不是很大。但是在系统开发中，这些都是很重要的辅助信息。开发工程师分析的log很多都是由测试工程师抓取的，所以可能有些log根本就不是当时出错的log。如果出现这种情况，无论你怎么分析都不太可能得出正确的结论。如何能最大限度的避免这种情况呢？笔者就要求测试工程师报bug时必须填上bug发生的时间。这样结合log里的时间戳信息就能大致判断是否是发生错误时的log。而且根据测试工程师提供的bug发生时间点，开发工程师可以在长长的log信息中快速的定位错误的位置，缩小分析的范围。

同时我们也要注意，时间信息在log分析中可能被错误的使用。例如：在分析多线程相关的问题时，我们有时需要根据两段不同线程中log语句执行的先后顺序来判断错误发生的原因，但是我们不能以两段log在log文件中出现的先后做为判断的条件，这是因为在小段时间内两个线程输出log的先后是随机的，log打印的先后顺序并不完全等同于执行的顺序。那么我们是否能以log的时间戳来判断呢？同样是不可以，因为这个时间戳实际上是系统打印输出log时的时间，并不是调用log函数时的时间。遇到这种情况唯一的办法是在输出log前，调用系统时间函数获取当时时间，然后再通过log信息打印输出。这样虽然麻烦一点，但是只有这样取得的时间才是可靠的，才能做为我们判断的依据。

另外一种误用log中时间戳的情况是用它来分析程序的性能。一个有多年工作经验的工程师拿着他的性能分析结果给笔者看，但是笔者对这份和实际情况相差很远的报告表示怀疑，于是询问这位工程师是如何得出结论的。他的回答让笔者很惊讶，他计算所采用的数据就是log信息前面的时间戳。前面我们已经讲过，log前面时间戳和调用log函数的时间并不相同，这是由于系统缓冲log信息引起的，而且这两个时间的时间差并不固定。所以用log信息前附带的时间戳来计算两段log间代码的性能会有比较大的误差。正确的方法还是上面提到的：在程序中获取系统时间然后打印输出，利用我们打印的时间来计算所花费的时间。

了解了时间，我们再谈谈进程Id和线程Id，它们也是分析log时很重要的依据。我们看到的log文件，不同进程的log信息实际上是混杂在一起输出的，这给我们分析log带来了很大的麻烦。有时即使是一个函数内的两条相邻的log，也会出现不同进程的log交替输出的情况，也就是A进程的第一条log后面跟着的是B进程的第二条log，对于这样的组合如果不细心分析，就很容易得出错误的结论。这时一定要仔细看log前面的进程Id，把相同Id的log放到一起看。

不同进程的log有这样的问题，不同的线程输出的log当然也存在着相同的问题。Logcat加上-vthread就能打印出线程Id。但是有一点也要引起注意，就是Android的线程Id和我们平时所讲的Linux线程Id并不完全等同。首先，在Android系统中，C++层使用的Linux获取线程Id的函数gettid()是不能得到线程Id的，调用gettid()实际上返回的是进程Id。作为替代，我们可以调用pthread_self()得到一个唯一的值来标示当前的native线程。Android也提供了一个函数androidGetThreaId()来获取线程Id，这个函数实际上就是在调用pthread_self函数。但是在Java层线程Id又是另外一个值，Java层的线程Id是通过调用Thread的getId方法得到的，这个方法的返回值实际上来自Android在每个进程的java层中维护的一个全局变量，所以这个值和C++层所获得的值并不相同。这也是我们分析log时要注意的问题，如果是Java层线程Id，一般值会比较小，几百左右；如果是C++层的线程，值会比较大。在前里面的log样本中，就能很容易的看出，第一条log是Jave层输出的log，第二条是native层输出的。明白了这些，我们在分析log时就不要看见两段log前面的线程Id不相同就得出是两个不同线程log的简单结论，还要注意Jave层和native层的区别，这样才能防止被误导。

AndroidLog的优先级在打印输出时会被转换成V，I，D，W，E等简单的字符标记。在做系统log分析时，我们很难把一个log文件从头看到尾，都是利用搜索工具来查找出错的标记。比如搜索“E/”来看看有没有指示错误的log。所以如果参与系统开发的每个工程师都能遵守Android定义的优先级含义来输出log，这会让我们繁重的log分析工作变得相对轻松些。

Android比较常见的严重问题有两大类，一是程序发生崩溃；二是产生了ANR。程序崩溃和ANR既可能发生在java层，也可能发生在native层。如果问题发生在java层，出错的原因一般比较容易定位。如果是native层的问题，在很多情况下，解决问题就不是那么的容易了。我们先看一个java层的崩溃例子：

I/ActivityManager( 396): Start proccom.test.crash for activity com.test.crash/.MainActivity:
pid=1760 uid=10065 gids={50065, 1028}

D/AndroidRuntime( 1760): Shutting downVM

W/dalvikvm( 1760): threadid=1: threadexiting with uncaught exception(group=0x40c38930)

E/AndroidRuntime( 1760): FATALEXCEPTION: main

E/AndroidRuntime( 1760):java.lang.RuntimeException: Unable to start activityComponentInfo
{com.test.crash/com.test.crash.MainActivity}:java.lang.NullPointerException

E/AndroidRuntime( 1760): atandroid.app.ActivityThread.performLaunchActivity(ActivityThread.java:2180)

E/AndroidRuntime( 1760): atandroid.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2230)

E/AndroidRuntime( 1760): atandroid.app.ActivityThread.access$600(ActivityThread.java:141)

E/AndroidRuntime( 1760): atandroid.app.ActivityThread$H.handleMessage(ActivityThread.java:1234)

E/AndroidRuntime( 1760): atandroid.os.Handler.dispatchMessage(Handler.java:99)

E/AndroidRuntime( 1760): atandroid.os.Looper.loop(Looper.java:137)

E/AndroidRuntime( 1760): atandroid.app.ActivityThread.main(ActivityThread.java:5050)

E/AndroidRuntime( 1760): atjava.lang.reflect.Method.invokeNative(NativeMethod)

E/AndroidRuntime( 1760): atjava.lang.reflect.Method.invoke(Method.java:511)

E/AndroidRuntime( 1760): atcom.android.internal.os.ZygoteInit$MethodAndArgsCaller.run
(ZygoteInit.java:793)

E/AndroidRuntime( 1760): atcom.android.internal.os.ZygoteInit.main(ZygoteInit.java:560)

E/AndroidRuntime( 1760): atdalvik.system.NativeStart.main(NativeMethod)

E/AndroidRuntime( 1760): Caused by:java.lang.NullPointerException

E/AndroidRuntime( 1760): atcom.test.crash.MainActivity.setViewText(MainActivity.java:29)

E/AndroidRuntime( 1760): atcom.test.crash.MainActivity.onCreate(MainActivity.java:17)

E/AndroidRuntime( 1760): atandroid.app.Activity.performCreate(Activity.java:5104)

E/AndroidRuntime( 1760): atandroid.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1080)

E/AndroidRuntime( 1760): atandroid.app.ActivityThread.performLaunchActivity(ActivityThread.java:2144)

E/AndroidRuntime( 1760): ... 11more

I/Process ( 1760): Sending signal.PID: 1760 SIG: 9

W/ActivityManager( 396): Force finishing activitycom.test.crash/.MainActivity

Jave层的代码发生crash问题时，系统往往会打印出很详细的出错信息。比如上面这个例子，不但给出了出错的原因，还有出错的文件和行数。根据这些信息，我们会很容易的定位问题所在。native层的crash虽然也有栈log信息输出，但是就不那么容易看懂了。下面我们再看一个native层crash的例子：

F/libc ( 2102): Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1), thread2102 (testapp)

D/dalvikvm(26630):GC_FOR_ALLOC freed 604K, 11% free 11980K/13368K, paused 36ms, total36ms

I/dalvikvm-heap(26630):Grow heap (frag case) to 11.831MB for 102416-byteallocation

D/dalvikvm(26630):GC_FOR_ALLOC freed 1K, 11% free 12078K/13472K, paused 34ms, total34ms

I/DEBUG ( 127):*** *** *** *** *** *** *** *** *** *** *** *** *** *** ******

I/DEBUG ( 127):Build fingerprint:
'Android/full_maguro/maguro:4.2.2/JDQ39/eng.liuchao.20130619.201255:userdebug/test-keys'

I/DEBUG ( 127):Revision: '9'

I/DEBUG ( 127):pid: 2102, tid: 2102, name: testapp >>>./testapp <<<
I/DEBUG ( 127):signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr00000000

I/DEBUG ( 127): r0 00000020 r173696874 r2 400ff520 r300000000

I/DEBUG ( 127): r4 400ff469 r5beb4ab24 r6 00000001 r7beb4ab2c

I/DEBUG ( 127): r8 00000000 r900000000 sl 00000000 fpbeb4ab1c

I/DEBUG ( 127): ip 4009b5dc spbeb4aae8 lr 400ff46f pc400ff45e cpsr 60000030

I/DEBUG ( 127): d0 000000004108dae8 d1 4108ced84108cec8

I/DEBUG ( 127): d2 4108cef84108cee8 d3 4108cf184108cf08

I/DEBUG ( 127): d4 4108c5a84108c598 d5 4108ca084108c5b8

I/DEBUG ( 127): d6 4108ce684108ce58 d7 4108ce884108ce78

I/DEBUG ( 127): d8 0000000000000000 d9 0000000000000000

I/DEBUG ( 127): d10 0000000000000000 d110000000000000000

I/DEBUG ( 127): d120000000000000000 d130000000000000000

I/DEBUG ( 127): d14 0000000000000000 d150000000000000000

I/DEBUG ( 127): d16 c1dcf7c087fec8b4 d173f50624dd2f1a9fc

I/DEBUG ( 127): d18 41c7b1ac89800000 d190000000000000000

I/DEBUG ( 127): d20 0000000000000000 d210000000000000000

I/DEBUG ( 127): d22 0000000000000000 d230000000000000000

I/DEBUG ( 127): d24 0000000000000000 d250000000000000000

I/DEBUG ( 127): d26 0000000000000000 d270000000000000000

I/DEBUG ( 127): d28 0000000000000000 d290000000000000000

I/DEBUG ( 127): d30 0000000000000000 d310000000000000000

I/DEBUG ( 127): scr 00000010

I/DEBUG ( 127):

I/DEBUG ( 127):backtrace:

I/DEBUG ( 127): #00 pc0000045e /system/bin/testapp

I/DEBUG ( 127): #01 pc0000046b /system/bin/testapp

I/DEBUG ( 127): #02 pc0001271f /system/lib/libc.so (__libc_init+38)

I/DEBUG ( 127): #03 pc00000400 /system/bin/testapp

I/DEBUG ( 127):

I/DEBUG ( 127):stack:

I/DEBUG ( 127): beb4aaa8 000000c8
I/DEBUG ( 127): beb4aaac 00000000
I/DEBUG ( 127): beb4aab0 00000000
I/DEBUG ( 127): beb4aab4 401cbee0 /system/bin/linker

I/DEBUG ( 127): beb4aab8 00001000
I/DEBUG ( 127): beb4aabc 4020191d /system/lib/libc.so (__libc_fini)

I/DEBUG ( 127): beb4aac0 4020191d /system/lib/libc.so (__libc_fini)

I/DEBUG ( 127): beb4aac4 40100eac /system/bin/testapp

I/DEBUG ( 127): beb4aac8 00000000
I/DEBUG ( 127): beb4aacc 400ff469 /system/bin/testapp

I/DEBUG ( 127): beb4aad0 beb4ab24 [stack]

I/DEBUG ( 127): beb4aad4 00000001
I/DEBUG ( 127): beb4aad8 beb4ab2c [stack]

I/DEBUG ( 127): beb4aadc 00000000
I/DEBUG ( 127): beb4aae0 df0027ad
I/DEBUG ( 127): beb4aae4 00000000
I/DEBUG ( 127): #00 beb4aae8 00000000
I/DEBUG ( 127): ........ ........

I/DEBUG ( 127): #01 beb4aae8 00000000
I/DEBUG ( 127): beb4aaec 401e9721 /system/lib/libc.so (__libc_init+40)

I/DEBUG ( 127): #02 beb4aaf0 beb4ab08 [stack]

I/DEBUG ( 127): beb4aaf4 00000000
I/DEBUG ( 127): beb4aaf8 00000000
I/DEBUG ( 127): beb4aafc 00000000
I/DEBUG ( 127): beb4ab00 00000000
I/DEBUG ( 127): beb4ab04 400ff404 /system/bin/testapp

I/DEBUG ( 127):

这个log就不那么容易懂了，但是还是能从中看出很多信息，让我们一起来学习如何分析这种log。首先看下面这行：

pid: 2102, tid: 2102,name: testapp >>>./testapp <<<
从这一行我们可以知道crash进程的pid和tid，前文我们已经提到过，Android调用gettid函数得到的实际是进程Id号，所以这里的pid和tid相同。知道进程号后我们可以往前翻翻log，看看该进程最后一次打印的log是什么，这样能缩小一点范围。

接下来内容是进程名和启动参数。再接下来的一行比较重要了，它告诉了我们从系统角度看，出错的原因：

signal 11 (SIGSEGV), code 1(SEGV_MAPERR), fault addr 00000000

signal11是Linux定义的信号之一，含义是Invalidmemory reference，无效的内存引用。加上后面的“faultaddr 00000000”我们基本可以判定这是一个空指针导致的crash。当然这是笔者为了讲解而特地制造的一个Crash的例子，比较容易判断，大部分实际的例子可能就没有那么容易了。

再接下来的log打印出了cpu的所有寄存器的信息和堆栈的信息，这里面最重要的是从堆栈中得到的backtrace信息：

I/DEBUG ( 127):backtrace:

I/DEBUG ( 127): #00 pc0000045e /system/bin/testapp

I/DEBUG ( 127): #01 pc0000046b /system/bin/testapp

I/DEBUG ( 127): #02 pc0001271f /system/lib/libc.so (__libc_init+38)

I/DEBUG ( 127): #03 pc00000400 /system/bin/testapp

因为实际的运行系统里没有符号信息，所以打印出的log里看不出文件名和行数。这就需要我们借助编译时留下的符号信息表来翻译了。Android提供了一个工具可以来做这种翻译工作：arm-eabi-addr2line，位于prebuilts/gcc/linux-x86/arm/arm-eabi-4.6/bin目录下。用法很简单：

#./arm-eabi-addr2line -f -eout/target/proct/hammerhead/symbols/system/bin/testapp0x0000045e

参数-f表示打印函数名；参数-e表示带符号表的模块路径；最后是要转换的地址。这条命令在笔者的编译环境中得到的结果是：

memcpy /home/rd/compile/android-4.4_r1.2/bionic/libc/include/string.h:108

剩余三个地址翻译如下：

main /home/rd/compile/android-4.4_r1.2/packages/apps/testapp/app_main.cpp:38

out_vformat /home/rd/compile/android-4.4_r1.2/bionic/libc/bionic/libc_logging.cpp:361

_start libgcc2.c:0

利用这些信息我们很快就能定位问题了。不过这样手动一条一条的翻译比较麻烦，笔者使用的是从网上找到的一个脚本，可以一次翻译所有的行，有需要的读者可以在网上找一找。

了解了如何分析普通的Log文件，下面让我们再看看如何分析ANR的Log文件。