安卓日志这块我刚入行那会儿是真吃过亏。一个偶现的崩溃测试同学只丢过来一句“打开某个页面就闪退”没有设备、没有时间点、没有任何上下文我和另一个开发对着代码猜了一下午最后发现是推送 SDK 在某款定制 ROM 上初始化顺序出了问题。从那以后我就养成习惯只要涉及问题定位第一件事不是看代码而是先把日志拿下来。标题里说的“安卓设备 App 查看抓取日志的方式以及测试时常用的工具”本质就是一套完整的“取证”能力——你能不能在问题发生的那一刻把系统、应用、网络、性能这几路证据完整截留下来。这套东西的受众其实比想象中广。开发要它来定位崩溃和 ANR测试要它来出具缺陷报告运维和客诉支持要它来还原用户现场连产品同学做竞品分析时也常需要看别人 App 的运行轨迹。工具门槛不高真正拉开差距的是细节logcat 的缓冲区怎么调、高版本安卓为什么读不到别人的日志、ANR trace 去哪找、Monkey 跑出来的日志怎么筛。下面我按自己的实际工作流把这几块从头到尾捋一遍能直接抄的就抄踩过的坑我也一并标出来。1. 先搞清楚安卓日志到底分几条道1.1 logcat 只是主路不是全部很多人一说抓日志脑子里只有adb logcat其实安卓的日志体系是分层的不同问题得去不同的管道里找。我习惯把这套东西分成五类。第一类是logcat也就是应用层和框架层打出来的那堆文本Java 代码里的Log.d()、系统 ActivityManager 的启动记录、输入法状态变化全在这儿。它是日常用得最多的但它有个天然缺陷环形缓冲区写满了就覆盖旧的。第二类是dmesg / kernel log内核态的输出。像驱动加载失败、内存分配异常、部分 native 崩溃的上下文会出现在这里。以前adb shell dmesg很常用新版本安卓因为权限收紧普通用户读不全一般靠adb shell dmesg加 root 或者从 bugreport 里扒。第三类是ANR traces应用主线程卡死超过阈值时系统 dump 出来的线程堆栈路径在/data/anr/。这是定位卡顿和死锁的核心证据后面会单独讲。第四类是tombstonenative 层崩溃比如 so 库挂掉时生成的记录在/data/tombstones/里面有完整的寄存器状态和调用栈。做 JNI 或者接第三方 so 的同学这东西必须会看。第五类是dropbox系统的一个“事件档案馆”。ANR、崩溃、系统重启、电池异常这些事件会被系统摘要性地存进去用dumpsys dropbox能列出来。它的价值在于——logcat 已经被冲掉的时候dropbox 里可能还留着一条摘要。提示排查“偶现且无法复现”的问题时优先去 dropbox 和 ANR 目录翻那里留存的东西比实时 logcat 靠谱得多。1.2 日志级别和缓冲区是两个必须先懂的概念日志级别从小到大是VVerbose、DDebug、IInfo、WWarn、EError、FFatal最后还有一个SSilent它不是级别而是“静默”的意思专门用来做过滤器。理解这点很关键因为 logcat 的过滤语法是“标签:级别”比如MyTag:D表示只看 MyTag 这个标签的 Debug 及以上。而*:S是万能静默意思是“其他所有标签全部闭嘴”。缓冲区是另一个新手常踩的坑。logcat 不是单独一块内存而是分成几个命名缓冲区main应用日志、system系统框架、crash崩溃、events结构化事件、radio通信相关。默认每个缓冲区大概 256KB 左右应用日志一多几秒钟就滚没了。所以排查问题时我一般会先干两件事清空旧日志adb logcat -c然后临时把缓冲区调大adb logcat -G 16M。调大之后缓冲区是内存占用重启就恢复默认不用担心留后遗症。1.3 什么场景抓什么日志先建立一张对照表我把常见问题和对口的日志源整理成了一张表遇到问题先对号入座能省掉大量无效尝试。问题现象优先看的日志源关键命令应用闪退Java 层logcat crash 缓冲区adb logcat -b crash应用无响应、卡死ANR traces logcatadb shell ls /data/anr/native 崩溃、so 报错tombstone logcatadb pull /data/tombstones/系统级异常、重启dropboxadb shell dumpsys dropbox --print冷启动慢、页面卡顿Perfetto / Systraceadb shell perfetto -c - --txt网络请求失败抓包工具 logcat见第 4 章内存持续增长Profiler / LeakCanaryAndroid Studio Profiler兼容性问题特定机型logcat 全量 dmesgadb logcat -b all这张表我一般会贴给团队新人让他们先学会“问对问题”而不是一上来就adb logcat全量输出然后被几万行刷屏刷到怀疑人生。2. adb logcat 抓日志的完整实操2.1 环境准备与设备连接前提是你得有一台装了 adb 的电脑。最省事的方式是装 Android Studio它自带 platform-tools。不装 Studio 的话单独下载 platform-tools 压缩包解压把目录加到系统 PATH 里就行。验证一下adb version adb devicesadb devices能列出设备序列号和状态才算通。状态有几种device是正常unauthorized是设备上还没点“允许 USB 调试”offline通常是连接不稳或者 adb 服务卡了。遇到后两种先看手机屏幕上有没有授权弹窗没有就拔插一次数据线再不行执行adb kill-server adb start-server adb devicesWindows 上还有一个经典坑设备管理器里驱动带感叹号。大部分国产机型装个通用 ADB 驱动能解决或者去厂商开发者官网下对应驱动。这一步不通后面所有操作都是空谈。2.2 logcat 的核心参数逐个拆解adb logcat的参数看着多实际高频的就那么几个。我把最常用的整理如下。-v控制输出格式默认是 brief信息太少。生产环境我几乎只用threadtime它包含日期、时间、PID、TID、级别、标签是排查问题的黄金格式。adb logcat -v threadtime-b指定缓冲区可以叠加比如同时看主日志和崩溃日志adb logcat -b main -b crash -v threadtime想看全部就-b all。-c是清空建议在复现问题前先清一次避免旧日志干扰。-d是把当前缓冲区的日志 dump 出来然后退出适合脚本化抓取不会一直挂着。-t 500是只输出最近 500 行用来快速看现场。-G设置缓冲区大小前面说过了。--pid是精准过滤单个进程的利器需要 Android 7.0 以上adb shell pidof com.example.app adb logcat --pid12345 -v threadtime如果pidof没输出有些机型裁剪了用adb shell ps -A | grep com.example.app替代。2.3 过滤表达式把噪音砍掉九成不做过滤直接看 logcat等于把耳朵贴在高速路口听人说话。过滤有两种思路。一种是按标签过滤用-s或者显式的过滤表达式。-s相当于“只显示这些标签”adb logcat -s MyApp:V OkHttp:V等价于MyApp:V OkHttp:V *:S。这里的*:S把其他所有标签静默掉非常干净。另一种是用 grep 二次过滤。这种方式更灵活适合关键词、异常类名、包名搜索。Linux/macOS 下adb logcat -v threadtime | grep -E Exception|FATAL|ANRWindows 的 cmd 没有 grep用 findstradb logcat -v threadtime | findstr /I Exception FATAL ANR我的习惯是先粗后细第一遍不加过滤全量落盘到一个文件第二遍在文件上做各种 grep反复搜关键词。因为实时过滤的时候你永远不知道下一秒哪个标签会冒出来漏掉关键行就白抓了。2.4 把日志落盘脚本化和轮转排查偶现问题最大的痛点是“日志滚没了”。所以正式抓取时我一定是落盘而不是盯着屏幕看。最基础的一条adb logcat -v threadtime run.log但这样有个问题文件会一直涨长时间跑测试能到几个 G。我一般写个小脚本做按大小切分或者用-t配合定时任务。下面这个 bash 片段是我常用的简化版每 50MB 切一次#!/bin/bash DIR./logs mkdir -p $DIR i0 while true; do adb logcat -v threadtime $DIR/logcat_$i.log PID$! # 监控文件大小超过阈值就重启抓取 while kill -0 $PID 2/dev/null; do SIZE$(stat -c%s $DIR/logcat_$i.log 2/dev/null || echo 0) if [ $SIZE -gt 52428800 ]; then kill $PID break fi sleep 5 done i$((i1)) doneWindows 下用 PowerShell 也能写类似的循环思路一样。关键是分段保存 记录时间点这样复现问题后能快速定位到对应时间段。提示抓取前先确认设备和电脑的时间同步否则日志时间戳和你的操作记录对不上排查时会非常痛苦。手机一般在设置里能手动校准或者用 NTP 对齐。2.5 无线调试与多设备场景USB 连着的限制挺多尤其是要拿着手机到处走动做真机测试时。Android 11 以上支持无线调试配对进入开发者选项里的“无线调试”选“使用配对码配对设备”adb pair 192.168.1.100:37000 # 输入配对码 adb connect 192.168.1.100:5555更老的方式是先 USB 连上然后adb tcpip 5555再adb connect 设备IP:5555。注意这种方式重启设备就失效要重新来一遍。同时连了多台设备时所有命令都要加-s指定序列号否则 adb 会直接报错“more than one device”adb -s emulator-5554 logcat -v threadtime adb -s ABC123456 logcat -b crash3. 不接电脑设备端也能抓日志3.1 开发者选项里的错误报告不是所有场景都能架着电脑连 adb。比如你在地铁上遇到一个闪退或者在客户现场做演示。这时候最实用的是系统自带的**错误报告Bug Report**功能开发者选项里能直接点部分机型长按电源键组合也能触发。它生成的是一个 zip 包里面含 logcat 全量、dumpsys 各项快照、ANR trace、dropbox 记录内容相当完整。缺点是体积大几十到几百 MB、生成慢要跑一两分钟。生成后可以分享导出再拿到电脑上慢慢拆。如果手边有 adb等价的命令更直接adb bugreport ./bugreport.zip这个 zip 解压后重点看bugreport-xxx.txt里面按章节分了SYSTEM LOG、EVENT LOG、ANR、DUMPSYS等搜索类名或者关键字非常高效。3.2 第三方日志 App 和高版本的权限墙应用市场里有一批日志查看工具早年比较出名的像 MatLog、Logcat Reader 这类它们本质是调用系统的日志接口。但这里有个非常关键的分水岭从 Android 10API 29开始普通应用无法读取其他应用的日志了。也就是说这些第三方 App 现在基本只能看到它自己和少量公开的系统日志想抓你目标 App 的日志除非设备 root。这个限制很多人不知道折腾半天以为是工具不好用其实是系统从权限层面就堵死了。READ_LOGS这个权限现在只授给系统应用和签名为 signature 的应用。所以结论很明确设备端第三方 App 抓日志只适合看自己开发的应用同一签名要抓别人或者做全面测试还是老老实实上 adb。3.3 root 设备的额外玩法与风险root 之后确实能解锁很多能力比如直接adb shell su -c logcat读全部日志、直接 pull/data/anr/和/data/tombstones/、用特殊工具持久化抓取。但我得泼盆冷水root 会带来三方面代价。一是安全性下降权限完全开放后恶意应用更容易获得高权限二是部分应用会主动拒绝在 root 环境运行检测到 root 直接退出或限制功能金融类、部分游戏尤其明显三是系统 OTA 和安全补丁升级会变麻烦。我的建议是日常测试用一台专门的测试机尽量用 adb bugreport 这套非侵入式方案。只有当问题只在特定内核或 native 层复现、必须要看受保护目录时才考虑 root 机器并且把它隔离成专用的取证设备。4. 测试时常用的工具清单按用途分组4.1 基础调试三件套Logcat、Profiler、Layout InspectorAndroid Studio自带的 Logcat 窗口是我最常用的。相比命令行它有几个优势按包名自动分组、支持正则过滤、可以直接跳转崩溃堆栈对应代码行、能把多设备日志合并显示。唯一的缺点是吃内存长时间挂着会卡所以我会定期清理窗口。Profiler是性能排查的主力CPU、内存、网络、电量四个维度一条时间轴。它的用法是“先看形状再看细节”比如 CPU 曲线在某个操作后一直不下来说明有耗时任务没释放内存曲线呈锯齿状上升大概率是泄漏。定位到时间段后再点进去看具体调用栈。Layout Inspector用来查界面问题能实时看到 View 树、层级、每个控件的属性。遇到“某按钮点了没反应”这种先确认它有没有被上层透明 View 挡住这个工具一眼就能看出来。4.2 UI 自动化Monkey 到 Maestro 的梯度Monkey是系统自带的随机事件压测工具零门槛一条命令就能跑adb shell monkey -p com.example.app -v -v -v --throttle 300 \ --pct-touch 40 --pct-motion 25 --pct-nav 15 \ --ignore-crashes --ignore-timeouts -s 20240601 10000参数里-p指定包名-v -v -v是最高详细级别--throttle 300是事件间隔毫秒数--pct-*控制各类事件占比-s是随机种子固定种子可复现最后的数字是事件总数。关键点在于一定要重定向保存日志adb shell monkey -p com.example.app -v 10000 21 | tee monkey.log不然崩溃信息一闪而过根本来不及看。--ignore-crashes和--ignore-timeouts让 Monkey 遇到崩溃继续跑而不是停下适合长时间稳定性测试。UiAutomator / Espresso是写固定用例的框架适合回归测试。UiAutomator 跨应用Espresso 专注单应用内速度快但隔离性强。Appium走 WebDriver 协议一套用例可以覆盖安卓和 iOS适合团队已经有 Web 自动化积累的情况。装起来稍麻烦npm i -g appium appium driver install uiautomator2Maestro是这两年比较火的轻量方案用 YAML 描述流程上手极快特别适合冒烟测试。一个典型流程长这样appId: com.example.app --- - launchApp - tapOn: 登录 - inputText: 13800000000 - tapOn: 获取验证码 - assertVisible: 请输入验证码它底层调 adb所以跑之前设备必须是 adb 可见状态。选择哪个没有绝对答案探索性压测用 Monkey固定回归用 UiAutomator/Espresso跨平台用 Appium快速冒烟用 Maestro。4.3 性能与内存Perfetto、Systrace、LeakCanaryPerfetto是现在安卓性能抓取的主流方案取代了老的 systrace。它采集的信息非常全CPU 调度、频率、进程线程、Binder 调用、帧渲染。抓取命令adb shell perfetto -c - --txt -o /data/misc/perfetto-traces/trace.pftrace EOF buffers: { size_kb: 65536 } data_sources: { config { name: linux.ftrace } } duration_ms: 10000 EOF adb pull /data/misc/perfetto-traces/trace.pftrace生成的 trace 文件拖到浏览器里的 Perfetto UI 打开能看到完整的时间轴。看卡顿的核心是找主线程上过长的连续块超过 16ms 就可能掉帧超过几百毫秒用户就能感觉到明显卡顿。LeakCanary是内存泄漏检测神器集成到 debug 包里它会自动监控 Activity、Fragment 的销毁发现泄漏后 dump 堆内存并给出引用链。它的报告非常直观——直接告诉你“谁持有了这个本该被回收的对象”。内存快照hprof是兜底手段。用 Profiler 抓一份堆转储在 Android Studio 或者 MAT 里分析。这个适合 LeakCanary 覆盖不到的场景比如大对象长期驻留。4.4 网络抓包与高版本证书难题看网络请求工具选择挺多。电脑端主流是Charles和mitmproxy也有Fiddler设备端有HttpCanary这类。核心原理都是让流量经过工具监听然后解密展示。这里有个绕不开的坎Android 7.0 之后应用默认不再信任用户手动安装的 CA 证书。也就是说你把抓包工具的证书装到手机里系统层面信任了但目标应用自己不一定买账很多请求会直接失败或者显示为加密的乱码。破解思路有这么几条按侵入性排序应用自身配置了 network security config 并允许用户证书——这种最好办直接装证书就行但多见于开发调试包。改包重签在应用里注入信任用户证书的配置。这个只适合自家应用或者有授权的测试对象改别人的包涉及法律和合规风险别碰。在系统层面把证书装到系统证书分区需要 root前面说过 root 的代价。用设备端工具直接抓部分工具能在不依赖系统信任链的情况下抓 HTTPS但兼容性和可靠性因版本而异。注意抓包涉及数据隐私务必只对自己拥有授权或自己开发的应用操作抓到的数据要妥善保管、按规范脱敏和销毁。这条底线不能越。4.5 线上崩溃收集Crashlytics、Bugly、Sentry本地抓日志解决的是测试阶段的问题但真正的崩溃大头在线上。这块得靠崩溃收集平台。Google 的Firebase Crashlytics生态成熟和 Android Studio 集成顺滑国内的Bugly对国产机型和符号表处理友好Sentry强在自建和多语言支持友盟类方案胜在接入简单。选型我一般看三点符号表上传是否自动化、聚合去重是否准确、能否定位到具体版本和设备。其中符号表是重中之重尤其是 native 崩溃没有符号表解出来的堆栈全是地址毫无意义。建议把符号表上传直接挂在 CI 流程里每次构建自动传别指望人工记得。5. 系统级日志深挖ANR 和 native 崩溃怎么读5.1 ANR traces 的正确打开方式ANR 也就是“应用无响应”系统弹窗“等待 / 关闭”那个。触发它的原因通常有四类主线程做耗时 IO、主线程等待锁、BroadcastReceiver 超时、Service 启动超时。现场证据在/data/anr/目录。老版本只有一个traces.txtAndroid 11 之后是一堆anr_日期时间命名的文件。非 root 读不全但可以通过adb bugreport打包取出。拿到之后怎么看核心是找主线程通常叫 main的堆栈看它卡在哪一行。常见的几种形态卡在ScheduledFutureTask或者MessageQueue.nativePollOnce这往往是正常的空闲等待不代表问题。卡在Thread.sleep、Socket.read、文件读写说明主线程在做阻塞操作。卡在synchronized或者Object.wait说明在等锁要去找是谁长期持有那把锁。我一般会在 trace 里搜两遍先搜main看主线程再搜held by看有没有显式的锁竞争。ANR trace 的价值在于它是全进程所有线程的快照能还原“谁在等谁”的完整关系。5.2 native 崩溃与 tombstoneJava 崩溃你能看到清晰堆栈native 崩溃so 库崩溃就没这么友好了。系统会在/data/tombstones/下生成 tombstone 文件里面记录了信号类型、崩溃地址、寄存器状态和调用栈。其中signal 11 (SIGSEGV)是最常见的一般是空指针或者野指针signal 6 (SIGABRT)多半是主动 abort可能是断言失败或者 C 未捕获异常。要看懂 tombstone 得有对应版本的符号表用工具做地址还原否则那一堆十六进制地址根本没法读。这也是为什么我一直强调符号表要归档——每出一个版本就存一份出问题时才能对应上。6. 常见问题与排查技巧实录6.1 高频问题速查表我把这些年被问得最多的问题整理成了表遇到先查这里。现象可能原因解决办法adb devices显示 unauthorized设备未授权调试手机上点“允许”勾选“始终允许”显示 offlineadb 服务异常或线材问题adb kill-server后重启换数据线抓不到目标应用日志Android 10 权限限制改用 adb或确认读取方是系统应用日志刷太快看不到关键行缓冲区小、输出量大-G 16M扩大同时落盘到文件中文显示乱码终端编码不匹配Windows 执行chcp 65001或直接输出到文件崩溃日志缺失缓冲区被覆盖用-b crash单独抓或用 bugreportMonkey 跑一半停了未忽略崩溃超时加--ignore-crashes --ignore-timeouts抓包 HTTPS 全是乱码用户证书不被信任见 4.4 节优先用调试包或系统级证书多设备命令报错未指定设备所有命令加-s 序列号日志时间对不上操作设备与电脑时间不同步校准时间或记录时间偏移量6.2 几个只有踩过才知道的细节第一崩溃不一定出现在 crash 缓冲区。有时候 Java 崩溃因为进程被杀得太快日志还没 flush 到 crash 里就没了。这种时候 dropbox 或者 bugreport 里的SYSTEM LOG反而可能有残留。所以抓崩溃我一般是-b all全量落盘而不是只盯着一个缓冲区。第二logcat -c之后立刻抓第一行可能是空的。因为它清空需要一点时间脚本化抓取时最好清空后 sleep 一秒再开始避免开头丢日志。第三过滤表达式里标签区分大小写。MyApp:D和myapp:D是两个不同的过滤器写错了就一条都出不来很容易误判成“应用没打日志”。第四高版本安卓的日志权限墙不止影响第三方 App也影响一些自动化框架。某些工具在新系统上跑不出来日志不一定是工具坏了而是系统策略变了。第五别迷信“日志越全越好”。有一次同事给我传了个 800MB 的全量日志我打开一是没有时间标记二是不知道他做了什么操作。后来我要求团队提交缺陷时必须附上问题时间段、复现步骤、当时的操作时间点。日志是证据但证据得有上下文才有价值。6.3 建立自己的抓取模板折腾久了我把常用抓取动作固化成了一个脚本命名为grab.sh参数是包名#!/bin/bash PKG$1 TS$(date %Y%m%d_%H%M%S) DIR./catch_$PKG_$TS mkdir -p $DIR # 调整缓冲区并清空 adb shell logcat -G 16M adb shell logcat -c # 全量日志后台落盘 adb logcat -b all -v threadtime $DIR/logcat_all.log echo $! $DIR/logcat.pid # 抓取进程信息 adb shell ps -A $DIR/ps.txt adb shell dumpsys activity $DIR/dumpsys_activity.txt echo 抓取已启动目录$DIR echo 停止请执行kill $(cat $DIR/logcat.pid)这个脚本我几乎每天都在用简单但极其实用。它的价值在于把“记得做哪些事”变成“自动做哪些事”避免临时手忙脚乱漏掉关键信息。7. 我个人的一点实操体会摸索这套流程的过程中我最大的感受是抓日志的能力本质上反映的是你对系统运行机制的理解深度。同样一个崩溃新手只知道去 logcat 里搜“Exception”老手会先想“这是 Java 层还是 native 层、是主线程还是子线程、是必现还是偶现”然后决定去哪个缓冲区、哪个目录、用哪个工具。另一个体会是要把抓取动作前置。等你发现问题的那个瞬间再开始抓往往已经晚了——缓冲区被冲掉、现场被覆盖。所以我的习惯是做任何测试之前先跑一遍抓取脚本让日志在后台静静躺着。真出问题了直接翻文件而不是手忙脚乱现学现抓。这种“先装好行车记录仪再上路”的思路比任何技巧都管用。还有个小技巧分享给常做长时间稳定性测试的朋友给抓取脚本加一个定时打时间戳的日志比如每五分钟往文件里写一行当前时间。这样回头定位“问题大概发生在哪一段”时有个天然的锚点不用再靠猜。这个小改动成本极低收益却很高值得一试。