包里的日志与自己的日志：从 Log 级别到四份日志的排障分工

先说场景。安卓修改大师智改工坊是一款 Windows 桌面工具，把"改 APK"压缩成一句话：拖入安装包，用中文写需求，AI 改 smali 与资源，改完自动回编、对齐、签名、校验，最后一键装到手机或模拟器上看效果。介绍页在 https://www.apkeditor.cn/ai-version.aspx，官网是 www.apkeditor.cn。

排障这件事，最怕的不是"没有日志"，而是不知道该看哪一份日志。很多人一遇到"改完的包不对"就去抓手机 logcat，抓了半天发现设备上根本没有那条日志 —— 因为它早在编译期就被剥掉了；也有人抱着应用内的日志翻来翻去，却不知道工具这边其实已经写了一份更直白的打包日志，里面明明白白写着是回编失败还是签名没签上。

所以这篇讲两件事：包里那份日志（Android 的 Log 体系、级别、Release 为什么要把它关掉、改包能把它"打开"到什么程度）和自己这边那份日志（智改工坊的四份日志，谁记什么、默认开不开、怎么开）。最后给一条固定流程，把两层日志串成一套能复用的排障路径。

一、先立框架：日志天然分成两层，别混着查

只要接受"日志分两层"这个框架，绝大多数排障的混乱感会立刻减少一半。第一层是包里的日志：被改的那个应用通过 Android 的日志接口打印到系统日志缓冲区里的内容，你用 adb logcat 去读。它的特点是"跟设备相关"—— 换一台手机、换一个系统版本，你能看到的内容可能完全不同；同时它也"跟构建配置相关"—— 同一个应用，Debug 包能刷屏，Release 包可能一行都没有。

第二层是自己这边的日志：改包工具在解析、反编译、等待 AI、打包、装机、吸附窗口这些环节里自己写下来的记录。它的特点是"跟包无关"—— 只要工具在你手上跑过，记录就在你的硬盘上；而且它记的是"流程有没有走通"，不是"应用运行时发生了什么"。

这两层的价值完全不同。应用启动就闪退，那是运行时的问题，第一层（设备日志）才是关键；反编译失败、回编报错、装不上去，那是流程问题，第二层（工具日志）一眼就能看到原因。最浪费时间的做法，是用一层去解释另一层的现象 —— 比如"打包失败了"去翻手机日志，"应用崩了"去翻工具日志，都属于问错了人。

工具侧这几份日志的设计取舍也值得说一句，因为它解释了"为什么日志长这样"。它们记的是判断与结果，而不是流水账：反编译日志记的是"出没出问题、问题是什么"，打包日志记的是"四条命令的原文 + 每一条输出"，诊断日志记的是"做了哪个判断"。原因很实在 —— 一个改包流程里，值得留痕的节点并不多，把"关键判断"记全，比把每个动作都记下来更有用，也不会因为日志太长而没人愿意看。另一个取舍是失败提示里直接带上日志末尾几行：很多人报问题时的第一反应是复述现象，而程序其实已经把"原因是什么"写在界面上了，只是藏在日志文件里没人翻。把尾巴直接摆到提示里，是刻意降低"看日志"的门槛。

对比项	包里的日志（第一层）	自己这边的日志（第二层）
存在哪里	设备的系统日志缓冲区	电脑硬盘（程序目录与项目目录）
谁来读	adb logcat（工作目录的 tools 里就带着 adb）	直接用记事本打开日志文件
能回答的问题	运行时为什么崩、为什么慢、走到了哪一步	反编译/回编/签名/装机哪一步没过、原话是什么
能否改包影响	能，但有边界（见第三章与边界表）	不用改包，改一个开关就全都有
常见误用	拿它解释"装不上"（其实是签名问题）	拿它解释"进不去主界面"（其实是权限弹窗）

二、Log 的五个级别：它们的意义不在"详细程度"，而在"过滤门槛"

Android 的日志接口提供了五个常用的级别：VERBOSE / DEBUG / INFO / WARN / ERROR。很多人把它们理解成"从啰嗦到严重"的阶梯，这只对了一半。更准确的说法是：它们是一套可过滤的优先级，每个级别在系统里对应一个固定的数值（VERBOSE 2、DEBUG 3、INFO 4、WARN 5、ERROR 6），你设置一个"最低门槛"之后，低于它的日志根本不会被打出来。

