获取 Android 应用APP测试过程中的日志文件
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抓取详解
l 实时打印
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 打印系统事件的日志，比如触屏事件。。。
//android log的抓取
adb logcat
//kernel log的抓取
adb shell cat /proc/kmsg
//log 信息的保存
mkdir /data/anr
logcat *：V > /data/anr/android
demsg >/data/anr/kernel
//按ctrl+c结束log输出
adb pull /data/anr ./log/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的基本使用说明及作用)
l 状态信息
o bugreport（命令adb bugreport>bugreport.log)。里面包含有dmesg，dumpstate和dumpsys。
o dumpstate是系统状态信息，里面比较全，包括手机当前的内存信息、cpu信息、logcat缓存，kernel缓存等等。
o adb shell dumpsys这个是关于系统service的内容都在这个里面，这个命令还有更详尽的用法，比如adb shell dumpsys meminfo system是查看system这个process的内存信息。
o kmsg抓取
adb shell cat /proc/kmsg > kmsg.txt，打开后查msm_kgsl字段
说明：用于检索用printk生成的内核消息。任何时刻只能有一个具有超级用户权限的进程可以读取这个文件。也可以用系统调用syslog检索这些消息。通常使用工具dmesg或守护进程klogd检索这些消息。proc是一个内存文件系统， 每次读文件kmsg实际是内核内部的循环缓冲区，每读过后，循环缓冲区的东西就被认为已经处理过了(也就是变成无效内容)，所以你再次读为空是很正常的 为什么会这样处理呢，循环缓冲区大小有限，内核又随时可能往里面写东西，所以这样处理很正常. 你去查一下/proc/kmsg的信息有没有跟系统日志关联，如果有的话，你就可以读日志文件
o dmsg抓取
adb shell dmesg > dmesg.txt
说明：dmesg用来显示开机信息，kernel会将开机信息存储在ring buffer中。您若是开机时来不及查看信息，可利用dmesg来查看。dmesg是kernel的log，凡是跟kernel相关的，比如driver出了问题（相机，蓝牙，usb，启动，等等）开机信息亦保存在/var/log目录中，名称为dmesg的文件里。more /var/log/dmesg
o 工程模式下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信息等等到.
单独察看某个数据可使用cat指令察看，例如cat /proc/meminfo
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
推荐阅读
-
获取 Android 应用APP测试过程中的日志文件
-
直接获取并下载Android 9原生Settings应用的APK文件方法
-
【Netty】「萌新入门」（七）ByteBuf 的性能优化-堆内存的分配和释放都是由 Java 虚拟机自动管理的，这意味着它们可以快速地被分配和释放，但是也会产生一些开销。 直接内存需要手动分配和释放，因为它由操作系统管理，这使得分配和释放的速度更快，但是也需要更多的系统资源。 另外，直接内存可以映射到本地文件中，这对于需要频繁读写文件的应用程序非常有用。 此外，直接内存还可以避免在使用 NIO 进行网络传输时发生数据拷贝的情况。在使用传统的 I/O 时，数据必须先从文件或网络中读取到堆内存中，然后再从堆内存中复制到直接缓冲区中，最后再通过 SocketChannel 发送到网络中。而使用直接缓冲区时，数据可以直接从文件或网络中读取到直接缓冲区中，并且可以直接从直接缓冲区中发送到网络中，避免了不必要的数据拷贝和内存分配。 通过 ByteBufAllocator.DEFAULT.directBuffer 方法来创建基于直接内存的 ByteBuf： ByteBuf directBuf = ByteBufAllocator.DEFAULT.directBuffer(16); 通过 ByteBufAllocator.DEFAULT.heapBuffer 方法来创建基于堆内存的 ByteBuf： ByteBuf heapBuf = ByteBufAllocator.DEFAULT.heapBuffer(16); 注意： 直接内存是一种特殊的内存分配方式，可以通过在堆外申请内存来避免 JVM 堆内存的限制，从而提高读写性能和降低 GC 压力。但是，直接内存的创建和销毁代价昂贵，因此需要慎重使用。 此外，由于直接内存不受 JVM 垃圾回收的管理，我们需要主动释放这部分内存，否则会造成内存泄漏。通常情况下，可以使用 ByteBuffer.clear 方法来释放直接内存中的数据，或者使用 ByteBuffer.cleaner 方法来手动释放直接内存空间。 测试代码： public static void testCreateByteBuf { ByteBuf buf = ByteBufAllocator.DEFAULT.buffer(16); System.out.println(buf.getClass); ByteBuf heapBuf = ByteBufAllocator.DEFAULT.heapBuffer(16); System.out.println(heapBuf.getClass); ByteBuf directBuf = ByteBufAllocator.DEFAULT.directBuffer(16); System.out.println(directBuf.getClass); } 运行结果： class io.netty.buffer.PooledUnsafeDirectByteBuf class io.netty.buffer.PooledUnsafeHeapByteBuf class io.netty.buffer.PooledUnsafeDirectByteBuf 池化技术 在 Netty 中，池化技术指的是通过对象池来重用已经创建的对象，从而避免了频繁地创建和销毁对象，这种技术可以提高系统的性能和可伸缩性。 通过设置 VM options，来决定池化功能是否开启： -Dio.netty.allocator.type={unpooled|pooled} 在 Netty 4.1 版本以后，非 Android 平台默认启用池化实现，Android 平台启用非池化实现； 这里我们使用非池化功能进行测试，依旧使用的是上面的测试代码 testCreateByteBuf，运行结果如下所示： class io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeDirectByteBuf class io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeHeapByteBuf class io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeDirectByteBuf 可以看到，ByteBuf 类由 PooledUnsafeDirectByteBuf 变成了 UnpooledUnsafeDirectByteBuf； 在没有池化的情况下，每次使用都需要创建新的 ByteBuf 实例，这个操作会涉及到内存的分配和初始化，如果是直接内存则代价更为昂贵，而且频繁的内存分配也可能导致内存碎片问题，增加 GC 压力。 使用池化技术可以避免频繁内存分配带来的开销，并且重用池中的 ByteBuf 实例，减少了内存占用和内存碎片问题。另外，池化技术还可以采用类似 jemalloc 的内存分配算法，进一步提升分配效率。 在高并发环境下，池化技术的优点更加明显，因为内存的分配和释放都是比较耗时的操作，频繁的内存分配和释放会导致系统性能下降，甚至可能出现内存溢出的风险。使用池化技术可以将内存分配和释放的操作集中到预先分配的池中，从而有效地降低系统的内存开销和风险。 内存释放 当在 Netty 中使用 ByteBuf 来处理数据时，需要特别注意内存回收问题。 Netty 提供了不同类型的 ByteBuf 实现，包括堆内存（JVM 内存）实现 UnpooledHeapByteBuf 和堆外内存（直接内存）实现 UnpooledDirectByteBuf，以及池化技术实现的 PooledByteBuf 及其子类。 UnpooledHeapByteBuf：通过 Java 的垃圾回收机制来自动回收内存； UnpooledDirectByteBuf：由于 JVM 的垃圾回收机制无法管理这些内存，因此需要手动调用 release 方法来释放内存； PooledByteBuf：使用了池化机制，需要更复杂的规则来回收内存; 由于池化技术的特殊性质，释放 PooledByteBuf 对象所使用的内存并不是立即被回收的，而是被放入一个内存池中，待下次分配内存时再次使用。因此，释放 PooledByteBuf 对象的内存可能会延迟到后续的某个时间点。为了避免内存泄漏和占用过多内存，我们需要根据实际情况来设置池化技术的相关参数，以便及时回收内存； Netty 采用了引用计数法来控制 ByteBuf 对象的内存回收，在博文 「源码解析」ByteBuf 的引用计数机制 中将会通过解读源码的形式对 ByteBuf 的引用计数法进行深入理解； 每个 ByteBuf 对象被创建时，都会初始化为1，表示该对象的初始计数为1。 在使用 ByteBuf 对象过程中，如果当前 handler 已经使用完该对象，需要通过调用 release 方法将计数减1，当计数为0时，底层内存会被回收，该对象也就被销毁了。此时即使 ByteBuf 对象还在，其各个方法均无法正常使用。 但是，如果当前 handler 还需要继续使用该对象，可以通过调用 retain 方法将计数加1，这样即使其他 handler 已经调用了 release 方法，该对象的内存仍然不会被回收。这种机制可以有效地避免了内存泄漏和意外访问已经释放的内存的情况。 一般来说，应该尽可能地保证 retain 和 release 方法成对出现，以确保计数正确。