教你如何像侦探一样查看Android系统中Binder通信的"工作日志"。
一、什么是Debugfs？
想象你的手机内核里有个"记事本"（Debugfs），专门用来记录各种系统模块的工作情况。Binder驱动（Android跨进程通信的核心）会把自己的工作日志写在这个记事本里。
- 位置：
/sys/kernel/debug/binder/目录下 - 关键文件：
stats（统计报表）、state（实时状态）、transactions（通信记录）等
二、Binder的"日志开关"（debug_mask）
Binder可以记录多种类型的日志（比如错误、通信失败等），通过一个叫debug_mask的开关控制：
-
怎么改开关？
执行命令：echo 数字 > /sys/module/binder/parameters/debug_mask -
数字怎么选？
每个数字对应一种日志类型（二进制位控制）：1（二进制0001）→ 用户错误 2（0010）→ 通信失败 4（0100）→ 通信死亡 8（1000）→ 打开/关闭记录...比如想同时记录错误和失败：
1+2=3→echo 3 > ...
三、看懂关键日志文件
1. stats文件（统计报表）
-
查看命令：
cat /sys/kernel/debug/binder/stats -
看什么？
- 总通信次数（BC/BR开头的命令计数）
- 各进程的线程数、内存使用情况
- 类似"本月通话时长统计"
2. state文件（实时状态）
-
查看命令：
cat /sys/kernel/debug/binder/state -
看什么？
- 当前活跃的进程和线程（像"正在通话中的联系人"）
- Binder对象引用情况（哪些对象被谁拿着不放）
- 内存缓冲区信息（还剩多少"通话时长"可用）
3. transactions文件（通信记录）
-
查看命令：
cat /sys/kernel/debug/binder/transactions -
看什么？
- 最近发生的跨进程通信详情（谁给谁发了什么消息）
- 失败记录会单独在
failed_transaction_log中
四、实际应用场景
- 卡顿分析：查看
state中线程是否堵塞 - 内存泄漏：通过
stats的buffer计数判断是否内存未释放 - 通信失败：从
failed_transaction_log找失败原因 - 死锁排查：观察
state中的线程等待关系
五、比喻理解
- Debugfs → 手机系统的"黑匣子"
- debug_mask → 黑匣子的录音开关（选录哪些声音）
- stats/state → 飞行数据报表（高度、速度、油量）
- transactions → 驾驶舱对话记录（机长和塔台说了什么）
通过这套工具，你就像有了X光机，能透视Android系统内部最核心的通信机制。下次遇到APP卡死或系统问题，就知道该从哪里看"病历"啦！
