企业官网建设流程全解析

做WS2812灯带项目的老哥，应该都跟这根只有一根数据线的灯带打过交道。颜色丰富、串联方便，拿来搞呼吸灯、跑马灯、鱼缸灯都特别合适。早期我也用过最直接的方案：GPIO拉高拉低加delay，灯确实会亮，但只要系统里开了串口中断、定时器中断，或者任务一多，灯带就开始抖、闪烁、颜色错乱，排查半天都不知道问题出在时序上。后来换成了STM32的PWM+DMA方案，灯带数据完全由硬件搬运，CPU基本不用管，实测下来效果稳定很多，呼吸渐变也能做到非常顺滑。这篇文章就把这套方案的思路、参数计算、完整代码和踩坑记录都写出来，如果你正准备用STM32驱动WS2812做灯效，这份内容可以直接抄作业。

1. 方案设计思路：为什么WS2812就该用PWM+DMA

1.1 WS2812的时序协议和“看起来简单”的坑

WS2812的通信协议本质上是一根数据线上的串行脉冲宽度调制。每个LED内部有一个20mA恒流驱动芯片，通过识别数据线上的高电平持续时间来区分逻辑0和逻辑1。标准时序大致是：0码要求高电平0.22~0.38us，低电平0.58~1.0us；1码要求高电平0.58~1.0us，低电平0.22~0.38us。每一位的周期大约1.25us，数据按GRB顺序、高位先发，一整帧传完之后需要一个大于50us的复位码来锁存数据。

如果你第一次接触这个灯，第一反应肯定是：这不就是按照时序拉高拉低嘛，GPIO翻转加几个延时就好。实际跑起来你会发现，问题全出在“延时”两个字上。单片机的GPIO翻转本身很快，但C语言里的delay，尤其是用循环写的软件延时，受中断、编译器优化、Flash等待周期影响很大。只要UART中断进来，或者SysTick高低优先级打断了一下，某一位的高电平时间就可能从0.35us变成0.8us，灯珠直接把它识别成1码，颜色瞬间就乱了。这也是为什么很多人做WS2812第一版都“能亮但没法稳定用”。

所以我后来把思路从“用CPU去模拟时序”换成“用硬件去生成时序”。既然WS2812的每一位本质上是一个固定周期、可变占空比的脉冲，那这不就是PWM吗？既然每一位的占空比是预先能算出来的，那为什么不把这一整帧的占空比数据放在内存里，用DMA自动喂给PWM的比较寄存器？这就是PWM+DMA方案的核心逻辑。

1.2 PWM+DMA方案的运行逻辑

PWM+DMA方案说起来并不复杂。定时器始终以800kHz的频率产生PWM波形，也就是每个周期1.25us，这正好对应WS2812每一位的时间长度。PWM输出引脚接灯带DIN，CCR寄存器决定当前周期的高电平宽度。DMA的作用，就是把内存里预先存好的一串CCR值，一个周期搬运一个，自动写入到TIM的CCR寄存器里。

这样做的好处很直接：CPU只负责在DMA传输之前把“每一位对应的高电平时间”准备好，传输过程中CPU完全不用管。这就好比一个自动售货机，MCU是上货员，DMA是传送带，定时器是机械臂，每个周期自动拿一个值放到出口，整个过程不需要人盯着。所以无论系统里有多少中断，哪怕串口一直在收发，灯带时序也不会受到任何影响，因为时序已经和CPU指令执行无关了。

实测下来这个方案有三个明显优势。第一，时序精度高，每个位的误差只取决于定时器的时钟精度，稳定度远超人肉延时。第二，CPU占用极低，一帧60颗灯的数据传输大约2ms，全程零CPU参与，主循环可以随便跑业务逻辑。第三，代码结构清晰，只要把颜色数据转换成CCR序列，加什么特效都只是往缓冲区里填写不同的数据而已。

1.3 资源选型：定时器、DMA通道和缓冲区规划

以最常见的STM32F103为例，我选TIM1作为PWM发生器，PA8复用为TIM1_CH1输出。DMA用DMA1的Channel5，对应TIM1的更新事件，也就是TIM1_UP请求。为什么要用更新事件而不是比较事件？因为更新事件在每个PWM周期开始时都会触发一次，不会出现CCR等于ARR时无法触发比较中断的问题，时序更稳定。

