android自定义log

① android+slog+log区别是怎么回事

工具/原料

Eclipse
Android SDK
方法/步骤

日常Android开发真机调试过程经常会遇到系统日志过多过快，想看的内容一闪而过的问题。而自定义些log可以很好的解决这些问题。
代码中添加 log
androidsdk中提供了log输出的api，方法在android.util.Log类中。
Log.v(tag,message); //verbose模式,打印最详细的日志
Log.d(tag,message); //debug的日志
Log.i(tag,message); //info的日志
Log.w(tag,message); //warn的日志
Log.e(tag,message); //error的日志
根据首字母对应VERBOSE，DEBUG，INFO，WARN，ERROR。
tag和message分别是两个String值
tag用来标记log消息的源头的. message是这条log的内容。
看代码我这里写了5行日志对应不同的级别

查看log
Activity其中的中加上了Log.v来记录日志输出,结果如下图.

Eclipse指定看某个tag信息
当然我们也可以指定看某个日志信息，具体是在Eclipse LohCat中设置需要看的tag，可见图中红色框体。在by Log Tag中设置先看的日志tag。

这里我设置tag为 ，运行程序。

就可以看到指定的某个log信息了，这样调试代码起来是不是很方便。

② android 自定义一个log类带有开关，debug赋值true，那什么时候变成false