这个设计的意义在于成本可控：代码里可以放心地把每一处关键分支都写上日志，因为线上只要把门槛定在 INFO 或 WARN，那些 VERBOSE、DEBUG 行就完全不会产生输出 —— 既不用改代码，也不用担心日志把用户的存储空间和性能吃掉。

级别	数值	通常记什么	排障时的价值
VERBOSE	2	最细的流水：每一步的入参、分支走向、循环次数	定位"走到第几步断的"，包体积与性能代价最大
DEBUG	3	开发期调试信息：接口返回、缓存命中、状态切换	最常用的一档，够细又不至于淹没视线
INFO	4	关键节点：登录成功、订单提交、页面进入	线上默认门槛通常定在这里，还原用户操作路径
WARN	5	可疑但可继续：重试、降级、参数被兜底修正	"没崩但不对"的现场证据，比如接口连续重试
ERROR	6	失败与异常：请求失败、解析失败、不可恢复的错误	配合崩溃栈用，改包后回归时第一眼先看这一档

过滤是在读的时候做的。adb logcat *:W 表示"所有标签只显示 WARN 及以上"，而 adb logcat *:S MyTag:V 是"先把所有标签静音（Silent），只留 MyTag 的 VERBOSE 及以上"。这些写法的意义在于：设备上的日志是所有应用混在一起的，不过滤就没法看。

这里有一个容易被忽略的坑：系统里有个按标签控制开关的机制（读一个形如 log.tag.标签名 的属性来决定某个标签要不要输出），但它是"给敢用的人准备的"—— 一是要求代码里真的走了这个判断，二是修改它需要设备侧相应的权限，零售机上基本碰不到。所以对绝大多数人来说，"打开日志"这件事的现实路径只有一条：改包。

另外，日志从来不是免费的，这一点决定了"什么时候该开、什么时候必须关"。它的成本至少有三块：第一是包体积，每条日志的文本都是常量，会实实在在占在包里的代码段中，写得多的应用光日志文本就相当可观；第二是运行开销，日志调用要先拼接字符串、再走系统接口，放在高频路径上（列表滚动、循环体、每帧渲染）会把性能拖出肉眼可见的差距 —— 这正是"门槛"这个设计存在的意义：把开关留在代码里，把成本交给配置去控制；第三是信息暴露，详细日志里往往带着业务信息与设备信息，它落在设备的日志缓冲区里，接上调试桥就能读到，在具备系统级权限的环境里也更容易被查看 —— 换句话说，它不该被当成"只有自己看得见"的东西。

三、Release 包里日志为什么会消失：三道闸门，一道比一道狠

"我 Debug 包里明明刷屏，Release 包里一条都没有"—— 这不是某一家应用的问题，而是 Android 工程默认就会发生的现象。日志在 Release 构建里会依次撞上三道闸门，而且三道的后果完全不同：前两道是"打了但被挡住/被过滤"，日志调用本身还在；第三道是"代码被删了"，日志在任何设备上都不存在了。

第一道：运行时的布尔开关

最常见的一种写法是给日志套一个开关：只有某个常量/字段为真时才调用日志接口。这个开关在 Debug 构建里为真、Release 构建里为假（工程模板里那个"是否调试"的编译期标记就常被这么用）。它的后果很温和：调用都还在，只是永远不执行。改包时把这处判断绕过去，日志就回来了。

第二道：级别门槛与标签开关

有些工程不写全局开关，而是走"级别门槛"：代码调用日志接口时先问一句"这个标签在当前级别下要不要输出"。这样 Release 环境把门槛设高，VERBOSE、DEBUG 就自然不产生输出。它的后果同样温和：代码都在，只是被门槛挡住。改包时把门槛的判断改掉，或者在设备侧把标签级别放开（如果条件允许），都能看到日志。这道闸门也解释了为什么有些应用"能看到 ERROR 看不到 DEBUG"—— 不是日志被删了，是被门槛拦住了。

