简介ScreenCapture 是一份面向 Android 与 Java 开发初学者及屏幕捕获技术爱好者的开源项目源码包基于 Gradle 构建可用于研究屏幕截图、录屏与内容编辑类应用的实现思路。压缩包共 42 个文件约 143KB以 8 个 java 源码、11 个 xml 布局与配置、12 个 png 图片资源为主另含 gradle 构建脚本、gradle wrapper 相关 jar 与 properties、proguard 混淆规则及 gitignore 等工程配置文件完整呈现了一个 Android 工程的目录组织方式。其中 app 模块承载主要业务逻辑与界面资源构建脚本负责依赖管理与打包流程版本控制配置则帮助保持仓库整洁。目前已有 235 人学习浏览适合希望理解 Gradle 构建机制、Android 模块划分与屏幕捕获基础实现的读者参考借鉴也可作为二次开发的起点。1. 桌面捕获这件事为什么“能跑”和“好用”之间隔着一整套工程很多开发者第一次接触桌面捕获都是从一个不到五十行的 Demo 开始的调一个系统 API拿到一帧位图存成 PNG收工。但真把它放进录屏工具、远程协作、在线教学或者自动化测试流水线里问题立刻冒出来——帧率不稳、鼠标指针丢失、多显示器坐标错乱、高 DPI 下画面糊成一片、长时间运行内存一路涨到崩。ScreenCapture 这个资源包解决的就是从“能截一张图”到“能稳定持续捕获桌面”之间的那段工程距离。它适合三类人想给自己的工具加录屏/截图能力的应用开发者、需要做桌面行为采集或自动化验证的测试工程师、以及正在选型桌面捕获方案的技术负责人。你拿到的不只是一段调用代码而是一套把捕获、编码、输出串起来的可复现骨架。2. ScreenCapture 的捕获管线从 API 调用到帧数据落地2.1 捕获后端的选择逻辑与适用边界桌面捕获在不同系统上走的是完全不同的底层通道。Windows 上常见的有 GDI 的 BitBlt、Windows Graphics CaptureWGC和 Desktop Duplication APImacOS 上主要是 Core Graphics 的 CGDisplayStream 和 ScreenCaptureKitLinux 则依赖 X11 的 XShm 或 Wayland 下的 PipeWire。ScreenCapture 资源包一般会把这些差异封装成统一接口但封装不等于抹平选错后端照样翻车。我一般按三个维度选要不要捕获受保护内容、要不要硬件加速、目标帧率是多少。GDI 兼容性最好老系统也能跑但它是 CPU 拷贝1080p 下跑到 30fps 就开始吃满一个核而且遇到独占全屏的游戏或 DRM 窗口直接黑屏。WGC 和 Desktop Duplication 走 GPU 路径帧率高、CPU 占用低但前者对窗口最小化状态敏感后者在显卡驱动切换时会丢帧。macOS 上如果目标系统版本够新ScreenCaptureKit 是首选它把权限、音频、窗口过滤都收进了一个框架老版本只能退回 CGDisplayStream代码量大一截。提示不要一上来就追求最高帧率。先确认你的场景是“录屏存档”还是“实时预览”前者 15fps 足够后者才需要 30/60fps帧率翻倍往往意味着内存带宽和编码压力翻倍。2.2 最小可运行捕获循环的搭建下面这段 Python 示例用 mss 库演示跨平台捕获循环逻辑和 ScreenCapture 资源包里的核心循环一致初始化、抓帧、转格式、输出。选它是因为依赖少、跨平台、代码短适合先把管线跑通再替换成资源包里的高性能实现。import mss import numpy as np import time # 初始化捕获器monitors[1] 表示第一块物理显示器 with mss.mss() as sct: monitor sct.monitors[1] target_fps 30 frame_interval 1.0 / target_fps frame_count 0 start time.time() while frame_count 300: # 抓 300 帧后退出避免无限循环 loop_start time.time() # grab 返回 BGRA 原始字节不经过磁盘速度最快 raw sct.grab(monitor) # 转成 numpy 数组方便后续送编码器或做图像处理 frame np.array(raw) # 这里可以接编码、推流、存盘示例只统计帧率 frame_count 1 # 补偿处理耗时维持目标帧率 elapsed time.time() - loop_start sleep_time frame_interval - elapsed if sleep_time 0: time.sleep(sleep_time) total time.time() - start print(f实际平均帧率: {frame_count / total:.2f} fps)逻辑说明sct.monitors[1]取的是主显示器区域索引 0 是所有显示器拼起来的虚拟桌面多屏场景要特别注意这个区别。grab返回的是 BGRA 格式不是常见的 RGB送进 OpenCV 或 FFmpeg 前要转换通道顺序否则颜色会偏。帧率补偿那段是关键很多人写完循环发现帧率忽高忽低就是因为没扣掉处理耗时。参数说明target_fps决定循环节奏设太高而单帧处理超时实际帧率反而更低frame_count是安全阀生产环境要换成外部停止信号monitor的四个字段 left/top/width/height 可以手动指定用来只捕获屏幕某个区域区域越小帧率越稳。2.3 帧数据格式与编码前的处理捕获拿到的原始帧数据量很吓人1920×1080 的 BGRA 一帧就是 8.3MB30fps 下每秒 249MB 的内存带宽。所以捕获之后不能直接堆在内存里必须尽快转成压缩格式或者送进编码器。ScreenCapture 资源包通常会在这一层做三件事色彩空间转换、缩放、以及可选的指针叠加。色彩空间转换最常见的是 BGRA 转 NV12 或 YUV420因为 H.264/H.265 编码器吃的是 YUV。这个转换如果放在 CPU 上做1080p 下大概要 3 到 5 毫秒一帧用 GPU shader 做能压到 1 毫秒以内。缩放则是为了适配输出分辨率比如捕获 4K 屏幕但只推 1080p 流提前缩放比编码后缩放省带宽。指针叠加是个容易被忽略的点很多捕获 API 默认不包含鼠标指针录出来的教程视频没有光标观众根本不知道你在点哪里。资源包里一般会单独抓指针位置和图标在合成阶段叠上去。import cv2 # 假设 frame 是上一段捕获到的 BGRA numpy 数组 # 转成 BGR 供 OpenCV 使用去掉 alpha 通道 bgr cv2.cvtColor(frame, cv2.COLOR_BGRA2BGR) # 缩放到 1280x720INTER_AREA 在缩小场景下画质最好 resized cv2.resize(bgr, (1280, 720), interpolationcv2.INTER_AREA) # 送编码器前确认尺寸是偶数H.264 要求宽高均为偶数 h, w resized.shape[:2] if w % 2 ! 0 or h % 2 ! 0: resized resized[:h - h % 2, :w - w % 2] print(f输出帧尺寸: {resized.shape}, 数据类型: {resized.dtype})这段代码里COLOR_BGRA2BGR是最常用的转换如果你要做绿幕抠像才需要保留 alpha。INTER_AREA在缩小图像时比默认的INTER_LINEAR更清晰代价是稍慢。偶数尺寸那个检查看着多余但 H.264 编码器遇到奇数宽高会直接报错这个坑我踩过不止一次。3. 把捕获接进实际工具参数配置与性能调优3.1 分辨率、帧率、码率的三角平衡捕获参数不是随便填的分辨率、帧率、码率三者互相牵制。分辨率决定单帧数据量帧率决定每秒帧数码率决定编码后每秒输出多少数据。三者配不好要么画质糊要么文件巨大要么编码器跟不上丢帧。场景分辨率帧率建议码率说明文档演示/代码教学1920×1080152-4 Mbps画面变化小低帧率足够软件操作录屏1920×1080304-8 Mbps兼顾流畅与体积游戏/视频播放1920×1080608-15 Mbps高动态画面需要高码率4K 屏幕存档3840×21603015-25 Mbps分辨率高码率必须跟上这张表是起点不是终点。实际调的时候我习惯先固定分辨率和帧率然后从低码率往上加直到画面里的文字边缘不再发虚。文字发虚是码率不足最直观的信号比看数值靠谱。3.2 多显示器与高 DPI 的坐标处理多显示器和 Windows 的 DPI 缩放是桌面捕获里最容易出玄学问题的地方。假设你有两块屏主屏 2560×1440 缩放 125%副屏 1920×1080 缩放 100%虚拟桌面的坐标系会把它们拼在一起但每个显示器的物理像素和逻辑像素比例不同。如果你按逻辑坐标去抓物理像素抓出来的区域就是错的要么偏移要么尺寸不对。处理原则是捕获阶段一律用物理像素坐标UI 展示阶段再转逻辑坐标。Windows 上可以用SetProcessDpiAwareness让进程感知 DPImacOS 上 CGDisplay 系列 API 返回的本身就是物理像素。ScreenCapture 资源包里如果有跨屏捕获功能一定会处理这个转换你自己写的时候要盯住monitors数组里每个显示器的实际尺寸别用系统设置里看到的那个数字。import mss with mss.mss() as sct: # 打印所有显示器的物理坐标和尺寸 for i, mon in enumerate(sct.monitors): print(f显示器 {i}: left{mon[left]}, top{mon[top]}, fwidth{mon[width]}, height{mon[height]}) # 只捕获副屏假设索引 2 是第二块物理屏 if len(sct.monitors) 2: secondary sct.monitors[2] shot sct.grab(secondary) print(f副屏捕获尺寸: {shot.width}x{shot.height})sct.monitors[0]是所有屏幕的并集它的 left/top 可能是负数因为副屏可能摆在主屏左边或上边。这个负坐标是很多坐标计算 bug 的源头做区域捕获时一定要基于目标显示器自己的 left/top 来算偏移不要基于 0,0。3.3 长时间运行的资源管理捕获程序跑几分钟没问题跑几小时就是另一回事。内存缓慢增长是最常见的症状原因通常有三个帧缓冲区没释放、编码器内部队列积压、以及日志或统计对象无限追加。Python 里如果每帧都创建 numpy 数组而不复用GC 压力会很大表现为帧率周期性抖动。我的做法是预分配帧缓冲池捕获时写入固定缓冲区而不是每帧新建对象。编码器那边要设一个最大队列长度队列满了就丢最旧的帧宁可丢帧也不要让延迟无限累积。资源包里如果有buffer_pool或frame_queue之类的配置项优先调这两个。注意丢帧策略要跟业务匹配。录屏存档可以丢帧保连续但自动化测试的每一帧都可能对应一个断言丢帧等于丢证据这种场景要改成阻塞等待而不是丢弃。4. 避坑与排查那些让捕获程序翻车的细节4.1 抓出来全黑或只有窗口边框现象捕获受保护内容、独占全屏应用或某些播放器时抓到的帧是全黑或者只有标题栏。原因这些窗口走了硬件覆盖层或 DRM 保护路径GDI 的 BitBlt 读不到覆盖层内容。解决换用 Desktop Duplication 或 WGC 后端它们能拿到合成后的画面如果目标内容有 DRM任何常规捕获都拿不到这是系统设计如此不要在这上面浪费时间。4.2 帧率标称 30 实际只有十几现象配置里写 30fps实际统计出来只有 12 到 18。原因单帧处理链路太长捕获、转换、编码串行执行每一环都在等上一环。解决把捕获和编码拆到不同线程用队列解耦或者降低分辨率、关掉不必要的后处理。先测单帧各阶段耗时找到瓶颈再优化别盲目换库。4.3 高 DPI 下捕获区域偏移现象在缩放 125% 或 150% 的屏幕上指定区域捕获总是偏一点或者尺寸对不上。原因逻辑坐标和物理像素混用。解决统一用物理像素坐标捕获前打印实际显示器参数核对Windows 上给进程设置 DPI 感知避免系统帮你做隐式缩放。4.4 长时间运行后内存持续上涨现象跑一小时后内存从 200MB 涨到 2GB 以上。原因帧对象未复用、编码器队列无上限、或者异常路径下资源没释放。解决预分配缓冲池、给队列设上限、用 try/finally 确保释放用内存分析工具抓增长点通常集中在每帧新建的对象上。4.5 多屏环境下捕获到错误的屏幕现象想抓副屏却抓到了主屏或者抓到的区域横跨两块屏。原因显示器索引和系统显示设置里的编号不一致虚拟桌面坐标计算错误。解决遍历monitors数组打印每块屏的实际参数用参数匹配而不是硬编码索引区域捕获时基于目标屏的 left/top 计算偏移。5. 进阶技巧用捕获帧做自动化验证与画质校验捕获管线跑通之后一个很实用的进阶方向是拿帧数据做自动化验证。比如 UI 回归测试里定时抓取目标窗口区域跟基准图做像素级或结构相似度对比就能自动发现界面异常。这里的关键不是捕获本身而是怎么判断“两帧是否足够相似”。我一般用 SSIM结构相似度而不是逐像素比对因为逐像素对光标闪烁、抗锯齿差异太敏感误报率高。SSIM 在 0.95 以上基本可以认为一致低于 0.9 就要人工确认。下面这段代码演示了从捕获到比对的完整链路。import cv2 import numpy as np from skimage.metrics import structural_similarity as ssim def capture_region(region): 捕获指定区域并返回 BGR 图像 import mss with mss.mss() as sct: raw sct.grab(region) frame np.array(raw) return cv2.cvtColor(frame, cv2.COLOR_BGRA2BGR) def compare_frames(baseline, current, threshold0.95): 用 SSIM 比对两帧返回是否通过及相似度 # 统一尺寸避免分辨率差异导致比对失败 if baseline.shape ! current.shape: current cv2.resize(current, (baseline.shape[1], baseline.shape[0])) # 转灰度SSIM 在单通道上计算更快也更稳定 gray_a cv2.cvtColor(baseline, cv2.COLOR_BGR2GRAY) gray_b cv2.cvtColor(current, cv2.COLOR_BGR2GRAY) score, diff ssim(gray_a, gray_b, fullTrue) passed score threshold return passed, score, diff # 使用示例先存一张基准图后续每次捕获都跟它比 region {left: 100, top: 100, width: 800, height: 600} baseline capture_region(region) cv2.imwrite(baseline.png, baseline) current capture_region(region) passed, score, diff compare_frames(baseline, current) print(f相似度: {score:.4f}, 是否通过: {passed}) # diff 是差异图可以存下来定位具体变化区域 if not passed: diff_vis (diff * 255).astype(np.uint8) cv2.imwrite(diff.png, diff_vis)逻辑说明capture_region把捕获封装成函数传入区域字典返回标准 BGR 图像。compare_frames先统一尺寸再转灰度SSIM 对亮度变化比结构变化更敏感灰度化能减少颜色波动带来的干扰。fullTrue让 SSIM 同时返回差异图差异图在排查“到底哪里变了”时非常有用。参数说明threshold是判定阈值0.95 适合界面稳定的场景如果界面有动画或视频要降到 0.85 甚至更低或者只比对静态区域。region的坐标要用物理像素跟前面捕获部分的规则一致。这套方法我用了很久最大的体会是基准图要定期更新否则界面正常改版也会触发告警时间一长就没人看告警了。从那以后我每次改完界面都强制走一遍基准图更新流程把误报压到最低。希望帮到你。本文还有配套的精品资源点击获取