Debug和Release区别 VC下Debug和Release区别 最近写代码过程中，发现 Debug 下运行正常，Release 下就会出现问题，百思不得其解，而Release 下又无法进行调试，于是只能采用printf方式逐步定位到问题所在处，才发现原来是给定的一个数组未初始化，导致后面处理异常。网上查找了些资料，在这 罗列汇总下，做为备忘～ 一、Debug 和 Release 的区别 Debug 通常称为调试版本，它包含调试信息，并且不作任何优化，便于程序员调试程序。Release 称为发布版本，它往往是进行了各种优化，使得程序在代码大小和运行速度上都是最优的，以便用户很好地使用。 Debug 和 Release 的真正区别，在于一组编译选项。 Debug 版本 参数 含义 /MDd /MLd 或 /MTd 使用 Debug runtime library(调试版本的运行时刻函数库) /Od 关闭优化开关 /D "_DEBUG" 相当于 #define _DEBUG,打开编译调试代码开关(主要针对assert函数) /ZI 创建 Edit and continue(编辑继续)数据库，这样在调试过程中如果修改了源代码不需重新编译 GZ 可以帮助捕获内存错误 Release 版本 参数含义 /MD /ML 或 /MT 使用发布版本的运行时刻函数库 /O1 或 /O2 优化开关，使程序最小或最快 /D "NDEBUG" 关闭条件编译调试代码开关(即不编译assert函数) /GF 合并重复的字符串，并将字符串常量放到只读内存，防止被修改 Debug 和 Release 并没有本质的界限，他们只是一组编译选项的集合，编译器只是按照预定的选项行动。 1. 变量。 大家都知道，debug跟release在初始化变量时所做的操作是不同的，debug是将每个字节位都赋成0xcc(注1)，而release的赋值近 似于随机(我想是直接从内存中分配的，没有初始化过)。这样就明确了，如果你的程序中的某个变量没被初始化就被引用，就很有可能出现异常：用作控制变量将 导致流程导向不一致；用作数组下标将会使程序崩溃；更加可能是造成其他变量的不准确而引起其他的错误。所以在声明变量后马上对其初始化一个默认的值是最简 单有效的办法，否则项目大了你找都没地方找。代码存在错误在debug方式下可能会忽略而不被察觉到，如debug方式下数组越界也大多不会出错，在 release中就暴露出来了，这个找起来就比较难了:( 还是自己多加注意吧 呵呵，就是我犯的问题～～ 2. 自定义消息的消息参数。 MFC为我们提供了很好的消息机制，更增加了自定义消息，好处我就不用多说了。这也存在debug跟release的问题吗？答案是肯定的。在自定义消息 的函数体声明时，时常会看到这样的写法：afx_msg LRESULT OnMessageOwn(); Debug情况下一般不会有任何问题，而当你在Release下且多线程或进程间使用了消息传递时就会导致无效句柄之类的错误。导致这个错误直接原因是消 息体的参数没有添加，即应该写成：afx_msg LRESULT OnMessageOwn(WPARAM wparam, LPARAM lparam); (注2) 3. release模式下不出错，但debug模式下报错。 这种情况下大多也是因为代码书写不正确引起的，查看MFC的源码，可以发现好多ASSERT的语句(断言)，这个宏只是在debug模式下才有效，那么就 清楚了，release版不报错是忽略了错误而不是没有错误，这可能存在很大的隐患，因为是Debug模式下，比较方便调试，好好的检查自己的代码，再此 就不多说了。 4. ASSERT, VERIFY, TRACE..........调试宏 这种情况很容易解释。举个例子：请在VC下输入ASSERT然后选中按F12跳到宏定义的地方，这里你就能够发现Debug中ASSERT要执行 AfxAssertFailedLine，而Release下的宏定义却为"#define ASSERT(f) ((void)0)"。所以注意在这些调试宏的语句不要用程序相关变量如i++写操作的语句。VERIFY是个例外，"#define VERIFY(f) ((void)(f))"，即执行，这里的作用就不多追究了，有兴趣可自己研究:)。 总结： Debug与Release不同的问题在刚开始编写代码时会经常发生，99%是因为你的代码书写错误而导致的，所以不要动不动就说系统问题或编译器问题， 努力找找自己的原因才是根本。我从前就常常遇到这情况，经历过一次次的教训后我就开始注意了，现在我所写过的代码我已经好久没遇到这种问题了。下面是几个 避免的方面，即使没有这种问题也应注意一下： 1. 注意变量的初始化，尤其是指针变量，数组变量的初始化(很大的情况下另作考虑了)。 2. 自定义消息及其他声明的标准写法 3. 使用调试宏时使用后最好注释掉 4. 尽量使用try - catch(...) 5. 尽量使用模块，不但表达清楚而且方便调试。 注1： debug版初始化成0xcc是因为0xcc在x86下是一条int 3单步中断指令，这样程序如果跑飞了遇到0xcc就会停下来，这和单片机编程时一般将没用的代码空间填入jmp 0000语句是一样地转贴于：计算机二级考试_考试大【责编:drfcy 纠错】 [VC]DEBUG和RELEASE2007年08月26日 星期日 下午 04:33 I. 内存分配问题 1. 变量未初始化。下面的程序在debug中运行的很好。 thing * search(thing * something) BOOL found; for(int i = 0; i < whatever.GetSize(); i++) { if(whatever[i]->field == something->field) { /* found it */ found = TRUE; break; } /* found it */ } if(found) return whatever[i]; else return NULL; 而在release中却不行，因为debug中会自动给变量初始化found=FALSE,而在release版中则不会。所以尽可能的给变量、类或结构初始化。 2. 数据溢出的问题 如：char buffer[10]; int counter; lstrcpy(buffer, "abcdefghik"); 在debug版中buffer的NULL覆盖了counter的高位，但是除非counter>16M,什么问题也没有。但是在release版 中，counter可能被放在寄存器中，这样NULL就覆盖了buffer下面的空间，可能就是函数的返回地址，这将导致ACCESS ERROR。 3. DEBUG版和RELEASE版的内存分配方式是不同的 。如果你在DEBUG版中申请 ele 为 6*sizeof(DWORD)=24bytes,实际上分配给你的是32bytes（debug版以32bytes为单位分配）， 而在release版，分配给你的就是24bytes（release版以8bytes为单位），所以在debug版中如果你写ele[6],可能不会有 什么问题，而在release版中，就有ACCESS VIOLATE。 II. ASSERT和VERIFY 1. ASSERT在Release版本中是不会被编译的。 ASSERT宏是这样定义的 #ifdef _DEBUG #define ASSERT(x) if( (x) == 0) report_assert_failure() #else #define ASSERT(x) #endif 实际上复杂一些，但无关紧要。假如你在这些语句中加了程序中必须要有的代码 比如 ASSERT(pNewObj = new CMyClass); pNewObj->MyFunction(); 这种时候Release版本中的pNewObj不会分配到空间 所以执行到下一个语句的时候程序会报该程序执行了非法操作的错误。这时可以用VERIFY ： #ifdef _DEBUG #define VERIFY(x) if( (x) == 0) report_assert_failure() #else #define VERIFY(x) (x) #endif 这样的话，代码在release版中就可以执行了。 III. 参数问题： 自定义消息的处理函数，必须定义如下： afx_msg LRESULT OnMyMessage(WPARAM, LPARAM); 返回值必须是HRESULT型，否则Debug会过，而Release出错 IV. 内存分配 保证数据创建和清除的统一性：如果一个DLL提供一个能够创建数据的函数，那么这个DLL同时应该提供一个函数销毁这些数据。数据的创建和清除应该在同一个层次上。 V. DLL的灾难 人们将不同版本DLL混合造成的不一致性形象的称为 “动态连接库的地狱“(DLL Hell) ，甚至微软自己也这么说 如果你的程序使用你自己的DLL时请注意： 1. 不能将debug和release版的DLL混合在一起使用。debug都是debug版，release版都是release版。 解决办法是将debug和release的程序分别放在主程序的debug和release目录下 2. 千万不要以为静态连接库会解决问题，那只会使情况更糟糕。 VI. RELEASE板中的调试 ： 1. 将ASSERT() 改为 VERIFY() 。找出定义在"#ifdef _DEBUG"中的代码，如果在RELEASE版本中需要这些代码请将他们移到定义外。查找TRACE(...)中代码，因为这些代码在RELEASE中 也不被编译。 请认真检查那些在RELEASE中需要的代码是否并没有被便宜。 2. 变量的初始化所带来的不同，在不同的系统，或是在DEBUG/RELEASE版本间都存在这样的差异，所以请对变量进行初始化。 3. 是否在编译时已经有了警告?请将警告级别设置为3或4,然后保证在编译时没有警告出现. VII. 将Project Settings" 中 "C++/C " 项目下优化选项改为Disbale（Debug）。编译器的优化可能导致许多意想不到的错误 1. 此外对RELEASE版本的软件也可以进行调试，请做如下改动： 在"Project Settings" 中 "C++/C " 项目下设置 "category" 为 "General" 并且将"Debug Info"设置为 "Program Database"。 在"Link"项目下选中"Generate Debug Info"检查框。 "Rebuild All" 如此做法会产生的一些限制： 无法获得在MFC DLL中的变量的值。 必须对该软件所使用的所有DLL工程都进行改动。