第三道：压缩与混淆阶段把日志调用整条删掉

最狠的一道来自构建期的代码压缩与优化。现代的 Android 构建链在 Release 里会做代码收缩与优化，而工程里可以配置一条规则，声明"这些日志方法没有副作用，可以安全移除"。优化器据此把日志调用连同它的参数、字符串一起删掉。这就是为什么有些包你在 dex 里连日志文本都搜不到 —— 它从来没被编进去。

一句话记住三道的区别：第一道是"关了开关"，第二道是"设了门槛"，第三道是"东西没了"。 前两道改包能救，第三道改包救不回来 —— 这不是能力问题，而是"包里的字节里本来就没有这段日志"。

混淆还会带来一个"看起来像丢日志"的干扰项：类名、方法名被改成短名之后，崩溃栈里的类名会变成看不懂的短标识。但请注意，日志的文本内容本身通常不受混淆影响（字符串常量不会被改写成乱码），受影响的是栈里的类名方法名 —— 所以"日志里能搜到关键词、但栈里全是不认识的类名"是很正常的组合，不要因此以为日志坏了。

附带的麻烦：混淆之后，崩溃栈里的类名也一起"消失"了

混淆带来的是第二种"日志好像坏了"的假象：类名、方法名被替换成短名之后，崩溃栈里会出现一堆 a.a.a 这样的标识。这是正常的混淆结果，与日志开关无关。工程上通用的做法是：构建产物里会同时生成一份名字映射文件，拿它可以把栈里的短名还原回可读的类名与方法名。所以一个很实在的操作习惯是：内测包的构建产物别随手删 —— 尤其是映射文件，它是你日后读懂崩溃栈的唯一钥匙。

如果实在拿不到映射文件，也还有一条能用的路：靠日志前缀 + 时间线 + 操作路径去反推。比如"点提交之后 200 毫秒出现的第一条 ERROR"通常就能定位到是哪个动作触发的；再配合改进后的日志前缀过滤，可读性会明显提升。这也是为什么前面反复强调"给日志加统一前缀"值得做 —— 它在混淆环境下几乎是唯一稳定的锚点。

顺便说一个非常实用的自查动作：在动手改之前，先确认这段日志到底还在不在包里。做法很朴素 —— 把包当成压缩文件解开，拿到里面的 dex 文件，然后用任意一个能按字节搜文本的工具去搜你记得的那句日志文本或标签名。搜得到，说明前两道闸门之一在挡着，改包有戏；一个字都搜不到，八成是第三道，别再花时间在改包上了。工作目录里本来就带着 7z 这类解压工具，这一步不需要额外装东西。

一张边界表："打开调试日志"到底能改到什么程度

把上面三道闸门翻译成"能不能改、怎么改、怎么验证"，就是下面这张表。它也是这篇文章最该被截图保存的部分 —— 它决定了你写需求时的措辞：需求写得越贴近表里"可改"的那几行，AI 一次改对的概率越高。

日志的现状	改包能不能救	怎么改 / 怎么验证
日志调用在，被一个布尔开关挡住	能	把开关的取值改掉；装机后 logcat 里能搜到该标签的行
日志调用在，被级别门槛拦着	能	把门槛判断改成"全部输出"；验证时先看 DEBUG 档有没有出现
日志标签/前缀不统一，混在别的输出里	能	给日志文本加一个固定前缀（如 [TAG-X]），logcat 按前缀过滤
日志改成了"写文件"而不是打系统日志	看情况	写文件的多半也有一个总开关；打开后去应用私有目录里找文件
日志调用在压缩/优化阶段被整条移除	不能	dex 里搜不到日志文本即属此类；只能回源码把移除规则关掉重新构建
依赖设备侧权限才能打开的标签开关	一般不能	普通零售设备改不动这类开关；改包其实是绕开它的可行替代

还有一条容易被忽略的边界：改包不会让日志"变多"。它只能把已经写在包里的日志放出来。如果某段关键路径本来就没有日志，想"补一行日志进去"属于改 smali 的范畴，能做，但比"打开一个开关"复杂得多，也更需要你把需求写清楚（在哪个类、哪个方法、打印什么内容）。实务上的建议是：优先做"打开已有的"，谨慎做"新增日志"，因为前者改一处、影响面小、验证简单。

