• [整理]Android测试日志文件抓取与分析 -顶


    http://blog.csdn.net/ameyume/article/details/7667574

    1.log文件分类简介
    实时打印的主要有:logcat main,logcat radio,logcat events,tcpdump,还有高通平台的还会有QXDM日志
    状态信息的有:adb shell cat /proc/kmsg ,adb shell dmesg,adb shell dumpstate,adb shell dumpsys,adb bugreport,工程模式等


    2.LOG抓取详解
    (1)实时打印
    adb logcat -b main -v time>app.log  打印应用程序的log

    adb logcat -b radio -v time> radio.log 打印射频相关的log,SIM STK也会在里面,modem相关的ATcommand等,当然跟QXDM差的很远了。

    adb logcat -b events -v time  打印系统事件的日志,比如触屏事件。。。

    tcpdump 是很有用的,对于TCP/IP协议相关的都可以使用这个来抓,adb shell tcpdump -s 10000 -w /sdcard/capture.pcap,比如抓mms下载的时候的UA profile,browser上网的时候,使用proxy的APN下载,streaming的相关内容包括UA profile等。

    最后是高通平台的QXDM,不管是不是Android,只要使用高通芯片,都会对它很熟悉,当然了,不是高通的芯片就不用提它了。这个不多讲,内容丰富,射频,电话,上网,...凡是高通提供的解决方案,这个都可以抓。(QXDM 的LOG抓取方法请参考QPST、QXDM的基本使用说明及作用)

    (2)状态信息
    bugreport(命令adb bugreport>bugreport.log)。里面包含有dmesg,dumpstate和dumpsys。

    dumpstate是系统状态信息,里面比较全,包括手机当前的内存信息、cpu信息、logcat缓存,kernel缓存等等。

    adb shell dumpsys这个是关于系统service的内容都在这个里面,这个命令还有更详尽的用法,比如adb shell dumpsys meminfo system是查看system这个process的内存信息。

    kmsg抓取
    adb shell cat /proc/kmsg > kmsg.txt,打开后查msm_kgsl字段

    说明:用于检索用printk生成的内核消息。任何时刻只能有一个具有超级用户权限的进程可以读取这个文件。也可以用系统调用syslog检索这些消息。通常使用工具dmesg或守护进程klogd检索这些消息。proc是一个内存文件系统, 每次读文件kmsg实际是内核内部的循环缓冲区,每读过后,循环缓冲区的东西就被认为已经处理过了(也就是变成无效内容),所以你再次读为空是很正常的 为什么会这样处理呢,循环缓冲区大小有限,内核又随时可能往里面写东西,所以这样处理很正常. 你去查一下/proc/kmsg的信息有没有跟系统日志关联,如果有的话,你就可以读日志文件

    dmsg抓取
    adb shell dmesg > dmesg.txt

    说明:dmesg用来显示开机信息,kernel会将开机信息存储在ring buffer中。您若是开机时来不及查看信息,可利用dmesg来查看。dmesg是kernel的log,凡是跟kernel相关的,比如driver出了问题(相机,蓝牙,usb,启动,等等)开机信息亦保存在/var/log目录中,名称为dmesg的文件里。more /var/log/dmesg

    工程模式下log的抓取
    对于Apollo手机请拨打*#*#8888#*#* ,然后勾选相应的LOG。待测试结束后,通过SD卡导出LOG到PC.


    3.Log分析
    Get Log from Android System

    adb bugreport > bugreport.txt

    copy bugreport to the current directory.

    bugreport里面包含了各种log信息,大部分log也可以通过直接运行相关的程序来直接获得.

    步骤如下:
    (1)adb shell
    (2)进入相关工具程式的目录
    (3)执行相关程式
    (4)得到相关信息

    下面以输出进程信息为例
    (1)adb shell
    (2)输入ps -P
    (3)可以看到相关进程信息
     

    --------------------------------------------------------------------------------------------------

    Log Archive Analysis 

    1.bugreport
    bugreport记录android启动过程的log,以及启动后的系统状态,包括进程列表,内存信息,VM信息等等到.

    2.bugreport结构分析
    (1)dumpstate

    MEMORY INFO
    获取该log:读取文件/proc/meminfo
    系统内存使用状态

    CPU INFO
    获取该log:执行/system/bin/top -n 1 -d 1 -m 30 -t
    系统CPU使用状态

    PROCRANK
    获取该log:执行/system/bin/procrank
    执行/system/xbin/procrank后输出的结果,查看一些内存使用状态

    VIRTUAL MEMORY STATS
    获取该log:读取文件/proc/vmstat
    虚拟内存分配情况

    vmalloc申请的内存则位于vmalloc_start~vmalloc_end之间,与物理地址没有简单的转换关系,虽然在逻辑上它们也是连续的,但是在物理上它们不要求连续。

    VMALLOC INFO  
    获取该log:读取文件/proc/vmallocinfo
    虚拟内存分配情况

    SLAB INFO
    获取该log:读取文件/proc/slabinfo
    SLAB是一种内存分配器.这里输出该分配器的一些信息

    ZONEINFO
    获取该log:读取文件/proc/zoneinfo
    zone info

    SYSTEM LOG(需要着重分析)
    获取该log:执行/system/bin/logcat -v time -d *:v
    会输出在程序中输出的Log,用于分析系统的当前状态

    VM TRACES
    获取该log:读取文件/data/anr/traces.txt
    因为每个程序都是在各自的VM中运行的,这个Log是现实各自VM的一些traces

    EVENT LOG TAGS
    获取该log:读取文件/etc/event-log-tags

    EVENT LOG
    获取该log:执行/system/bin/logcat -b events -v time -d *:v
    输出一些Event的log

    RADIO LOG
    获取该log:执行/system/bin/logcat -b radio -v time -d *:v
    显示一些无线设备的链接状态,如GSM,PHONE,STK(Satellite Tool Kit)…

    NETWORK STATE
    获取该log:执行/system/bin/netcfg (得到网络链接状态)
    获取该log:读取文件/proc/net/route (得到路由状态)
    显示网络链接和路由

    SYSTEM PROPERTIES
    获取该log:参考代码实现
    显示一些系统属性,如Version,Services,network…

    KERNEL LOG
    获取该log:执行/system/bin/dmesg
    显示Android内核输出的Log

    KERNEL WAKELOCKS
    获取该log:读取文件/proc/wakelocks
    内核对一些程式和服务唤醒和休眠的一些记录

    KERNEL CPUFREQ
    (Linux kernel CPUfreq subsystem) Clock scaling allows you to change the clock speed of the CPUs on the fly.
    This is a nice method to save battery power, because the lower the clock speed is, the less power the CPU consumes.

    PROCESSES
    获取该log:执行ps -P
    显示当前进程

    PROCESSES AND THREADS
    获取该log:执行ps -t -p -P
    显示当前进程和线程

    LIBRANK
    获取该log:执行/system/xbin/librank
    剔除不必要的library

    BINDER FAILED TRANSACTION LOG
    获取该log:读取文件/proc/binder/failed_transaction_log

    BINDER TRANSACTION LOG
    获取该log:读取文件/proc/binder/transaction_log

    BINDER TRANSACTIONS
    获取该log:读取文件/proc/binder/transactions

    BINDER STATS
    获取该log:读取文件/proc/binder/stats

    BINDER PROCESS STATE
    获取该log:读取文件/proc/binder/proc/*
    bind相关的一些状态

    FILESYSTEMS
    获取该log:执行/system/bin/df
    主要文件的一些容量使用状态(cache,sqlite,dev…)

    PACKAGE SETTINGS
    获取该log:读取文件/data/system/packages.xml
    系统中package的一些状态(访问权限,路径…),类似Windows里面的一些lnk文件吧.

    PACKAGE UID ERRORS
    获取该log:读取文件/data/system/uiderrors.txt
    错误信息

    KERNEL LAST KMSG LOG
    最新kernel message log

    LAST RADIO LOG
    最新radio log

    KERNEL PANIC CONSOLE LOG
    KERNEL PANIC THREADS LOG
    控制台/线程的一些错误信息log

    BACKLIGHTS
    获取该log:获取LCD brightness读/sys/class/leds/lcd-backlight/brightness
    获取该log:获取Button brightness读/sys/class/leds/button-backlight/brightness
    获取该log:获取Keyboard brightness读/sys/class/leds/keyboard-backlight/brightness
    获取该log:获取ALS mode读/sys/class/leds/lcd-backlight/als
    获取该log:获取LCD driver registers读/sys/class/leds/lcd-backlight/registers
    获取相关亮度的一些信息

    (2)build.prop
    VERSION INFO输出下列信息
    当前时间
    当前内核版本:可以读取文件(/proc/version)获得
    显示当前命令:可以读取文件夹(/proc/cmdline)获得
    显示系统build的一些属性:可以读取文件(/system/build.prop)获得
    输出系统一些属性
    gsm.version.ril-impl
    gsm.version.baseband
    gsm.imei
    gsm.sim.operator.numeric
    gsm.operator.alpha

    (3)dumpsys
    执行/system/bin/dumpsys后可以获得这个log.
    经常会发现该log输出不完整,因为代码里面要求该工具最多只执行60ms,可能会导致log无法完全输出来.
    可以通过修改时间参数来保证log完全输出.
    信息:
    Currently running services
    DUMP OF SERVICE services-name(running)

    Log Code Analysis
    Site: .frameworksasecmdsdumpstate
    相关Log程序的代码可以从上面目录获取

    Log Analysis Experience

    分析步骤

    1.查看一些版本信息
    确认问题的系统环境
    2.查看CPU/MEMORY的使用状况
    看是否有内存耗尽,CPU繁忙这样的背景情况出现.
    3.分析traces
    因为traces是系统出错以后输出的一些线程堆栈信息,可以很快定位到问题出在哪里.
    4.分析SYSTEM LOG
    系统Log详细输出各种log,可以找出相关log进行逐一分析


    实例分析

    下面分析我写的一个测试例子,在OnCreate做一个死循环,这样主线程会被锁住,在按下硬件的Back之后会出现ANR的错误.
    在traces中发现该程序的堆栈信息如下:
    —– pid 20597 at 2010-03-15 01:29:53 —–
    Cmd line: com.android.test
    DALVIK THREADS:
    "main" prio=5 tid=3 TIMED_WAIT
    | group="main" sCount=1 dsCount=0 s=N obj=0x2aac6240 self=0xbda8
    | sysTid=20597 nice=0 sched=0/0 cgrp=default handle=1877232296
    at java.lang.VMThread.sleep(Native Method)
    at java.lang.Thread.sleep(Thread.java:1306)
    at java.lang.Thread.sleep(Thread.java:1286)
    at android.os.SystemClock.sleep(SystemClock.java:114)
    at com.android.test.main.onCreate(main.java:20)
    at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1047)
    at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2459)
    at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2512)
    at android.app.ActivityThread.access$2200(ActivityThread.java:119)
    at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1863)
    at android.os.Handler.dispatchMessage(Handler.java:99)
    at android.os.Looper.loop(Looper.java:123)
    at android.app.ActivityThread.main(ActivityThread.java:4363)
    at java.lang.reflect.Method.invokeNative(Native Method)
    at java.lang.reflect.Method.invoke(Method.java:521)
    at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:868)
    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:626)
    at dalvik.system.NativeStart.main(Native Method)
    "Binder Thread #2" prio=5 tid=11 NATIVE
    | group="main" sCount=1 dsCount=0 s=N obj=0x2fb7c260 self=0×143860
    | sysTid=20601 nice=0 sched=0/0 cgrp=default handle=1211376
    at dalvik.system.NativeStart.run(Native Method)
    "Binder Thread #1" prio=5 tid=9 NATIVE
    | group="main" sCount=1 dsCount=0 s=N obj=0x2fb7c1a0 self=0x14c980
    | sysTid=20600 nice=0 sched=0/0 cgrp=default handle=1207920
    at dalvik.system.NativeStart.run(Native Method)
    "Signal Catcher" daemon prio=5 tid=7 RUNNABLE
    | group="system" sCount=0 dsCount=0 s=N obj=0x2fb7a1e8 self=0x126cc0
    | sysTid=20599 nice=0 sched=0/0 cgrp=default handle=1269048
    at dalvik.system.NativeStart.run(Native Method)
    "HeapWorker" daemon prio=5 tid=5 VMWAIT
    | group="system" sCount=1 dsCount=0 s=N obj=0x2e31daf0 self=0x135c08
    | sysTid=20598 nice=0 sched=0/0 cgrp=default handle=1268528
    at dalvik.system.NativeStart.run(Native Method)
    —– end 20597 —–

    该文件的堆栈结构从下往上进行分析
    (1)栈底at dalvik.system.NativeStart.run(Native Method)
    系统为当前的task(应用程式)启动一个专用的虚拟机
    (2) at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2459)
    Activity Services是在后台负责管理Activity,它此时将测试例子的Activity启动起来了
    (3)at com.android.test.main.onCreate(main.java:20)
    启动测试程序
    (4)栈顶at java.lang.VMThread.sleep(Native Method)
    线程被sleep掉了,所以无法响应用户,出现ANR错误.


    上面是对一个非常简单的问题的分析.


    如果遇到比较复杂的问题还需要详细分析SYSTEM LOG.
    1.比如网络异常,要通过SYSTEM LOG里面输出的网络链接信息来判断网络状态
    2.数据传输,网络链接等耗时的操作需要分析SYSTEM LOG里面ActivityManager的响应时间
    3…

  • 相关阅读:
    java.sql.SQLException: Lock wait timeout exceeded --转
    一致性问题和Raft一致性算法——一致性问题是无法彻底解决的,可以说一个分布式系统可靠性达到99.99…%,但不能说它达到了100%
    分布式系统的Raft算法——在失联阶段这个老Leader的任何更新都不能算commit,都回滚,接受新的Leader的新的更新 意味着还是可能丢数据!!!
    NFL原则告诉我们做决策的时候,试图找到一个能解决所有问题,“大而全”的方案是不存在的。我们应当找到最关心的问题,因地制宜做出选择。——聚焦目标,取舍有道!
    wiredtiger存储引擎介绍——本质就是LSM,当然里面也可以包含btree和列存储
    Druid:一个用于大数据实时处理的开源分布式系统——大数据实时查询和分析的高容错、高性能开源分布式系统
    ES doc_values的来源,field data——就是doc->terms的正向索引啊,不过它是在查询阶段通过读取倒排索引loading segments放在内存而得到的?
    ES doc_values介绍2——本质是field value的列存储,做聚合分析用,ES默认开启,会占用存储空间
    列存储压缩技巧,除公共除数或者同时减去最小数,字符串压缩的话,直接去重后用数字ID压缩
    ES doc_values介绍——本质是field value的列存储,做聚合分析用,ES默认开启,会占用存储空间(列存储压缩技巧,除公共除数或者同时减去最小数,字符串压缩的话,直接去重后用数字ID压缩)
  • 原文地址:https://www.cnblogs.com/xu-neal/p/3766389.html
Copyright © 2020-2023  润新知