③ Android studio怎么自定义logcat提示信息

一、下载安装 下载后，打开并将Android Studio拖动到Applications中去，拷贝完毕即可，可以到应用程序下将图标拖动到Dock上。 二、新建工程 安装完成后，选择默认选项点击OK即可： 进入Android Studio，开始界面和Xcode有点类似，点击New project新建一个工程，新建过程和在Eclipse上差不多。 新建工程完毕后就进入了Android Studio主界面。第一次进去可能什么也没有，点击箭头所示按钮目录结构， 后可以看到Android Studio的目录结构，和Eclipse的工程还是有一点区别的： 区别： 1.Android Studio的目录结构本来就代表一个workspace，一个workspace里面可以有Mole，可以将一个Mole理解成Eclipse中的一个Project； 2.目录中将java代码和资源文件（图片、布局文件等）全部归结为src，在src目录下有一个main的分组，同时划分出java和res两个Group，res和Eclipse下的结构一样，java下就是源码的包和类文件； 3.新建文件方式的不同，右键选择New或Command+N后出现新建菜单，类型有Java Class，也就是一般的java类，File就是普通文件，Package就是建包，值得注意的就是Android Component，它直接提供了Android中基本组件的创建。 可以选择创建Android中不同类型的组件： 三、窗口布局及主题介绍 另外，主界面底部有一个名为Android的选项卡，打开可以看到DDMS中的设备信息和Logcat输出： 顶部工具栏中可以看到和Eclipse中功能一样的一个选项，这些相信大家都比较熟悉了： 最后需要说明的是，大家看到我的主界面是暗色风格，和Google演示的是一样的风格，大家第一次使用打开的是默认风格（亮色），如果想要修改的话，进入Preferences（按Command+，）到IDE Settings下选择Colors&font并设置Schema name为Darcula就可以设置成暗色风格，如果需要自己定义样式，比如字体大小颜色等，可以新建一个Schema来自己定义 四、布局文件编写（实时预览） 最炫的功能要来了，实时编写并预览布局文件，此项功能着实大大提高开发效率，打开一个xml布局文件点击右侧Preview选项卡即可唤出预览界面，可以选择很多尺寸的手机进行预览： 同时，还可以同时预览多种不同型号和尺寸的设备，编写代码的同时适配多种机型，这不就是当初梦寐以求的嘛！ 上面介绍了Android Studio的基本使用，包括安装、新建工程、工程结构以及主题设置。下面介绍一些其他技巧，以及与Eclipse之前的一些对比。需要重申一下，我所有的操作与版本是基于Mac系统，在Windows上的同学基本类似，下面就分主题开始吧： 一、从Eclipse导入工程到Android Studio 根据官方的介绍，Android Studio可以兼容Eclipse的现有工程，但需要做一些操作： 首先升级ADT到最新版本，目前为版本号为22（注意和ADT相关的组件最好一并升级，避免后期可能出现的错误） 选择需要从Eclipse导出的工程，右键选择Export并选择Android下的Generate Gradle Build Files 选择完毕后并不会导出到其他地方，而是在本地工程生成了一个build.gradle文件，在Eclipse工程中也可以看到，这个文件是Android Studio识别的 3.随后进入Android Studio并选择Import Project，可以看到刚刚在Eclipse中的项目图标变成了一个Android机器人图标，说明转换成功，这时候选择工程导入即可： 至此，就完成了从Eclipse导入现有Android工程到Android Studio，现在可以开始对工程进行操作了！ 二、Eclipse工程与Android Studio的区别 Eclipse工程可以导入Android Studio运行，而反过来在Android Studio建立的工程不能在Eclipse中运行； 二者的工程结构不一样，在Eclipse中一个Project就代表一个项目工程，而在Android Studio中就和Intellij一样，一个Project代表一个工作空间，相当于Eclipse中的workspace，而在Android Studio中一个Mole就相当于Eclipse中的一个Project，这个概念需要弄明白，不要混了或觉得糊涂了。 在编辑操作上，在Eclipse中编辑修改后必须手动command+s保存文件，而在Android Studio中就和Intellij一样是自动保存的，这一点和第二点和Xcode也是类似的。 工程目录上的区别，在Eclipse中src部分一般是java文件，res部分是资源文件，包括布局文件和多媒体资源等。在Android Studio中 包括java文件和资源文件全部放到了src目录下，src目录下包括一个main文件夹，再下面就是java文件夹和res文件夹，其实这里，java文件夹就相当于Eclipse中的src，res还是那个res，这里想起了本山老师的小品“src已经不是那个src了，res还是那个res” 三、真机运行以及常用快捷键 在Android Studio中点击界面下方的Android选项卡可以看到Device信息和Logcat，连上设备后打开Android选项卡会检测真机，成功后会显示在Device中，点击顶部的绿色小箭头就可以开始运行工程了。有一点需要注意的是，运行时可以选择模拟器也可以选择真机，由于在Android Studio中运行工程的时候有一个Device优先级选择，如果不设置的话可能会出现只运行在模拟器上的现象，我们可以自行设置一下：先点击Run菜单选择Run Configuration，并选择你想选择的目标设备，可以是模拟器和真机，也可以在运行选由用户选择： 快捷键大家可以对照官方文档进行熟悉，如下表，也可以自己修改配置选项进行自定义： 个人觉得Android Studio还是有一定的前景的，这里就需要Google不断进行完善和改进了，赶紧把大家从Eclipse中解救出来吧。另外，在此期间，大家其实可以尝试使用一下Intellij IDEA，这个默认也是集成Android开发环境的。Android Studio是基于前者改进而来，二者在使用上差不多，也是Eclipse的一个不错的替代者。