缓冲区设计是这个方案里最关键的一环。很多新手会存一帧的RGB数据，然后让DMA直接搬运，其实不对。DMA搬运的数据不是颜色字节，而是每一位的CCR值。一个像素有24位，所以一个像素就需要24个CCR元素。我一般会在缓冲区开头放一个CCR=0的占位元素，然后把所有LED的颜色数据按位展开成CCR值，最后再补80个0作为复位码。整体缓冲区大小就是：1 + LED数量*24 + 80。

2. 核心细节拆解：时序计算、DMA配置与呼吸效果调优

2.1 800kHz PWM时序参数到底怎么算出来的

STM32F103的APB2定时器时钟是72MHz，这个频率下要产生800kHz的PWM，计算方式很简单：定时器不分频，预分频PSC=0，重载值ARR=89，这样PWM频率就是72MHz除以90，等于800kHz，周期1.25us。这里有个容易踩的坑：有人习惯把ARR算成79，结果PWM频率变成900kHz，每个位周期变成1.11us，看起来好像也在WS2812的容忍范围内，但余量很小，灯珠多了就容易出问题，我建议严格按800kHz来。

CCR值的计算也不复杂。WS2812的0码高电平约0.35us，那么CCR就是0.35us乘以72MHz，算出来25.2，取整为25。1码高电平约0.7us，CCR就是0.7乘以72MHz，约50.4，取整为50。这两个值对应的实际高电平时间分别是0.347us和0.694us，都在规格书允许范围内，余量也很充足。我建议新手直接用25和50，先不要自己乱改，等拿到示波器再微调。

还有一个非常重要的细节：为什么缓冲区开头要放一个CCR=0的占位元素？因为定时器的CCR预装载机制，第一次通过DMA写入的CCR值并不是立刻生效，而是要等到下一个更新事件才锁存。如果不加占位元素，第一个实际脉冲就会跟DMA搬运错开一个周期，虽然从整体上看只是延迟了一个周期，但在某些灯珠上可能表现为首灯颜色偏移。我实际测试下来，多花一个数组元素换来严格的相位对齐，很值得。

2.2 DMA配置里容易被忽略的三个细节

DMA配置本身不复杂，但有几个细节非常关键，稍微弄错一个灯带就可能不工作。

第一个是数据宽度。CCR寄存器是16位的，所以DMA的外设数据宽度和存储器数据宽度都要设置为HalfWord，也就是16位半字。有人图省事把缓冲区定义成uint8_t，然后DMA数据宽度也设置成Byte，这会导致外设宽度不匹配，高低字节错乱，颜色会变得完全不可控。缓冲区老老实实用uint16_t数组就好。

第二个是CCR预装载必须使能。如果关闭CCR预装载，DMA写入CCR后，占空比变化是在一个PWM周期中间发生的，等于在一个位中间切换了高低电平，波形会出现毛刺，严重干扰灯珠识别。开启CCR预装载之后，CCR的影子寄存器会在每个更新事件统一锁存新值，这样每个周期的高电平宽度就是从周期开始就确定的，波形干净利落。

第三个是DMA中断的处理逻辑。我采用DMA正常模式，传输一帧完成后进入中断，在中断里做三件事：清除传输完成标志、关闭DMA、把全局标志位ws2812_frame_done置1。主循环检测到这个标志位后，才会去更新颜色缓冲区并启动下一帧传输。这样做的好处是，缓冲区更新永远发生在DMA停止期间，不会出现DMA正在搬运数据、主循环同时改数据导致的“撕裂”问题。

还有一个操作细节：启动DMA后，需要用TIM_GenerateEvent手动触发一次更新事件，否则DMA要等下一个自然产生的更新事件才开始搬运，虽然最多只延迟1.25us，但第一次启动时会有一种“灯带反应慢半拍”的感觉。手动触发一下就干净利落了。

2.3 呼吸灯渐变的核心：Gamma校正与亮度曲线

呼吸灯效果看起来复杂，核心算法其实就是两件事：控制整体亮度随时间变化，再让这个变化符合人眼感知。

