为什么有的动画卡，有的不卡 帧预算、脏矩形和屏幕的节奏

请把上一课的弹球改成 ___ 个小球：
每个球有自己的位置和速度，各自运动、各自反弹，
球的颜色你自己定 ___（可以都给一个颜色，也可以各不相同）；
每一帧仍然先擦掉旧位置、再画上新位置，其它写法保持不变。
请在中文注释里写清：这样每一帧一共要往屏幕送多少次数据。
请用中文注释；烧录前先运行 arduino-cli board list 核对端口；
另存一个新版本，把上一课 1 个球的版本留着方便对比。

<details>
<summary>想好了再点开：我们的参考数字</summary>

**这不是标准答案。**参考值：**50** 个球。

**为什么球数值得你自己定？**因为它决定了这一课后面所有实验的"卡"的程度：

- 填 **50**：卡得明显，一眼能看出来，帧耗时会超过 33 毫秒；
- 填 **10**：可能还不够卡，你会以为"我的板子挺快的"，后面优化就没有对比；
- 填 **200**：一开始就卡死了，看不出优化前后的差别。

> 想体验"从顺到卡"的过程？先填 5 跑一次，再改成 50 跑一次——**中间那个感觉就是帧预算被吃完了。**

**颜色**随便选。不过有个小提示：**都给同一个颜色**的话，代码简单、每帧的数据量也固定，后面测帧耗时更干净。

</details>

请给上一课的弹球加上帧率统计：
每一帧开始时记下时刻，画完以后算出这一帧用了多少毫秒；
每 ___ 帧统计一次平均值（你自己定，参考 60），同时算出大约多少帧/秒；
结果显示在屏幕上，并通过串口以 115200 打印一份，
格式像"平均帧耗时：__ 毫秒，约 __ 帧/秒"。
再加一个 BOOT（GPIO0）切换，在 1 个球和 50 个球之间来回切，方便我对比。
请用中文注释；烧录前先运行 arduino-cli board list 核对端口；
另存一个新版本，保留旧程序。

<details>
<summary>想好了再点开：我们的参考数字</summary>

**这不是标准答案。**参考值：每 **60** 帧统计一次。

**这个数字管的是"数字有多稳"：**

- 每 **60** 帧算一次：约 2 秒刷新一次读数，**看得清、也够稳**；
- 每 **1** 帧算一次：屏幕上的数字疯狂乱跳，你根本读不出来；
- 每 **600** 帧算一次：等 20 秒才更新一次，调参数时急死人。

> 60 帧还有个好处：**60 帧 ÷ 30 帧/秒 = 2 秒**，你心里好换算。
> 想看清楚"稳定值"和"瞬时抖动"的区别？故意填 1，看屏幕上的数字怎么跳。

</details>

请做一个对比实验，同样的 ___ 个小球，两种画法：
A 版：每一帧先用 fillScreen 把整屏填黑，再画这些球；
B 版：每一帧只把每个球上一帧的位置用背景色盖掉，再在新位置画上，不清整屏。
两版都要统计平均帧耗时，同时显示在屏幕上并从串口 115200 打印；
按 BOOT（GPIO0）在 A 版和 B 版之间切换，
屏幕上用中文写清现在正在跑的是哪一版；
亮度不超过 ___（参考 80）。
请用中文注释；烧录前先运行 arduino-cli board list 核对端口；
另存一个新版本，保留旧程序。

<details>
<summary>想好了再点开：我们的参考数字</summary>

**这不是标准答案。**参考值：**20** 个小球。

**这一节的任务是"比出差别"，所以球数要选得刚好：**

- **20 个**：两个版本都跑得动，但 B 版明显更快——差别一眼看得出；
- **5 个**：两个版本都不卡，比了等于没比；
- **50 个**：A 版直接卡死，B 版也吃力，反而说不清"谁快"。

> 更关键的是**为什么 A 版慢**：A 版每帧要送 **76,800 × 2 = 153,600 字节**，
> B 版只送 `球数 × 小矩形面积 × 2`。20 个球的话大约是 **20 × 144 × 2 ≈ 5,760 字节**——
> **差了 26 倍多**。这就是第 6 课"改多少就送多少"的又一次验证。

</details>

启动时：
    初始化屏幕，整屏填黑
    记下 50 个小球各自的位置和速度
    记下"上一帧每个球画在哪里"（一开始都是空的）

每一帧：
    记下这一帧开始的时刻

    对每个小球：
        用背景色盖掉它上一帧所在的小矩形      ← 脏矩形：只清这一小块
    有重叠时：把重叠的小矩形合并成一块大的再清

    对每个小球：
        算出新位置
        如果撞到边界：把对应的速度取反
        在新位置画上小球
        记下这一帧画在了哪里（供下一帧清除）

    统计这一帧花了多少毫秒
    如果还没到下一帧的时间：等一小会儿（用 millis 判断，不要 delay 空等）

    累加帧数，每隔一段时间算出平均帧耗时并打印

请帮我优化 ___ 个小球的动画，目标是平均帧耗时不超过 ___ 毫秒：
1. 不要每帧 fillScreen 整屏重画，改成只清除每个球上一帧占用的小矩形；
2. 如果有球的区域重叠，把要清除的区域合并后再清；
3. 用 millis() 控制节奏，不要用 delay() 空等；
4. 保留帧率统计，把平均帧耗时和帧率显示在屏幕上并通过串口打印。
如果试下来还是达不到目标，请直接告诉我瓶颈卡在哪一步。
请先告诉我你打算怎么改，等我确认后再动手。

<details>
<summary>想好了再点开：我们的参考数字</summary>

**这不是标准答案。**参考值：**50** 个球、**33** 毫秒。

**33 毫秒是怎么来的？**上一节算过：**每秒 30 帧 → 1000 ÷ 30 ≈ 33.3 毫秒**。

那**球数**为什么也让你填？因为它决定了这个目标**难不难**：

- **50 个球 + 33 毫秒**：要动真格优化，是这一课的正题；
- **10 个球**：可能不优化就达标了——你学不到东西；
- **200 个球**：也许优化到极限也达不到 33 毫秒。**那也是一种正确答案**——
  这时候程序该做的不是硬撑，而是**如实告诉你瓶颈在哪**。

> 目标定得够不着的时候，"**测出瓶颈**"比"假装达标"有价值得多。
> 第 4 问就是为这个写的：达不到就说出来，别硬撑。

</details>