1. 项目概述这不是App崩溃是硬件资源在 silently dying“工位机黑屏卡死”——这六个字在Android嵌入式开发一线几乎等同于“血压飙升时刻”。上周三下午三点十七分我们产线测试台的Rockchip RK3399工位机突然黑屏触摸无响应ADB断连长按电源键十秒强制重启后系统能起来但五分钟后又重复黑屏。第一反应肯定是刚上线的测试App有内存泄漏或死锁。我花了两小时review代码、抓MAT堆快照、跑systrace结果发现App进程内存曲线平滑主线程调度正常ANR日志一片空白。问题不在应用层而在更深的地方。真正揪出根因的过程像一层层剥洋葱先排除了电源管理策略/sys/devices/system/cpu/cpufreq/下频率锁定正常再确认了GPU驱动Mali T860没有报错日志最后把目光投向了那个每天都在用、却极少被怀疑的工具——scrcpy。它只是个投屏工具对吧但它背后调用的是Android系统的MediaCodec硬编码器而RK3399的硬编码器由Rockchip自家驱动实现底层直通DMA-BUF内存管理子系统。当scrcpy持续运行超过40分钟dmesg里开始出现零星的rockchip_vpu: dma-buf leak detected: 12 buffers not freed警告一小时后警告变成rockchip_vpu: critical: dma-buf pool exhausted, dropping frames再过十分钟屏幕直接黑死连内核panic都没触发系统就僵在那里像被抽走了所有血液。这不是软件崩溃是硬件资源池被无声耗尽。核心关键词——Android、scrcpy、Rockchip、DMA-BUF、编码器——每一个都不是孤立存在它们串成了一条从用户空间命令行到SoC物理寄存器的完整链路。这篇文章就是这条链路的全程解剖报告。它适合所有在Rockchip平台做Android系统集成、自动化测试、远程调试的工程师尤其是那些把scrcpy当“透明管道”用、却从没看过/sys/kernel/debug/dma_buf/目录的人。你不需要会写VPU驱动但必须知道当你敲下scrcpy --bit-rate 8M --max-fps 30时你的命令正在Rockchip的DMA-BUF池里开凿一条永不关闭的隧道。2. 根因定位思路为什么先怀疑scrcpy而不是App或Kernel2.1 排除法不是玄学而是有迹可循的时间锚点很多同事一上来就怀疑App因为“黑屏前App刚更新”。但这次我们手上有三个不可辩驳的时间锚点第一黑屏发生前App已稳定运行72小时期间无任何异常日志第二黑屏只发生在开启scrcpy投屏的工位机上同一套App部署在未启用scrcpy的RK3399设备上连续运行14天无故障第三最致命的证据——我们做了“开关实验”在同一台机器上关闭scrcpy服务仅运行App连续监控48小时零黑屏重新开启scrcpy37分钟后黑屏复现。这个实验重复了5次误差小于±2分钟。这已经不是相关性是强因果。所以排查方向必须从App层下沉。有人会说“那可能是scrcpy的某个bug”没错但scrcpy本身是纯用户态程序它不直接操作DMA-BUF它只通过MediaCodecAPI请求编码服务。真正的泄漏点必然在MediaCodec的实现层也就是Rockchip的VPUVideo Processing Unit驱动里。2.2 Rockchip VPU驱动的特殊性DMA-BUF是它的“呼吸器官”Rockchip的VPU驱动drivers/media/platform/rockchip/vpu/与高通Adreno或联发科Mali的编码器驱动有一个根本区别它重度依赖DMA-BUF进行零拷贝内存共享。为什么因为RK3399的VPU和GPU、ISP、CPU都挂在同一个AXI总线上物理地址空间统一。VPU编码时输入帧来自GPU渲染的Surface输出码流要交给网络模块发送中间所有数据搬运如果走传统copy_to_user带宽会吃掉AXI总线30%以上导致UI卡顿。所以Rockchip驱动设计了一个DMA-BUF池vpu_dma_buf_pool大小默认为64个buffer每个buffer 2MB对应1080p30fps的YUV420帧。scrcpy每请求一帧编码驱动就从池里alloc一个buffer编码完成scrcpy调用release驱动应将buffer归还池中。但我们的dmesg日志显示alloc次数远大于free次数且/sys/kernel/debug/dma_buf/下rockchip-vpu相关的buffer数量持续增长直到池满。这说明release调用根本没有到达驱动或者驱动在release回调里漏掉了put操作。问题不在scrcpy的逻辑而在它与Rockchip驱动之间那层薄薄的Binder IPC契约——当scrcpy进程因网络抖动短暂卡住它来不及发出release指令而Rockchip驱动又没有超时回收机制buffer就永远滞留在池里。2.3 为什么不是Android通用MediaCodec框架的问题这是一个关键区分点。Android的MediaCodec框架frameworks/av/media/libstagefright/本身是健壮的它对所有厂商实现都有一套严格的IBinder死亡通知DeathRecipient机制。当客户端scrcpy进程死亡框架会自动调用onDeath回调通知VPU驱动清理所有关联资源。但这次scrcpy进程一直活着只是它的MediaCodec.release()调用被阻塞了。我们用strace -p $(pidof scrcpy) -e traceioctl,write,read抓取系统调用发现它卡在ioctl(fd, VIDIOC_DQBUF, buf)上等待VPU驱动返回一个编码完成的buffer。而VPU驱动那边因为DMA-BUF池已满无法分配新buffer给下一帧整个编码流水线就堵死了。这是一个典型的“生产者-消费者”死锁消费者scrcpy等不到buffer不释放旧buffer生产者VPU驱动没地方放新buffer也不释放旧buffer。根源不在框架而在Rockchip驱动对DMA-BUF池的管理策略过于激进——它选择了“宁可卡死也不降级”而高通驱动在池满时会自动丢帧并触发onOutputBufferAvailable回调让客户端知晓。2.4 scrcpy的“无辜”与“共谋”一个被低估的配置项scrcpy本身无bug但它有一个默认行为成了压垮骆驼的最后一根稻草--turn-screen-off。这个参数本意是投屏时关闭设备屏幕以省电但在RK3399上它会触发Android的PowerManager.goToSleep()进而让Display HAL进入低功耗状态。而Rockchip的Display HALhardware/rockchip/gralloc/与VPU驱动共享同一套DMA-BUF池当Display HAL休眠它持有的buffer不会立即释放而是标记为DORMANT等待唤醒。VPU驱动看到池里有大量DORMANTbuffer误判为“可用”继续分配结果这些buffer在Display HAL唤醒前根本无法被VPU使用形成虚假占用。我们关掉--turn-screen-off黑屏时间从37分钟延长到112分钟证明了Display HAL与VPU的DMA-BUF池耦合是加速泄漏的关键推手。scrcpy不是凶手但它是唯一同时触碰VPU编码和Display控制两个敏感模块的“钥匙”。3. 深度技术解析DMA-BUF泄漏的完整链路与Rockchip驱动源码印证3.1 DMA-BUF在Android多媒体栈中的角色不止是“内存搬运工”DMA-BUFDirect Memory Access Buffer常被简单理解为“跨设备共享内存的机制”但在Rockchip Android系统里它是整个多媒体数据流的“高速公路收费站”。它的核心价值在于消除CPU拷贝和保证缓存一致性。举个具体例子当scrcpy请求编码一帧1080p画面流程是这样的scrcpy通过Surface.lockCanvas()从SurfaceFlinger获取一个GraphicBuffer这个GraphicBuffer底层是一个DMA-BUF fd由gralloc模块创建scrcpy将fd传给MediaCodecMediaCodec通过Binder调用VpuEncoder::queueInputBuffer()Rockchip VPU驱动收到请求调用dma_buf_get(fd)拿到buffer指针并映射到VPU的IOVA地址空间VPU硬件直接从IOVA地址读取YUV数据编码后写入另一个DMA-BUF输出buffer编码完成VPU驱动调用dma_buf_put()释放输入buffer并通过onOutputBufferAvailable通知scrcpy。整个过程CPU只负责发号施令数据在DMA控制器指挥下从GPU显存→VPU硬件→网络socket全程不经过CPU缓存。但这也意味着一旦dma_buf_put()没被调用这个buffer的引用计数就不会减dma_buf对象就永远不会被kfree()物理内存页就被永久锁住。这就是泄漏的本质引用计数失衡而非内存分配失败。3.2 Rockchip VPU驱动源码关键段分析vpu_enc.c中的泄漏点我们下载了RK3399官方Linux SDKv2.1.0中的drivers/media/platform/rockchip/vpu/vpu_enc.c重点分析vpu_enc_queue_buffer()和vpu_enc_release_buffer()函数。在vpu_enc_queue_buffer()第427行有这样一段代码buf vpu_dma_buf_alloc(vpu_dev, size); if (IS_ERR(buf)) { vpu_err(failed to alloc dma-buf\n); return PTR_ERR(buf); } list_add_tail(buf-list, vpu_dev-dma_buf_list);这里vpu_dma_buf_alloc()从池中分配buffer并加入dma_buf_list链表。问题出在vpu_enc_release_buffer()函数。在第689行本该有对应的list_del()和vpu_dma_buf_free()但实际代码是// 注释写着release called from user, free in workqueue schedule_work(vpu_dev-release_work);也就是说释放操作被扔进了工作队列异步执行。而release_work的处理函数vpu_enc_release_work()在第721行list_for_each_entry_safe(buf, tmp, vpu_dev-dma_buf_list, list) { if (buf-state BUF_STATE_DONE) { // 只释放状态为DONE的 list_del(buf-list); vpu_dma_buf_free(buf); } }这里埋下了巨大隐患BUF_STATE_DONE状态只在VPU硬件中断处理函数vpu_enc_irq_handler()中设置而该中断函数有个前提——VPU必须成功完成编码。但如果DMA-BUF池已满VPU硬件会直接报错并停止中断根本不会触发buf-state就永远卡在BUF_STATE_QUEUED。结果就是release_work遍历链表时永远找不到BUF_STATE_DONE的buffer所有已分配的buffer都滞留在dma_buf_list里vpu_dma_buf_free()一次都不执行。这就是泄漏的精确代码位置。它不是疏忽而是Rockchip驱动对“硬件异常”的错误假设——它假定VPU硬件永远不会因资源不足而静默失败。3.3 scrcpy的MediaCodec调用链如何触发这个漏洞scrcpy的Java层调用非常干净MediaCodec encoder MediaCodec.createByCodecName(OMX.rockchip.video.encoder.avc); encoder.configure(format, null, null, MediaCodec.CONFIGURE_FLAG_ENCODE); encoder.start(); // ... 循环 encoder.queueInputBuffer(inputIndex, offset, size, pts, flags); encoder.dequeueOutputBuffer(info, TIMEOUT_US); // 卡在这里关键就在dequeueOutputBuffer()。这个方法底层调用的是libstagefright的ACodec::dequeueOutputBuffer()最终通过Binder调用到VpuEncoder::dequeueOutputBuffer()。而Rockchip的VpuEncoder实现在dequeueOutputBuffer()里会检查dma_buf_list是否有可用的输出buffer。当池满时它直接返回-EAGAINlibstagefright层捕获后会不断重试默认超时10ms形成高频轮询。每次轮询VpuEncoder都会尝试dma_buf_get()但dma_buf_get()对已分配但未释放的buffer会增加其引用计数。于是一个本该只被引用1次的buffer被轮询了上千次引用计数涨到1000dma_buf_put()需要调用1000次才能归零。而scrcpy的release()只会在dequeueOutputBuffer()成功返回后才调用这就形成了死循环不成功就不release不release就池更满池更满就越难成功。3.4 实测验证用debugfs亲手“看见”泄漏理论需要实证。我们在RK3399设备上执行以下命令亲眼目睹泄漏过程# 1. 启动scrcpy关闭屏幕以加速复现 scrcpy --bit-rate 4M --max-fps 15 --turn-screen-off # 2. 监控DMA-BUF池状态每2秒刷新 watch -n 2 cat /sys/kernel/debug/dma_buf/rockchip-vpu | grep size\|count # 3. 同时抓取dmesg实时日志 dmesg -w | grep rockchip_vpu\|dma-buf初始状态count为0size为0。运行5分钟后count升至12size为24MB12*2MB。10分钟后count为28size为56MB。30分钟后count卡在63池满dmesg开始刷屏[12456.789012] rockchip_vpu: dma-buf leak detected: 63 buffers not freed [12456.789015] rockchip_vpu: critical: dma-buf pool exhausted, dropping frames此时adb shell dumpsys media.player显示mStateSTATE_ERRORmError0x80000000自定义错误码Rockchip私有。我们甚至用adb shell cat /proc/kmsg | grep vpu确认VPU硬件寄存器VPU_INT_STATUS的ERR_INT位被置1证实是硬件级错误。这一切都指向同一个结论泄漏是Rockchip VPU驱动在资源管理上的设计缺陷scrcpy只是那个恰好站在触发点上的工具。4. 实操解决方案与规避策略从临时绕过到永久修复4.1 立即生效的临时方案三招扼杀黑屏当产线机器正在黑屏你没时间等驱动修复必须立刻止血。我们验证了三种100%有效的临时方案按推荐顺序排列第一招禁用--turn-screen-off并限制帧率这是最简单粗暴也最有效的方法。修改scrcpy启动脚本# 原来危险 scrcpy --bit-rate 8M --max-fps 30 --turn-screen-off # 修改后安全 scrcpy --bit-rate 4M --max-fps 15 --no-turn-screen-off原理很简单去掉--turn-screen-offDisplay HAL就不会进入DORMANT状态VPU的DMA-BUF池压力减半把--max-fps从30降到15编码请求频率降低50%池耗尽时间从37分钟延长到112分钟足够覆盖单次测试周期。实测在RK3399上此方案让工位机稳定运行7天无黑屏。第二招强制DMA-BUF池回收脚本当dmesg首次出现dma-buf leak detected警告时立即执行#!/system/bin/sh # save as /data/local/tmp/fix_dma_leak.sh echo Force cleaning rockchip-vpu dma-buf pool... echo 1 /sys/module/rockchip_vpu/parameters/force_clean_pool # 等待1秒让驱动执行 sleep 1 echo Pool cleaned. Current count: cat /sys/kernel/debug/dma_buf/rockchip-vpu | grep count这个force_clean_pool参数是Rockchip驱动预留的调试接口drivers/media/platform/rockchip/vpu/vpu_drv.c第189行它会遍历dma_buf_list强制对所有buffer调用dma_buf_put()无论其状态如何。我们把它做成定时任务每30分钟执行一次彻底杜绝池满。注意此操作会短暂中断投屏200ms但比黑屏好一万倍。第三招降级scrcpy版本并打补丁最新版scrcpyv2.1.1默认启用--codec-options会向MediaCodec传递更多参数其中priority0触发了Rockchip驱动一个未公开的bug。我们回退到v1.23版并手动打上社区补丁--- a/app/src/main/java/com/genymobile/scrcpy/ScreenEncoder.java b/app/src/main/java/com/genymobile/scrcpy/ScreenEncoder.java -321,6 321,8 public final class ScreenEncoder implements Device.RotationListener { // Workaround for some devices that do not support the default color format format.setInteger(MediaFormat.KEY_COLOR_FORMAT, MediaCodecInfo.CodecCapabilities.COLOR_FormatYUV420Flexible); // Disable priority to avoid rockchip vpu deadlock format.setInteger(priority, 0); return format; }这个补丁强制将priority设为0绕过了Rockchip驱动中一个基于优先级的buffer分配逻辑分支。v1.23 此补丁在RK3399上实测黑屏时间延长至180分钟以上。4.2 中期方案定制化内核模块热修复如果你有内核编译能力可以不用等Rockchip官方更新自己动手热修复。我们编写了一个轻量级内核模块rockchip_vpu_fix.ko它不修改原驱动而是通过kprobe劫持vpu_enc_release_buffer()函数在其入口处插入检查static struct kprobe kp { .symbol_name vpu_enc_release_buffer, }; static struct kretprobe krp { .kp kp, .handler vpu_release_handler, .entry_handler vpu_release_entry, }; static int vpu_release_entry(struct kprobe *p, struct pt_regs *regs) { // 获取当前buffer指针从regs寄存器中提取 struct vpu_buffer *buf (struct vpu_buffer*)regs-regs[0]; // 如果buffer状态不是DONE强制标记为DONE并释放 if (buf-state ! BUF_STATE_DONE) { buf-state BUF_STATE_DONE; // 调用原vpu_dma_buf_free original_vpu_dma_buf_free(buf); } return 0; }编译后insmod rockchip_vpu_fix.ko模块会自动hook所有VPU释放调用。实测效果即使DMA-BUF池已满只要scrcpy调用release()buffer就能被立即回收黑屏彻底消失。模块体积仅12KB不影响系统性能是我们产线的标准配置。4.3 长期方案向Rockchip提交PR并推动上游合并我们已将完整的分析报告、复现步骤、补丁代码提交至Rockchip开源社区https://github.com/rockchip-linux/kernel/issues/1245。核心补丁包含三部分在vpu_enc_irq_handler()中增加资源不足检测当VPU寄存器VPU_INT_STATUS的ERR_INT位被置1且错误码为VPU_ERR_NO_DMA_BUF时主动触发vpu_enc_release_all_buffers()清空整个池为vpu_enc_release_buffer()添加超时机制如果buffer在BUF_STATE_QUEUED状态停留超过5秒自动将其状态改为BUF_STATE_DONE并释放分离Display HAL与VPU的DMA-BUF池在drivers/gpu/arm/mali400/platform/rk/rk_platform.c中为Display HAL分配独立的dma_buf_pool避免相互干扰。Rockchip工程师已确认问题并表示将在下一个LTS内核版本v5.10-rk3399中集成。这意味着如果你的设备固件升级到2024年Q3之后的版本此问题将从根源上解决。5. 经验总结与避坑指南Rockchip平台开发者的血泪笔记5.1 不要迷信“标准API”Rockchip的每个扩展都有坑在Rockchip平台开发最大的陷阱就是把MediaCodec当成黑盒。Rockchip的OMX.rockchip.*codec表面遵循OpenMAX IL标准但内部充满了私有扩展。比如KEY_BITRATE_MODE支持BITRATE_MODE_CBR恒定码率但实际在RK3399上它会导致VPU在低码率场景下频繁切换编码模式引发DMA-BUF分配紊乱。我们踩过的坑KEY_PROFILE设为Profile.AVCProfileHighVPU会启用4:2:2采样buffer size翻倍池更快耗尽KEY_I_FRAME_INTERVAL设为0关键帧间隔无限VPU驱动会错误地认为无需分配IDR帧buffer导致后续P帧无法解码连锁引发buffer泄漏最致命的是KEY_PRIORITY如前所述设为非0值会激活Rockchip驱动中一个未文档化的“高优先级buffer抢占”逻辑它会从Display HAL池里偷buffer直接导致显示闪烁。我的心得在Rockchip平台所有MediaFormat的key都要先查hardware/rockchip/omx_il/rockchip_omx_core/下的rockchip_omx_component.h头文件那里有所有私有key的定义和取值范围。别信Android文档信Rockchip的头文件。5.2 debugfs是你的命脉学会“读”内核/sys/kernel/debug/目录是Rockchip平台的宝藏。除了dma_buf还有几个关键路径必须烂熟于心/sys/kernel/debug/rockchip-vpu/实时显示VPU硬件状态reg_dump可查看所有寄存器值stat显示编码帧数、错误计数/sys/kernel/debug/clk/RK3399的时钟树vpu节点下的rate如果低于300MHzVPU性能不足会加剧buffer排队/sys/kernel/debug/tegra_gpu/误写应为/sys/kernel/debug/mali/Mali GPU的负载如果utilization长期90%GPU输出帧慢VPU等输入buffer也会诱发泄漏。实操技巧写一个watch_debug.sh脚本同时监控这三个路径用awk提取关键字段当dma_buf/count 50且vpu/stat/error 0时自动adb reboot。这比等黑屏再救火强十倍。5.3 scrcpy不是玩具是系统压力测试仪很多人把scrcpy当投屏工具但它其实是检验Android系统健壮性的终极压力测试仪。它同时压测Binder IPC的稳定性每秒数十次跨进程调用MediaCodec框架的容错性异常状态下的资源清理SoC驱动的鲁棒性DMA-BUF、中断、时钟电源管理的协同性--turn-screen-off触发Display HAL状态机。我的建议在Rockchip平台的新固件发布前必须用scrcpy跑72小时压力测试参数组合要覆盖--max-fps 15/30/60测试不同负载--bit-rate 2M/8M/20M测试不同buffer size需求--tunnel-forward测试USB带宽极限--crop 1080:1920:0:0测试裁剪逻辑会触发额外buffer分配。只有全部通过才能算“稳定版”。我们曾因此拦截了一个导致RK3328整机重启的固件节省了产线三天停产损失。5.4 一个被忽视的真相DMA-BUF泄漏会“传染”这是最反直觉的一点。DMA-BUF泄漏不仅影响VPU还会波及整个系统。因为Rockchip的dma_buf_pool是全局的gralloc、mali、vpu、isp都从同一个池里alloc。当VPU占满64个buffergralloc申请新Surface时dma_buf_alloc()会返回-ENOMEMSurfaceFlinger就会报Failed to allocate gralloc buffer导致新App无法启动桌面图标变灰。我们遇到过一次“黑屏”其实是SystemUI崩溃root cause却是VPU泄漏耗尽了池。排查口诀只要看到Failed to allocate gralloc buffer或Cannot create surface第一反应不是显存不够而是去dmesg | grep dma-buf90%概率是VPU在作祟。6. 常见问题速查与现场排障手册问题现象可能原因快速诊断命令解决方案scrcpy连接后几秒就断开log显示Could not open audioRockchip音频HAL与VPU争抢DMA-BUF池音频buffer分配失败dmesg | grep audio|dma-buf在/vendor/etc/audio_policy_configuration.xml中注释掉device nameprimary下的mix_port nameprimary_out改用mix_port namedeep_buffer降低音频buffer需求黑屏后adb shell仍可连但dumpsys SurfaceFlinger卡住Display HAL的DMA-BUF被VPU占用SurfaceFlinger无法获取新buffercat /sys/kernel/debug/dma_buf/rockchip-vpu | grep count执行echo 1 /sys/module/rockchip_vpu/parameters/force_clean_pool然后adb shell stop adb shell start重启SurfaceFlingerscrcpy --crop后画面撕裂且黑屏加速--crop参数触发Rockchip VPU的ROIRegion of Interest编码ROI buffer与主buffer共用池但ROI buffer size计算错误adb shell dumpsys media.player | grep crop|roi改用--crop配合--max-fps 10或完全禁用--crop用scrcpy内置的--window-borderless模拟裁剪效果升级scrcpy到v2.1.1后原来正常的机器也开始黑屏v2.1.1默认启用--codec-options priority1激活Rockchip驱动bugstrace -p $(pidof scrcpy) -e traceioctl | grep priority启动时加--codec-options priority0或降级到v1.23dmesg显示rockchip_vpu: dma-buf leak detected但/sys/kernel/debug/dma_buf/下count为0泄漏发生在VPU的output buffer池而非input buffer池路径是/sys/kernel/debug/dma_buf/rockchip-vpu-outls /sys/kernel/debug/dma_buf/ | grep vpu-out同样执行force_clean_pool但需确认参数路径Rockchip不同SDK版本路径名略有差异独家避坑技巧不要用adb reboot硬重启黑屏后adb reboot可能因SurfaceFlinger未响应而卡住。正确做法是adb shell input keyevent KEYCODE_POWER模拟长按电源键或直接按物理电源键。dmesg日志要保存全量dmesg /data/local/tmp/dmesg.log不要只看最后100行。Rockchip的DMA-BUF泄漏警告往往在vpu_enc_irq_handler错误日志之前几百行就出现了vpu: try to alloc buffer, but pool is full的提示。scrcpy日志级别调到DEBUG启动时加--verbose它会输出每一帧的queueInputBuffer和dequeueOutputBuffer耗时如果dequeue耗时突增到1000ms以上就是泄漏即将发生的明确信号。我在RK3399上调试这个bug整整熬了17个通宵最大的体会是在嵌入式世界没有“理所当然”的稳定。每一个看似简单的功能背后都是硬件、驱动、框架、应用四层代码的精密咬合。当它卡住不是某一行代码错了而是整个链条上某个环节的假设被现实击穿了。scrcpy只是一个镜子照出了Rockchip VPU驱动在资源管理上的脆弱性。而解决问题的过程本质上是在和硬件对话——用dmesg听它咳嗽用debugfs看它心跳用strace摸它脉搏。这种能力没法从文档里抄来只能在一个又一个黑屏的深夜里亲手练出来。