很多人一上来就把亮度值直接按时间线性增减，或者用一个简单的正弦波算，结果效果很不自然，感觉灯“亮了半天才暗，暗着暗着突然亮起来”。原因是LED亮度与驱动占空比基本呈线性关系，但人眼的亮度感知是接近对数的，对暗部变化极其敏感，对亮部变化相对迟钝。换句话说，在占空比较低时，人眼能分辨出每一个细微变化；在占空比较高时，变化好几百个等级可能也没啥感觉。所以如果直接用物理线性变化，暗部变化太快，亮部变化太慢，看起来就像“陡升缓降”。

解决办法是加Gamma校正。我一般用指数曲线做转换，公式是：实际输出 = (目标亮度 / 255)的gamma次方再乘以255。gamma取2.2到3.0之间都算常见，LED灯带我比较喜欢2.8，暗部过渡更细腻。这个转换可以在系统初始化时一次性算好256个点的查找表，运行时直接把亮度索引映射过去，几乎不占CPU时间。

有了Gamma表之后，呼吸效果我仍然用正弦包络，但注意正弦值要映射到0到255之间。如果想做得更圆润，可以把呼吸周期拉长到4秒左右，帧间隔控制到20ms，也就是50帧每秒，这样渐变过程肉眼看不出任何跳变。

3. 手把手代码实现与联调

3.1 硬件接线与工程准备

先把接线说清楚。STM32的PA8接到WS2812灯带的DIN数据脚，灯带的VCC和GND接外部5V电源，灯带的GND和开发板的GND必须共地，否则数据信号没有参考电平，灯带根本不会正常工作。PA8和DIN之间我建议串联一个330欧姆电阻，用来抑制信号线上的振铃，尤其是数据线稍微长一点的时候效果很明显。

这里必须提醒一下电平问题。WS2812的推荐驱动电平是5V，STM32的GPIO输出高电平是3.3V，大多数情况下3.3V直接接DIN也能亮，但余量不大，特别是线长超过20cm或者遇到劣质灯珠，就容易出现颜色错乱、第一颗灯不亮这类问题。我用的方案是加一颗74AHCT125四路电平转换芯片，3.3V侧接PA8，5V侧接灯带DIN，一劳永逸。如果你手头没有电平转换芯片，至少保证数据线尽量短，并靠近单片机输出端加上拉电阻至5V。

工程配置方面，我用的是标准外设库。需要开启的时钟包括：GPIOA、TIM1的APB2时钟，DMA1的AHB时钟。PA8配置为复用推挽输出，速度50MHz。TIM1配置为PWM模式1。DMA1_Channel5配置为存储器到外设传输，源地址是缓冲区数组，目标地址是TIM1->CCR1寄存器。

3.2 底层驱动代码：WS2812编码与DMA搬运

直接看代码。这里我写了一个比较完整的驱动，ws2812.h定义对外接口，ws2812.c实现了初始化、设置单灯颜色和更新整帧数据。缓冲区大小按60颗灯计算，如果你用的灯珠数量不同，改一下LED_NUM宏就行。

// ws2812.h #ifndef __WS2812_H #define __WS2812_H #include "stm32f10x.h" #include <string.h> #define LED_NUM 60 #define RESET_LEN 80 #define LED_DMA_BUFFER_SIZE (1 + LED_NUM * 24 + RESET_LEN) extern volatile uint8_t ws2812_frame_done; void WS2812_Init(void); void WS2812_SetPixelColor(uint16_t index, uint8_t r, uint8_t g, uint8_t b); void WS2812_Update(void); #endif

