去年做一款带数据记录功能的BLE传感器时，我踩过一个特别典型的坑：设备在连接状态下每5秒想把采集到的数据写进片内Flash，结果手机App上每隔一会儿就提示“连接已断开”。一开始我怀疑是天线问题，后来用BLE分析仪抓包，才发现每次断链的时间点都刚好卡在Flash页擦除函数返回前后。那一刻我才认真去读BlueNRG手册里关于Flash操作和BLE协议栈事件调度的说明，也才有了这篇笔记。
如果你也在用ST的BlueNRG-1/BlueNRG-2这类单核BLE SoC，并且需要在运行中保存参数、记录日志或更新配置，那这篇内容你应该用得上。这篇文章会从头解释为什么Flash擦写会和BLE事件抢CPU，再给出几种可落地的互斥调度方案，最后附上我实际调试中整理的排查思路和代码框架。内容偏向工程实践，不是抄手册，所有方法都在真实项目里验证过。
1. 问题根源：Flash擦写为什么会干扰BLE事件
1.1 BlueNRG的存储架构和Flash操作特性
BlueNRG系列是ST的BLE单芯片方案，把Cortex-M0/M0+内核、射频收发器、片上Flash和RAM集成在一颗芯片里。用户应用程序、BLE协议栈（以静态库形式提供）和射频驱动全部跑在同一个CPU上。这和“MCU+外部蓝牙模块”的结构有本质区别：模块方案里MCU写自己的Flash不会影响蓝牙芯片，但BlueNRG里所有任务共享一个核，任何长时间占用的操作都会挤压BLE协议栈的处理时间。
片内Flash用于存放代码和用户数据。用户实际会用到的Flash操作大致分三类：
- 页擦除（Page Erase）：Flash写入前必须先把目标区域擦成0xFF，擦除粒度是一个page。BlueNRG-1和BlueNRG-2的页大小不太一样，典型值在1KB到2KB这个量级，具体以对应型号数据手册为准。
- 字编程（Word Program）：按32位字为单位写入数据，写入前目标区域必须是已擦除状态。
- NVDS（Non-Volatile Data Storage）：这是ST提供的非易失数据存储机制，由协议栈维护一部分，用户也可以使用保留槽位。NVDS底层依旧是Flash操作，但内部做了擦写管理和数据组织。
关键问题在于：Flash控制器执行擦除或编程时，会独占Flash阵列。而Cortex-M内核的指令通常也是从同一片Flash取出，于是CPU在Flash控制器忙的时候只能停顿等待。也就是说，Flash擦写不只是“执行一些代码”那么简单——它是一个硬阻塞窗口，期间中断响应会被延迟，指令取指会停止，BLE协议栈哪怕想做点什么都做不了。
这跟很多人熟悉的STM32外部SPI Flash完全不一样。外挂SPI Flash通过SPI接口读写，CPU可以一边等SPI传输一边干别的；但BlueNRG内部Flash是CPU取指的直接来源，擦写期间整个内核都被“锁住”，这是所有互斥问题的物理根源。
1.2 BLE协议栈事件处理的时间敏感点在哪里
BLE链路层是严格时分复用的。连接建立以后，主设备和从设备按固定的连接间隔（Connection Interval）互相收发数据，每个连接事件里要完成交换、确认、重传等动作。如果从设备在连接事件到来时没有及时处理，主机那边就会丢包、重传，连续错过多个事件后，连接监督定时器（Supervision Timeout）超时，链路直接断掉。广播模式类似：每个广播间隔要发一个广播包，如果CPU正卡在Flash擦写上，广播包就会被推迟甚至漏发，手机端表现为扫描不到设备或者广播数据不刷新。
BlueNRG的协议栈通过事件队列和应用层交互。射频中断或者协议栈内部定时器到达时，底层会把事件打包放入HCI事件队列，用户程序在主循环里调用BLE_EvtRx()查询、调用HCI_Event_Processing()消费处理。这本身就是异步设计，正常情况下完全够用。但问题是用户代码如果在主循环里长时间执行Flash擦写，HCI_Event_Processing()迟迟得不到调用，队列越积越多，链路层状态机得不到及时推进，最终就是断链。
还有一个很多人容易忽略的点：即使你把Flash操作放在一个定时器中断里，或者放在一个“看起来优先级很高”的位置，也无法绕过这个阻塞。因为Flash控制器忙时，CPU连中断服务程序的指令都无法从Flash取出，中断响应被硬件层面延后。所以这不是软件调度优先级能解决的问题，必须在时间窗口层面做统筹。
1.3 复现现场：一次Flash页擦除带来的断链实验
为了把问题讲清楚，我在BlueNRG-2评估板上做了一个简单实验。
测试环境：BlueNRG-2评估板作为从设备，手机用nRF Connect连接，连接间隔设置为30ms，连接监督超时设置为4s。代码里在收到一个特定写指令后，触发一次整页Flash擦除（典型值约20~40ms，以具体芯片手册为准），擦除完再写入64字节数据。
现象记录得很清楚：
- 连接间隔30ms时，一次页擦除大约跨过1~2个连接事件，连接没有断，但手机端看到明显的通信延迟，RSSI曲线出现周期性波动。
- 连接间隔缩短到15ms后，同样的擦除操作导致连续丢包，部分Android手机直接报连接不稳定。
- 如果把连接监督超时从4s改小到1s，再将Flash擦除操作连续执行多次（模拟批量写日志），连接几乎必然断开。
这个实验说明一个问题：并不是“只要Flash操作时间小于监督超时时间就安全”，因为断链的临界条件不仅取决于总超时，还取决于你让主机“等”了多久、丢了多少包。链路不稳定一样会影响产品体验，不是只有彻底断开才算故障。
2. 互斥调度的四种方案：从主循环空闲窗口到NVDS
2.1 方案一：主循环空闲窗口里执行Flash操作
最直接也最容易被接受的思路，是在主循环处理完所有BLE事件之后，利用事件与事件之间的空闲时间做Flash操作。典型代码如下：
while (1) { /* 1. 优先把BLE协议栈事件全部处理完 */ while (BLE_EvtRx()) { HCI_Event_Processing(); } /* 2. 用户应用业务逻辑 */ user_app_task(); /* 3. Flash写入任务，只在空闲窗口执行 */ flash_task_scheduler(); /* 4. 进入低功耗或继续循环 */ }这个方案的核心逻辑是：先让协议栈把当前所有事件消费干净，再做自己的耗时操作。它实现最简单，适合两种情况：设备处于未连接状态只是偶尔更新参数，或者连接业务的实时性要求不高。
但它的局限也很明显。BLE事件是持续到达的，你处理完当前事件队列只是一瞬间，下一个连接事件可能就在几毫秒后到来。如果在flash_task_scheduler()里执行了一次40ms的页擦除，下一次连接事件照样被堵住。所以这个方案只适合“操作时间远小于连接间隔”的轻量写入，不适合批量日志写入或大块数据更新。
2.2 方案二：拆写不拆擦，用状态机让BLE事件插队
针对Flash写操作的耗时主要来自两部分：擦除和编程。擦除是一次性动作，很难拆碎；但编程可以按字拆，每写一个字大约几十微秒，几十微秒对BLE连接事件来说是一个可以容忍的窗口。于是可以把“写一大块数据”拆成“多次写一小块数据”，每写完一小块就检查一次BLE事件队列，有事件就先让协议栈处理，处理完再继续写。
void flash_write_chunk(void) { if (g_flash_op.offset >= g_flash_op.length) { g_flash_op.state = FLASH_OP_DONE; return; } /* 每次只写一个字（32位），时间很短 */ FLASH_Program(g_flash_op.dst_addr + g_flash_op.offset, g_flash_op.src_data + g_flash_op.offset); g_flash_op.offset += 4; /* 写完一个字之后，主动让出：有BLE事件就返回主循环 */ if (BLE_EvtRx()) return; }但是必须提醒：拆写只在“编程”阶段有效，页擦除这个动作是拆不开的。所以更完整的做法是把擦除和写入分成两个阶段：先找一个足够宽裕的时间窗口执行页擦除，然后利用多次小窗口逐字写入。对于需要跨多页的大块数据，还要一页一页处理，不能一口气把所有页都擦完。
这个方案的核心价值是把“不可抢占的长时间段”尽量缩小，让BLE事件在每两个字之间都有插队机会。代价是代码复杂度上升，必须引入状态机管理写入进度，否则断电中断后状态就丢了。
2.3 方案三：根据连接间隔选择安全写入窗口
如果设备处于连接状态，可以动态获取当前连接参数，再决定Flash操作是否执行。BlueNRG协议栈提供了获取连接参数的接口，比如aci_gap_get_connection_parameters()或者aci_hal_get_link_status()（具体接口名以所用SDK版本为准）。拿到连接间隔和监督超时后，就能估算当前还有多少时间可以安全做Flash操作。
一个保守的判断逻辑：
- 获取当前连接间隔
conn_interval和监督超时supervision_timeout。 - 计算出单次Flash操作的最大允许时间，比如页擦除需要约
T_erase毫秒。 - 如果
T_erase远小于监督超时，并且能保证在下一个连接事件到来之前完成，就执行；否则推迟到下一个连接间隔再试。
实际做的时候，我还会配合L2CAP连接参数更新请求aci_l2cap_connection_parameters_update()调整连接参数。比如在需要批量写Flash前，临时请求把连接间隔从15ms放宽到50ms，给链路层留出更多空闲窗口，写完再调回来。这个方法很有效，但代价是连接带宽下降、数据延迟变大，不能频繁使用，否则会影响正常业务。
还有一个更精准的窗口计算方式：用协议栈提供的系统Tick获取当前距离下一次连接事件的时间，如果这个剩余时间大于“Flash操作时间+余量”，就执行操作；否则直接放弃本轮。这样可以在不调整连接参数的情况下，尽量把Flash操作塞进连接事件间隙里。
2.4 方案四：用NVDS替代裸Flash操作
很多场景下，用户根本不需要直接操作Flash，用NVDS就够了。NVDS是协议栈维护的非易失数据区，用来保存设备地址、绑定信息、配对密钥等。同时它向用户开放了一批槽位，可以存自定义参数。
BlueNRG SDK里提供了NVDS读写接口，用法大致如下：
#define USER_NVDS_ADDR 0x10 #define USER_NVDS_SIZE 64 uint8_t buf[64]; uint16_t len = USER_NVDS_SIZE; /* 读取用户NVDS数据 */ GetNvdsUserData(USER_NVDS_ADDR, len, buf); /* 更新数据后写回 */ buf[0] = 0xAA; WriteNvdsUserData(USER_NVDS_ADDR, USER_NVDS_SIZE, buf);NVDS的好处是内部处理了擦写对齐、数据管理和掉电保护逻辑，你不需要关心底层哪一页要擦、哪一页要写。它本身也是一次Flash操作，但通常针对小数据量做了优化，阻塞时间比直接整页擦除要短。
局限是用户槽位有限，单槽容量一般不大（常见为64字节级别，具体见SDK头文件定义），不适合存日志或大块二进制数据。如果你的存储需求就是保存几十字节配置参数，NVDS是最省心的选择，完全不用自己写Flash调度器。如果数据量超过NVDS能力，再考虑自管理Flash区域，或者干脆外挂一颗SPI NOR Flash。
这四种方案不是互斥的，在一个实际产品里经常组合使用。比如：配置参数用NVDS保存，运行日志用自管理Flash区域，大块固件数据走外挂存储。我建议先明确自己的数据量、写入频率和掉电安全要求，再决定用哪一层方案。
下表是四种方案的对比：
| 方案 | 实现复杂度 | 实时性风险 | 适用场景 |
|---|---|---|---|
| 主循环空闲窗口 | 低 | 中 | 未连接状态、写入频率低 |
| 拆写不拆擦 + 状态机 | 中 | 低 | 连接态下写日志、参数频繁更新 |
| 连接间隔感知调度 | 中高 | 低 | 连接态批量数据写入 |
| NVDS | 低 | 低 | 小容量配置参数存储 |
3. 实操：写一个带状态机的Flash写入调度器
3.1 调度器的数据结构与状态机设计
在正式项目里，我最终采用的是“状态机 + 可让出”的Flash调度器。状态机的好处是：每次操作只做一小步，做完就退出，由主循环决定是否继续；中间随时可以被BLE事件打断，断了下次接着做；而且状态可读、可诊断，出问题能定位是卡在擦除还是卡在写入。
定义如下数据结构：
typedef enum { FLASH_OP_IDLE = 0, FLASH_OP_PENDING, FLASH_OP_ERASE, FLASH_OP_WRITE, FLASH_OP_VERIFY, FLASH_OP_DONE, FLASH_OP_ERROR } flash_op_state_t; typedef struct { flash_op_state_t state; uint32_t dst_addr; const uint8_t *src_data; uint32_t length; uint32_t offset; uint32_t erase_page_count; } flash_op_t; static flash_op_t g_flash_op;状态转换逻辑：
- IDLE：没有待处理任务。
- PENDING：有一笔Flash操作请求进来了，还没开始执行。
- ERASE：执行页擦除阶段。擦除完成后进入WRITE。
- WRITE：逐字写入数据，每次只写一个word，写完检查BLE事件，如果有事件就主动让出。
- VERIFY：写入完成后回读校验，确保数据正确。
- DONE：操作成功完成。
- ERROR：擦除或写入失败，进入错误处理。
之所以单独设置PENDING而不是在IDLE里直接执行，是为了把“请求操作”和“执行操作”解耦。比如你在BLE事件回调里想写数据，回调里只需要登记状态，不需要立刻执行Flash操作，这样天然避开了在回调里阻塞协议栈的问题。
3.2 主循环集成与调度优先级
调度器在主循环里的位置很关键。我自己的规则是：BLE事件处理优先级最高，用户普通任务其次，Flash操作排最后。每次flash_scheduler_tick()执行前都会先问一句“现在允许操作Flash吗”，不允许就返回，让主循环继续跑。
while (1) { /* 1. 优先处理BLE协议栈事件 */ while (BLE_EvtRx()) { HCI_Event_Processing(); } /* 2. 用户应用任务 */ user_app_task(); /* 3. 如果有待写数据，注册Flash操作请求 */ if (user_data_dirty && g_flash_op.state == FLASH_OP_IDLE) { flash_op_start(USER_DATA_FLASH_ADDR, user_data_buf, user_data_len); } /* 4. 执行Flash调度器的一小步 */ flash_scheduler_tick(); }flash_op_start()只是把数据结构初始化并置为PENDING，不做任何实际Flash操作：
void flash_op_start(uint32_t dst, const uint8_t *src, uint32_t len) { if (g_flash_op.state != FLASH_OP_IDLE) return; g_flash_op.dst_addr = dst; g_flash_op.src_data = src; g_flash_op.length = len; g_flash_op.offset = 0; g_flash_op.state = FLASH_OP_PENDING; }真正的执行逻辑放在flash_scheduler_tick()里，每一步之前都检查"是否允许继续"：
static int flash_can_proceed(void) { if (BLE_EvtRx()) return 0; /* 如果连接是激活的，检查距下一个连接事件是否足够远 */ if (conn_active && conn_remaining_time < SAFE_MARGIN) return 0; return 1; } void flash_scheduler_tick(void) { if (g_flash_op.state == FLASH_OP_IDLE) return; if (g_flash_op.state == FLASH_OP_PENDING) { g_flash_op.state = FLASH_OP_ERASE; } if (!flash_can_proceed()) return; switch (g_flash_op.state) { case FLASH_OP_ERASE: /* 整页擦除，一次性完成，不做拆分 */ for (uint32_t i = 0; i < g_flash_op.erase_page_count; i++) { FLASH_ErasePage(g_flash_op.dst_addr + i * PAGE_SIZE); } g_flash_op.state = FLASH_OP_WRITE; break; case FLASH_OP_WRITE: /* 每次只写一个字，写完立刻退出 */ FLASH_Program(g_flash_op.dst_addr + g_flash_op.offset, g_flash_op.src_data + g_flash_op.offset); g_flash_op.offset += 4; if (g_flash_op.offset >= g_flash_op.length) g_flash_op.state = FLASH_OP_VERIFY; break; case FLASH_OP_VERIFY: /* 回读校验，可选择在WRITE阶段分段校验 */ if (memcmp((void *)g_flash_op.dst_addr, g_flash_op.src_data, g_flash_op.length) == 0) g_flash_op.state = FLASH_OP_DONE; else g_flash_op.state = FLASH_OP_ERROR; break; default: break; } }注意这里的FLASH_ErasePage和FLASH_Program是SDK底层驱动的抽象命名，实际函数名要看具体SDK版本，但功能是对应的。flash_can_proceed()里的conn_remaining_time来自连接参数和系统Tick的推算，如果拿不到精确时间，最简单的保守策略是：只要BLE_EvtRx()有事件就立即让出。
这个调度器看起来简单，但解决了实际项目里90%的互斥问题。剩下10%是页擦除这种不可拆操作，必须在更宏观的窗口里统筹。
3.3 时间边界：不同数据量的Flash操作对连接的影响
做调度器之前，必须清楚每种Flash操作到底要花多久。BlueNRG-1/2的典型时序（具体数值以数据手册为准）：
- 字编程（32位）：几十微秒量级，典型约60µs。
- 页擦除（一个page）：典型约20~40ms量级。
- 读操作：正常取指速度，不构成阻塞。
以这些典型值为基准，做一些粗略估算：
写64字节参数：
- 如果使用NVDS，底层通常先擦后写，整体阻塞时间可以控制在几毫秒到几十毫秒级别。
- 如果裸写Flash：64字节 = 16个字，编程时间约1ms；如果之前还要擦一页，再加约20~40ms，总阻塞约21~41ms。
写1KB数据：
- 1KB = 256个字，编程时间约15ms；加一页擦除约40ms，总计约55ms。
- 如果连接间隔是30ms，这已经跨过两个连接事件了。
写4KB数据（跨4页）：
- 擦除4页约160ms，编程约60ms，总计约220ms。
- 这种操作如果发生在连接态，不提前调整连接参数或设计分时写入，基本等于主动断链。
把这些数值放进BLE时间尺度里看：连接间隔30ms，监督超时4s时，几十毫秒的阻塞虽然不会立即断链，但会造成持续的丢包和重传，功耗也会上去；监督超时缩到1s以下时，单次超过100ms的阻塞就非常危险了。
所以我的工程建议是：
- 小参数更新（几十字节）：用NVDS，或等待空闲窗口一次写入。
- 日志批量写（几百字节到几KB）：用状态机拆写，每次写一个字，并在两次写入之间穿插BLE事件处理。
- 大块数据更新（几十KB以上）：不要硬在应用层裸写内部Flash，优先考虑外部SPI NOR Flash或者专门的OTA/DFU流程。
3.4 掉电保护与存储布局设计
Flash操作最怕的是写入过程中掉电。页擦除到一半断电，这页数据处于不确定状态；写入到一半断电，数据可能半旧半新。如果产品有掉电保存需求，存储布局必须做冗余设计。
我常用的存储布局是“双槽 + 有效标志”：
| 区域 | 内容 |
|---|---|
| Slot A | 数据块 + CRC32 + 版本号 |
| Slot B | 数据块 + CRC32 + 版本号 |
| Valid Flag | 记录当前哪个Slot是有效的 |
写入流程：
- 把新数据写入当前非活动Slot（比如当前有效是A，就写B）。
- 写完后读回校验，确认数据无误。
- 更新Valid Flag指向新的Slot。
- 最后擦除旧Slot，留作下次使用。
这样即使写入过程中掉电，旧Slot依然保留完整数据，下次上电时通过Valid Flag和CRC判断哪份数据可用。代价是Flash用量翻倍，但可靠性收益很大。
另外一个细节：我自己调试时经常踩的坑是“写完忘记校验”。Flash写入偶尔会因为电压波动、调试器侵入等原因失败，如果不做回读校验，等到设备运行起来才发现配置是坏的，排查成本会很高。所以VERIFY阶段不能省，哪怕只是对关键数据做校验。
4. 实测中的常见问题与排查技巧
4.1 连接态下擦写导致断链
现象：设备连接正常，一旦触发Flash操作，几秒后手机侧提示连接断开。用BLE分析仪抓包，断链原因大多是Supervision Timeout。
排查思路：
- 先确认Flash操作实际耗时。在Flash擦写函数前后用GPIO翻转配合逻辑分析仪测量，看阻塞时间真实是多少。
- 抓取设备当前连接参数，看连接间隔是否过短、监督超时是否过小。
- 检查Flash操作是不是发生在协议栈事件处理路径上（比如某回调函数里）。
解决方案：把Flash操作移到主循环空闲调度器里；如果数据量较大，按2.3节的方法先调大连接间隔，给系统留出余量；或者改小擦除页数量，分多个周期完成。
4.2 广播/扫描业务被Flash操作打乱
现象：设备处于广播模式，手机扫描时设备时有时无，或者广播数据更新不及时。
原因：广播事件同样有严格时间要求，如果Flash操作正好占用广播发送时刻，广播包会被推迟甚至丢弃。广播间隔较短时（比如20ms），40ms的页擦除足以让连续好几个广播包全部丢失。
实践经验是：广播模式下做Flash操作前，先确认广播间隔是否足够大。如果广播间隔是100ms，单次几十ms的阻塞还可以容忍；如果广播间隔很短，就需要把Flash操作拆到两次广播事件之间，或者降低广播频率换存储窗口。另一个偏方是把广播数据先暂存到RAM，Flash操作完成后再重新启动广播并更新数据，但这个方法要看业务是否能接受广播暂时中断。
4.3 在协议栈事件回调里直接操作Flash
现象：在连接断开回调、GATT写回调等协议栈事件处理函数里直接调用Flash擦写，轻则卡顿、重则死机。
原因：协议栈事件回调运行在协议栈上下文中，回调里耗时过长会阻塞后续协议栈处理。Flash操作在硬件层面阻塞CPU取指，等于把协议栈按了暂停键，等它恢复时链路层状态已经乱了。
正确做法：回调里只置标志位，比如g_flag_need_save = 1，然后返回。主循环检测到标志后，注册一次Flash操作，由调度器执行。这是把互斥问题从架构上解决，而不是靠运气。
4.4 Flash寿命与频繁写入问题
现象：设备运行几个月后，配置参数写不进去了，或者写入后读出来数据不对。
原因：片内Flash有擦写寿命限制。如果应用层频繁写日志、频繁更新参数，很容易在某一个固定存储区域反复擦写，导致该区域提前达到寿命上限。典型寿命次数因芯片而异，但“10k~100k次”这个量级对某些高频写入场景是不够的。
排查和处理：
- 用调试器读取Flash操作失败时的错误寄存器，确认是不是擦写超时或失败。
- 检查代码里是不是每次数据变化都立即写Flash，能否通过RAM缓存、定时批量写入来降低写频率。
- 规划磨损均衡：不要固定写同一个页，轮流使用多个页，避免单个区域集中老化。
- 如果日志数据量很大、写入频繁，外部SPI NOR Flash或者小容量EEPROM是更合理的选择。
4.5 排查思路速查表
| 症状 | 优先排查项 | 推荐处理 |
|---|---|---|
| 连接态Flash操作后断链 | Flash操作真实耗时、连接监督超时、回调路径 | 移到空闲调度器，拆写，必要时调大连接间隔 |
| 广播时扫描不到设备 | 广播间隔、Flash操作与广播事件重叠 | 增大广播间隔，广播事件外执行Flash操作 |
| 回调里操作Flash后死机 | 协议栈事件回调里是否出现耗时操作 | 回调置标志，主循环统一处理Flash请求 |
| 数据写入后读回异常 | 是否有校验、掉电是否发生在写入中 | 增加CRC校验，双槽备份，掉电前延时保持供电 |
| 写失败但代码没有报错 | 是否只写不校验、是否忽略错误寄存器 | VERIFY阶段回读校验，检查Flash错误标志 |
再补充一句调试经验：不要在设备运行过程中用调试器发起额外的Flash擦写或下载操作。运行时调试器的侵入可能触发Flash控制器状态错乱，出现类似“flash download failed”或“cannot access memory”这类错误。调试阶段的烧录和运行时的Flash操作要分开看待，前者芯片还没跑BLE协议栈，不存在互斥问题；后者才是这篇笔记讨论的范畴。
最后说一点实际体会
花了大半篇幅讲代码和参数计算，其实最后真正让我受益的是一种意识：在这类单核BLE SoC上，Flash操作不是“写个函数调一下就完事”的普通外设操作，它自带一个几十毫秒的阻塞窗口，会直接影响链路层实时性。无论是用NVDS、状态机调度、连接参数调整，还是外挂存储，核心思路都是让Flash操作“避让”BLE事件，而不是和它抢CPU。
我个人现在的做法是：能用NVDS绝不用裸Flash，必须用裸Flash一定会加双槽备份和CRC校验，凡是超过一页的数据写入都会走调度器而不是直接塞在主流程里。如果再有连接不稳定的反馈，第一步不是改天线，而是先把Flash操作的时序拖出来看一遍。希望这篇笔记对你有用，也欢迎按自己的场景调整调度器参数——它本身就是一个很灵活的基础框架。
