Logcat日志详细解析
--------- beginning of xxxx
解析：日志以--------- beginning of xxxx为起点，开始捕捉Android日志。xxx对应这存储着Android日志记录器的环形缓冲区。Android系统在运行时会时刻在几个设备文件中的一个中写入字符串。而这几个设备文件指向几个环形缓冲区。这是Android日志的记录原理。而这几个缓冲区合称日志记录器缓冲区。
扩展，讲讲logcat缓冲区log。
logcat缓冲区介绍： android log输出量巨大，特别是通信系统的log, 缓冲区主要给系统组件使用，一般的应用不需要关心，应用的log都输出到main缓冲区中 .
Radio：无线电，无线网络设备/电话通讯相关log
System：系统，系统组件或系统应用的log
Event：事件，事件/监听相关log
Main：主要，所有java层的log，遗迹不属于上面3层的log
Crash：崩溃，应用崩溃时在此写入崩溃信息log
注意：使用命令adb logcat -b default时（显示默认的缓冲区log），未特殊指定缓冲区名称,指main,system,crash缓冲区的log。
02-10 10:13:14.234 21857 18515 E AndroidRuntime: FATAL EXCEPTION: URGENT_THREAD_540
日志时间：02-10 10:13:14.234
PID（进程ID）：21857
TID（线程ID）：18515
优先级：E
便签：AndroidRuntime
正文日志：FATAL EXCEPTION: URGENT_THREAD_540
现在再针对这句话给进行详细的说明（不带任何参数的logcat命令）：
默认输出的日志格式：（不带任何参数的logcat命令）由六部分组成：
写下日志时的时间，如上中07-22 20:31:21.565。
PID（进程ID），如上中993。
TID（线程ID），如上中1032。
优先级，在Android中，日志的优先级从低到高分以下几种： V—Verbose（啰嗦，最低级别，开发调试中的一些详细信息，仅在开发中使用，不可在发布产品中输出，不是很常见，包含诸如方法名，变量值之类的信息）
D—Debug（调试，用于调试的信息，可以在发布产品中关闭，比较常见，开发中经常选择输出此种级别的日志，有时在beta版应用中出现）
I—Info（信息，该等级日志显示运行状态信息，可在产品出现问题时提供帮助，从该级别开始的日志通常包含完整意义的英语语句和调试信息，是最常见的日志级别）
W—Warning（警告，运行出现异常即将发生错误或表明已发生非致命性错误，该级别日志通常显示出执行过程中的意外情况，例如将try-catch语句块中的异常打印堆栈轨迹之后可输出此种级别日志）
E—Error（错误，已经出现可影响运行的错误，比如应用crash时输出的日志）
F—Fatal（严重错误，比error级别更高，目前我只在android系统内核发出的日志中看到此种级别。在Android6.0以前表明开发者认为绝对不应该出现的错误，在此以后一般开发场景下绝不应该输出此种级别的日志）
S—Silent（寂静，最高级别，没有一条日志会属于这个级别，仅仅作为关闭logcat输出的过滤器参数） 示例中日志等级显示为W，表示警告级别。
标签，标明日志发起者和方便日志的过滤筛选，如上中BroadcastQueue，表示该日志关于广播队列。
正文，本日志的主体内容。示例日志中表示一个后台执行被阻止，并显示出了接收到的意图的详细信息
从logcat.log中发现内存泄漏方法
在logcat.log中搜索关键词GC，如果有下面四个中的一个，就可能存在内存泄露。
GC_FOR_ALLOC, 因为在分配内存时内存丌够引发的 GC_EXPLICIT, 表明GC被显式请求触发的，如System.gc调用 GC_CONCURRENT, 表明GC在内存使用率达到一定的警戒值时，自动触发。 GC_BEFORE_OOM, 表明在虚拟机抛出内存丌够异常ＯＯＭ之前，执行最后一次回收内存垃圾 举例：
02-27 14:42:52.544 I/art ( 1844): Background sticky concurrent mark sweep GC freed 181925(7MB) AllocSpace objects, 0(0B) LOS objects, 9% free, 74MB/82MB, paused 2.857ms total 104.330ms
解析：Gson序列化问题导致的内存溢出，问题原因，如果在json model里面放了非可序列化的对象就会导致这中问题，可序列化的就是那些基础数据类型和集合类型，如果在里面放个Android的Activity或者adapter这类类型字段，变量声明前面一定要加
transient，否则就是长期GC提示。
从logcat.log中查找ANR以及ForceClosed 等异常退出问题
如果是ANR问题 ， 则搜索“ANR ”关键词(ANR后加个空格，屏蔽掉anr.log文件的无效信息) 。 快速定位到关键事件信息 。 如果是ForceClosed 和其它异常退出信息，则搜索"Fatal" 关键词， 快速定位到关键事件信息 。 定位到关键事件信息后 ， 如果信息不够明确的，再去搜索应用程序包的虚拟机信息 ，查看具体的进程和线程跟踪的日志，来定位到代码 。 traces日志中ANR的定位与分析
当ANR发生时除过logcat可以看见的log以外，我们还可以在系统指定目录下找到traces文件进行分析，获取ANR trace文件： adb pull /data/anr/traces.txt /Users/weixiangyang/Desktop/ 分析虚拟机信息，搜索Dalvik Thread关键词，快速定位到本应用程序的虚拟机信息日志，如下： //显示进程id、ANR发生时间点、ANR发生进程包名 ----- pid 8562 at 2018-03-03 14:39:49 ----- Cmd line: com.taobao.taobao //一些GC等object信息，通常可以忽略 … //ANR方法堆栈打印信息！重点！ DALVIK THREADS (132): “main” prio=5 tid=1 Native | group=“main” sCount=1 dsCount=0 obj=0x787c5000 self=0x7f8e696a00 | sysTid=1786 nice=-10 cgrp=default sched=0/0 handle=0x7f92c45aa0 | state=S schedstat=( 0 0 0 ) utm=17421 stm=10643 core=4 HZ=100 | stack=0x7fcaf1e000-0x7fcaf20000 stackSize=8MB | held mutexes= kernel: (couldn’t read /proc/self/task/1786/stack) native: #00 pc 0000000000078230 /system/lib64/libc.so (__epoll_pwait+8) native: #01 pc 000000000001e80c /system/lib64/libc.so (epoll_pwait+64) native: #02 pc 00000000000185c0 /system/lib64/libutils.so (_ZN7android6Looper9pollInnerEi+160) native: #03 pc 0000000000018460 /system/lib64/libutils.so (_ZN7android6Looper8pollOnceEiPiS1_PPv+60) native: #04 pc 00000000000f2d24 /system/lib64/libandroid_runtime.so (_ZN7android18NativeMessageQueue8pollOnceEP7_JNIEnvP8_jobjecti+48) native: #05 pc 0000000000b790b0 /system/framework/arm64/boot-framework.oat (Java_android_os_MessageQueue_nativePollOnce__JI+140) //真正导致ANR的问题点 at android.os.MessageQueue.nativePollOnce(Native method) at android.os.MessageQueue.next(MessageQueue.java:323) at android.os.Looper.loop(Looper.java:142) at com.android.server.SystemServer.run(SystemServer.java:377) at com.android.server.SystemServer.main(SystemServer.java:239) at java.lang.reflect.Method.invoke!(Native method) at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:901) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:791) … //省略一些不常关注堆栈打印
每一段都是一个线程 。通过分析发现关键问题，到这里就可以找开发协助，深入代码具体分析，将 traces日志，logcat有问题的日志进行整理，发给开发工程师即可！