// ws2812.c #include "ws2812.h" #define T0H_VAL 25 #define T1H_VAL 50 static uint16_t dma_buf[LED_DMA_BUFFER_SIZE]; static uint8_t led_rgb[LED_NUM][3]; volatile uint8_t ws2812_frame_done = 1; void WS2812_Init(void) { GPIO_InitTypeDef GPIO_InitStructure; TIM_TimeBaseInitTypeDef TIM_TimeBaseStructure; TIM_OCInitTypeDef TIM_OCInitStructure; DMA_InitTypeDef DMA_InitStructure; NVIC_InitTypeDef NVIC_InitStructure; RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA | RCC_APB2Periph_TIM1, ENABLE); RCC_AHBPeriphClockCmd(RCC_AHBPeriph_DMA1, ENABLE); GPIO_InitStructure.GPIO_Pin = GPIO_Pin_8; GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF_PP; GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz; GPIO_Init(GPIOA, &GPIO_InitStructure); TIM_TimeBaseStructure.TIM_Prescaler = 0; TIM_TimeBaseStructure.TIM_CounterMode = TIM_CounterMode_Up; TIM_TimeBaseStructure.TIM_Period = 89; TIM_TimeBaseStructure.TIM_ClockDivision = 0; TIM_TimeBaseInit(TIM1, &TIM_TimeBaseStructure); TIM_OCInitStructure.TIM_OCMode = TIM_OCMode_PWM1; TIM_OCInitStructure.TIM_OutputState = TIM_OutputState_Enable; TIM_OCInitStructure.TIM_Pulse = 0; TIM_OCInitStructure.TIM_OCPolarity = TIM_OCPolarity_High; TIM_OCInitStructure.TIM_OCIdleState = TIM_OCIdleState_Reset; TIM_OC1Init(TIM1, &TIM_OCInitStructure); TIM_OC1PreloadConfig(TIM1, TIM_OCPreload_Enable); TIM_ARRPreloadConfig(TIM1, ENABLE); TIM_CtrlPWMOutputs(TIM1, ENABLE); TIM_Cmd(TIM1, ENABLE); DMA_DeInit(DMA1_Channel5); DMA_InitStructure.DMA_PeripheralBaseAddr = (uint32_t)&TIM1->CCR1; DMA_InitStructure.DMA_MemoryBaseAddr = (uint32_t)dma_buf; DMA_InitStructure.DMA_DIR = DMA_DIR_PeripheralDST; DMA_InitStructure.DMA_BufferSize = LED_DMA_BUFFER_SIZE; DMA_InitStructure.DMA_PeripheralInc = DMA_PeripheralInc_Disable; DMA_InitStructure.DMA_MemoryInc = DMA_MemoryInc_Enable; DMA_InitStructure.DMA_PeripheralDataSize = DMA_PeripheralDataSize_HalfWord; DMA_InitStructure.DMA_MemoryDataSize = DMA_MemoryDataSize_HalfWord; DMA_InitStructure.DMA_Mode = DMA_Mode_Normal; DMA_InitStructure.DMA_Priority = DMA_Priority_High; DMA_InitStructure.DMA_M2M = DMA_M2M_Disable; DMA_Init(DMA1_Channel5, &DMA_InitStructure); DMA_ITConfig(DMA1_Channel5, DMA_IT_TC, ENABLE); NVIC_InitStructure.NVIC_IRQChannel = DMA1_Channel5_IRQn; NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 0; NVIC_InitStructure.NVIC_IRQChannelSubPriority = 0; NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE; NVIC_Init(&NVIC_InitStructure); memset(dma_buf, 0, sizeof(dma_buf)); WS2812_Update(); } void WS2812_SetPixelColor(uint16_t index, uint8_t r, uint8_t g, uint8_t b) { if (index >= LED_NUM) return; led_rgb[index][0] = r; led_rgb[index][1] = g; led_rgb[index][2] = b; } void WS2812_Update(void) { uint16_t pos = 1; for (int i = 0; i < LED_NUM; i++) { uint8_t g = led_rgb[i][1]; uint8_t r = led_rgb[i][0]; uint8_t b = led_rgb[i][2]; for (int bit = 7; bit >= 0; bit--) { dma_buf[pos++] = (g & (1 << bit)) ? T1H_VAL : T0H_VAL; } for (int bit = 7; bit >= 0; bit--) { dma_buf[pos++] = (r & (1 << bit)) ? T1H_VAL : T0H_VAL; } for (int bit = 7; bit >= 0; bit--) { dma_buf[pos++] = (b & (1 << bit)) ? T1H_VAL : T0H_VAL; } } for (int i = 0; i < RESET_LEN; i++) { dma_buf[pos++] = 0; } DMA_Cmd(DMA1_Channel5, DISABLE); DMA_ClearFlag(DMA1_FLAG_TC5); DMA_SetCurrDataCounter(DMA1_Channel5, pos); DMA_Cmd(DMA1_Channel5, ENABLE); TIM_ClearFlag(TIM1, TIM_FLAG_Update); TIM_GenerateEvent(TIM1, TIM_EventSource_Update); } void DMA1_Channel5_IRQHandler(void) { if (DMA_GetITStatus(DMA1_IT_TC5)) { DMA_ClearITPendingBit(DMA1_IT_TC5); DMA_Cmd(DMA1_Channel5, DISABLE); ws2812_frame_done = 1; } }

