Android App日志查看与抓取：adb logcat、崩溃与ANR排查

线上出问题产品经理甩过来一张用户截图运维说服务端一切正常这时候你作为测试或者开发手里唯一能说话的东西就是日志。安卓设备上的日志不像服务端那样随手 tail 一个文件就完事它藏在环形缓冲区里、藏在 /data/anr 下面、藏在开发者选项的开关背后还得靠 adb 或者一个能跑起来的工具链把它捞出来。我自己做过几年移动端的质量保障从早期的 Eclipse DDMS 到现在的 Android Studio Logcat 加 Perfetto抓日志这件事看着简单真到复现偶现问题时十次里有八次是卡在没抓到或者抓了一堆没用的上面。这篇内容我想把安卓 App 日志查看、抓取的方式以及测试过程中真正会用到的工具按我实际干活的顺序捋一遍从日志分几层、命令怎么写、工具怎么选一直讲到抓不到日志时该怎么排查。不管你是刚入行的测试还是写了两年代码突然被拉去定位崩溃的开发看完至少能少走一截弯路。1. 安卓日志体系的整体认知与抓取思路拆解1.1 从一次偶现崩溃说起日志是唯一能回溯现场的东西先说个真实场景。之前有个 App用户反馈在某个页面滑动几屏之后偶尔闪退概率大概百分之三开发本地怎么点都不复现用户截图里只有一张桌面。这种情况你靠再点一遍是没用的只能靠日志把崩溃那一刻的堆栈留下来。安卓系统的日志机制本质上是一个多生产者、多消费者的环形缓冲区系统进程、应用进程、驱动层都往里写Logd 守护进程负责收集和分发我们平时看到的 logcat 只是其中一部分视图。理解这一层很重要因为它决定了三件事第一日志是有容量上限的写满了会覆盖旧的你不主动保存出问题的日志可能几秒钟后就被冲掉了第二日志是有分区buffer的main、system、crash、events 各管一摊默认只看 main 经常会漏掉关键信息第三日志的量级非常大一台正常使用的设备一分钟能产生几千行不做过滤直接看就是灾难。所以抓日志这件事本质上不是把日志打出来而是在正确的时间窗口里把正确的缓冲区内容以可读的格式落到磁盘上。想清楚这个目标后面所有命令和工具的用法都好理解了。1.2 安卓日志的几条主线main、system、crash、events 各管什么很多人抓了几年日志只知道敲adb logcat其实加不加-b参数看到的东西完全不一样。把几个主要缓冲区搞清楚定位问题的效率能翻倍。缓冲区参数主要内容典型用途main-b main应用层日志默认输出业务逻辑、三方 SDK 日志system-b system系统框架、ActivityManager、WindowManager生命周期、权限、启动流程crash-b crash崩溃堆栈Java 层异常、崩溃快速定位events-b events二进制事件流需-b events -v解析系统行为统计、埋点校核radio-b radio通信相关网络状态、信号变化all-b all以上全部全面排查量非常大实际工作中我的习惯是日常调试只看main涉及页面跳转异常、权限被拒、应用被杀必须把system一起打开专门看崩溃就-b crash这个缓冲区内容少、命中准是快速定位的第一步。需要说明的是不同厂商定制系统对缓冲区的划分略有差异比如部分设备把events做了裁剪具体以设备实测为准不要死记硬背。1.3 动手之前先想清楚三个决策在哪抓、抓什么、抓多久这是我最想强调的一点。抓日志翻车八成不是命令写错了而是抓之前没想清楚。在哪抓。是插着 USB 用电脑抓还是在设备本机上抓如果问题只在特定用户设备上出现你拿不到那台机器就得靠应用内置的日志收集能力把日志回传。如果是你自己的测试机adb 是最顺手的。抓什么。是只看崩溃还是要看整个操作链路如果只抓崩溃-b crash加上清空缓冲区再复现就够了如果要看一个完整流程就得把时间窗口留够并且用 TAG 或者 PID 把范围收窄。抓多久。这是最容易被忽略的。有些兼容性问题要跑几分钟甚至几十分钟才出现日志量会非常大这时候就得考虑用-f写到设备文件、用轮转控制大小而不是在终端里刷屏。提示清空缓冲区这个动作adb logcat -c一定要在复现之前做而且要注意它清的是所有缓冲区还是指定缓冲区。清完之后立刻开始复现不要让无关操作污染时间窗口。2. adb logcat 命令的深度用法与参数拆解2.1 先清空再复现缓冲区的基本操作adb logcat -c是清空adb logcat -g是看当前缓冲区大小adb logcat -G 16M是把缓冲区调大。这三个命令我建议你背下来。# 查看当前各缓冲区大小默认多数设备 main 是 256KB 到 2MB 不等 adb logcat -g # 把 main 缓冲区临时调到 16M重启后失效需要重新设置 adb logcat -G 16M # 清空所有缓冲区 adb logcat -c为什么要调大因为默认缓冲区小的时候一个稍微啰嗦点的应用几秒钟就把 main 写满了等你想回头找线索日志早被覆盖了。把缓冲区调到 16M配合设备本身内存情况一般能撑住几分钟到十几分钟的中等强度日志。要注意的是-G参数在部分较老的安卓版本上不生效属于系统限制遇到这种情况只能靠及时落盘来解决不要硬刚。另外提醒一句-c清空在某些定制系统上可能因为权限原因失败如果报权限错误先确认 adb 授权弹窗点过没有以及是否被系统安全策略限制了。这是实测中比较容易踩的点。2.2 格式化输出-v 参数到底选哪个logcat 默认输出格式很挤时间戳不直观线程信息也看不全所以我几乎永远会加-v参数。常用的几种格式对比如下。格式输出内容适用场景-v brief优先级/TAG/PID/内容快速浏览默认风格-v time时间 完整信息日常记录最常用之一-v threadtime时间 PID TID TAG多线程问题排查首选-v long内容与元信息分开空行日志内容长的场景-v raw只输出内容配合 grep 做二次处理-v thread只带 PID/TID线程调度分析我的默认选择是-v threadtime理由是它把线程 IDTID也带上了排查线程阻塞、主线程耗时这类问题时没有 TID 基本等于瞎猜。adb logcat -v threadtime如果是要交给别人分析或者存档我会先用threadtime抓成文件再用-v long重新过一遍长文本两种格式配合着看。2.3 精准过滤TAG、优先级、PID 与正则的组合拳不过滤的 logcat 就是一个噪音制造机。过滤有四把刀用好了能砍掉九成无关内容。第一把优先级过滤。*:E表示所有 TAG 只看 Error 及以上。这个在崩溃排查时特别爽。# 只看 Error 及以上 adb logcat *:E # 只打印指定 TAG并指定最低优先级 adb logcat -s MyTag:V第二把TAG 白名单。-s参数后面跟 TAG 名多个用逗号隔开。-s的本质是把其他 TAG 的优先级压到 silent所以它跟优先级过滤能配合。第三把PID 过滤。Android 7 之后支持--pid这是我最喜欢的能力因为一个设备的日志里塞满了各种应用按进程号过滤能瞬间干净。# 先拿到应用的进程号 adb shell pidof com.example.app # 再用 --pid 过滤进程存活期间有效 adb logcat --pid$(adb shell pidof -s com.example.app) -v threadtime这里有个坑要注意--pid绑定的是具体进程号App 一旦被杀重启PID 就变了日志会断掉。所以如果测试过程中应用会反复重启比如压测、崩溃复现PID 过滤就要小心用或者改用 TAG 过滤。第四把正则匹配。较新的安卓版本支持-e参数直接上正则非常方便。adb logcat -e NullPointer|OutOfMemory -v threadtime四把刀怎么组合我的一般顺序是先按 PID 收窄进程再用优先级挡掉 debug 和 info 的噪音最后如果还嫌乱用-s或者-e精确定位。整套下来日志从几千行降到几十行肉眼能扫完。2.4 落盘与轮转别让日志把内存吃满终端刷屏只适合短时间观察真正的排查必须落盘。落盘有两个方向写到电脑或者写到设备。写到电脑最简单# -d 表示 dump 当前缓冲区后退出不会一直挂着 adb logcat -v threadtime -d app_log.txt # 持续抓取CtrlC 结束 adb logcat -v threadtime | tee app_log.txt写到设备上适合长时间无人值守的场景# -f 指定设备端输出文件-r 指定单文件大小-n 指定轮转文件数量 adb logcat -f /sdcard/logcat.txt -r 4096 -n 10 -v threadtime-r 4096 -n 10的意思是每个文件 4MB最多保留 10 个总共约 40MB轮转覆盖。这套参数在压测和稳定性测试里非常实用既不会撑爆存储又能保证出问题时有历史可查。要注意设备存储空间和写入权限部分系统对/sdcard的写入做了限制可以先写到自己应用的外部目录再导出来。注意长时间抓取记得关掉屏幕自动旋转和自动息屏相关的高频日志源否则日志里会混进大量无意义内容反而稀释了有用信息。2.5 用管道做二次加工grep、awk 和 pidcatadb 输出本质就是标准输出Linux/macOS 环境下可以直接用管道接各种文本工具。# 只看含关键字的行并高亮 adb logcat -v threadtime | grep --coloralways -i crash\|exception # 按线程 ID 排序看最活跃的线程 adb logcat -v threadtime | awk {print $3} | sort | uniq -c | sort -rn | head # 过滤掉指定 TAG 的噪音 adb logcat -v threadtime | grep -v Chatty\|GraphicsStats这里必须提一个老牌工具pidcat虽然年久失修但思路很值得借鉴它按进程给日志自动着色把不同应用的输出用颜色区分开一眼就能看出这行日志是谁打的。现在 Android Studio 自带的 Logcat 面板已经把这个能力做得更好了颜色、过滤条件、崩溃折叠都有所以我更推荐直接在 Studio 里看命令行留给脚本化场景。3. 设备端免电脑的日志查看方案3.1 开发者选项里那些和日志有关的开关不是所有场景都能插电脑比如你在用户现场、在客户办公室或者就是懒得掏数据线。这时候设备端方案就派上用场了。开发者选项里有个日志记录器缓冲区大小Logger buffer sizes可以在这里把缓冲区调大跟前面-G是一个效果只是图形化操作。另外USB 调试、无线调试这两个开关是 PC 端方案的前提。还有一个容易被忽略的错误报告Bug report入口长按电源键或者通过开发者选项可以触发它会把系统状态、日志、截图、dump 信息打包成一个 zip这个包里的信息量非常惊人是排查系统级疑难杂症的大杀器。要说明的是不同品牌的开发者选项名称和位置差异很大有的叫开发者选项有的藏在关于手机里连点版本号七次才出来。这部分只能按具体设备摸索没有统一答案。3.2 应用内集成日志框架并留好导出入口真正成熟的项目都会在应用内做日志能力而不是等出问题了再想办法。常见的做法是集成一个日志库比如 Timber、Logger 这类把日志分级写文件再配一个隐藏的导出入口。这套设计的价值在于当线上用户反馈问题时你可以引导他进入一个隐藏页面比如连续点击版本号一键把本地日志打包发回来。这比任何 adb 命令都管用因为你能拿到的是用户真实环境下的日志而不是你自己测试机上的。设计时要注意几点日志文件要有大小上限和轮转策略别把用户手机存储写满要区分正常日志和崩溃日志崩溃日志优先保留导出前做一次脱敏手机号、账号这类信息该打码就打码这既是合规要求也是基本的职业素养。3.3 系统级 bugreport 的触发与内容构成# 生成完整 bugreport 并拉到本地 adb bugreport ./bugreport.zip# 设备端直接生成适用于无法连电脑的场景 adb shell bugreportzbugreport 里包含dumpsys各服务的输出、logcat 各缓冲区、ANR trace、崩溃信息、电池统计、网络统计等基本上系统能给你的它都给了。缺点是体积大几十 MB 很常见、内容杂需要耐心翻。我的用法是先解压直奔bugreport-xxx.txt里的VM TRACES、SYSTEM LOG、EVENT LOG这几段八成的系统级问题都能在这里找到线索。4. 崩溃、ANR、Native 异常的日志定位实战4.1 Java 崩溃栈的阅读顺序拿到一段 Java 崩溃日志很多人是从上往下读其实应该反过来找几个关键锚点。FATAL EXCEPTION: main Process: com.example.app, PID: 12345 java.lang.NullPointerException: Attempt to invoke virtual method int java.lang.String.length() on a null object reference at com.example.app.ui.DetailActivity.onCreate(DetailActivity.java:88) at android.app.Activity.performCreate(Activity.java:8000) Caused by: java.lang.IllegalStateException: ...阅读顺序建议是先看Process和PID确认是不是你的应用再看异常类型和消息这里往往直接点出问题然后看at堆栈里第一个属于你自己包名的帧那一行往往就是问题源头最后看Caused by链根因通常在最后一层。提示堆栈里带$的类名是内部类或者匿名类比如DetailActivity$1.onClick这说明问题出在匿名内部类里常见于点击回调没做判空排查时优先往这个方向想。4.2 ANR 日志的三种获取途径ANR应用无响应比崩溃更难查因为程序还在只是卡住了。它的日志获取有三条路。第一条是 logcat 里的ANR in关键字这个提示出现时后面会跟上 CPU 使用情况、主线程状态等关键信息。adb logcat -b crash -b main -v threadtime | grep -A 30 ANR in第二条是/data/anr/目录下的 traces 文件里面是各进程的线程堆栈快照是定位死锁和主线程阻塞的核心资料。不过从 Android 10 开始这个目录普通权限读不到了需要 root 或者通过 bugreport 获取。adb shell ls -l /data/anr/ adb shell cat /data/anr/traces.txt第三条是adb shell dumpsys activity processes里带的 ANR 记录以及adb shell dumpsys dropbox里保存的历史崩溃和 ANR 事件后者相当于一个系统级的事件归档能翻到比较久之前的记录很实用。排查 ANR 的思路是拿到主线程堆栈看它卡在哪一行。如果卡在synchronized或者wait基本就是锁竞争如果卡在onCreate、onDraw这类 UI 方法里那就是主线程做了耗时工作。方向确定了改起来就快了。4.3 Native 崩溃与 tombstone 文件涉及 JNI、NDK 的应用崩溃会变成 Native 崩溃logcat 里会出现signal 11 (SIGSEGV)这类信息此时核心资料是 tombstone 文件。adb shell ls /data/tombstones/ adb shell cat /data/tombstones/tombstone_00tombstone 里会有崩溃时的寄存器状态、内存映射、各线程调用栈。看它需要点耐心关键是找backtrace那一段定位到第一个属于自己 so 库的帧。如果你不想每次手动翻可以用一些符号化解析工具配合 so 文件做自动还原这个是团队级基建的范畴个人排查时先把 tombstone 完整留存下来交给负责 NDK 的同学是最务实的做法。4.4 卡顿、耗电、内存问题的日志线索不是所有问题都会崩很多是感觉卡费电越用越卡。这类问题日志里的线索更隐蔽。卡顿可以看Choreographer打出的Skipped N frames也能用dumpsys gfxinfo看每帧渲染耗时。adb shell dumpsys gfxinfo com.example.app耗电主要看dumpsys batterystats它可以告诉你哪些模块持有唤醒锁、哪些网络请求在后台频繁触发。内存走dumpsys meminfo观察 PSS 和堆增长趋势判断是否存在泄漏。adb shell dumpsys meminfo com.example.app adb shell dumpsys batterystats com.example.app battery.txt这些 dump 信息本身就是日志的一种形态配合前面讲的 bugreport 一起用能拼出一幅比较完整的现场图。5. 测试环节常用工具的分层盘点5.1 官方工具链Android Studio 与命令行Android Studio 自带的 Logcat 面板是目前最省心的查看工具支持多设备、多进程视图切换内置崩溃折叠、关键字过滤、正则匹配、收藏过滤条件还能把选中的日志直接导出。新手如果一开始就用命令行反而容易被参数劝退建议先在 Studio 里建立对日志结构的直觉再去学命令。命令行这边adb本身就是最核心的工具除了 logcatadb shell、adb install、adb pull、adb shell am这些命令在测试中出场率极高。比如要复现某个页面直接一条命令拉起来adb shell am start -n com.example.app/.ui.MainActivity adb shell am force-stop com.example.app还有adb shell input可以模拟点击、滑动、输入文本配合脚本能做轻量自动化。# 点击坐标 (500, 1200) adb shell input tap 500 1200 # 向上滑动 adb shell input swipe 500 1500 500 500 300这套东西看着原始但在临时验证、脚本化冒烟测试里非常有效尤其是没有引入重型框架的时候。5.2 UI 自动化测试工具Maestro、Appium、UiAutomator、EspressoUI 自动化工具这几年变化挺大我按实际使用体感排个序。Maestro是近几年比较受欢迎的轻量方案用 YAML 描述操作流程不需要写 Java/Kotlin 代码安装完直接跑适合快速搭建冒烟用例。appId: com.example.app --- - launchApp - tapOn: 登录 - inputText: testuser - assertVisible: 首页Appium是跨平台老将支持多语言客户端社区资料多适合需要覆盖 Android 和 iOS 的团队。缺点是环境搭建比较折腾启动慢调试体验一般。UiAutomator是谷歌官方的 Android UI 测试框架能跨应用操作适合系统级交互场景。Espresso更偏白盒和代码放在一起运行速度快、稳定性高但只能测自己应用内部且需要开发配合写代码。选型建议如果只是想做关键路径的回归冒烟Maestro 上手最快如果团队有多端覆盖需求Appium 更稳如果是开发自己写测试Espresso 配合 UiAutomator 是经典组合。不要一上来就追求全量覆盖稳定性比覆盖率重要得多。5.3 性能与稳定性Monkey、Perfetto、PerfDog、SoloPiMonkey是自带的随机事件压测工具用来做稳定性验证非常合适。# 对指定包跑 10000 次随机事件忽略崩溃继续 adb shell monkey -p com.example.app --throttle 300 --ignore-crashes --ignore-timeouts -v 10000跑 Monkey 的关键是同时抓日志否则崩了不知道原因。--throttle 300表示每个事件间隔 300ms节奏比较接近真人。Perfetto是现在系统级性能分析的主力替代了老的 systrace能同时采集 CPU 调度、渲染、内存、binder 调用等大量信息输出可以用网页端可视化查看。它信息量大但上手门槛也高建议先用预设的 trace 配置跑起来看看。PerfDog、SoloPi这类工具主打免代码接入的性能数据采集能实时看 FPS、CPU、内存、耗电曲线适合测试同学做性能基线对比和前后版本回归。用的时候要注意采样频率和后台干扰否则数据抖动会很大做出错误结论。5.4 接口与协议调试从 HTTP 到 ModbusApp 出问题很多时候根因不在 UI而在接口。HTTP 接口调试常用 Postman、Apifox 这类工具快速构造请求验证参数和返回。JMeter 更适合做并发和压测配合定时器、断言能搭出比较完整的场景。如果 App 涉及工业协议对接比如设备通讯场景里的 Modbus就需要专门的协议测试工具来模拟主站或从站构造 TCP/RTU 报文验证设备读写寄存器是否正常。这类工具通常要求你能看懂报文结构和功能码属于专业门槛较高的一块测试前一定要拿到协议文档明确寄存器地址和数据类型否则很容易出现读出来是乱的这种问题。再往上WebService 类的老接口或者自定义长连接协议会用专门的抓取和模拟工具。这里的通用原则是先在 PC 端把协议调通再接回 App 验证把变量控制住。5.5 抓包工具的定位与合规边界抓包是接口问题排查的常规手段Charles、Fiddler、mitmproxy、Wireshark 这几个各有侧重。抓包能解决的最典型问题是请求到底发出去了没有、参数对不对、响应是什么、耗时花在哪个环节。使用上要把证书配置做对否则移动端很多请求会因为证书校验失败直接断掉表现出来就是 App 里一片空白抓包工具什么都没有。遇到这种情况先确认证书是否装到了系统信任区以及应用有没有做额外的证书校验这部分内容属于应用自身安全机制测试时应当在与项目组约定的测试环境和授权范围内进行不要对非授权对象做任何抓取操作。合规这块必须说清楚抓包只能用于你拥有授权的测试环境或自己的设备涉及用户数据的包要严格脱敏不要把包含手机号、身份证、地理位置的信息随意传播。这是红线。6. 一次完整的复现与日志采集流程演示6.1 场景与准备假设这样一个场景测试反馈应用在弱网环境下切换页面时有概率闪退本地稳定网络下不复现。准备工作一台能复现的测试机或者能模拟弱网的环境、USB 线、adb 环境、一个足够清晰的复现步骤。先把设备缓冲区调大避免日志被冲掉。adb devices adb logcat -G 16M adb logcat -g确认设备已经授权并且缓冲区调整成功。如果-G不生效就准备用-f直接写文件的方式。6.2 分步执行与现场记录第一步清空缓冲区确保时间窗口干净。adb logcat -c第二步起一个带时间戳的抓取进程写到本地文件同时屏幕上也能看到。adb logcat -v threadtime -b main -b system -b crash | tee weaknet_crash.log第三步按预先设计好的步骤操作模拟弱网可以用系统自带的网络限速功能或者调整路由策略反复切换页面直到复现。第四步一旦闪退发生立刻停止抓取CtrlC然后马上补一条崩溃缓冲区的 dump防止漏掉关键堆栈。adb logcat -b crash -v threadtime -d crash_only.log第五步如果应用已经重启进程号变了可以在重启后再补一份当前进程的日志和 bugreport。adb bugreport ./bugreport_after_crash.zip6.3 日志裁剪、脱敏与提交规范抓到的日志往往有好几 MB直接甩给开发是一种伤害。提交之前做三件事。裁剪。用崩溃时间戳定位取前后各 500 到 1000 行即可。可以用sed或者直接在编辑器里定位。脱敏。把账号、手机号、token 这类内容替换掉。# 简单的脱敏示例把 11 位手机号替换为掩码 sed -E s/1[3-9][0-9]{9}/138****0000/g weaknet_crash.log sanitized.log结构化提交。一份合格的日志提交应该包含复现步骤、复现概率、设备型号和系统版本、应用版本号、日志文件、当时的网络环境说明。这些东西看着琐碎但能省掉开发来回追问的十几分钟长期看是效率的关键。可以做一个固定的模板每次填就行。7. 常见问题与排查技巧速查7.1 抓不到日志的七种典型原因第一个也是最高频的设备没授权。adb devices显示unauthorized手机上没点允许调试的弹窗或者弹窗被系统拦截了。重新插拔、撤销授权再连一次通常能解决。第二个应用进程已经退出。崩溃后进程被杀日志里能看到的只有系统记录的崩溃信息业务日志的尾部可能已经丢失所以崩溃缓冲区的及时 dump 很关键。第三个PID 过滤绑定了旧进程号。前面提过重启后 PID 变了日志直接断掉。第四个缓冲区被冲爆。默认缓冲区小日志量大关键信息被覆盖。解决办法是提前调大或者提前落盘。第五个权限限制。Android 10 以后普通应用和 shell 用户对/data/anr、/data/tombstones的读取受到严格限制只能靠 bugreport 或 root 设备。第六个日志等级设置过高。有些应用在生产包里把 release 版本的日志级别调到了 Errordebug 和 info 全部不输出自然什么都看不到。这个要跟开发确认构建配置。第七个TAG 拼写或者过滤语法写错。-s MyTag和-s MyTag:V行为不同正则里的特殊字符没转义也会导致过滤失效。这种属于低级错误但真的经常发生。7.2 日志时间戳错乱、乱码与截断的处理时间戳的问题主要有两类。一类是设备时间和电脑时间不一致导致你对着操作记录找不到对应日志。解决办法是抓日志前先校时或者以设备时间为准记录操作节点。另一类是日志行首的时间戳格式和你预期不同那是因为-v参数没指定默认格式比较简略。乱码问题多出现在中文日志上。logcat 默认按 UTF-8 处理如果应用输出的是其他编码终端里就会花掉。解决办法是把日志输出重定向到文件再用支持编码切换的编辑器打开。另外某些终端对宽字符的支持不好也会造成显示错位这不影响实际内容换工具即可。截断问题就是前面说的Chatty提示表示某进程日志输出太频繁被系统做了折叠。看到Chatty字样说明你漏掉了一部分行这种情况下要调大缓冲区或者降低日志频率不能装作没看见。7.3 常见问题速查表现象可能原因处理办法adb devices显示 unauthorized未授权调试手机点允许或撤销授权重连日志刷屏但看不到业务日志未过滤噪音太多加--pid或-s TAG崩了但日志里没有堆栈查了 main 没查 crash用-b crash单独 dump关键日志被覆盖缓冲区太小-G调大或-f落盘出现 Chatty 提示日志输出频率过高调大缓冲区降低输出频率ANR 没有堆栈无权限读/data/anr用 bugreport 获取抓包工具里看不到请求证书未信任或应用做了校验在授权测试环境内确认证书配置时间戳对不上设备与 PC 时间不同步抓取前校时并记录操作节点8. 我个人在这件事上的一些习惯说到底抓日志和用工具这套东西技巧层面就那么些真正拉开差距的是习惯。我自己的几个固定动作是任何一次问题复现之前先清空缓冲区、先确认设备授权、先调大缓冲区这三步做完再动手抓日志永远同时落盘哪怕只是看一眼因为人眼会漏文件不会提交日志前一定裁剪和脱敏既是对别人时间的尊重也是对自己职业操守的要求。还有一点体会比较深工具不要贪多。我刚入行那会儿听说什么工具都想装一遍结果每个都只会点两下真出问题时反而不知道该用哪个。后来收敛成一套核心组合——Android Studio 看日志、adb 做命令行补充、bugreport 兜底、Maestro 做冒烟、Perfetto 看性能够用了。剩下的工具等真的遇到那个场景再学那时候带着问题学效率比平时瞎点高得多。如果非要再补一个建议那就是把常用的命令整理成一个脚本或者备忘录放在手边。人的记忆在紧张的时候是靠不住的而一条存的命令能帮你省下十分钟的慌张。这个内容后面还能往两个方向扩展一是把日志采集做成 CI 里自动跑的环节每次构建后自动抓一轮关键路径日志做回归二是把崩溃日志做成自动聚类和去重避免同一个问题在群里被反复粘贴。这两件事我都试过一部分后面有机会再细说。