我当初折腾Python屏幕共享工具的时候，刚好踩过和你一模一样的坑——PIL的ImageGrab截图延迟拉胯、直接发大量图片导致传输卡成狗，给你分享几个亲测有效的优化思路，帮你搞定24FPS的目标：

一、先搞定截图帧率：换掉ImageGrab！ #

PIL的ImageGrab在Windows上的性能真的很一般，想要达标帧率，优先换用专门做快速屏幕捕获的mss库，它针对不同系统做了底层优化，帧率轻松能冲到30+，完全能满足你的需求。给你个简单的示例：

import mss
from PIL import Image

with mss.mss() as sct:
    # 捕获主显示器（如果有多屏，调整monitors的索引）
    target_monitor = sct.monitors[1]
    # 一秒钟能抓个三四十次完全没问题
    screenshot = sct.grab(target_monitor)
    # 转换成PIL Image方便后续处理（如果需要的话）
    img = Image.frombytes("RGB", screenshot.size, screenshot.bgra, "raw", "BGRX")

另外，如果不需要全屏共享，只捕获指定区域也能大幅降低截图耗时，比如设置target_monitor={"top": 100, "left": 100, "width": 800, "height": 600}，只抓你需要的部分。

二、传输方案优化：绝对不能直接发原始图片！ #

直接发送大量原始截图（比如未压缩的PNG或者RGB数据）的方案完全不合理，带宽占用会高到离谱，延迟根本无法接受。推荐这几个优化方向：

• 差分传输：只发送和上一帧相比变化的区域。比如对比当前帧和上一帧的像素，找出差异的矩形块，只传输这些块的像素数据和位置信息，客户端收到后把这些块覆盖到上一帧画面上，能省掉80%以上的传输量。
• 图片压缩：用高压缩比的格式处理截图，比如JPEG（可以调整质量参数，比如img.save(buffer, format='JPEG', quality=80)，画质损失不大但体积能缩到原来的1/10）或者WebP（压缩效率比JPEG还高），把图片转成字节流再发送。
• 视频编码传输：把连续的截图序列编码成H.264这类视频流，用ffmpeg-python或者OpenCV就能实现，视频编码的压缩效率是最高的，实时性和画质的平衡做得最好，适合长时间的屏幕共享。
• 选对传输协议：如果追求极致实时性，用UDP协议（允许少量丢包，屏幕共享对丢包的容忍度很高）；如果需要绝对可靠的传输，TCP可以配合分块发送，但要注意设置合适的缓冲区大小，避免阻塞导致延迟。

三、客户端显示的小优化 #

pygame的blit本身不算慢，但如果每次都重复做格式转换，也会拖慢帧率：

• 提前转换Surface：把收到的图片字节流直接转换成pygame的Surface对象，避免重复转换操作：

import pygame
from io import BytesIO
from PIL import Image

# 假设从服务器收到的图片字节是img_bytes
img_buffer = BytesIO(img_bytes)
pil_img = Image.open(img_buffer)
# 直接转成pygame可用的Surface
pygame_surface = pygame.image.fromstring(pil_img.tobytes(), pil_img.size, pil_img.mode)
# 然后blit到屏幕
screen.blit(pygame_surface, (0, 0))

• 开启硬件加速：初始化pygame显示窗口时加上硬件加速和双缓冲参数，能大幅提升blit的速度：

screen = pygame.display.set_mode((width, height), pygame.HWSURFACE | pygame.DOUBLEBUF)

最后总结下方案合理性 #

直接发送大量原始图片的方案完全不可行，根本满足不了24FPS的实时要求。但只要你按照「高效截图（mss）+ 压缩/差分/视频编码传输 + 客户端显示优化」的思路来做，达到24FPS甚至更高帧率是完全没问题的，而且传输带宽也能控制在合理范围内。

内容的提问来源于stack exchange，提问作者0Interest