代码里有两个细节提一下。一是WS2812_Init最后调用了一次WS2812_Update，目的是上电先把所有灯刷成灭，避免数据线悬浮时灯带出现随机颜色。二是WS2812_Update里DMA启动前手动清除TC标志，防止上一次传输完成标志残留导致中断误触发。

如果你用的是HAL库，思路完全一样，只是把标准外设库的初始化结构体换成HAL对应的句柄和函数即可。核心的缓冲区编码逻辑、DMA中断标志位处理，以及PWM参数计算，都是通用的。

3.3 呼吸灯效果层：主循环里的渐变逻辑

驱动层跑通之后，上层效果代码其实很简单。我做的是整条灯带一起呼吸，所以只需要计算出一个全局亮度值，然后把这个亮度应用到每个像素的RGB上。

// main.c 核心部分 #include "ws2812.h" #include <math.h> #define BREATH_PERIOD 4.0f #define BASE_R 64 #define BASE_G 128 #define BASE_B 192 static uint8_t gamma_table[256]; static void build_gamma_table(float gamma) { for (int i = 0; i < 256; i++) { float normalized = (float)i / 255.0f; gamma_table[i] = (uint8_t)(powf(normalized, gamma) * 255.0f + 0.5f); } } int main(void) { WS2812_Init(); build_gamma_table(2.8f); float t = 0.0f; const float dt = 0.02f; ws2812_frame_done = 1; while (1) { if (ws2812_frame_done) { ws2812_frame_done = 0; float phase = sinf(2.0f * 3.14159f * t / BREATH_PERIOD); float p = (phase + 1.0f) * 0.5f; uint8_t bright = gamma_table[(uint8_t)(p * 255.0f)]; uint8_t r = (uint8_t)((BASE_R * bright) >> 8); uint8_t g = (uint8_t)((BASE_G * bright) >> 8); uint8_t b = (uint8_t)((BASE_B * bright) >> 8); for (int i = 0; i < LED_NUM; i++) { WS2812_SetPixelColor(i, r, g, b); } WS2812_Update(); t += dt; if (t >= BREATH_PERIOD) t -= BREATH_PERIOD; } } }

BASE_R、BASE_G、BASE_B是呼吸到最亮时的目标颜色值，数值范围是0到255。我这里用的是蓝色偏紫的一组值，你可以改成任意颜色。bright经过Gamma表转换后，实际作用是把颜色值非线性地“压缩”到暗部细节更丰富的曲线上。

主循环里的ws2812_frame_done标志非常重要。每次DMA传输完成后，中断里会置1，主循环检测到之后才更新颜色并开启下一帧。这样一来，缓冲区绝对不会在DMA搬运中途被修改。实测下来，20ms一帧完全感觉不到闪烁，呼吸过程非常顺滑。如果你调的灯带很长，一帧DMA传输时间超过20ms，那就得把帧间隔稍微加大，或者考虑双缓冲方案。

关于编译环境，如果是Keil MDK，记得把Target选项卡里的Use MicroLIB勾上，否则浮点库可能会报半主机错误。如果你不喜欢浮点运算，可以提前用Python把正弦表和Gamma表生成好，直接放到代码里，运行起来会更快，但在F103上每次呼吸周期才调几次sinf和powf，占用时间完全可忽略。

4. 实测踩坑与排查技巧，帮你省掉半天debug时间

4.1 灯带不亮、颜色错乱、闪烁

我在调这套方案时，翻车最多的场景就是灯带完全不亮。排查顺序一般是：先量DIN脚波形，再看DMA有没有搬运数据，最后检查缓冲区编码。如果你手头没有示波器，可以先写一个单颗灯常亮的测试程序，逐项排除。

