1. 先想清楚要做成什么样再动手写第一行 Python很多人搜“Python 代码雨”心里想的其实是电影里那种绿色字符往下淌的画面。但真正动手时第一行代码就开始纠结用什么画要不要装库为什么我写出来的效果像一堆静止的乱码在闪。这篇就把我用 Python 复刻这套视觉效果的全过程拆开讲从方案选型、数据结构、渲染顺序一直到最后调参末端给两份可以直接跑起来的完整代码——一份 pygame 版一份纯标准库 tkinter 版。你手里电脑上大概已经装好了 Python看完挑一份复制就能看到东西动起来。先说清楚这件事的边界。所谓“代码雨”本质不是文字动画而是一列一列竖直排列的字符各自以不同速度下落每列带一条由亮到暗的拖尾字符内容还会随机变化。它不涉及任何算法难点难点全在“怎么把这几百上千个字符按正确的位置、正确的亮度、正确的时机画到屏幕上还能稳住 60 帧”。这就决定了工具选型的优先级——渲染方式的批量绘制能力远比库的知名度重要。我见过不少人第一版是拿print加time.sleep在终端里刷屏跑起来整屏往下滚观感完全不对。原因很简单终端的换行是“推上去”不是“画上去”你没法把某一格的字符单独改成暗色。想做出拖尾和渐变必须有一个能按坐标画字的画布。搞明白这一层需求后面的选择就顺理成章了。适合谁看会写 Python 基础语法、知道函数和类是什么就够不需要任何图形学背景。如果你只是想找段代码复制跑一下第 3 节的完整代码直接拿走如果你想弄明白每一行参数为什么这么设、屏幕卡顿怎么救、换台机器为什么字全挤在一起那从头看更省事。2. 方案选型三种实现路线的取舍2.1 pygame、tkinter、终端库的横向对比摆在我面前的有三条路我当时都试了一遍下面是实测下来的对比供你按自己的场景挑方案依赖单帧绘制能力帧率上限1080p约 2000 字符上手成本适合场景pygame需pip install pygame强Surface 批量 blit60 帧稳定CPU 约 10%~20%低演示、录屏、桌面玩具tkinter标准库自带弱每个字符是一个 Canvas item25~30 帧CPU 约 30%~50%中不能装第三方库的环境curses / 终端标准库自带极弱只能按字符格刷依赖终端观感差低服务器里自娱自乐我最后选 pygame 做主方案理由不是“它最强”而是它把离屏绘制这件事做得最省心。pygame 里一个Surface就是一块像素缓冲你可以先把一个字符渲染成一张小图缓存起来之后每帧只是把这张小图往画布上贴贴一千次也就几毫秒。tkinter 的 Canvas 每次delete(all)再重建几千个 item开销就上去了还得手动管理 canvas id一旦泄漏就是内存缓慢上涨。至于终端方案我建议只在最极端的环境下用——比如你只能 SSH 到一台什么都不让装的机器上。真要在终端里做也得靠 curses 的addstr指定行列能做出个粗糙的雏形但没有颜色渐变视觉效果差得远。2.2 把“炫酷”这个模糊的词拆成可实现的图层“炫酷”是个没法直接编码的词。我的做法是把它拆成四个可以量化的图层每一层单独实现、单独调参第一层是网格。屏幕上字符不是随便放的而是严格对齐到一个单元格矩阵里列宽等于字符宽度行高等于字体的行高。这一层决定了画面的“秩序感”一旦网格不整齐看起来就像故障而不是效果。第二层是下落。每一列有一个虚拟的“头部位置”按各自的速度往下推进。速度必须逐列随机如果所有列同速画面会变成整体平移的横条瞬间失去灵魂。第三层是拖尾。头部后面的若干个格子颜色从亮绿逐渐过渡到接近背景的深绿。这一层是“像雨”的关键没有渐变就只是一排排跳动的字。第四层是字符刷新。每个格子里的字符会以一定概率被换成新的随机字符模拟“数字在流动”的感觉。刷新太快是雪花屏太慢是静态文字墙。把这四层分开想之后代码结构自然就出来了一个二维字符数组管内容一个列对象数组管位置和速度一个渲染函数负责按“距离头部的格数”算亮度。剩下的全是调参数。2.3 为什么不用“画完再整体淡化”的经典写法网上流传最广的写法是另一种思路每帧在整块画布上盖一层半透明黑让上一帧的内容自然变暗然后再画新的字符。代码极短十几行就能跑我第一次也是这么写的。但它有两个绕不过去的毛病。一是颜色会脏。绿色被黑色按 alpha 混合多次之后拖尾会往灰绿、土黄的方向偏尤其在纯黑背景上末端会出现一层说不清的杂色。二是拖尾长度不可控。淡化速度由那层黑色的 alpha 决定你想让某一列尾巴长一点、某一列短一点根本做不到所有列只能共用同一个衰减率。我最终换成了“按深度算亮度”的方案。虽然多写了几十行但换来的是拖尾长度逐列可调、颜色渐变可以精确指定起止色、头部能单独高亮成接近白色的亮绿。这个取舍在我看来非常值——视觉效果的可控性全靠这里。3. 核心细节拆解五个决定成败的关键点3.1 每列独立的速度与相位是“雨感”的来源如果你只从这篇文章里记住一件事那应该是这一条随机化必须发生在列的维度上而且必须包含初始相位。速度好理解每列给一个 6 到 20 行/秒之间的随机值。相位指的是每列初始的头部位置必须让它在屏幕上方之外随机散布比如random.uniform(-rows, 0)。如果不做相位随机所有列从同一条水平线同时出发第一秒钟你会看到一排字齐刷刷往下掉像阅兵。这里还有个容易忽略的细节位置要用浮点数存不要用整数。用整数的话速度是 6 行/秒60 帧下每帧只前进 0.1 格取整之后十帧才动一格看起来是卡顿的跳跃。用浮点数累积、只在绘制时取整视觉上就是平滑的连续下移。# 位置存浮点绘制时取整这是平滑滚动的前提 self.head self.speed * dt # dt 是秒 end int(self.head) # 只在画的时候取整3.2 拖尾长度短了像跳蚤长了像色块拖尾长度我用“格子数”来表示随机范围 10 到 28。这个数字不是拍脑袋定的得跟屏幕行数挂钩。以 720p、字号 20 为例整屏大概 36 行拖尾 10 格意味着尾巴占屏幕高度的四分之一多一点看起来是一段清爽的短雨拖尾 28 格几乎贯穿全屏那就是连绵不断的长雨。我实测下来如果拖尾超过屏幕行数视觉上会退化成“整列常亮”因为尾巴一直没离开屏幕新的雨头又接上来看起来就是一根竖着的亮条在闪。所以调参时记住一条经验拖尾上限不要超过屏幕总行数的一半。亮度映射我用了 8 个等级把拖尾从头部到末端线性映射过去depth end - r # 距离头部几格0 就是头部 if depth 0: level LEVELS # 头部最高亮 else: level int((1.0 - depth / col.tail) * (LEVELS - 1))为什么是 8 级而不是 256 级因为每多一级就要多缓存一批字形图。8 级 × 大约 90 个字符 720 张小图内存占用可以忽略而人眼在这种高速下落的画面上根本分辨不出 8 级和 32 级的差别。用离散等级换缓存命中率是这类效果里非常划算的优化。3.3 字符刷新率一秒改多少次才“像数字在流动”刷新率这个参数最玄学。我最初每帧把所有格子全部重新随机一遍60 帧下等于每秒变 60 次结果是满屏雪花眼睛疼。后来改成每秒每个格子有 0.3 到 0.5 的概率被替换瞬间就对了——你会看到零零星星几个字符在闪剩下的保持稳定像电影里那种“偶尔跳一下”的感觉。实现上别写成“遍历每个格子掷骰子”那样是 2000 多次随机调用。用总量控制的写法更省total rows * cols n int(total * MUTATE_RATE * dt) # dt 已换算成秒 for _ in range(n): r random.randrange(rows) c random.randrange(cols) grid[r][c] random.choice(CHARSET)这里有个小问题值得说随机取格子是有可能重复取到同一格的实际刷新量会略少于 n。对视觉效果毫无影响不值得为此引入集合去重——那反而更慢。注意刷新率跟帧率是解耦的。如果你把 FPS 从 60 降到 30刷新量的公式里乘了 dt每秒的刷新总次数保持不变画面观感不会因为降帧而变慢只是变卡。这个设计在调性能的时候能救命。3.4 头部高亮一个像素级的细节决定“高级感”很多复刻版本通篇只有一种绿色看起来就是一堆绿字往下掉。真正的观感差距在于头部那一格——它应该是接近白色的浅绿比如(215, 255, 235)跟后面的正绿拉开明显对比。这一格是整个画面的视觉焦点它在动你的眼睛就会跟着它走。我一开始担心头部太亮会刺眼实测下来恰恰相反正绿(0, 255, 95)在纯黑背景上的亮度已经很高了头部再亮一档不会难受反而让“雨头”这个结构清晰起来。如果你用的是偏冷的绿色头部可以往青白方向偏比如(200, 255, 255)气质会更“冷”。3.5 时间步长拖动窗口之后画面突然暴走的原因一个新手几乎必踩的坑用固定的位移量累加位置也就是head 2这种写法。这样写在同一台机器上没问题换台性能差一点的机器帧率从 60 掉到 30雨就变成了半速更糟的是你拖动一下窗口主循环被阻塞几百毫秒恢复的瞬间积累的时间没被处理画面会突然“暴走”一下。正确做法是每帧取实际经过的时间乘进位移里dt clock.tick(FPS) / 1000.0 # 毫秒转秒 dt min(dt, 0.05) # 上限截断防暴走那个min(dt, 0.05)是保命的。窗口被拖动、系统切到别的程序、笔记本合盖再打开这些情况下 dt 可能是好几秒。不截断的话所有列一次性往下冲几百格画面直接飞出去用户以为程序崩了。截到 50 毫秒最坏情况就是画面顿一下逻辑不会乱。4. 完整实现pygame 版逐段拆解4.1 环境准备与三个容易翻车的准备动作依赖只有 pygame 一个装完就完python -m pip install pygame装完先做三件事能省掉后面一半的排查时间。第一确认 pygame 能正常初始化。跑一下python -c import pygame; pygame.init(); print(pygame.version.ver)能打印出版本号就说明底层库没问题。如果是 Linux 无桌面环境pygame.display.set_mode会直接报错那就老老实实用 tkinter 版或者别折腾了。第二确认字体。这是最容易翻车的一环下一小节单独讲。第三把窗口尺寸设成你要录屏的分辨率。我一开始用 800×600 做原型效果满意改成 1920×1080 录屏时发现列数变了、整体密度完全不是那个味只能重新调一遍参数。所以先定最终分辨率再调参。4.2 字体加载为什么你的字全挤在一起了pygame.font.Font(None, 20)会用 pygame 的默认字体而默认字体不是等宽的。这意味着“i”和“W”渲染出来的宽度不一样你按固定列宽去摆位置行与行之间就会错位画面上看起来像字符在互相挤压。解决办法是加载一个等宽字体并且用M的宽度作为列宽基准def load_font(size): for name in (consolas, couriernew, dejavusansmono, menlo, monaco): path pygame.font.match_font(name) if path: return pygame.font.Font(path, size) return pygame.font.Font(None, size)pygame.font.match_font会按名字去系统字体目录里找找到就返回路径。列表里放了 Windows 的 consolas、macOS 的 menlo、Linux 常见的 dejavusansmono三个平台基本都能命中一个。全都找不到时回退到默认字体这时候就得接受轻微错位或者自己下一个等宽 TTF 文件把FONT_FILE指向它。列宽和行高这么算cell_w max(1, font.size(M)[0]) cell_h font.get_height() cols max(1, WIDTH // cell_w) rows HEIGHT // cell_h 1行数那个1是有意为之。最后一行可能只露出半个字高不加一的话底部会留一条黑边雨往下落时看起来像被裁掉了。4.3 字形缓存把 60 帧从不可能变成轻松这是性能上最关键的一段。如果你每帧对每个可见字符都调一次font.render那是每秒上万次文本渲染CPU 直接拉满帧率掉到个位数。正确做法是把“字符 亮度等级”当作缓存键渲染一次存起来之后只做 blitclass GlyphCache: def __init__(self, font, levels8): self.font font self.levels levels self._cache {} staticmethod def _mix(c1, c2, t): return ( int(c1[0] (c2[0] - c1[0]) * t), int(c1[1] (c2[1] - c1[1]) * t), int(c1[2] (c2[2] - c1[2]) * t), ) def get(self, ch, level): key (ch, level) surf self._cache.get(key) if surf is None: if level self.levels: color HEAD_COLOR else: color self._mix(TAIL_COLOR, BODY_COLOR, level / (self.levels - 1)) surf self.font.render(ch, True, color) self._cache[key] surf return surf_mix做的是两个 RGB 颜色之间的线性插值。拖尾末端用(0, 50, 18)这种深橄榄绿中间过渡到正绿(0, 255, 95)。注意末端色别直接用纯黑(0,0,0)虽然视觉上差不多但纯黑在不同显示器上会有色阶断层用一点点绿反而是更稳的做法。缓存建好之后一帧的绘制就变成了纯粹的贴图操作。实测同样 2000 个可见字符不做缓存是 8 帧做了缓存稳定 60 帧CPU 从 90% 多降到 15% 左右。4.4 主循环与绘制顺序绘制顺序在这里很讲究。我一开始是先算所有列的新位置再统一画结果发现重叠的列会出现“后面的盖住前面的”这种自然效果其实是对的但如果你先画暗的再画亮的观感更通透。所以我的循环是先遍历列、在列内部先算头部位置、再按由暗到亮的顺序画也就是从拖尾末端往头部画for c, col in enumerate(columns): col.head col.speed * dt end int(col.head) start end - col.tail for r in range(start, end 1): # 从小到大末尾暗、头部亮 if 0 r rows: depth end - r level LEVELS if depth 0 else int((1.0 - depth / col.tail) * (LEVELS - 1)) screen.blit(glyphs.get(grid[r][c], level), (c * cell_w, r * cell_h))因为行号是从上往下递增的而头部在下面所以从头部的角度往回看末端在上面。这个顺序天然就是“先画上面暗的、最后画下面亮的”重叠时亮色压在上面视觉上更立体。列的回收也在这段里做。判断条件是整条尾巴都跑出屏幕底部也就是头部位置减去拖尾长度大于总行数。这时候重新随机速度、拖尾和初始位置让这一列从顶部重新开始画面就能无限循环下去。4.5 完整可运行代码把上面所有片段拼起来这里是完整版本复制存成rain.py直接跑import random import sys import pygame # ---------------- 参数区 ---------------- WIDTH, HEIGHT 1280, 720 FPS 60 FONT_SIZE 20 FONT_FILE None # 指定等宽 TTF 路径留空则自动查找 BG_COLOR (0, 0, 0) HEAD_COLOR (215, 255, 235) BODY_COLOR (0, 255, 95) TAIL_COLOR (0, 50, 18) CHARSET ( 0123456789 ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz !#$%^*()_-[]{}/\\| ) LEVELS 8 # 亮度分级数 MUTATE_RATE 0.35 # 每秒每个格子被刷新的概率 def load_font(size): if FONT_FILE: return pygame.font.Font(FONT_FILE, size) for name in (consolas, couriernew, dejavusansmono, menlo, monaco): path pygame.font.match_font(name) if path: return pygame.font.Font(path, size) return pygame.font.Font(None, size) class GlyphCache: def __init__(self, font, levelsLEVELS): self.font font self.levels levels self._cache {} staticmethod def _mix(c1, c2, t): return ( int(c1[0] (c2[0] - c1[0]) * t), int(c1[1] (c2[1] - c1[1]) * t), int(c1[2] (c2[2] - c1[2]) * t), ) def get(self, ch, level): key (ch, level) surf self._cache.get(key) if surf is None: if level self.levels: color HEAD_COLOR else: color self._mix(TAIL_COLOR, BODY_COLOR, level / (self.levels - 1)) surf self.font.render(ch, True, color) self._cache[key] surf return surf class Column: __slots__ (head, speed, tail) def __init__(self, rows, initialFalse): self.tail random.randint(10, 28) self.speed random.uniform(6.0, 20.0) self.head random.uniform(-rows, 0) if initial else random.uniform(-self.tail, 0) def reset(self): self.tail random.randint(10, 28) self.speed random.uniform(6.0, 20.0) self.head random.uniform(-self.tail, 0) def main(): pygame.init() screen pygame.display.set_mode((WIDTH, HEIGHT)) pygame.display.set_caption(Code Rain) clock pygame.time.Clock() font load_font(FONT_SIZE) cell_w max(1, font.size(M)[0]) cell_h font.get_height() cols max(1, WIDTH // cell_w) rows HEIGHT // cell_h 1 grid [[random.choice(CHARSET) for _ in range(cols)] for _ in range(rows)] columns [Column(rows, initialTrue) for _ in range(cols)] glyphs GlyphCache(font) running True while running: dt min(clock.tick(FPS) / 1000.0, 0.05) for event in pygame.event.get(): if event.type pygame.QUIT: running False elif event.type pygame.KEYDOWN: if event.key in (pygame.K_ESCAPE, pygame.K_q): running False elif event.key pygame.K_F11: pygame.display.toggle_fullscreen() for _ in range(int(rows * cols * MUTATE_RATE * dt)): grid[random.randrange(rows)][random.randrange(cols)] random.choice(CHARSET) screen.fill(BG_COLOR) for c, col in enumerate(columns): col.head col.speed * dt end int(col.head) for r in range(end - col.tail, end 1): if 0 r rows: depth end - r if depth 0: level LEVELS else: level max(0, int((1.0 - depth / col.tail) * (LEVELS - 1))) screen.blit(glyphs.get(grid[r][c], level), (c * cell_w, r * cell_h)) if end - col.tail rows: col.reset() pygame.display.flip() pygame.quit() sys.exit(0) if __name__ __main__: main()按 ESC 或 Q 退出F11 切全屏。有人问能不能用 F11实测在部分缩放设置下切全屏会导致画面模糊因为 pygame 是把你的窗口内容拉伸上去的不是重新按全屏分辨率渲染。追求清晰的话直接把WIDTH, HEIGHT设成屏幕原生分辨率全屏时用pygame.FULLSCREEN标志创建窗口。4.6 调参速查表参数就那么几个但每个管什么得心里有数不然改一处崩三处参数位置调大的效果建议范围FONT_SIZE参数区字符变大、列数变少、更粗犷14 ~ 28speed范围Column.__init__雨下得更急压迫感强6 ~ 20 行/秒tail范围Column.__init__尾巴更长画面更满屏幕行数的 25%~50%MUTATE_RATE参数区字符闪得更频繁超过 1.0 变雪花0.2 ~ 0.6LEVELS参数区渐变更细腻缓存体积变大6 ~ 12BODY_COLOR参数区决定整体色相换成青色就是另一种味任意 RGB我个人的常用组合是1080p 下FONT_SIZE18、速度 8~22、拖尾 12~32、刷新率 0.3。这套参数在录屏时密度刚好既不会密到看不清也不会稀到像在下毛毛雨。5. 不装第三方库的 tkinter 版本5.1 换思路没有 Surface就得靠 Canvas 硬扛有些环境就是装不了第三方包比如公司电脑权限受限或者你只是想把脚本丢给同事双击就能跑。这时候 tkinter 是唯一选择但它得换一套实现思路。pygame 有离屏 Surface我可以先把字符渲染好缓存起来。tkinter 的 Canvas 没有这个东西每个字符都必须作为独立的 item 存在。所以只能接受“每帧清空重画”把开销压到最低的办法是控制字符总量、降低帧率。我实测下来900×600 的窗口、14 号字、大约 1600 个可见字符50 毫秒一帧20 帧/秒是能跑顺的再往上就明显卡顿。如果你把窗口拉大或者字号调大得相应地降帧。5.2 完整代码import random import tkinter as tk W, H 900, 600 CELL_W, CELL_H 14, 20 FONT (Consolas, 14) DELAY 50 # 毫秒约 20 帧 CHARSET 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ#$%* BG #000000 COLOR_HEAD #d4ffe8 COLOR_BODY #00ff5f COLOR_TAIL #00330f def hex_to_rgb(h): return int(h[1:3], 16), int(h[3:5], 16), int(h[5:7], 16) def blend(h1, h2, t): r1, g1, b1 hex_to_rgb(h1) r2, g2, b2 hex_to_rgb(h2) return #%02x%02x%02x % ( int(r1 (r2 - r1) * t), int(g1 (g2 - g1) * t), int(b1 (b2 - b1) * t), ) class Rain: def __init__(self, root): self.canvas tk.Canvas(root, widthW, heightH, bgBG, highlightthickness0) self.canvas.pack() self.cols W // CELL_W self.rows H // CELL_H 1 self.heads [random.uniform(-self.rows, 0) for _ in range(self.cols)] self.speeds [random.uniform(4, 12) for _ in range(self.cols)] self.tails [random.randint(8, 22) for _ in range(self.cols)] self.grid [[random.choice(CHARSET) for _ in range(self.cols)] for _ in range(self.rows)] self.loop() def loop(self): self.canvas.delete(all) for _ in range(int(self.cols * self.rows * 0.02)): self.grid[random.randrange(self.rows)][random.randrange(self.cols)] \ random.choice(CHARSET) for i in range(self.cols): self.heads[i] self.speeds[i] * DELAY / 1000.0 end int(self.heads[i]) for r in range(max(0, end - self.tails[i]), min(self.rows, end 1)): depth end - r if depth 0: color COLOR_HEAD else: t max(0.0, 1.0 - depth / self.tails[i]) color blend(COLOR_TAIL, COLOR_BODY, t) self.canvas.create_text( i * CELL_W, r * CELL_H, textself.grid[r][i], fillcolor, fontFONT, anchornw, ) if end - self.tails[i] self.rows: self.heads[i] random.uniform(-self.tails[i], 0) self.speeds[i] random.uniform(4, 12) self.tails[i] random.randint(8, 22) self.canvas.after(DELAY, self.loop) if __name__ __main__: root tk.Tk() root.title(Code Rain) root.resizable(False, False) Rain(root) root.mainloop()5.3 tkinter 版绕不开的三个取舍第一个取舍是帧率。DELAY 设 30 的话画面明显卡设 80 又显得拖沓50 是我试出来比较舒服的值。如果你只想要个能跑的效果别纠结就用 50。第二个取舍是颜色计算开销。blend()每调用一次都要做字符串切片和格式化一帧上万次调用也是负担。优化办法是把亮度也做缓存——建一个{(char, level): color_string}的字典跟 pygame 版一个思路。这个改动不大但能再挤出一截性能。第三个取舍是字体。tkinter 直接用系统字体名(Consolas, 14)在 Windows 上有macOS 上会回退到别的字体。稳妥点写(Courier New, 14)三个平台基本都有虽然字形没那么好看。真在意的话可以用tkinter.font.families()查一下系统里有哪些等宽字体再选。6. 性能实测与优化路径6.1 从 90% CPU 到 15%改了哪三处我把优化前后的数据记了一下环境是一台四年前的轻薄本、1080p、字号 18、满屏约 2400 个可见字符阶段帧率CPU 占用关键改动初版8~1290%每帧对所有可见字符调font.render加入字形缓存4540%按 (字符, 亮度) 缓存 Surface加帧率上限 dt 截断60 稳定18%clock.tick(60)主动降速别让它空转加大字号减字符数60 稳定12%字号 18→22可见字符降到 1600第一处的收益最大占了七成以上。这里要特别说一句“加帧率上限”的收益不加clock.tick(FPS)的话死循环会以屏幕刷新率疯狂跑本来 60 帧够用它非要跑到 300 帧白白烧 CPU。加个上限画面观感一模一样风扇立刻安静。第二处的收益容易被忽略减少可见字符数比优化绘制更有效。字号从 18 调到 22字符数少了三分之一画面反而更霸气因为字大了。如果你在低配机器上跑第一件事就是调大字号。6.2 高 DPI 屏幕上的模糊问题在 Windows 高分屏或 macOS 的 Retina 屏上pygame 窗口可能被系统按比例缩放结果就是画面发虚字符边缘糊。这不是代码写错了是操作系统的 DPI 缩放机制。处理办法有两个。一是启动时告诉系统“这个程序我自己管 DPI”在pygame.init()之前加import os os.environ[SDL_WINDOWS_DPI_AWARENESS] permonitorv2二是干脆绕过缩放直接把窗口尺寸设成物理分辨率再全屏。这个方案更粗暴但更可靠缺点是你得自己算好字号保证列数是整数。6.3 录屏导出怎么录才不掉帧想把它做成 GIF 发出去直接录屏往往掉帧。我的做法是逐帧导出图片再合成完全绕开录屏工具的性能干扰frame_idx 0 while running: # ... 正常绘制 ... pygame.image.save(screen, fframes/{frame_idx:05d}.png) frame_idx 1 if frame_idx 600: break clock.tick(FPS)存够 600 帧10 秒再用 ffmpeg 合成ffmpeg -framerate 60 -i frames/%05d.png -vf fps30,scale960:-1 -loop 0 out.gif注意导出时把 FPS 保持在 60 采集合成时再降到 30这样 GIF 体积能小一半观感损失几乎看不出来。另外存帧的时候记得先把frames目录建好pygame 不会自动创建。7. 常见问题与排查实录7.1 问题速查表现象最可能的原因处理动作窗口一片黑什么都没有字体渲染失败或颜色是纯黑打印一下font.get_height()把 BODY_COLOR 改成红色验证字符左右错位、互相挤压用了非等宽字体换 consolas / couriernew或指定 TTF底部留一条黑边行数算少了rows HEIGHT // cell_h 1画面像雪花屏MUTATE_RATE太大降到 0.3 左右拖尾是一根常亮的竖条拖尾长度超过屏高一半把tail上限压到 rows//2拖动窗口后画面暴走没做 dt 截断dt min(dt, 0.05)关闭窗口没反应主循环阻塞在事件队列检查有没有调用pygame.event.get()帧率上不去没做字形缓存上GlyphCache换台电脑雨变慢用了固定位移量改成 dt 乘速度tkinter 版越跑越占内存Canvas item 没删干净每帧delete(all)7.2 几个我踩过的真实坑坑一字符内容每次都重新随机看起来像故障。我最初的实现里绘制时直接random.choice(CHARSET)取字符根本没存二维数组。结果就是每个格子每帧都在变画面像老电视的雪花。正确的做法是维护一个grid二维数组每帧只改其中一小部分。这个改动看着不起眼观感差了一个量级。坑二列的回收判断写反了。我一开始写的是if col.head rows: reset()只判断头部离开屏幕。结果拖尾还挂在屏幕上呢这一列就从顶部重新开始了画面上会出现上下两段雨同时存在中间断开。正确条件是end - col.tail rows整条尾巴都出界才算走完。坑三全屏之后所有参数都不对了。我在窗口模式下把参数调到满意全屏一开列数从 71 变成 106雨密得像一堵墙。教训是分辨率变化会直接改变列数和行数参数必须跟着重新校准。如果要做成能切分辨率的程序把速度单位从“行/秒”换算成“屏幕高度比例/秒”会更稳。坑四pygame 装好了但 import 报错。十有八九是装到了另一个 Python 环境里。用python -m pip install pygame而不是直接pip install能保证装到当前解释器下面这个习惯值得养成。提示调试视觉参数时别反复启动程序。在循环里加一句键盘响应比如按上下箭头实时加减MUTATE_RATE按左右箭头加减速度范围几秒钟就能试出最优组合比改代码重启快十倍。8. 还能玩出什么花样原版效果做稳定之后我陆续加了几个变体都只需要在现有代码上改十几行这里把思路留给你。彩色版本把BODY_COLOR用 HSV 空间生成每列给一个随机的色调偏移画面会变成青紫、橙红的混合雨科技感更足。改动点就在GlyphCache里把_mix的终点色从固定值改成按列传参。缺点是缓存键要多带一个维度内存翻几倍但依然可接受。交互版本加个鼠标位置检测靠近鼠标的区域让拖尾变亮或速度变快像是被搅动了。实现上是在绘制前判断一下格子中心和鼠标的距离做个亮度加成。扫描线叠加在最后一层盖一张横向条纹的透明图模拟老显示器的扫描线复古味立刻就出来了。生成这张图不需要素材几十行循环往一个Surface上填一行黑一行透明即可。字符集替换把CHARSET换成你熟悉的符号集比如二进制只有 0 和 1或者换成偏旁部首、希腊字母、几何图形气质完全不同。我甚至试过换成 emoji 之外的表情符号效果意外地有意思不过这类字符宽度不一致会破坏网格得慎重。最后分享一个我在调这类视觉效果时反复验证的经验先让画面稳定在 60 帧再谈好不好看。掉帧的动画再炫也留不住人而参数调优的空间永远是有的。我通常的做法是先把所有会变化的东西做成变量顶在文件头上跑起来之后开着窗口一边看一边改数值改到满意再收工。这套流程走下来一个晚上足够把效果调到能直接发出去的水平。 
长河君 · 2026/11/2 9:10:14 · 阅读 1.2k Python代码雨实现指南：pygame与tkinter双方案性能调优
1. 先想清楚要做成什么样再动手写第一行 Python很多人搜“Python 代码雨”心里想的其实是电影里那种绿色字符往下淌的画面。但真正动手时第一行代码就开始纠结用什么画要不要装库为什么我写出来的效果像一堆静止的乱码在闪。这篇就把我用 Python 复刻这套视觉效果的全过程拆开讲从方案选型、数据结构、渲染顺序一直到最后调参末端给两份可以直接跑起来的完整代码——一份 pygame 版一份纯标准库 tkinter 版。你手里电脑上大概已经装好了 Python看完挑一份复制就能看到东西动起来。先说清楚这件事的边界。所谓“代码雨”本质不是文字动画而是一列一列竖直排列的字符各自以不同速度下落每列带一条由亮到暗的拖尾字符内容还会随机变化。它不涉及任何算法难点难点全在“怎么把这几百上千个字符按正确的位置、正确的亮度、正确的时机画到屏幕上还能稳住 60 帧”。这就决定了工具选型的优先级——渲染方式的批量绘制能力远比库的知名度重要。我见过不少人第一版是拿print加time.sleep在终端里刷屏跑起来整屏往下滚观感完全不对。原因很简单终端的换行是“推上去”不是“画上去”你没法把某一格的字符单独改成暗色。想做出拖尾和渐变必须有一个能按坐标画字的画布。搞明白这一层需求后面的选择就顺理成章了。适合谁看会写 Python 基础语法、知道函数和类是什么就够不需要任何图形学背景。如果你只是想找段代码复制跑一下第 3 节的完整代码直接拿走如果你想弄明白每一行参数为什么这么设、屏幕卡顿怎么救、换台机器为什么字全挤在一起那从头看更省事。2. 方案选型三种实现路线的取舍2.1 pygame、tkinter、终端库的横向对比摆在我面前的有三条路我当时都试了一遍下面是实测下来的对比供你按自己的场景挑方案依赖单帧绘制能力帧率上限1080p约 2000 字符上手成本适合场景pygame需pip install pygame强Surface 批量 blit60 帧稳定CPU 约 10%~20%低演示、录屏、桌面玩具tkinter标准库自带弱每个字符是一个 Canvas item25~30 帧CPU 约 30%~50%中不能装第三方库的环境curses / 终端标准库自带极弱只能按字符格刷依赖终端观感差低服务器里自娱自乐我最后选 pygame 做主方案理由不是“它最强”而是它把离屏绘制这件事做得最省心。pygame 里一个Surface就是一块像素缓冲你可以先把一个字符渲染成一张小图缓存起来之后每帧只是把这张小图往画布上贴贴一千次也就几毫秒。tkinter 的 Canvas 每次delete(all)再重建几千个 item开销就上去了还得手动管理 canvas id一旦泄漏就是内存缓慢上涨。至于终端方案我建议只在最极端的环境下用——比如你只能 SSH 到一台什么都不让装的机器上。真要在终端里做也得靠 curses 的addstr指定行列能做出个粗糙的雏形但没有颜色渐变视觉效果差得远。2.2 把“炫酷”这个模糊的词拆成可实现的图层“炫酷”是个没法直接编码的词。我的做法是把它拆成四个可以量化的图层每一层单独实现、单独调参第一层是网格。屏幕上字符不是随便放的而是严格对齐到一个单元格矩阵里列宽等于字符宽度行高等于字体的行高。这一层决定了画面的“秩序感”一旦网格不整齐看起来就像故障而不是效果。第二层是下落。每一列有一个虚拟的“头部位置”按各自的速度往下推进。速度必须逐列随机如果所有列同速画面会变成整体平移的横条瞬间失去灵魂。第三层是拖尾。头部后面的若干个格子颜色从亮绿逐渐过渡到接近背景的深绿。这一层是“像雨”的关键没有渐变就只是一排排跳动的字。第四层是字符刷新。每个格子里的字符会以一定概率被换成新的随机字符模拟“数字在流动”的感觉。刷新太快是雪花屏太慢是静态文字墙。把这四层分开想之后代码结构自然就出来了一个二维字符数组管内容一个列对象数组管位置和速度一个渲染函数负责按“距离头部的格数”算亮度。剩下的全是调参数。2.3 为什么不用“画完再整体淡化”的经典写法网上流传最广的写法是另一种思路每帧在整块画布上盖一层半透明黑让上一帧的内容自然变暗然后再画新的字符。代码极短十几行就能跑我第一次也是这么写的。但它有两个绕不过去的毛病。一是颜色会脏。绿色被黑色按 alpha 混合多次之后拖尾会往灰绿、土黄的方向偏尤其在纯黑背景上末端会出现一层说不清的杂色。二是拖尾长度不可控。淡化速度由那层黑色的 alpha 决定你想让某一列尾巴长一点、某一列短一点根本做不到所有列只能共用同一个衰减率。我最终换成了“按深度算亮度”的方案。虽然多写了几十行但换来的是拖尾长度逐列可调、颜色渐变可以精确指定起止色、头部能单独高亮成接近白色的亮绿。这个取舍在我看来非常值——视觉效果的可控性全靠这里。3. 核心细节拆解五个决定成败的关键点3.1 每列独立的速度与相位是“雨感”的来源如果你只从这篇文章里记住一件事那应该是这一条随机化必须发生在列的维度上而且必须包含初始相位。速度好理解每列给一个 6 到 20 行/秒之间的随机值。相位指的是每列初始的头部位置必须让它在屏幕上方之外随机散布比如random.uniform(-rows, 0)。如果不做相位随机所有列从同一条水平线同时出发第一秒钟你会看到一排字齐刷刷往下掉像阅兵。这里还有个容易忽略的细节位置要用浮点数存不要用整数。用整数的话速度是 6 行/秒60 帧下每帧只前进 0.1 格取整之后十帧才动一格看起来是卡顿的跳跃。用浮点数累积、只在绘制时取整视觉上就是平滑的连续下移。# 位置存浮点绘制时取整这是平滑滚动的前提 self.head self.speed * dt # dt 是秒 end int(self.head) # 只在画的时候取整3.2 拖尾长度短了像跳蚤长了像色块拖尾长度我用“格子数”来表示随机范围 10 到 28。这个数字不是拍脑袋定的得跟屏幕行数挂钩。以 720p、字号 20 为例整屏大概 36 行拖尾 10 格意味着尾巴占屏幕高度的四分之一多一点看起来是一段清爽的短雨拖尾 28 格几乎贯穿全屏那就是连绵不断的长雨。我实测下来如果拖尾超过屏幕行数视觉上会退化成“整列常亮”因为尾巴一直没离开屏幕新的雨头又接上来看起来就是一根竖着的亮条在闪。所以调参时记住一条经验拖尾上限不要超过屏幕总行数的一半。亮度映射我用了 8 个等级把拖尾从头部到末端线性映射过去depth end - r # 距离头部几格0 就是头部 if depth 0: level LEVELS # 头部最高亮 else: level int((1.0 - depth / col.tail) * (LEVELS - 1))为什么是 8 级而不是 256 级因为每多一级就要多缓存一批字形图。8 级 × 大约 90 个字符 720 张小图内存占用可以忽略而人眼在这种高速下落的画面上根本分辨不出 8 级和 32 级的差别。用离散等级换缓存命中率是这类效果里非常划算的优化。3.3 字符刷新率一秒改多少次才“像数字在流动”刷新率这个参数最玄学。我最初每帧把所有格子全部重新随机一遍60 帧下等于每秒变 60 次结果是满屏雪花眼睛疼。后来改成每秒每个格子有 0.3 到 0.5 的概率被替换瞬间就对了——你会看到零零星星几个字符在闪剩下的保持稳定像电影里那种“偶尔跳一下”的感觉。实现上别写成“遍历每个格子掷骰子”那样是 2000 多次随机调用。用总量控制的写法更省total rows * cols n int(total * MUTATE_RATE * dt) # dt 已换算成秒 for _ in range(n): r random.randrange(rows) c random.randrange(cols) grid[r][c] random.choice(CHARSET)这里有个小问题值得说随机取格子是有可能重复取到同一格的实际刷新量会略少于 n。对视觉效果毫无影响不值得为此引入集合去重——那反而更慢。注意刷新率跟帧率是解耦的。如果你把 FPS 从 60 降到 30刷新量的公式里乘了 dt每秒的刷新总次数保持不变画面观感不会因为降帧而变慢只是变卡。这个设计在调性能的时候能救命。3.4 头部高亮一个像素级的细节决定“高级感”很多复刻版本通篇只有一种绿色看起来就是一堆绿字往下掉。真正的观感差距在于头部那一格——它应该是接近白色的浅绿比如(215, 255, 235)跟后面的正绿拉开明显对比。这一格是整个画面的视觉焦点它在动你的眼睛就会跟着它走。我一开始担心头部太亮会刺眼实测下来恰恰相反正绿(0, 255, 95)在纯黑背景上的亮度已经很高了头部再亮一档不会难受反而让“雨头”这个结构清晰起来。如果你用的是偏冷的绿色头部可以往青白方向偏比如(200, 255, 255)气质会更“冷”。3.5 时间步长拖动窗口之后画面突然暴走的原因一个新手几乎必踩的坑用固定的位移量累加位置也就是head 2这种写法。这样写在同一台机器上没问题换台性能差一点的机器帧率从 60 掉到 30雨就变成了半速更糟的是你拖动一下窗口主循环被阻塞几百毫秒恢复的瞬间积累的时间没被处理画面会突然“暴走”一下。正确做法是每帧取实际经过的时间乘进位移里dt clock.tick(FPS) / 1000.0 # 毫秒转秒 dt min(dt, 0.05) # 上限截断防暴走那个min(dt, 0.05)是保命的。窗口被拖动、系统切到别的程序、笔记本合盖再打开这些情况下 dt 可能是好几秒。不截断的话所有列一次性往下冲几百格画面直接飞出去用户以为程序崩了。截到 50 毫秒最坏情况就是画面顿一下逻辑不会乱。4. 完整实现pygame 版逐段拆解4.1 环境准备与三个容易翻车的准备动作依赖只有 pygame 一个装完就完python -m pip install pygame装完先做三件事能省掉后面一半的排查时间。第一确认 pygame 能正常初始化。跑一下python -c import pygame; pygame.init(); print(pygame.version.ver)能打印出版本号就说明底层库没问题。如果是 Linux 无桌面环境pygame.display.set_mode会直接报错那就老老实实用 tkinter 版或者别折腾了。第二确认字体。这是最容易翻车的一环下一小节单独讲。第三把窗口尺寸设成你要录屏的分辨率。我一开始用 800×600 做原型效果满意改成 1920×1080 录屏时发现列数变了、整体密度完全不是那个味只能重新调一遍参数。所以先定最终分辨率再调参。4.2 字体加载为什么你的字全挤在一起了pygame.font.Font(None, 20)会用 pygame 的默认字体而默认字体不是等宽的。这意味着“i”和“W”渲染出来的宽度不一样你按固定列宽去摆位置行与行之间就会错位画面上看起来像字符在互相挤压。解决办法是加载一个等宽字体并且用M的宽度作为列宽基准def load_font(size): for name in (consolas, couriernew, dejavusansmono, menlo, monaco): path pygame.font.match_font(name) if path: return pygame.font.Font(path, size) return pygame.font.Font(None, size)pygame.font.match_font会按名字去系统字体目录里找找到就返回路径。列表里放了 Windows 的 consolas、macOS 的 menlo、Linux 常见的 dejavusansmono三个平台基本都能命中一个。全都找不到时回退到默认字体这时候就得接受轻微错位或者自己下一个等宽 TTF 文件把FONT_FILE指向它。列宽和行高这么算cell_w max(1, font.size(M)[0]) cell_h font.get_height() cols max(1, WIDTH // cell_w) rows HEIGHT // cell_h 1行数那个1是有意为之。最后一行可能只露出半个字高不加一的话底部会留一条黑边雨往下落时看起来像被裁掉了。4.3 字形缓存把 60 帧从不可能变成轻松这是性能上最关键的一段。如果你每帧对每个可见字符都调一次font.render那是每秒上万次文本渲染CPU 直接拉满帧率掉到个位数。正确做法是把“字符 亮度等级”当作缓存键渲染一次存起来之后只做 blitclass GlyphCache: def __init__(self, font, levels8): self.font font self.levels levels self._cache {} staticmethod def _mix(c1, c2, t): return ( int(c1[0] (c2[0] - c1[0]) * t), int(c1[1] (c2[1] - c1[1]) * t), int(c1[2] (c2[2] - c1[2]) * t), ) def get(self, ch, level): key (ch, level) surf self._cache.get(key) if surf is None: if level self.levels: color HEAD_COLOR else: color self._mix(TAIL_COLOR, BODY_COLOR, level / (self.levels - 1)) surf self.font.render(ch, True, color) self._cache[key] surf return surf_mix做的是两个 RGB 颜色之间的线性插值。拖尾末端用(0, 50, 18)这种深橄榄绿中间过渡到正绿(0, 255, 95)。注意末端色别直接用纯黑(0,0,0)虽然视觉上差不多但纯黑在不同显示器上会有色阶断层用一点点绿反而是更稳的做法。缓存建好之后一帧的绘制就变成了纯粹的贴图操作。实测同样 2000 个可见字符不做缓存是 8 帧做了缓存稳定 60 帧CPU 从 90% 多降到 15% 左右。4.4 主循环与绘制顺序绘制顺序在这里很讲究。我一开始是先算所有列的新位置再统一画结果发现重叠的列会出现“后面的盖住前面的”这种自然效果其实是对的但如果你先画暗的再画亮的观感更通透。所以我的循环是先遍历列、在列内部先算头部位置、再按由暗到亮的顺序画也就是从拖尾末端往头部画for c, col in enumerate(columns): col.head col.speed * dt end int(col.head) start end - col.tail for r in range(start, end 1): # 从小到大末尾暗、头部亮 if 0 r rows: depth end - r level LEVELS if depth 0 else int((1.0 - depth / col.tail) * (LEVELS - 1)) screen.blit(glyphs.get(grid[r][c], level), (c * cell_w, r * cell_h))因为行号是从上往下递增的而头部在下面所以从头部的角度往回看末端在上面。这个顺序天然就是“先画上面暗的、最后画下面亮的”重叠时亮色压在上面视觉上更立体。列的回收也在这段里做。判断条件是整条尾巴都跑出屏幕底部也就是头部位置减去拖尾长度大于总行数。这时候重新随机速度、拖尾和初始位置让这一列从顶部重新开始画面就能无限循环下去。4.5 完整可运行代码把上面所有片段拼起来这里是完整版本复制存成rain.py直接跑import random import sys import pygame # ---------------- 参数区 ---------------- WIDTH, HEIGHT 1280, 720 FPS 60 FONT_SIZE 20 FONT_FILE None # 指定等宽 TTF 路径留空则自动查找 BG_COLOR (0, 0, 0) HEAD_COLOR (215, 255, 235) BODY_COLOR (0, 255, 95) TAIL_COLOR (0, 50, 18) CHARSET ( 0123456789 ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz !#$%^*()_-[]{}/\\| ) LEVELS 8 # 亮度分级数 MUTATE_RATE 0.35 # 每秒每个格子被刷新的概率 def load_font(size): if FONT_FILE: return pygame.font.Font(FONT_FILE, size) for name in (consolas, couriernew, dejavusansmono, menlo, monaco): path pygame.font.match_font(name) if path: return pygame.font.Font(path, size) return pygame.font.Font(None, size) class GlyphCache: def __init__(self, font, levelsLEVELS): self.font font self.levels levels self._cache {} staticmethod def _mix(c1, c2, t): return ( int(c1[0] (c2[0] - c1[0]) * t), int(c1[1] (c2[1] - c1[1]) * t), int(c1[2] (c2[2] - c1[2]) * t), ) def get(self, ch, level): key (ch, level) surf self._cache.get(key) if surf is None: if level self.levels: color HEAD_COLOR else: color self._mix(TAIL_COLOR, BODY_COLOR, level / (self.levels - 1)) surf self.font.render(ch, True, color) self._cache[key] surf return surf class Column: __slots__ (head, speed, tail) def __init__(self, rows, initialFalse): self.tail random.randint(10, 28) self.speed random.uniform(6.0, 20.0) self.head random.uniform(-rows, 0) if initial else random.uniform(-self.tail, 0) def reset(self): self.tail random.randint(10, 28) self.speed random.uniform(6.0, 20.0) self.head random.uniform(-self.tail, 0) def main(): pygame.init() screen pygame.display.set_mode((WIDTH, HEIGHT)) pygame.display.set_caption(Code Rain) clock pygame.time.Clock() font load_font(FONT_SIZE) cell_w max(1, font.size(M)[0]) cell_h font.get_height() cols max(1, WIDTH // cell_w) rows HEIGHT // cell_h 1 grid [[random.choice(CHARSET) for _ in range(cols)] for _ in range(rows)] columns [Column(rows, initialTrue) for _ in range(cols)] glyphs GlyphCache(font) running True while running: dt min(clock.tick(FPS) / 1000.0, 0.05) for event in pygame.event.get(): if event.type pygame.QUIT: running False elif event.type pygame.KEYDOWN: if event.key in (pygame.K_ESCAPE, pygame.K_q): running False elif event.key pygame.K_F11: pygame.display.toggle_fullscreen() for _ in range(int(rows * cols * MUTATE_RATE * dt)): grid[random.randrange(rows)][random.randrange(cols)] random.choice(CHARSET) screen.fill(BG_COLOR) for c, col in enumerate(columns): col.head col.speed * dt end int(col.head) for r in range(end - col.tail, end 1): if 0 r rows: depth end - r if depth 0: level LEVELS else: level max(0, int((1.0 - depth / col.tail) * (LEVELS - 1))) screen.blit(glyphs.get(grid[r][c], level), (c * cell_w, r * cell_h)) if end - col.tail rows: col.reset() pygame.display.flip() pygame.quit() sys.exit(0) if __name__ __main__: main()按 ESC 或 Q 退出F11 切全屏。有人问能不能用 F11实测在部分缩放设置下切全屏会导致画面模糊因为 pygame 是把你的窗口内容拉伸上去的不是重新按全屏分辨率渲染。追求清晰的话直接把WIDTH, HEIGHT设成屏幕原生分辨率全屏时用pygame.FULLSCREEN标志创建窗口。4.6 调参速查表参数就那么几个但每个管什么得心里有数不然改一处崩三处参数位置调大的效果建议范围FONT_SIZE参数区字符变大、列数变少、更粗犷14 ~ 28speed范围Column.__init__雨下得更急压迫感强6 ~ 20 行/秒tail范围Column.__init__尾巴更长画面更满屏幕行数的 25%~50%MUTATE_RATE参数区字符闪得更频繁超过 1.0 变雪花0.2 ~ 0.6LEVELS参数区渐变更细腻缓存体积变大6 ~ 12BODY_COLOR参数区决定整体色相换成青色就是另一种味任意 RGB我个人的常用组合是1080p 下FONT_SIZE18、速度 8~22、拖尾 12~32、刷新率 0.3。这套参数在录屏时密度刚好既不会密到看不清也不会稀到像在下毛毛雨。5. 不装第三方库的 tkinter 版本5.1 换思路没有 Surface就得靠 Canvas 硬扛有些环境就是装不了第三方包比如公司电脑权限受限或者你只是想把脚本丢给同事双击就能跑。这时候 tkinter 是唯一选择但它得换一套实现思路。pygame 有离屏 Surface我可以先把字符渲染好缓存起来。tkinter 的 Canvas 没有这个东西每个字符都必须作为独立的 item 存在。所以只能接受“每帧清空重画”把开销压到最低的办法是控制字符总量、降低帧率。我实测下来900×600 的窗口、14 号字、大约 1600 个可见字符50 毫秒一帧20 帧/秒是能跑顺的再往上就明显卡顿。如果你把窗口拉大或者字号调大得相应地降帧。5.2 完整代码import random import tkinter as tk W, H 900, 600 CELL_W, CELL_H 14, 20 FONT (Consolas, 14) DELAY 50 # 毫秒约 20 帧 CHARSET 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ#$%* BG #000000 COLOR_HEAD #d4ffe8 COLOR_BODY #00ff5f COLOR_TAIL #00330f def hex_to_rgb(h): return int(h[1:3], 16), int(h[3:5], 16), int(h[5:7], 16) def blend(h1, h2, t): r1, g1, b1 hex_to_rgb(h1) r2, g2, b2 hex_to_rgb(h2) return #%02x%02x%02x % ( int(r1 (r2 - r1) * t), int(g1 (g2 - g1) * t), int(b1 (b2 - b1) * t), ) class Rain: def __init__(self, root): self.canvas tk.Canvas(root, widthW, heightH, bgBG, highlightthickness0) self.canvas.pack() self.cols W // CELL_W self.rows H // CELL_H 1 self.heads [random.uniform(-self.rows, 0) for _ in range(self.cols)] self.speeds [random.uniform(4, 12) for _ in range(self.cols)] self.tails [random.randint(8, 22) for _ in range(self.cols)] self.grid [[random.choice(CHARSET) for _ in range(self.cols)] for _ in range(self.rows)] self.loop() def loop(self): self.canvas.delete(all) for _ in range(int(self.cols * self.rows * 0.02)): self.grid[random.randrange(self.rows)][random.randrange(self.cols)] \ random.choice(CHARSET) for i in range(self.cols): self.heads[i] self.speeds[i] * DELAY / 1000.0 end int(self.heads[i]) for r in range(max(0, end - self.tails[i]), min(self.rows, end 1)): depth end - r if depth 0: color COLOR_HEAD else: t max(0.0, 1.0 - depth / self.tails[i]) color blend(COLOR_TAIL, COLOR_BODY, t) self.canvas.create_text( i * CELL_W, r * CELL_H, textself.grid[r][i], fillcolor, fontFONT, anchornw, ) if end - self.tails[i] self.rows: self.heads[i] random.uniform(-self.tails[i], 0) self.speeds[i] random.uniform(4, 12) self.tails[i] random.randint(8, 22) self.canvas.after(DELAY, self.loop) if __name__ __main__: root tk.Tk() root.title(Code Rain) root.resizable(False, False) Rain(root) root.mainloop()5.3 tkinter 版绕不开的三个取舍第一个取舍是帧率。DELAY 设 30 的话画面明显卡设 80 又显得拖沓50 是我试出来比较舒服的值。如果你只想要个能跑的效果别纠结就用 50。第二个取舍是颜色计算开销。blend()每调用一次都要做字符串切片和格式化一帧上万次调用也是负担。优化办法是把亮度也做缓存——建一个{(char, level): color_string}的字典跟 pygame 版一个思路。这个改动不大但能再挤出一截性能。第三个取舍是字体。tkinter 直接用系统字体名(Consolas, 14)在 Windows 上有macOS 上会回退到别的字体。稳妥点写(Courier New, 14)三个平台基本都有虽然字形没那么好看。真在意的话可以用tkinter.font.families()查一下系统里有哪些等宽字体再选。6. 性能实测与优化路径6.1 从 90% CPU 到 15%改了哪三处我把优化前后的数据记了一下环境是一台四年前的轻薄本、1080p、字号 18、满屏约 2400 个可见字符阶段帧率CPU 占用关键改动初版8~1290%每帧对所有可见字符调font.render加入字形缓存4540%按 (字符, 亮度) 缓存 Surface加帧率上限 dt 截断60 稳定18%clock.tick(60)主动降速别让它空转加大字号减字符数60 稳定12%字号 18→22可见字符降到 1600第一处的收益最大占了七成以上。这里要特别说一句“加帧率上限”的收益不加clock.tick(FPS)的话死循环会以屏幕刷新率疯狂跑本来 60 帧够用它非要跑到 300 帧白白烧 CPU。加个上限画面观感一模一样风扇立刻安静。第二处的收益容易被忽略减少可见字符数比优化绘制更有效。字号从 18 调到 22字符数少了三分之一画面反而更霸气因为字大了。如果你在低配机器上跑第一件事就是调大字号。6.2 高 DPI 屏幕上的模糊问题在 Windows 高分屏或 macOS 的 Retina 屏上pygame 窗口可能被系统按比例缩放结果就是画面发虚字符边缘糊。这不是代码写错了是操作系统的 DPI 缩放机制。处理办法有两个。一是启动时告诉系统“这个程序我自己管 DPI”在pygame.init()之前加import os os.environ[SDL_WINDOWS_DPI_AWARENESS] permonitorv2二是干脆绕过缩放直接把窗口尺寸设成物理分辨率再全屏。这个方案更粗暴但更可靠缺点是你得自己算好字号保证列数是整数。6.3 录屏导出怎么录才不掉帧想把它做成 GIF 发出去直接录屏往往掉帧。我的做法是逐帧导出图片再合成完全绕开录屏工具的性能干扰frame_idx 0 while running: # ... 正常绘制 ... pygame.image.save(screen, fframes/{frame_idx:05d}.png) frame_idx 1 if frame_idx 600: break clock.tick(FPS)存够 600 帧10 秒再用 ffmpeg 合成ffmpeg -framerate 60 -i frames/%05d.png -vf fps30,scale960:-1 -loop 0 out.gif注意导出时把 FPS 保持在 60 采集合成时再降到 30这样 GIF 体积能小一半观感损失几乎看不出来。另外存帧的时候记得先把frames目录建好pygame 不会自动创建。7. 常见问题与排查实录7.1 问题速查表现象最可能的原因处理动作窗口一片黑什么都没有字体渲染失败或颜色是纯黑打印一下font.get_height()把 BODY_COLOR 改成红色验证字符左右错位、互相挤压用了非等宽字体换 consolas / couriernew或指定 TTF底部留一条黑边行数算少了rows HEIGHT // cell_h 1画面像雪花屏MUTATE_RATE太大降到 0.3 左右拖尾是一根常亮的竖条拖尾长度超过屏高一半把tail上限压到 rows//2拖动窗口后画面暴走没做 dt 截断dt min(dt, 0.05)关闭窗口没反应主循环阻塞在事件队列检查有没有调用pygame.event.get()帧率上不去没做字形缓存上GlyphCache换台电脑雨变慢用了固定位移量改成 dt 乘速度tkinter 版越跑越占内存Canvas item 没删干净每帧delete(all)7.2 几个我踩过的真实坑坑一字符内容每次都重新随机看起来像故障。我最初的实现里绘制时直接random.choice(CHARSET)取字符根本没存二维数组。结果就是每个格子每帧都在变画面像老电视的雪花。正确的做法是维护一个grid二维数组每帧只改其中一小部分。这个改动看着不起眼观感差了一个量级。坑二列的回收判断写反了。我一开始写的是if col.head rows: reset()只判断头部离开屏幕。结果拖尾还挂在屏幕上呢这一列就从顶部重新开始了画面上会出现上下两段雨同时存在中间断开。正确条件是end - col.tail rows整条尾巴都出界才算走完。坑三全屏之后所有参数都不对了。我在窗口模式下把参数调到满意全屏一开列数从 71 变成 106雨密得像一堵墙。教训是分辨率变化会直接改变列数和行数参数必须跟着重新校准。如果要做成能切分辨率的程序把速度单位从“行/秒”换算成“屏幕高度比例/秒”会更稳。坑四pygame 装好了但 import 报错。十有八九是装到了另一个 Python 环境里。用python -m pip install pygame而不是直接pip install能保证装到当前解释器下面这个习惯值得养成。提示调试视觉参数时别反复启动程序。在循环里加一句键盘响应比如按上下箭头实时加减MUTATE_RATE按左右箭头加减速度范围几秒钟就能试出最优组合比改代码重启快十倍。8. 还能玩出什么花样原版效果做稳定之后我陆续加了几个变体都只需要在现有代码上改十几行这里把思路留给你。彩色版本把BODY_COLOR用 HSV 空间生成每列给一个随机的色调偏移画面会变成青紫、橙红的混合雨科技感更足。改动点就在GlyphCache里把_mix的终点色从固定值改成按列传参。缺点是缓存键要多带一个维度内存翻几倍但依然可接受。交互版本加个鼠标位置检测靠近鼠标的区域让拖尾变亮或速度变快像是被搅动了。实现上是在绘制前判断一下格子中心和鼠标的距离做个亮度加成。扫描线叠加在最后一层盖一张横向条纹的透明图模拟老显示器的扫描线复古味立刻就出来了。生成这张图不需要素材几十行循环往一个Surface上填一行黑一行透明即可。字符集替换把CHARSET换成你熟悉的符号集比如二进制只有 0 和 1或者换成偏旁部首、希腊字母、几何图形气质完全不同。我甚至试过换成 emoji 之外的表情符号效果意外地有意思不过这类字符宽度不一致会破坏网格得慎重。最后分享一个我在调这类视觉效果时反复验证的经验先让画面稳定在 60 帧再谈好不好看。掉帧的动画再炫也留不住人而参数调优的空间永远是有的。我通常的做法是先把所有会变化的东西做成变量顶在文件头上跑起来之后开着窗口一边看一边改数值改到满意再收工。这套流程走下来一个晚上足够把效果调到能直接发出去的水平。