Binder这套东西平时写应用的时候基本感觉不到它的存在但只要一牵扯到系统服务、跨进程调用、性能优化或者稳定性问题它就立马变成绕不开的坎。尤其是做系统开发或者框架层维护的同学多少都有过被Binder问题折磨的经历——要么服务莫名连不上要么进程卡死ANR要么内存只涨不降最后用各种手段定位下来根因全在Binder这一层。这个系列写到第14篇前面把Binder的驱动原理、通信模型、内存映射、线程池管理这些都拆得差不多了这篇专门聊调试。Binder调试最大的难点在于它横跨内核态和用户态问题出在哪一层光靠看logcat往往不够必须要组合使用内核调试接口、trace事件和用户态工具才能把一条跨进程调用的完整链路还原出来。我会结合这些年实际踩过的坑把这套调试方法论完整梳理一遍。1. Binder出问题时的真实表现先搞清楚在调试什么很多人一上来就翻内核日志、抓binder tracing其实方向错了一半。Binder调试的第一步不是开工具而是先判断问题的表象属于哪一类。Binder故障在用户态的表现五花八门但根因类别其实非常集中我列一下最常见的几类。1.1 故障现象的变脸从ANR到服务无法注册第一类是跨进程调用超时或失败。最典型的表现是应用层抛出DeadObjectException、TransactionTooLargeException或者系统直接报ANR日志里能看到“Waiting because no binder driver is available”或者“Binder transaction failure”。这类现象背后通常对应两种截然不同的根因。一种是被调用的服务端进程Binder线程池已经耗尽所有binder线程都卡在别的业务上新请求排不上队另一种是Binder驱动层面的buffer分配失败也就是一次transaction要拷贝的数据量超过了单个Binder buffer的上限或者目标进程的内存碎片化导致映射空间不够。第二类是进程行为异常比如某个系统服务无响应、SurfaceFlinger卡顿、AMS主线程被Binder调用阻塞。这类问题通常是某个持有Binder调用的线程一直没有返回导致依赖它的上层业务全部等待。第三类是内存问题伴随进程RSS只增不减、系统整体内存压力升高。这类问题往往和Binder的node引用计数、buffer缓存没有正确释放有直接关系。如果故障现象能对应到这三类中的某一类调试工具的选择和排查路径就清晰多了。1.2 三个常见根因方向线程饥饿、缓存不足、引用泄漏把上面这些现象再压缩一下Binder调试其实就是在围绕三个根因方向做排查。线程饥饿指的是目标进程的Binder线程池没有可用的线程来处理新请求。Android系统中每个进程的Binder线程池默认上限是15个线程高负载场景下如果没有合理配置或者线程被长时间占用很容易出现请求排队甚至超时。这种情况在内核侧表现为线程都处于等待状态但队列里始终有待处理的transaction。缓存不足和Binder驱动为每个进程预留的mmap区域有关。默认情况下每个进程的Binder缓冲区上限是1MB这是一块通过mmap映射的物理内存。如果单次传输数据量过大或者短时间内大量transaction同时进行缓冲区会被耗尽。这种情况在日志里会有明确的“Out of memory”提示。引用泄漏则是Binder最隐蔽的一类问题。Binder驱动内部维护着node、ref、buffer这几种对象正常情况下BC_ACQUIRE和BC_RELEASE、BC_INCREFS和BC_DECREFS是成对出现的。一旦出现泄漏内核里的binder_node和binder_ref会持续增长最终导致进程内存异常增长或者服务无法释放。明确了这三类根因方向接下来的每一个调试工具就都有了自己的用武之地。2. 先开“天眼”把内核侧的Binder状态捞出来看Binder驱动的调试接口是整条调试链路的基石。用户态工具再花哨最终看到的都是内核态driver暴露的数据。所以第一步不是打开Android Studio而是确认系统的Binder调试节点是否可用。2.1 binderfs与debugfs调试接口的开启方式Android系统在较新的内核版本中已经迁移到了binderfs而传统的debugfs接口在不同版本和不同厂商ROM上差异很大所以很多时候第一步是检查节点是否挂载。在Android设备上连接adb后先确认Binder设备节点是否存在adb shell ls -l /dev/binder* adb shell ls -l /sys/kernel/debug/binder 2/dev/null || echo debugfs not mounted如果你的内核开启了debugfs且Binder的debug支持被编译进去/sys/kernel/debug/binder目录下会出现proc、state、stats、transactions这些节点。但需要注意的是从Android 11开始很多设备默认不再挂载debugfs或者Binder的debug节点被限制访问。这时候需要重新挂载adb root adb shell mount -t debugfs none /sys/kernel/debug adb shell ls -l /sys/kernel/debug/binder如果内核开启了binderfs并且没有设置hidepid通常可以看到/dev/binderfs/binder-control这类节点。用binderfs的好处是每个设备节点可以按命名空间隔离调试的时候可以直接指定设备。这里有一个很关键的经验如果你在公司内部的定制系统上做调试debugfs节点经常不是默认开启的。不要浪费时间对着一个空的/sys/kernel/debug目录发呆直接去看内核配置里有没有CONFIG_DEBUG_FS和CONFIG_ANDROID_BINDERFS。没有的话要么用带debug的内核重新刷机要么就只能靠trace和用户态工具来兜底。2.2 读内核调试文件binder状态信息的“明文”输出把/proc/binder/proc/pid文件打开你会看到一份那个进程在Binder驱动里全部状态的明文dump。这个文件是内核把binder_proc结构体序列化输出来的信息量巨大。核心内容分为几个部分binder_proc基本信息进程pid、ioctl调用次数、buffer总大小、空闲buffer数、线程数等。线程列表每个已经创建的binder_thread以及它当前的状态waiting for transaction还是waiting for reply等。node列表这个进程作为服务端注册出去的binder_node每个node有自己的ptr、cookie、引用计数。ref列表这个进程持有的指向其他进程binder的引用每个ref有描述、node指针、死亡通知状态。buffer列表已经分配的transaction缓冲区每个buffer有大小、data_ptr、transaction信息。实际执行adb shell cat /proc/binder/proc/1234输出会很长但最有价值的是线程状态和node/ref计数这两块。我举个例子假设你看到一段输出proc 1234 binder transactions: 12345 buf: 10000/10000/10000 threads: 15 ...buf: 10000/10000/10000这种连续三个数字表示当前已用缓冲区大小和总缓冲区大小如果已用和总量非常接近说明buffer压力很大。threads: 15表示线程数已经到了默认上限。线程部分每一行对应一个binder线程如果看到大量waiting for transaction说明线程都在等活干。如果没有空闲线程且仍有待处理的transaction那就是典型的线程池饿死。2.3 state文件与stats文件概览和统计的入口state文件和transactions文件适合做全局扫描看当前系统里所有Binder相关活动。state文件输出所有进程的node、ref和线程信息相当于把所有proc目录下的文件合并成一个。stats文件则偏向统计维度会记录每个进程的binder调用次数、活跃transaction数、总数据量等累计数据。这个文件在排查“系统性性能问题”时特别有用——不用逐个进程看直接从统计里找出调用量最大的进程然后针对它深入分析。我在实际工作中习惯先用stats文件做全量扫描确定可疑进程再用proc/pid文件做单进程深入分析两步搭配效率是最高的。3. 动态过程追踪还原一次跨进程调用的完整旅程状态文件是静态快照适合看“当前卡在哪”但Binder问题往往要回答“为什么会卡在这”。这个时候就需要动态追踪手段把一次BC_TRANSACTION从用户态发起、到驱动处理、再到BR_TRANSACTION返回用户态的整个过程录下来。3.1 开启binder tracingsystrace和atrace的基本用法Android系统自带ftrace对Binder事件的支持事件类型主要包含binder_transaction、binder_transaction_received、binder_transaction_alloc_buf、binder_transaction_buffer_release等。用systrace抓取时这些事件会以时间戳的形式出现在trace中。抓取命令# 在PC上 python systrace.py -t 10 -o trace.html binder_driver binder_driver_lock sched或者用atrace直接在设备上抓取adb shell atrace --kfuncs binder_driver -t 5 -o /data/local/tmp/trace.dat adb pull /data/local/tmp/trace.dat抓取完成后在trace中搜索关键字binder_transaction。每一条记录会包含发起方进程pid、目标进程pid、transaction的code、flags、数据大小等信息。如果一次transaction耗时异常长你会看到它开始的时间戳和结束的时间戳相隔很远中间穿插着大量调度事件。3.2 从事件流还原BR/BC交换过程有一次我排查一个SurfaceFlinger卡顿问题trace事件显示一个binder_transaction在进程A发起后目标进程B迟迟没有返回。从trace的事件流来看B的binder线程确实收到了transaction但是在线程上下文中没有立刻执行返回逻辑而是被一个耗时很长的图形合成任务占用了。这个信息如果只看状态文件是完全看不出来的因为状态文件只能告诉你“B线程在忙”但trace能告诉你“B线程因为什么在忙”。具体还原方法不复杂。找到binder_transaction事件的pid然后沿时间轴找到同一个进程下binder_transaction_received事件两者之间就是目标进程从“收到调用”到“处理完调用”的时间窗口。如果这个窗口里出现了长耗时函数或高CPU占用根因就找到了。动态追踪特别适合定位“时好时坏”的偶现问题。静态dump抓不到现场但trace开着还能抓个大致的调用链脉络。4. 实战案例复盘三类最典型的Binder调试场景前面讲了工具这里我拿出三个真实场景把完整的排查链路走一遍。案例本身不一定多复杂但排查思路是可以直接复用的。4.1 场景一服务端线程池耗尽现象应用层日志反复出现DeadObjectException或者系统服务偶发无响应。查看服务端进程dump信息发现Binder线程池没有空闲线程。排查链路首先在用户态用dumpsys activity看有没有ANR记录确认无响应进程。连接adb拿到目标进程pid。查看/proc/binder/proc/pid重点看threads部分。正常情况下线程列表里15个线程的状态应该大部分是waiting for transaction。如果看到线程少、事务繁忙说明线程池已经打满。继续往上看这些线程具体停在哪可以看到它们关联的transaction是从哪个进程发来的。这个case的根因通常是服务端某个业务逻辑持有锁而Binder调用又在等同一把锁形成了锁竞争导致所有binder线程都被卡住。解决方向是优化锁粒度或避免在Binder线程里做长时间阻塞操作。经验提示服务端进程的Binder线程池默认上限是15个不是越大越好。线程数量增加会加剧锁竞争和上下文切换在系统服务里尤其明显。通过/proc/binder/proc/pid看到线程数打满时先排查业务逻辑问题不要盲目调大上限。4.2 场景二buffer分配失败1MB上限被谁吃了现象app调用系统服务时偶发TransactionTooLargeExceptionlogcat里能看到Binder driver报告Out of memory: binder_transaction。排查链路确认异常发生的时间点。查看目标进程的buffer占用情况cat /proc/binder/proc/pid看buf部分的已用大小。用cat /proc/binder/stats找buffer缓存占用高的进程。在Android系统中每个进程Binder mmap区域默认1MB。这1MB不仅承载正常的跨进程数据拷贝还包含内核为transaction分配的临时buffer。很多大图、大Bitmap、大字符串在传输时很容易撑爆这个空间。实战中最常见的坑是一个进程既是服务端又是客户端同一时间既处理大量incoming transaction又发起大量outgoing transactionbuffer空间被两头挤压。定位到一个具体场景当时是锁屏界面显示壁纸缩略图多个应用同时向SystemUI传输图片数据SystemUI的1MB buffer瞬间耗尽。这类问题的解决思路分两个层面。第一个层面是减少单次传输数据量比如用文件描述符传递替代大数据拷贝用共享内存android.os.SharedMemory传大块数据第二个层面是控制并发确保不在同一时间发起大量大事务调用。4.3 场景三node/ref引用泄漏导致的内存只涨不降现象某个常驻进程RSS缓慢但持续增长dumpsys meminfo显示Binder buffer、Binder node对象数量异常增长。排查链路记录一段时间内两次/proc/binder/proc/pid的输出对比node和ref数量。如果node数量持续增长说明服务端不断有binder对象被创建但从未释放。如果ref数量持续增长说明客户端持有引用但从未释放。node泄漏的根因通常是服务端把Binder对象注册在了某个全局容器里又忘记在对象销毁时从容器中移除。ref泄漏通常是客户端忘记调用unlinkToDeath或者没有正确释放ServiceConnection。对比命令很直接adb shell cat /proc/binder/proc/1234 | grep node | wc -l # 隔10分钟再执行一次 adb shell cat /proc/binder/proc/1234 | grep node | wc -l数值只增不减基本可以确定泄漏。再进一步看node对应的ptr和cookie和用户态ServiceManager注册的服务做对比缩小到具体是哪个服务泄漏。这类问题的调试难度不在工具而在于“谁创建了这些node”——内核只记录了进程和引用关系不记录业务调用栈。所以更高效的方法是结合用户态的binder proxy对象分析在Java层用android.os.Debug.getBinderDeathReceivedCount()或者hookBinderProxy的finalize方法来追踪未释放的proxy。5. 用户态调试工具与惯用“偏方”内核接口能解决绝大多数问题但有些场景需要从用户态反过来看或者需要更友好的可视化输出。这套工具链也值得备齐。5.1 用dumpsys system_server和DDMS做用户态侧写dumpsys系列命令里有两种和Binder调试强相关。一种是直接dump系统服务的当前binder状态比如dumpsys activity binder、dumpsys SurfaceFlinger --binder。另一种是通过dumpsys service列出所有已注册的system service快速确认服务是否存在、是否注册到了正确的context。在Android Studio的DDMS视角下可以通过Device Monitor里的Debug选项查看进程的Binder信息但说实话用起来并不如内核节点直接。我在实际工作中用DDMS更多是配合内存分析先确认进程native堆里的binder buffer对象是否有堆积再回到内核节点找对应关系。比较实用的是在原生代码里主动打印binder调用栈通过ALOGD输出当前线程正在执行的transaction code这在排查“某个线程卡在Binder调用上”的时候非常有效。5.2 strace与BPF更高阶的动态追踪手段strace在Android平台上可以用来追踪进程的Binder ioctl调用adb shell strace -p 1234 -e traceioctl输出很直接能看到进程发起的所有ioctl以及对应的cmdBC_TRANSACTION、BC_FREE_BUFFER等。缺点是strace本身会严重拖慢进程线上设备不太适合但在本地调试环境是很好的确认手段。如果设备内核支持BPF还可以用bpftrace等工具对Binder驱动函数做动态探针。我自己试过直接对binder_thread_read和binder_transaction函数挂kprobe采集调用参数和耗时分布。这个方案的优势是对进程性能影响极小而且可以精准统计每个transaction code的延迟分布。不过它的门槛在于需要root和较新的内核厂商设备往往受限。5.3 一套我长期在用的Binder调试套路把这些工具整理成一套流程的话我会按这样的优先级执行第一步复现问题时抓logcat和kernel log先排除明显错误TransactionTooLarge、DeadObject之类。第二步如果问题稳定可复现直接cat /proc/binder/stats和cat /proc/binder/proc/pid看静态状态。这一步能解决80%的定位需求。第三步如果是偶发或耗时问题开binder tracing抓systrace还原时间轴上的transaction生命周期。第四步如果问题在内存泄漏方向对比两次dump的node和ref数量缩小范围。最后结合用户态业务逻辑确认根因而不是只停留在内核层数据上。这套流程中我个人最看重的是“先看stats再抓trace”的顺序。很多人一上来就开systrace抓几分钟数据量大到没法分析。先用静态信息锁定目标和时间窗口再用动态追踪精准验证效率能提高数倍。6. 从内核日志里读到的不只是错误Binder调试还有一个容易被忽略的信息来源内核日志。dmesg里关于Binder的输出分为两类。一类是明显的错误级别日志比如binder: 1234:1234 transaction failed 29189/-22表示特定进程transaction失败并返回了错误码。另一类是正常的调试日志比如proc创建、binder线程创建、buffer分配回收等。如果内核开启了动态调试还可以通过echo file drivers/android/binder.c p /sys/kernel/debug/dynamic_debug/control打开Binder驱动的详细日志输出看到每一次transaction的具体流向。需要注意的是生产环境不建议长时间开启动态调试否则内核日志量会非常大直接把存储空间打满。我一般只会在本地测试机上开启抓完问题就立刻关闭。还有一个经验细节打开动态调试后transaction数据的大小会直接体现在日志里如果发现某个transaction大小达到几百KB那基本就离TransactionTooLargeException不远了。回到开头说的那三类根因方向内核日志里的-22EINVAL、-12ENOMEM、-28ENOSPC都很有指向性-12基本就是buffer不足-28排查node泄漏痕迹-22则需要结合业务代码看是不是传了非法参数。把错误码和静态dump数据配合起来看Binder出问题的定位就会快很多。Binder调试做到最后拼的不是知道多少命令而是能不能把“用户态现象—进程状态—内核数据—业务代码”这条链路串起来。每次排查完我都会把当时的内核节点输出和trace存一份很多问题隔几个月再遇到直接翻历史记录就能少走一大段弯路。
Binder调试实战：从内核状态到动态追踪，破解跨进程调用难题
Binder这套东西平时写应用的时候基本感觉不到它的存在但只要一牵扯到系统服务、跨进程调用、性能优化或者稳定性问题它就立马变成绕不开的坎。尤其是做系统开发或者框架层维护的同学多少都有过被Binder问题折磨的经历——要么服务莫名连不上要么进程卡死ANR要么内存只涨不降最后用各种手段定位下来根因全在Binder这一层。这个系列写到第14篇前面把Binder的驱动原理、通信模型、内存映射、线程池管理这些都拆得差不多了这篇专门聊调试。Binder调试最大的难点在于它横跨内核态和用户态问题出在哪一层光靠看logcat往往不够必须要组合使用内核调试接口、trace事件和用户态工具才能把一条跨进程调用的完整链路还原出来。我会结合这些年实际踩过的坑把这套调试方法论完整梳理一遍。1. Binder出问题时的真实表现先搞清楚在调试什么很多人一上来就翻内核日志、抓binder tracing其实方向错了一半。Binder调试的第一步不是开工具而是先判断问题的表象属于哪一类。Binder故障在用户态的表现五花八门但根因类别其实非常集中我列一下最常见的几类。1.1 故障现象的变脸从ANR到服务无法注册第一类是跨进程调用超时或失败。最典型的表现是应用层抛出DeadObjectException、TransactionTooLargeException或者系统直接报ANR日志里能看到“Waiting because no binder driver is available”或者“Binder transaction failure”。这类现象背后通常对应两种截然不同的根因。一种是被调用的服务端进程Binder线程池已经耗尽所有binder线程都卡在别的业务上新请求排不上队另一种是Binder驱动层面的buffer分配失败也就是一次transaction要拷贝的数据量超过了单个Binder buffer的上限或者目标进程的内存碎片化导致映射空间不够。第二类是进程行为异常比如某个系统服务无响应、SurfaceFlinger卡顿、AMS主线程被Binder调用阻塞。这类问题通常是某个持有Binder调用的线程一直没有返回导致依赖它的上层业务全部等待。第三类是内存问题伴随进程RSS只增不减、系统整体内存压力升高。这类问题往往和Binder的node引用计数、buffer缓存没有正确释放有直接关系。如果故障现象能对应到这三类中的某一类调试工具的选择和排查路径就清晰多了。1.2 三个常见根因方向线程饥饿、缓存不足、引用泄漏把上面这些现象再压缩一下Binder调试其实就是在围绕三个根因方向做排查。线程饥饿指的是目标进程的Binder线程池没有可用的线程来处理新请求。Android系统中每个进程的Binder线程池默认上限是15个线程高负载场景下如果没有合理配置或者线程被长时间占用很容易出现请求排队甚至超时。这种情况在内核侧表现为线程都处于等待状态但队列里始终有待处理的transaction。缓存不足和Binder驱动为每个进程预留的mmap区域有关。默认情况下每个进程的Binder缓冲区上限是1MB这是一块通过mmap映射的物理内存。如果单次传输数据量过大或者短时间内大量transaction同时进行缓冲区会被耗尽。这种情况在日志里会有明确的“Out of memory”提示。引用泄漏则是Binder最隐蔽的一类问题。Binder驱动内部维护着node、ref、buffer这几种对象正常情况下BC_ACQUIRE和BC_RELEASE、BC_INCREFS和BC_DECREFS是成对出现的。一旦出现泄漏内核里的binder_node和binder_ref会持续增长最终导致进程内存异常增长或者服务无法释放。明确了这三类根因方向接下来的每一个调试工具就都有了自己的用武之地。2. 先开“天眼”把内核侧的Binder状态捞出来看Binder驱动的调试接口是整条调试链路的基石。用户态工具再花哨最终看到的都是内核态driver暴露的数据。所以第一步不是打开Android Studio而是确认系统的Binder调试节点是否可用。2.1 binderfs与debugfs调试接口的开启方式Android系统在较新的内核版本中已经迁移到了binderfs而传统的debugfs接口在不同版本和不同厂商ROM上差异很大所以很多时候第一步是检查节点是否挂载。在Android设备上连接adb后先确认Binder设备节点是否存在adb shell ls -l /dev/binder* adb shell ls -l /sys/kernel/debug/binder 2/dev/null || echo debugfs not mounted如果你的内核开启了debugfs且Binder的debug支持被编译进去/sys/kernel/debug/binder目录下会出现proc、state、stats、transactions这些节点。但需要注意的是从Android 11开始很多设备默认不再挂载debugfs或者Binder的debug节点被限制访问。这时候需要重新挂载adb root adb shell mount -t debugfs none /sys/kernel/debug adb shell ls -l /sys/kernel/debug/binder如果内核开启了binderfs并且没有设置hidepid通常可以看到/dev/binderfs/binder-control这类节点。用binderfs的好处是每个设备节点可以按命名空间隔离调试的时候可以直接指定设备。这里有一个很关键的经验如果你在公司内部的定制系统上做调试debugfs节点经常不是默认开启的。不要浪费时间对着一个空的/sys/kernel/debug目录发呆直接去看内核配置里有没有CONFIG_DEBUG_FS和CONFIG_ANDROID_BINDERFS。没有的话要么用带debug的内核重新刷机要么就只能靠trace和用户态工具来兜底。2.2 读内核调试文件binder状态信息的“明文”输出把/proc/binder/proc/pid文件打开你会看到一份那个进程在Binder驱动里全部状态的明文dump。这个文件是内核把binder_proc结构体序列化输出来的信息量巨大。核心内容分为几个部分binder_proc基本信息进程pid、ioctl调用次数、buffer总大小、空闲buffer数、线程数等。线程列表每个已经创建的binder_thread以及它当前的状态waiting for transaction还是waiting for reply等。node列表这个进程作为服务端注册出去的binder_node每个node有自己的ptr、cookie、引用计数。ref列表这个进程持有的指向其他进程binder的引用每个ref有描述、node指针、死亡通知状态。buffer列表已经分配的transaction缓冲区每个buffer有大小、data_ptr、transaction信息。实际执行adb shell cat /proc/binder/proc/1234输出会很长但最有价值的是线程状态和node/ref计数这两块。我举个例子假设你看到一段输出proc 1234 binder transactions: 12345 buf: 10000/10000/10000 threads: 15 ...buf: 10000/10000/10000这种连续三个数字表示当前已用缓冲区大小和总缓冲区大小如果已用和总量非常接近说明buffer压力很大。threads: 15表示线程数已经到了默认上限。线程部分每一行对应一个binder线程如果看到大量waiting for transaction说明线程都在等活干。如果没有空闲线程且仍有待处理的transaction那就是典型的线程池饿死。2.3 state文件与stats文件概览和统计的入口state文件和transactions文件适合做全局扫描看当前系统里所有Binder相关活动。state文件输出所有进程的node、ref和线程信息相当于把所有proc目录下的文件合并成一个。stats文件则偏向统计维度会记录每个进程的binder调用次数、活跃transaction数、总数据量等累计数据。这个文件在排查“系统性性能问题”时特别有用——不用逐个进程看直接从统计里找出调用量最大的进程然后针对它深入分析。我在实际工作中习惯先用stats文件做全量扫描确定可疑进程再用proc/pid文件做单进程深入分析两步搭配效率是最高的。3. 动态过程追踪还原一次跨进程调用的完整旅程状态文件是静态快照适合看“当前卡在哪”但Binder问题往往要回答“为什么会卡在这”。这个时候就需要动态追踪手段把一次BC_TRANSACTION从用户态发起、到驱动处理、再到BR_TRANSACTION返回用户态的整个过程录下来。3.1 开启binder tracingsystrace和atrace的基本用法Android系统自带ftrace对Binder事件的支持事件类型主要包含binder_transaction、binder_transaction_received、binder_transaction_alloc_buf、binder_transaction_buffer_release等。用systrace抓取时这些事件会以时间戳的形式出现在trace中。抓取命令# 在PC上 python systrace.py -t 10 -o trace.html binder_driver binder_driver_lock sched或者用atrace直接在设备上抓取adb shell atrace --kfuncs binder_driver -t 5 -o /data/local/tmp/trace.dat adb pull /data/local/tmp/trace.dat抓取完成后在trace中搜索关键字binder_transaction。每一条记录会包含发起方进程pid、目标进程pid、transaction的code、flags、数据大小等信息。如果一次transaction耗时异常长你会看到它开始的时间戳和结束的时间戳相隔很远中间穿插着大量调度事件。3.2 从事件流还原BR/BC交换过程有一次我排查一个SurfaceFlinger卡顿问题trace事件显示一个binder_transaction在进程A发起后目标进程B迟迟没有返回。从trace的事件流来看B的binder线程确实收到了transaction但是在线程上下文中没有立刻执行返回逻辑而是被一个耗时很长的图形合成任务占用了。这个信息如果只看状态文件是完全看不出来的因为状态文件只能告诉你“B线程在忙”但trace能告诉你“B线程因为什么在忙”。具体还原方法不复杂。找到binder_transaction事件的pid然后沿时间轴找到同一个进程下binder_transaction_received事件两者之间就是目标进程从“收到调用”到“处理完调用”的时间窗口。如果这个窗口里出现了长耗时函数或高CPU占用根因就找到了。动态追踪特别适合定位“时好时坏”的偶现问题。静态dump抓不到现场但trace开着还能抓个大致的调用链脉络。4. 实战案例复盘三类最典型的Binder调试场景前面讲了工具这里我拿出三个真实场景把完整的排查链路走一遍。案例本身不一定多复杂但排查思路是可以直接复用的。4.1 场景一服务端线程池耗尽现象应用层日志反复出现DeadObjectException或者系统服务偶发无响应。查看服务端进程dump信息发现Binder线程池没有空闲线程。排查链路首先在用户态用dumpsys activity看有没有ANR记录确认无响应进程。连接adb拿到目标进程pid。查看/proc/binder/proc/pid重点看threads部分。正常情况下线程列表里15个线程的状态应该大部分是waiting for transaction。如果看到线程少、事务繁忙说明线程池已经打满。继续往上看这些线程具体停在哪可以看到它们关联的transaction是从哪个进程发来的。这个case的根因通常是服务端某个业务逻辑持有锁而Binder调用又在等同一把锁形成了锁竞争导致所有binder线程都被卡住。解决方向是优化锁粒度或避免在Binder线程里做长时间阻塞操作。经验提示服务端进程的Binder线程池默认上限是15个不是越大越好。线程数量增加会加剧锁竞争和上下文切换在系统服务里尤其明显。通过/proc/binder/proc/pid看到线程数打满时先排查业务逻辑问题不要盲目调大上限。4.2 场景二buffer分配失败1MB上限被谁吃了现象app调用系统服务时偶发TransactionTooLargeExceptionlogcat里能看到Binder driver报告Out of memory: binder_transaction。排查链路确认异常发生的时间点。查看目标进程的buffer占用情况cat /proc/binder/proc/pid看buf部分的已用大小。用cat /proc/binder/stats找buffer缓存占用高的进程。在Android系统中每个进程Binder mmap区域默认1MB。这1MB不仅承载正常的跨进程数据拷贝还包含内核为transaction分配的临时buffer。很多大图、大Bitmap、大字符串在传输时很容易撑爆这个空间。实战中最常见的坑是一个进程既是服务端又是客户端同一时间既处理大量incoming transaction又发起大量outgoing transactionbuffer空间被两头挤压。定位到一个具体场景当时是锁屏界面显示壁纸缩略图多个应用同时向SystemUI传输图片数据SystemUI的1MB buffer瞬间耗尽。这类问题的解决思路分两个层面。第一个层面是减少单次传输数据量比如用文件描述符传递替代大数据拷贝用共享内存android.os.SharedMemory传大块数据第二个层面是控制并发确保不在同一时间发起大量大事务调用。4.3 场景三node/ref引用泄漏导致的内存只涨不降现象某个常驻进程RSS缓慢但持续增长dumpsys meminfo显示Binder buffer、Binder node对象数量异常增长。排查链路记录一段时间内两次/proc/binder/proc/pid的输出对比node和ref数量。如果node数量持续增长说明服务端不断有binder对象被创建但从未释放。如果ref数量持续增长说明客户端持有引用但从未释放。node泄漏的根因通常是服务端把Binder对象注册在了某个全局容器里又忘记在对象销毁时从容器中移除。ref泄漏通常是客户端忘记调用unlinkToDeath或者没有正确释放ServiceConnection。对比命令很直接adb shell cat /proc/binder/proc/1234 | grep node | wc -l # 隔10分钟再执行一次 adb shell cat /proc/binder/proc/1234 | grep node | wc -l数值只增不减基本可以确定泄漏。再进一步看node对应的ptr和cookie和用户态ServiceManager注册的服务做对比缩小到具体是哪个服务泄漏。这类问题的调试难度不在工具而在于“谁创建了这些node”——内核只记录了进程和引用关系不记录业务调用栈。所以更高效的方法是结合用户态的binder proxy对象分析在Java层用android.os.Debug.getBinderDeathReceivedCount()或者hookBinderProxy的finalize方法来追踪未释放的proxy。5. 用户态调试工具与惯用“偏方”内核接口能解决绝大多数问题但有些场景需要从用户态反过来看或者需要更友好的可视化输出。这套工具链也值得备齐。5.1 用dumpsys system_server和DDMS做用户态侧写dumpsys系列命令里有两种和Binder调试强相关。一种是直接dump系统服务的当前binder状态比如dumpsys activity binder、dumpsys SurfaceFlinger --binder。另一种是通过dumpsys service列出所有已注册的system service快速确认服务是否存在、是否注册到了正确的context。在Android Studio的DDMS视角下可以通过Device Monitor里的Debug选项查看进程的Binder信息但说实话用起来并不如内核节点直接。我在实际工作中用DDMS更多是配合内存分析先确认进程native堆里的binder buffer对象是否有堆积再回到内核节点找对应关系。比较实用的是在原生代码里主动打印binder调用栈通过ALOGD输出当前线程正在执行的transaction code这在排查“某个线程卡在Binder调用上”的时候非常有效。5.2 strace与BPF更高阶的动态追踪手段strace在Android平台上可以用来追踪进程的Binder ioctl调用adb shell strace -p 1234 -e traceioctl输出很直接能看到进程发起的所有ioctl以及对应的cmdBC_TRANSACTION、BC_FREE_BUFFER等。缺点是strace本身会严重拖慢进程线上设备不太适合但在本地调试环境是很好的确认手段。如果设备内核支持BPF还可以用bpftrace等工具对Binder驱动函数做动态探针。我自己试过直接对binder_thread_read和binder_transaction函数挂kprobe采集调用参数和耗时分布。这个方案的优势是对进程性能影响极小而且可以精准统计每个transaction code的延迟分布。不过它的门槛在于需要root和较新的内核厂商设备往往受限。5.3 一套我长期在用的Binder调试套路把这些工具整理成一套流程的话我会按这样的优先级执行第一步复现问题时抓logcat和kernel log先排除明显错误TransactionTooLarge、DeadObject之类。第二步如果问题稳定可复现直接cat /proc/binder/stats和cat /proc/binder/proc/pid看静态状态。这一步能解决80%的定位需求。第三步如果是偶发或耗时问题开binder tracing抓systrace还原时间轴上的transaction生命周期。第四步如果问题在内存泄漏方向对比两次dump的node和ref数量缩小范围。最后结合用户态业务逻辑确认根因而不是只停留在内核层数据上。这套流程中我个人最看重的是“先看stats再抓trace”的顺序。很多人一上来就开systrace抓几分钟数据量大到没法分析。先用静态信息锁定目标和时间窗口再用动态追踪精准验证效率能提高数倍。6. 从内核日志里读到的不只是错误Binder调试还有一个容易被忽略的信息来源内核日志。dmesg里关于Binder的输出分为两类。一类是明显的错误级别日志比如binder: 1234:1234 transaction failed 29189/-22表示特定进程transaction失败并返回了错误码。另一类是正常的调试日志比如proc创建、binder线程创建、buffer分配回收等。如果内核开启了动态调试还可以通过echo file drivers/android/binder.c p /sys/kernel/debug/dynamic_debug/control打开Binder驱动的详细日志输出看到每一次transaction的具体流向。需要注意的是生产环境不建议长时间开启动态调试否则内核日志量会非常大直接把存储空间打满。我一般只会在本地测试机上开启抓完问题就立刻关闭。还有一个经验细节打开动态调试后transaction数据的大小会直接体现在日志里如果发现某个transaction大小达到几百KB那基本就离TransactionTooLargeException不远了。回到开头说的那三类根因方向内核日志里的-22EINVAL、-12ENOMEM、-28ENOSPC都很有指向性-12基本就是buffer不足-28排查node泄漏痕迹-22则需要结合业务代码看是不是传了非法参数。把错误码和静态dump数据配合起来看Binder出问题的定位就会快很多。Binder调试做到最后拼的不是知道多少命令而是能不能把“用户态现象—进程状态—内核数据—业务代码”这条链路串起来。每次排查完我都会把当时的内核节点输出和trace存一份很多问题隔几个月再遇到直接翻历史记录就能少走一大段弯路。