④ 如何实现一个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文件。

⑤ android开发怎么使用log

这个问题问的过于笼统了，给你做个截图说明几点吧

1. 

   这张图是过滤log信息用的，可以自定义log的tag，一般都是程序中log的tag，类似

   private static final String tag = "WebActivity";

   暂时就这吧

⑥ Android studio怎么自定义logcat提示信息

进行点击android studio菜单中的file的选项之后，弹出了下拉菜单中进行选择为“settings”的选项。

进入到了settings的选项框中，进行选中列表中的editor的选项。

进行点击editor的会展开，进行点击android logcat的选项。

由于默认的设置是不能修改的所以需要自己进行创建，进行点击save as的选项，需要输入文件名，名字可以随意去

新建的android logcat还是不能直接修改，把use inherited attribute的沟去掉。

这些设置主要进行设置颜色的选项，进行点击颜色按钮。

弹出了select color的窗口之后，进行选择需要的颜色，然后进行点击choose。

可以看到assert在logcat预览中显示为深蓝的颜色。其它设置的设置也是类似。

⑦ Android中怎么控制LogCat的自定义输出

你好！首先log有很多类型
log.v(String tag,String msg); // 冗余消息
log.d(String tag,String msg); // 调试消息
log.i(String tag,String msg); // 普通消息
log.w(String tag,String msg); //警告消息
log.e(String tag,String msg); // 错误消息
关于您说的建立一个log的tag，可用如下语句来实现
private static final String TAG="此处写您要设置的tag"

然后再程序中我一般用的是Log.v(TAG,"想打印的信息")
这样的话，在logcat中就可以显示出自定义的TAG

⑧ 实现android开机自动生成log的脚本

用广播接收者,接收开机广播,然后在广播里开启一条服务
在服务里写对log文件的写出就行了
开机广播为:
<action android:name="android.intent.action.BOOT_COMPLETED" />