1. 项目概述从手动翻查到精准捕获在移动应用开发或者日常的安卓设备调试中查看应用的日志输出是定位问题、分析行为最直接的手段。logcat作为 Android 系统日志的“总闸门”记录了从系统内核到上层应用的所有活动轨迹。然而面对海量、滚动的日志流如何快速、精准地找到属于我们目标应用的那几行关键信息并将其持久化保存以供后续分析就成了一个高频且刚性的需求。这个项目的核心就是构建一个在终端环境下高效、灵活的日志捕获工具。它不再需要我们手动在adb logcat的输出海洋里用肉眼筛选或者频繁地复制粘贴。而是通过组合adb、grep、进程状态查询等命令实现针对特定应用的日志过滤、基于关键字的二次筛选以及将结果实时输出到文件的一站式操作。无论是开发者在联调时追踪自己的应用还是测试人员需要保存特定场景下的日志这个工具都能显著提升效率。接下来我将拆解其背后的技术逻辑并分享一个经过实战检验的、可直接复用的脚本方案。2. 核心思路与方案选型实现这个目标有几种常见的路径。最朴素的方法是直接使用adb logcat | grep管道组合。这确实能实现过滤但存在几个明显短板其一它过滤的是日志内容中包含关键字的行但很多系统或其他应用的日志也可能包含相同关键字造成干扰其二它无法优雅地应对应用进程重启PID变化的情况其三将输出同时显示在终端并写入文件需要处理输出流的分发。因此一个更健壮的方案应该围绕“应用身份”而非单纯的内容关键字来构建过滤核心。Android 的logcat命令本身提供了强大的过滤机制这正是我们方案的基础。2.1 为何选择基于logcat原生过滤logcat的过滤语法是[tag]:[priority]但它还有一个更强大的特性可以通过进程IDPID或包名Package Name进行过滤。这是最精准的方式能确保只捕获目标应用进程产生的日志。我们的方案将优先采用--pid参数进行过滤。其工作流程是通过包名找到应用当前运行的进程ID。使用adb logcat --pidPID命令让logcat底层只输出该进程的日志。在此基础上如果用户有关键字需求再通过grep进行二次过滤。最后通过输出重定向或tee命令将结果保存到文件。相比于单纯用grep过滤内容基于 PID 的过滤由logcat在源头完成效率更高结果也更纯净。只有当我们需要在目标应用日志中进一步缩小范围时才启用grep。2.2 关键命令工具解析整个方案依赖于几个核心命令的协同工作adb(Android Debug Bridge)与设备通信的桥梁。我们主要使用adb shell在设备上执行命令以及adb logcat获取日志。ps/pidof/pgrep用于在设备上查询进程信息。ps命令可以列出进程结合grep可以筛选出特定包名的进程。更高效的是pidof或pgrep它们直接返回指定名称的进程ID但需要注意这些命令在安卓shell中的可用性toybox或busybox的实现可能不同。grep文本搜索利器。用于在ps的输出中查找包名以及在logcat的输出流中过滤特定关键字。支持正则表达式功能强大。tee分流命令。它可以从标准输入读取数据同时写入标准输出和一个或多个文件。这正是实现“既在屏幕显示又保存到文件”的关键。方案选型的决定是以adb logcat --pid为核心过滤器以ps | grep或pidof动态获取 PID以tee命令实现双路输出构建一个可接受包名和可选关键字作为参数的封装脚本。3. 实现细节与脚本拆解下面我将呈现一个完整的 Bash 脚本实现并逐段解析其设计意图和实操要点。#!/bin/bash # 定义颜色输出方便区分信息 RED\033[0;31m GREEN\033[0;32m YELLOW\033[1;33m NC\033[0m # No Color # 打印带颜色的信息 log_info() { echo -e ${GREEN}[INFO]${NC} $1; } log_warn() { echo -e ${YELLOW}[WARN]${NC} $1; } log_error() { echo -e ${RED}[ERROR]${NC} $1; } # 检查参数 if [ $# -lt 1 ]; then echo 用法: $0 应用包名 [关键字] [输出文件] echo 示例: $0 com.example.myapp \E/AndroidRuntime\ ./myapp_crash.log exit 1 fi PACKAGE_NAME$1 KEYWORD$2 OUTPUT_FILE${3:-./logcat_${PACKAGE_NAME}_$(date %Y%m%d_%H%M%S).log} # 函数获取应用进程PID get_app_pid() { local pid # 方法1: 尝试使用 pidof (部分系统可能没有) pid$(adb shell pidof $PACKAGE_NAME 2/dev/null) if [ -n $pid ]; then echo $pid return 0 fi # 方法2: 使用 ps 和 grep 组合更通用 pid$(adb shell ps -A | grep -E \\${PACKAGE_NAME}\\ | grep -v grep | awk {print \$2} 2/dev/null) if [ -n $pid ]; then echo $pid return 0 fi log_error 未找到包名为 ${PACKAGE_NAME} 的运行进程。请确保应用已启动。 return 1 } # 主函数 main() { log_info 开始捕获应用 ${PACKAGE_NAME} 的日志... # 1. 获取PID APP_PID$(get_app_pid) if [ $? -ne 0 ]; then exit 1 fi log_info 应用进程PID: ${APP_PID} # 2. 构建 logcat 命令基础部分 LOGCAT_CMDadb logcat --pid${APP_PID} # 3. 构建最终命令管道 FINAL_CMD$LOGCAT_CMD if [ -n $KEYWORD ]; then log_info 启用关键字过滤: \${KEYWORD}\ FINAL_CMD$FINAL_CMD | grep --line-buffered \${KEYWORD}\ fi log_info 日志同时输出至文件: ${OUTPUT_FILE} # 使用 tee 同时输出到屏幕和文件 FINAL_CMD$FINAL_CMD | tee \${OUTPUT_FILE}\ # 4. 捕获退出信号确保清理 trap log_warn 正在停止日志捕获...; kill $LOGCAT_PID 2/dev/null; exit 0 INT TERM # 5. 执行命令 log_info 执行命令: ${LOGCAT_CMD} ... eval $FINAL_CMD LOGCAT_PID$! # 等待后台任务 wait $LOGCAT_PID } # 启动主函数 main3.1 脚本核心逻辑分步解析第一步参数处理与初始化脚本首先检查输入参数最少需要提供应用包名。关键字和输出文件路径是可选的。输出文件默认以包名和时间戳自动生成避免覆盖。这里使用了${3:-“default”}的 Bash 参数扩展语法意思是如果第三个参数不存在则使用默认值。第二步动态获取进程PID (get_app_pid函数)这是脚本稳健性的关键。我们提供了两种获取 PID 的方法pidof最直接但依赖于设备shell的实现。有些精简的安卓系统可能没有此命令。ps -A | grep | awk这是更通用的方法。ps -A列出所有进程grep -E “\${PACKAGE_NAME}\”使用精确单词匹配\和\是单词边界查找包名grep -v grep排除掉grep进程自身最后awk ‘{print $2}’提取第二列PID。注意ps的输出格式在不同 Android 版本或 ROM 上可能略有差异例如 PID 在第几列。上述命令假设 PID 在第二列这在大多数情况下成立。如果遇到问题可以先在adb shell中手动运行ps -A | grep 包名确认列位置并相应调整awk的$2。第三步构建并执行命令管道获取 PID 后构建核心命令adb logcat --pid${APP_PID}。如果用户提供了关键字则通过管道传递给grep。这里有一个重要技巧使用了--line-buffered参数。默认情况下grep会使用块缓冲特别是当其输出不是终端时这会导致日志内容在管道中累积无法实时显示和写入文件。--line-buffered强制grep对每一行都进行缓冲刷新实现了实时性。最后通过tee命令将流同时导向标准输出屏幕和指定的文件。第四步信号捕获与优雅退出脚本通过trap命令捕获CtrlC(INT) 和终止 (TERM) 信号。当用户想停止时脚本会先尝试终止后台运行的logcat进程kill $LOGCAT_PID然后自己再退出。这确保了资源被正确清理不会留下僵尸进程。第五步后台执行与等待使用将整个命令管道放到后台执行并记录其进程ID ($!)。然后主脚本用wait等待这个后台进程结束。这样脚本在前台可以响应中断信号而日志捕获在后台持续进行。3.2 使用方式与示例保存脚本将上述代码保存为一个文件例如capture_log.sh并赋予执行权限chmod x capture_log.sh。基础用法捕获指定应用的所有日志并显示在屏幕。./capture_log.sh com.example.myapp带关键字过滤只捕获包含 “E/AndroidRuntime” 通常是崩溃信息或 “MyTag” 的日志。./capture_log.sh com.example.myapp “E/AndroidRuntime” ./capture_log.sh com.example.myapp “MyTag”指定输出文件将过滤后的日志保存到特定文件。./capture_log.sh com.example.myapp “error” /tmp/myapp_error.log4. 高级技巧与常见问题排查在实际使用中你可能会遇到一些特殊情况。下面分享一些进阶技巧和问题解决方法。4.1 应对进程重启与多进程应用如果目标应用崩溃后重启其 PID 会改变我们的脚本会因为最初的 PID 失效而停止捕获日志。为了解决这个问题我们可以实现一个“PID 监控循环”。思路是将主逻辑放入一个循环中定期检查目标 PID 是否存活。如果进程不存在则重新获取 PID 并重启logcat命令。这里需要注意处理文件追加使用而不是和避免重复输出。# 简化的监控循环示例片段 while true; do CURRENT_PID$(get_app_pid) if [ -z $CURRENT_PID ] || [ $CURRENT_PID ! $LAST_PID ]; then # 杀死旧的 logcat 进程如果存在 [ -n $LOGCAT_PID ] kill $LOGCAT_PID 2/dev/null log_info “进程PID已更新为: ${CURRENT_PID}” LAST_PID$CURRENT_PID # 用新的PID启动logcat并追加到文件 adb logcat --pid${CURRENT_PID} | grep --line-buffered $KEYWORD | tee -a $OUTPUT_FILE LOGCAT_PID$! fi sleep 5 # 每5秒检查一次 done对于多进程应用例如某些应用有主进程和:push、:webview等子进程你可能需要捕获所有相关进程的日志。这时可以将--pid参数改为使用logcat的--regex过滤器或者更简单地使用基于包名tag的过滤。你可以通过adb logcat -v brief | grep “${PACKAGE_NAME}”先观察你的应用日志通常使用哪些tag然后用adb logcat MyAppTag:I *:S这样的语法来捕获。其中MyAppTag:I表示接收该 tag 的 Info 及以上级别日志*:S表示静默其他所有 tag。4.2 常见问题与解决方案速查表问题现象可能原因排查步骤与解决方案脚本报错未找到运行进程1. 包名错误。2. 应用确实未运行。3.ps或grep命令在设备上不可用或格式不符。1. 使用adb shell pm list packages确认包名。2. 启动目标应用。3. 在adb shell中手动运行ps -A和ps -A | grep 包名检查命令是否可用及输出格式调整脚本中的awk列号。日志输出有严重延迟不实时grep命令的缓冲机制导致。在grep命令后添加--line-buffered参数。捕获到的日志很少甚至没有1.logcat缓冲区被清空。2. 过滤条件太严格如PID错误。3. 应用日志级别过低。1. 先运行adb logcat -c清空缓冲区再运行脚本。2. 去掉--pid和grep直接运行adb logcat | tee file.log看是否有日志。确认PID是否正确。3. 尝试使用adb logcat *:V查看所有级别日志确认应用有输出。脚本停止后adb logcat进程仍在运行脚本的信号捕获 (trap) 未生效或kill命令未成功终止子进程。手动查找并终止ps aux | grep “adb logcat”找到PID然后用kill -9 PID强制终止。优化脚本使用pkill -P $$来杀死脚本产生的所有子进程。输出文件内容为空1. 文件路径权限问题。2.tee命令用法错误。3. 根本没有日志流经过管道。1. 检查当前目录是否有写权限或尝试指定绝对路径如/tmp/test.log。2. 确认命令管道正确可以先将tee部分去掉看屏幕是否有输出。3. 按上一条“日志很少”的方案排查。关键字grep过滤无效关键字包含特殊字符或grep默认是基础正则表达式。对于包含正则元字符如.,*,[,]的关键字使用grep -F进行固定字符串匹配或者用反斜杠转义特殊字符。4.3 性能考量与日志清理长期捕获日志尤其是全量日志可能会影响设备性能并产生巨大文件。建议按需过滤始终使用--pid或tag过滤从源头减少数据量。控制级别使用logcat的优先级过滤例如*:W只捕获 Warning 和 Error 级别以上的日志。定期清理在脚本开始捕获前可以加入adb logcat -c命令清空旧的环形缓冲区避免无关历史日志干扰。对于设备本身如果日志缓冲区满了系统会自动丢弃旧日志通常无需手动干预。文件轮转对于需要长时间如数天监控的场景可以在脚本中实现简单的日志文件轮转例如按日期或文件大小分割文件。这个脚本工具的价值在于它将一系列琐碎、易错的命令行操作封装成了一个可靠、可配置的自动化流程。它解决的不是一个复杂的技术难题而是一个高频的体验痛点。经过几次迭代和问题排查后它就会成为你调试工具箱里最顺手的那把“螺丝刀”。
Android日志精准捕获：基于PID过滤与实时输出的自动化脚本方案
1. 项目概述从手动翻查到精准捕获在移动应用开发或者日常的安卓设备调试中查看应用的日志输出是定位问题、分析行为最直接的手段。logcat作为 Android 系统日志的“总闸门”记录了从系统内核到上层应用的所有活动轨迹。然而面对海量、滚动的日志流如何快速、精准地找到属于我们目标应用的那几行关键信息并将其持久化保存以供后续分析就成了一个高频且刚性的需求。这个项目的核心就是构建一个在终端环境下高效、灵活的日志捕获工具。它不再需要我们手动在adb logcat的输出海洋里用肉眼筛选或者频繁地复制粘贴。而是通过组合adb、grep、进程状态查询等命令实现针对特定应用的日志过滤、基于关键字的二次筛选以及将结果实时输出到文件的一站式操作。无论是开发者在联调时追踪自己的应用还是测试人员需要保存特定场景下的日志这个工具都能显著提升效率。接下来我将拆解其背后的技术逻辑并分享一个经过实战检验的、可直接复用的脚本方案。2. 核心思路与方案选型实现这个目标有几种常见的路径。最朴素的方法是直接使用adb logcat | grep管道组合。这确实能实现过滤但存在几个明显短板其一它过滤的是日志内容中包含关键字的行但很多系统或其他应用的日志也可能包含相同关键字造成干扰其二它无法优雅地应对应用进程重启PID变化的情况其三将输出同时显示在终端并写入文件需要处理输出流的分发。因此一个更健壮的方案应该围绕“应用身份”而非单纯的内容关键字来构建过滤核心。Android 的logcat命令本身提供了强大的过滤机制这正是我们方案的基础。2.1 为何选择基于logcat原生过滤logcat的过滤语法是[tag]:[priority]但它还有一个更强大的特性可以通过进程IDPID或包名Package Name进行过滤。这是最精准的方式能确保只捕获目标应用进程产生的日志。我们的方案将优先采用--pid参数进行过滤。其工作流程是通过包名找到应用当前运行的进程ID。使用adb logcat --pidPID命令让logcat底层只输出该进程的日志。在此基础上如果用户有关键字需求再通过grep进行二次过滤。最后通过输出重定向或tee命令将结果保存到文件。相比于单纯用grep过滤内容基于 PID 的过滤由logcat在源头完成效率更高结果也更纯净。只有当我们需要在目标应用日志中进一步缩小范围时才启用grep。2.2 关键命令工具解析整个方案依赖于几个核心命令的协同工作adb(Android Debug Bridge)与设备通信的桥梁。我们主要使用adb shell在设备上执行命令以及adb logcat获取日志。ps/pidof/pgrep用于在设备上查询进程信息。ps命令可以列出进程结合grep可以筛选出特定包名的进程。更高效的是pidof或pgrep它们直接返回指定名称的进程ID但需要注意这些命令在安卓shell中的可用性toybox或busybox的实现可能不同。grep文本搜索利器。用于在ps的输出中查找包名以及在logcat的输出流中过滤特定关键字。支持正则表达式功能强大。tee分流命令。它可以从标准输入读取数据同时写入标准输出和一个或多个文件。这正是实现“既在屏幕显示又保存到文件”的关键。方案选型的决定是以adb logcat --pid为核心过滤器以ps | grep或pidof动态获取 PID以tee命令实现双路输出构建一个可接受包名和可选关键字作为参数的封装脚本。3. 实现细节与脚本拆解下面我将呈现一个完整的 Bash 脚本实现并逐段解析其设计意图和实操要点。#!/bin/bash # 定义颜色输出方便区分信息 RED\033[0;31m GREEN\033[0;32m YELLOW\033[1;33m NC\033[0m # No Color # 打印带颜色的信息 log_info() { echo -e ${GREEN}[INFO]${NC} $1; } log_warn() { echo -e ${YELLOW}[WARN]${NC} $1; } log_error() { echo -e ${RED}[ERROR]${NC} $1; } # 检查参数 if [ $# -lt 1 ]; then echo 用法: $0 应用包名 [关键字] [输出文件] echo 示例: $0 com.example.myapp \E/AndroidRuntime\ ./myapp_crash.log exit 1 fi PACKAGE_NAME$1 KEYWORD$2 OUTPUT_FILE${3:-./logcat_${PACKAGE_NAME}_$(date %Y%m%d_%H%M%S).log} # 函数获取应用进程PID get_app_pid() { local pid # 方法1: 尝试使用 pidof (部分系统可能没有) pid$(adb shell pidof $PACKAGE_NAME 2/dev/null) if [ -n $pid ]; then echo $pid return 0 fi # 方法2: 使用 ps 和 grep 组合更通用 pid$(adb shell ps -A | grep -E \\${PACKAGE_NAME}\\ | grep -v grep | awk {print \$2} 2/dev/null) if [ -n $pid ]; then echo $pid return 0 fi log_error 未找到包名为 ${PACKAGE_NAME} 的运行进程。请确保应用已启动。 return 1 } # 主函数 main() { log_info 开始捕获应用 ${PACKAGE_NAME} 的日志... # 1. 获取PID APP_PID$(get_app_pid) if [ $? -ne 0 ]; then exit 1 fi log_info 应用进程PID: ${APP_PID} # 2. 构建 logcat 命令基础部分 LOGCAT_CMDadb logcat --pid${APP_PID} # 3. 构建最终命令管道 FINAL_CMD$LOGCAT_CMD if [ -n $KEYWORD ]; then log_info 启用关键字过滤: \${KEYWORD}\ FINAL_CMD$FINAL_CMD | grep --line-buffered \${KEYWORD}\ fi log_info 日志同时输出至文件: ${OUTPUT_FILE} # 使用 tee 同时输出到屏幕和文件 FINAL_CMD$FINAL_CMD | tee \${OUTPUT_FILE}\ # 4. 捕获退出信号确保清理 trap log_warn 正在停止日志捕获...; kill $LOGCAT_PID 2/dev/null; exit 0 INT TERM # 5. 执行命令 log_info 执行命令: ${LOGCAT_CMD} ... eval $FINAL_CMD LOGCAT_PID$! # 等待后台任务 wait $LOGCAT_PID } # 启动主函数 main3.1 脚本核心逻辑分步解析第一步参数处理与初始化脚本首先检查输入参数最少需要提供应用包名。关键字和输出文件路径是可选的。输出文件默认以包名和时间戳自动生成避免覆盖。这里使用了${3:-“default”}的 Bash 参数扩展语法意思是如果第三个参数不存在则使用默认值。第二步动态获取进程PID (get_app_pid函数)这是脚本稳健性的关键。我们提供了两种获取 PID 的方法pidof最直接但依赖于设备shell的实现。有些精简的安卓系统可能没有此命令。ps -A | grep | awk这是更通用的方法。ps -A列出所有进程grep -E “\${PACKAGE_NAME}\”使用精确单词匹配\和\是单词边界查找包名grep -v grep排除掉grep进程自身最后awk ‘{print $2}’提取第二列PID。注意ps的输出格式在不同 Android 版本或 ROM 上可能略有差异例如 PID 在第几列。上述命令假设 PID 在第二列这在大多数情况下成立。如果遇到问题可以先在adb shell中手动运行ps -A | grep 包名确认列位置并相应调整awk的$2。第三步构建并执行命令管道获取 PID 后构建核心命令adb logcat --pid${APP_PID}。如果用户提供了关键字则通过管道传递给grep。这里有一个重要技巧使用了--line-buffered参数。默认情况下grep会使用块缓冲特别是当其输出不是终端时这会导致日志内容在管道中累积无法实时显示和写入文件。--line-buffered强制grep对每一行都进行缓冲刷新实现了实时性。最后通过tee命令将流同时导向标准输出屏幕和指定的文件。第四步信号捕获与优雅退出脚本通过trap命令捕获CtrlC(INT) 和终止 (TERM) 信号。当用户想停止时脚本会先尝试终止后台运行的logcat进程kill $LOGCAT_PID然后自己再退出。这确保了资源被正确清理不会留下僵尸进程。第五步后台执行与等待使用将整个命令管道放到后台执行并记录其进程ID ($!)。然后主脚本用wait等待这个后台进程结束。这样脚本在前台可以响应中断信号而日志捕获在后台持续进行。3.2 使用方式与示例保存脚本将上述代码保存为一个文件例如capture_log.sh并赋予执行权限chmod x capture_log.sh。基础用法捕获指定应用的所有日志并显示在屏幕。./capture_log.sh com.example.myapp带关键字过滤只捕获包含 “E/AndroidRuntime” 通常是崩溃信息或 “MyTag” 的日志。./capture_log.sh com.example.myapp “E/AndroidRuntime” ./capture_log.sh com.example.myapp “MyTag”指定输出文件将过滤后的日志保存到特定文件。./capture_log.sh com.example.myapp “error” /tmp/myapp_error.log4. 高级技巧与常见问题排查在实际使用中你可能会遇到一些特殊情况。下面分享一些进阶技巧和问题解决方法。4.1 应对进程重启与多进程应用如果目标应用崩溃后重启其 PID 会改变我们的脚本会因为最初的 PID 失效而停止捕获日志。为了解决这个问题我们可以实现一个“PID 监控循环”。思路是将主逻辑放入一个循环中定期检查目标 PID 是否存活。如果进程不存在则重新获取 PID 并重启logcat命令。这里需要注意处理文件追加使用而不是和避免重复输出。# 简化的监控循环示例片段 while true; do CURRENT_PID$(get_app_pid) if [ -z $CURRENT_PID ] || [ $CURRENT_PID ! $LAST_PID ]; then # 杀死旧的 logcat 进程如果存在 [ -n $LOGCAT_PID ] kill $LOGCAT_PID 2/dev/null log_info “进程PID已更新为: ${CURRENT_PID}” LAST_PID$CURRENT_PID # 用新的PID启动logcat并追加到文件 adb logcat --pid${CURRENT_PID} | grep --line-buffered $KEYWORD | tee -a $OUTPUT_FILE LOGCAT_PID$! fi sleep 5 # 每5秒检查一次 done对于多进程应用例如某些应用有主进程和:push、:webview等子进程你可能需要捕获所有相关进程的日志。这时可以将--pid参数改为使用logcat的--regex过滤器或者更简单地使用基于包名tag的过滤。你可以通过adb logcat -v brief | grep “${PACKAGE_NAME}”先观察你的应用日志通常使用哪些tag然后用adb logcat MyAppTag:I *:S这样的语法来捕获。其中MyAppTag:I表示接收该 tag 的 Info 及以上级别日志*:S表示静默其他所有 tag。4.2 常见问题与解决方案速查表问题现象可能原因排查步骤与解决方案脚本报错未找到运行进程1. 包名错误。2. 应用确实未运行。3.ps或grep命令在设备上不可用或格式不符。1. 使用adb shell pm list packages确认包名。2. 启动目标应用。3. 在adb shell中手动运行ps -A和ps -A | grep 包名检查命令是否可用及输出格式调整脚本中的awk列号。日志输出有严重延迟不实时grep命令的缓冲机制导致。在grep命令后添加--line-buffered参数。捕获到的日志很少甚至没有1.logcat缓冲区被清空。2. 过滤条件太严格如PID错误。3. 应用日志级别过低。1. 先运行adb logcat -c清空缓冲区再运行脚本。2. 去掉--pid和grep直接运行adb logcat | tee file.log看是否有日志。确认PID是否正确。3. 尝试使用adb logcat *:V查看所有级别日志确认应用有输出。脚本停止后adb logcat进程仍在运行脚本的信号捕获 (trap) 未生效或kill命令未成功终止子进程。手动查找并终止ps aux | grep “adb logcat”找到PID然后用kill -9 PID强制终止。优化脚本使用pkill -P $$来杀死脚本产生的所有子进程。输出文件内容为空1. 文件路径权限问题。2.tee命令用法错误。3. 根本没有日志流经过管道。1. 检查当前目录是否有写权限或尝试指定绝对路径如/tmp/test.log。2. 确认命令管道正确可以先将tee部分去掉看屏幕是否有输出。3. 按上一条“日志很少”的方案排查。关键字grep过滤无效关键字包含特殊字符或grep默认是基础正则表达式。对于包含正则元字符如.,*,[,]的关键字使用grep -F进行固定字符串匹配或者用反斜杠转义特殊字符。4.3 性能考量与日志清理长期捕获日志尤其是全量日志可能会影响设备性能并产生巨大文件。建议按需过滤始终使用--pid或tag过滤从源头减少数据量。控制级别使用logcat的优先级过滤例如*:W只捕获 Warning 和 Error 级别以上的日志。定期清理在脚本开始捕获前可以加入adb logcat -c命令清空旧的环形缓冲区避免无关历史日志干扰。对于设备本身如果日志缓冲区满了系统会自动丢弃旧日志通常无需手动干预。文件轮转对于需要长时间如数天监控的场景可以在脚本中实现简单的日志文件轮转例如按日期或文件大小分割文件。这个脚本工具的价值在于它将一系列琐碎、易错的命令行操作封装成了一个可靠、可配置的自动化流程。它解决的不是一个复杂的技术难题而是一个高频的体验痛点。经过几次迭代和问题排查后它就会成为你调试工具箱里最顺手的那把“螺丝刀”。