• 如果第一颗灯都不亮，大概率是复位码太短。有些灯珠对复位码的时间要求比较苛刻，我把复位码从40个周期加到80个周期之后，兼容性明显好了很多。
• 如果第一颗灯亮但颜色不对，比如红色和绿色互换，这是GRB顺序填错导致的。WS2812的发送顺序是G、R、B，不是R、G、B，代码里设置颜色时要注意。
• 如果某一种颜色在特定亮度下开始闪，优先怀疑供电。灯带全亮时的瞬时电流很大，60颗灯全白约3.6A，普通的单片机板载稳压器根本扛不住。我用的是一个5V 5A的适配器，并且从灯带电源端引线同时给开发板供电，问题立刻消失。

4.2 DMA缓冲区与刷新时序的经典冲突

这个坑可以说是新手最容易踩的：一边在主循环里往缓冲区写新颜色，一边DMA正在从缓冲区搬数据到CCR，结果就是同一帧数据里前半段是旧颜色、后半段是新颜色，视觉表现是灯带出现撕裂感，或者某几颗灯颜色诡异。

我通过ws2812_frame_done标志避开了这个问题，但直接在主循环里写“等标志位再更新”还不够，必须保证所有缓冲区写入操作都发生在DMA停止状态下。我建议把WS2812_Update设计成“先停止DMA，再重新指定传输长度，再启动DMA”，并且在启动前手动清除TC标志，这样整个启停流程是完整且可预测的。

另外，DMA中断里不要做太多事情，只清标志、关DMA、置标志位。如果你在中断里直接调用WS2812_SetPixelColor和WS2812_Update，一是中断处理时间过长，可能影响其他实时任务；二是嵌套和重入问题会让逻辑变得非常难查。数据准备和传输启动必须全部放到主循环里做。

4.3 供电和电平转换：硬件层面的坑

WS2812灯带的VCC和GND一定不能从STM32开发板的3.3V引脚取。一颗灯全亮最大约60mA，60颗就是3.6A，这个电流足够烧掉稳压芯片。正确的做法是5V电源直接接灯带VCC，电源GND同时接到灯带GND和开发板GND，形成完整的地回路。

电平转换这个问题需要认真对待。STM32的3.3V高电平虽然在短距离下也能驱动，但数据线稍微拉长一点，比如超过30cm，就可能因为信号衰减出现首灯不亮、颜色错乱的情况。我测试过一款国产WS2812兼容灯珠，3.3V直接驱动时，10cm以内还能工作，超过20cm就开始随机闪烁。后来加了74AHCT125，无论线长多少都稳定很多。

如果你决定直接3.3V驱动，我建议在DIN线上串联一个330欧电阻，同时把数据线尽量贴近GND线走线，减少环路面积。别问我怎么知道的，都是眼泪换来的教训。

4.4 不同灯带数量下的刷新率估算

这部分是扩展知识，帮你提前算清楚项目能不能满足需求。一帧数据的传输时间大约是：(1 + LED数量24 + 80) * 1.25us。去掉占位符和复位码的开销，可以粗略估算为LED数量24*1.25us。

以60颗灯为例，一帧大约1.9ms，理论刷新率可以到500Hz以上，实际动画里50到100Hz就足够。如果灯带扩展到300颗，一帧大约9.1ms，刷新率大概110Hz，依然能接受。但要注意缓冲区内存占用，300颗灯需要1 + 7200 + 80个uint16_t，也就是约14.6KB，STM32F103C8T6的20KB RAM就比较紧张了。

如果要做长灯带，我还试过把每个像素的颜色数据压缩后再让DMA搬运的方式，但那样代码复杂度明显增加，对呼吸灯这类统一颜色效果来说有点得不偿失。所以我的建议是：灯带不超过144颗，直接用这套PWM+DMA方案就行；灯带特别长，再考虑双缓冲或者改用SPI方案。

最后分享一点个人体会。代码能抄，但参数一定要理解。我之前一度把T0H调到28、T1H调到54，单片机跑着没有任何报错，灯带却偶尔在某种颜色下闪，后来接示波器才发现是高电平过宽导致部分灯珠识别临界。WS2812对时序的冗余量其实挺大，但碰上劣质灯珠或者长线传输时，余量越小越容易出问题。所以建议先严格按标准值跑，等波形确认没问题了，再根据实际效果微调。这套PWM+DMA的思路跑通之后，你再回头看海浪、渐变、跑马那些效果，本质上就是往缓冲区里填不同的颜色序列，扩展起来会轻松很多。