四、四份日志的分工：dock.log / error.log / pack.log / apktool.log

再看自己这边。智改工坊在运行过程中会写四份日志，它们不是"同一个东西的四个副本"，而是四个不同环节的记录，各自负责回答一类问题。搞清楚分工，你就能做到"遇到问题一眼知道该开哪个文件"，而不是每次都把全部日志打包发给别人。

日志文件	记录什么	位置	默认开吗
dock.log	诊断日志：吸附与布局过程、打包过程、装机预览的关键判断	%LocalAppData%\ApkGallary\dock.log	否，要开
error.log	程序自己没接住的异常，排查"启动期/界面异常"用	%LocalAppData%\ApkGallary\error.log	异常出现时自动写
pack.log	打包全过程：工具链信息、四条命令、每一条输出、失败原因	项目目录下（跟项目走）	每次打包都写
apktool.log	反编译输出：解析出问题时的原因与完整输出	项目目录下（跟项目走）	反编译时写

dock.log 为什么默认关着？ 这是有意为之的取舍。吸附同步是以很高的频率在跑的（窗口位置反复写成），如果把每一轮都记下来，日志会以你想象不到的速度膨胀，同时白白吃掉磁盘 IO。所以它默认关闭，想开的时候有两种方式：配置里把诊断日志开关打开，或者启动时加一个命令行参数临时打开 —— 后者只对本次运行生效，不会写回配置，非常适合"我就要抓一次现场"的场景。这也解释了一个常见困惑：很多人第一次去找 dock.log，发现文件不存在 —— 不是坏了，是它还没被打开过。

用 dock.log 还有两个操作细节值得记住。第一，它在每次运行里第一次写入时会重建文件并写一行头部（含启动时间），之后是同一次运行内的追加。也就是说日志是"按运行分段"的，你要抓的问题是"刚刚这一次"的，就必须在这次运行里复现一次，然后再去读文件。第二，日志行前面带毫秒级时间戳，判断"哪个动作先发生"非常可靠 —— 这在排"窗口没跟上""装机没起来"这类时序问题时几乎决定成败。

打开它有两种方式，选哪种取决于你要抓的是"长期"还是"一次性"：

打开方式	生效范围	适合场景
改配置里的诊断日志开关	长期生效，重启程序后依然有效	这段时间一直在查同一类问题，希望每次运行都留记录
启动时加一个参数临时打开	只对本次运行生效，不写回配置	只想复现一次现场，不想留下长期开销

读 dock.log 也有窍门：它记的是"关键判断"，不是流水账。按关键词搜，比从头读到尾快得多。下面是几个最常被搜的词，以及它们出现时意味着什么：

搜索关键词	你会看到什么
打包：成功 / 打包：失败	打包结果那一行：成功后面跟着产物路径与签名信息，失败后面跟着一句原因
打包标记	标记写进资源文件的结果（已插入 / 已更新 / 跳过 / 写入失败，都不拦打包）
预览：	装机与拉起过程中的判断：模拟器端口、降级安装、测试专用包、装上了但没到前台、投屏连接
反编译 / 项目：	反编译环节的异常，以及项目目录相关的动作（例如复制原始包时失败）

pack.log 则完全相反，它每次都写。 因为打包是"低频、关键、必须留痕"的动作：它开头会记下是哪个项目目录、用的是哪套工具链（java / apktool / zipalign / apksigner 的路径）、签名私钥和证书的位置，然后把回编、对齐、签名、校验四步执行的完整命令行与全部输出逐行写进去。所以"包打不出来"这类问题的正确姿势是：先打开项目目录下的 pack.log，从下往上读，第一处报错就是原因。如果失败的提示里已经带了日志末尾几行，那更省事 —— 界面上的失败提示就是从这份日志里截的尾巴。

