Android应用Log分析入门

2019独角兽企业重金招聘Python工程师标准>>>

Android平台提供了多种log输出，这里主要针对常见的几种问题提供一些基础的分析指南。

1. Java Crash

Java Crash是我们最为常见的严重错误了。在Logcat中，可以找到其报错的地方，通过其标注的位置开始调查代码。

例如：

11-21 07:26:07.273 E/AndroidRuntime( 3755): FATAL EXCEPTION: main
11-21 07:26:07.273 E/AndroidRuntime( 3755): java.lang.NullPointerException
11-21 07:26:07.273 E/AndroidRuntime( 3755):     at com.csi.player.mediaCallback(SourceFile:422)
...

在这里，log里面已经明确说明了错误的类型为"java.lang.NullPointerException", 和发现这个问题的代码"mediaCallback.java"的422行。

常见的严重错误有如下几类：

• NullPointerException:  空对象错误
  IllegalStateException：非法状态，比如在View没有刷出来的时候去触摸。
  IndexOutOfBoundsException
  IllegalArgumentException
  ExceptionInInitializerError
  ClassCastException
  RuntimeException
  UnknownFormatConversionException
  UnsupportContentTypeException
  CursorIndexOutOfBoundsException
  
  

2.ANR

ANR是一种常见的严重错误，在logcat中会直接给出造成ANR的原因，例如：

11-01 18:16:15.966 E/ActivityManager(  344): ANR in com.android.systemui
11-01 18:16:15.966 E/ActivityManager(  344): Reason: Broadcast of Intent { act=android.intent.action.TIME_TICK flg=0x40000014 (has extras) }

以上这个ANR就是由BroadcastTimeout引起的。

常见的ANR原因有如下：

KeyDispatchTimeout(5 seconds)	Key事件响应超时
BroadcastTimeout(10 seconds)	BroadcastReceiver超时
ServiceTimeout(20 seconds)	Service超时

当ANR发生时，我们可以在/data/anr/下面发现响应的trace.txt里面会有ANR的callstack，有助于我们定位问题。

3. Tombstone

tombstone一般是由Dalvik错误、状态监视调试器、C层代码以及libc的一些问题导致的。当系统发生tombstone的时候，kernel首先会上报一个严重的警告信号（serious signal）,上层接收到之后，进程的调试工具会把进程中当时的调用栈现场保存起来，并在系统创建了data/tombstones目录后把异常时的进程信息写在此目录里面，开发者需要通过调用栈来分析整个调用流程来找出出问题的点。

这里主要介绍一下常用的分析步骤：

 a. 首先查看日志文件，搜索"SEGV_MAPERR" 或者 "SEGV_ACCERR"，

注： SEGV_MAPERR地址没有映射到对象，SEGV_ACCERR对映射的对象没有权限

例如：

pid: 122, tid: 14745, name: Binder_2  >>> /system/bin/mediaserver <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000058
    eax 00000000  ebx 41bbf784  ecx 00000000  edx 00000009
    esi 450578f0  edi 40378054
    xcs 00000073  xds 0000007b  xes 0000007b  xfs 00000000  xss 0000007b
    eip 4088a5c2  ebp 45e15cb8  esp 45e15ca0  flags 00010297

b. 再看backtrace

 #00  pc 000085c2  /system/lib/libcameraservice.so (android::CameraHardwareInterface::__set_buffer_count(preview_stream_ops*, int)+34)
    #01  pc 0003b6fa  /system/lib/hw/camera.XXXX.so (android::PreviewThread::allocateGfxPreviewBuffers(int)+154)
    #02  pc 0003ce83  /system/lib/hw/camera.XXXX.so (android::PreviewThread::threadLoop()+1203)
    #03  pc 0001a2bc  /system/lib/libutils.so (android::Thread::_threadLoop(void*)+556)
    #04  pc 0000dda8  /system/lib/libc.so (__thread_entry+248)
    #05  pc 0001b031  /system/lib/libc.so
    #06  pc 00001f2c  /system/lib/libc.so

从这段log来看，发现问题发生时，出错的lib为libcameraservice.so。

c. 如果需要进一步分析，需要动用symbol文件，具体步骤这次就不详述了。

4. Memory Leak

在Logcat输出中，会出现

E/AndroidRuntime(1112):
Caused by: java.lang.OutOfMemoryError: bitmap size
exceeds VM budget
E/AndroidRuntime(1112):
at android.graphics.BitmapFactory.nativeDecodeAsset(Native Method)
E/AndroidRuntime(1112):
at android.graphics.BitmapFactory.decodeStream(BitmapFactory.java:447)
E/AndroidRuntime(1112):
at android.graphics.BitmapFactory.decodeResourceStream(BitmapFactory.java:323)
E/AndroidRuntime(1112):

这里1112是进程的pid，代表出现OOM的应用。如果需要详细分析，一般来说需要先制造出来hprof文件，详细做法请参考Memaory debug。

5. Kernel Panic

通过demsg命令可以查看到内核log输出。查找kernel panic和Bug等字样就能找到。

转载于:https://my.oschina.net/milojiang/blog/268982