还值得单独说一句"为什么打包要多做一步签名校验"。回编、对齐、签名这三步都只看命令的退出码，而"到底签没签上、签成了什么"要靠校验这一步说了算 —— 万一密钥或证书的格式不对，只有校验会明确报出来。校验通过时，日志里会打印出签名证书的摘要信息，这一行就是你"这个包确实签好了"的凭据；出问题时，pack.log 里也能看到它卡在哪一步。

如果日志里出现的是"没找到某个工具"这类话，那问题不在项目、而在环境：回到「参数设置」页做一次工具链体检，它会把反编译与打包依赖的几个组件逐个检查一遍，给出是否就绪与完整路径，缺什么补什么即可 —— 环境类问题先看这一页，比翻日志快。

五、两层日志怎么配合：一条固定的排障路径

把前面的东西串起来，就是下面这条路径。它的核心思想是先分层、再定位、最后才动手：先用现象判断问题在"流程层"还是"运行层"，再决定开哪份日志，最后才决定要不要改包。

一个最常见的组合场景：改完包装上了，点开就闪退。 这时正确的顺序是：先看工具侧有没有异常（大概率没有，因为四步都过了），然后立刻用设备日志抓崩溃那一段 —— 崩溃栈里会明确写出异常类型和出错的类/方法。把这段栈贴回需求框里，让 AI 针对性地看那一处，比"再改一版试试"高效得多。这条链路的价值就在于：它把"猜"变成了"读"。

第二个组合场景：改完包，装机提示装不上去。 这类问题几乎不需要翻设备日志，答案就在工具的提示里。工具会用覆盖安装去装，遇到设备上已有更高版本时会自动加参数允许降级重装；遇到包声明为仅供测试时会自动换参数；而遇到"签名不一样"这一类，它会如实告诉你需要先卸载再装 —— 因为这类冲突是真正的装不上，不是参数能绕过去的。装完之后工具还会复核一次前台应用是不是它，这一个动作排掉了最容易误判的情况："命令返回了成功、但应用其实没起来"。

六个最常被问到的问题，集中答一遍

1. 找不到 dock.log，或者打开是空的。 先确认诊断开关有没有打开 —— 它默认是关的，没开过的机器上这个文件压根不会出现；如果开了还是空的，说明你这次运行里还没产生任何被记录的事件，复现一次再看。
2. 日志比现象"晚"了，看着对不上。 注意每次运行第一次写入会重建文件并写一行头部，你要看的是最后一段（也就是最近这次运行）的内容；配合毫秒级时间戳对齐操作时刻，时序就清楚了。
3. pack.log 显示四步都过了，装机也没报错，但应用闪退。 这属于运行层问题，工具侧日志不会有答案，直接去抓设备日志的崩溃段；把异常类型与出错位置抄回需求框，比反复重打有用得多。
4. 日志里全是短名字的类。 那是混淆的结果，不是日志坏了；找构建产物的名字映射文件还原，或者靠前缀与时间线反推。
5. 打开日志之后应用明显变慢。 关注串在与高频路径上的日志确实有成本。验证完就把包换回正式包，也不要用带详细日志的包去做性能对比，那样得出的结论没有意义。
6. 要把现场发给同事怎么发最有用。 一句话说清"哪一步、什么现象、大概时间点"，然后把项目目录下的 pack.log 和 %LocalAppData%\ApkGallary 下的 dock.log（需要时加上 error.log）一起给对方 —— 这比口述现象省掉一整轮来回。

六、两个自家应用实例：把开关打开，然后把话说明白

下面两个例子都是我们自己与同事的日常场景，用的是自家应用和内部工具，重点看"以前怎么做、现在一句话怎么做、改完怎么验证"这三步。

实例一：内部「巡检打卡」应用，需要在真机上看到被关掉的详细日志。

这是公司内部给外勤同事用的打卡应用，一直有个反馈：部分机型上"定位后提交"偶尔会失败，但现场描述只有一句"没成功"。而它的 Release 包里详细日志是关着的 —— 应用里有一个控制日志输出的开关，构建正式包时被置为关闭。以前的做法是把仓库拉下来、把那个开关改掉、重新构建一版内测包，再走一遍分发流程装到同事手机上；光是"等构建 + 等分发"就是大半天，而且每次只为了看一眼日志。

现在一句话：把自家安装包拖进安卓修改大师智改工坊，在需求框里写"把控制日志输出的开关打开，输出最详细级别的日志，标签保持原来的不变"，点「立刻修改」。改完 AI 在项目目录留下标志文件，程序自动弹出打包窗口，回编、对齐、签名、校验四步跑完；勾选打包后自动运行，包会直接装到设备上并拉起。

验证方式很具体：先把设备日志缓冲区清一次，然后在设备上复现一次"定位后提交"，再看日志 —— 能看到带该标签的详细行，说明这次改的是"被开关挡住的日志"，成功；如果一行都没有，那就直接得到了一条同样有价值的结论：这份日志属于被构建期移除的那一类，改包救不回来，需要回到源码把移除规则关掉重新构建。这条"要么拿到日志、要么拿到结论"的性质，是这套流程最实用的地方 —— 它不会让你白忙一场。

实例二：内部「工单派发」应用，要把藏起来的调试入口显示出来。

内部工单应用里原本有一个"开发者信息"入口，能看到当前接口地址、登录态、缓存状态，但它在正式包里被隐藏了（入口的显示与否由一个判断控制）。以前要核对接口返回，得让开发同学专门构建一版带入口的包；后来为了省事，有人干脆把这个入口留在正式包里，结果又担心内部同事误点。

现在一句话："把设置页里那个被隐藏的开发者信息入口显示出来，并把日志开关一起打开"，附件里放一张入口在设置页的位置截图，写清用途（说明栏要求不少于 10 个字，就是为了避免"这张图是干什么的"只能靠猜）。改完自动打包 + 装机拉起，验证两步：一是进设置页确认入口出现、点进去能看到各项信息；二是用设备日志确认启动阶段的详细行已经出现。两件事都确认完，这一轮改动就算验收通过 —— 而它全程只花了一次输入需求的时间。

这两个例子的共同点值得点出来：它们改的都不是"功能"，而是"可观测性"。 一个应用的日志与调试入口，本质上决定了它"出了问题之后能不能被查清楚"。而可观测性的开关，恰恰是那种"平时用不上、需要时必须马上有"的东西 —— 改包把它打开，比重新走一遍构建与分发链路，实在快太多。

还有一个让这类改动"一次投入、长期受益"的小习惯：把这一轮的需求原话留在项目历史里。 每次点「立刻修改」，需求原文与修改日期都会记进项目的历史（历史里只留你的原话，附件的用途说明不进历史），详情页按最新在最上排列，每条右边都有一个「选择」把那条需求填回输入框。于是"上次那个日志开关是怎么开的"这种问题不用再问人 —— 打开项目、翻历史、点一下「选择」，照抄着再改一遍，或者在新需求里加一句"跟上次一样，但标签换成 XX"。对经常要给同一批内部应用做重复改动的团队来说，这条习惯省下的时间比想象中多。

顺带一个提高效率的小习惯：给需求加一句验收条件，比如"改完请保证设备日志里能搜到某某关键字的行"。这句话不会让 AI 做更多事，但会让你在改完之后知道该验证什么。用过一段时间的人都会有同感：改包真正花时间的从来不是"改"，而是"改完之后不确定对不对"。

七、用户评价：他们是怎么用两层日志的

八、结语：把"看不见"变成"看得见"

这篇的技术部分可以收成三句话：日志是一套可过滤的优先级体系，级别决定的是门槛；Release 丢掉日志有三道闸门，前两道改包能打开、第三道改不回来；工具侧的四份日志各管一段，dock.log 管现场、error.log 管异常、pack.log 管打包、apktool.log 管反编译。把这三句话记住，你已经比大多数人更会查问题了。

于是打开安卓修改大师智改工坊时，整件事的样子其实就是那句口号：只需说话，就能让应用变成你想要的样子 —— 想看得更清楚，就把日志开关打开；想知道包是谁打的、什么时候打的，打包时标记会自动写进包里；想复现问题，装到设备上拉起就是几秒钟的事。排障这件事，从此不必再靠猜。

产品介绍页与下载入口：https://www.apkeditor.cn/ai-version.aspx（官网 www.apkeditor.cn）。