接到这个项目标题时我第一反应是它到底指的是“主动停止视频播放”的软件流程还是“播放过程中画面突然停住”的异常Bug这两件事在 STM32U5G9ZJT6Q 上我都遇到过而且都不是表面看起来那么省心。U5G9 这颗料本身很有特色——Cortex-M33 内核、NeoChrom GPU、硬件 JPEG 编解码器、LTDC 加 MIPI DSI 全都在一颗低功耗芯片里视频显示链路的能力远超传统印象里的 MCU。但也正因为外设多、链路长Video Stop 这个问题牵扯出来的往往不是一个中断标志那么简单可能是时序没配好可能是 PSRAM 带宽被抢了也可能是缓存一致性问题在特定帧率下才会暴露。这篇文章把 U5G9 上关于 Video Stop 的两层内容都拆开讲一是应用层主动停止播放时的正确收尾顺序二是播放中无故定格时怎么系统性地排查。适合正在用 U5 系列做 GUI 或视频显示、以及从 F4/H7 迁移过来被图形链路折腾的人参考。我会把硬件架构、配置思路、调试方法和踩坑记录都写出来尽量让刚接触的人也能直接照着做。1. 先搞清楚 U5G9 在视频链路里的位置1.1 这颗料到底是什么定位STM32U5G9ZJT6Q 属于 STM32U5 系列的高配型号Cortex-M33 内核主频最高 160MHz片上带 2MB Flash 和 2.5MB SRAM。很多人一看到“低功耗”三个字就把它归类到“跑跑传感器、做做屏保”的档次实际拿到手册才发现完全不是这么回事——U5G9 内置了 NeoChrom 图形加速器GPU、硬件 JPEG 编解码器、LTDC 显示控制器、MIPI DSI 主机接口还有一组完整的 DMA2D。这个外设组合放在几年前是 H7、MP1 才敢想的配置。我当初拿到这块板子的第一反应是ST 这是把一条完整的视频显示链路塞进了低功耗产品线。这也意味着凡是涉及视频播放、动画转场、图像缩放混合一类的工作U5G9 都有对应的硬件单元可以接手CPU 只要做调度。但多硬件单元协作也带来一个代价——任何一个环节配置不对画面就可能出现奇怪现象Video Stop 就是其中最常见的一组表现。1.2 视频从文件到屏幕的完整链路要理解 Video Stop先要在脑子里画一条数据通路。以播放 JPEG 图片序列或者 MJPEG 视频为例数据流大概是这样的从 Flash、SD 卡或者外部存储读入 JPEG 压缩数据送入硬件 JPEG Codec 解码输出 YCbCr 或 RGB 像素数据经过 DMA2D 或 NeoChrom GPU 做颜色格式转换、缩放、旋转、Alpha 混合最终写入显示缓冲区LTDC 按行扫描读取显示缓冲区内容数据通过 MIPI DSI 接口发送给屏幕面板逐行逐帧刷新。这条链路上每一步都有 DMA 参与Buffer 可能放在片内 SRAM也可能放在外部 PSRAM。于是问题来了只要其中一级的 DMA 传输出现延迟或者失败LTDC 读不到数据FIFO 一空面板就会停住。STM32 没有 GPU 那么高级的“画面冻结自动恢复”机制这类情况多数表现为 Video Stop。2. 视频中途“定格”的五种典型原因2.1 JPEG 解码超时硬件解码器不会给你报错先说一个最容易踩的坑U5G9 的 JPEG 硬件编解码器很强大但它不会像软件解码那样在帧头帧尾出问题时给你一个清晰的返回值。实际表现往往是 HAL_JPEG_Decode_DMA 一直转或者解码回调迟迟不来然后你的播放任务还在傻等屏幕上自然就是上一帧的静态画面看起来像 Video Stop。我排查过一个现象同一张 JPEG 图在板子上交替解码有时一帧就出图有时要十几帧才出一次。最后定位到问题是 JPEG 数据的输入缓冲区被后续任务覆盖了——硬件解码器读数据是异步的DMA 可能还没搬完软件就把这块内存拿去写新数据了。这不是算法问题而是同步问题。经验是JPEG 解码的输入 Buffer 在解码完成之前绝对不能被复用解码完成标志一定要以 JPEG 的 End of Decode 中断或回调为准不能以自己计算的时间为准。好多新手在这里贪性能提前复用 Buffer结果就是播放流程随机停帧非常难查。2.2 PSRAM 带宽被抢LTDC 刷新吃不满视频图像数据通常放外部 PSRAM通过 OctoSPI 接口访问。这里有个容易被忽略的带宽问题。做一个简单估算720p1280x720分辨率、RGB565 格式、30fpsLTDC 持续读屏需要的带宽是1280 x 720 x 2 字节 x 30 x (1 消隐比例约 15%) ≈ 63MB/s这个数字已经不小了。如果外部 PSRAM 跑的是普通 SPI 模式非 DDR实际有效带宽通常只有理论值的 60% 到 70%一旦某帧写入、JPEG 解码读取、DMA2D 读写这些操作同时压在 PSRAM 上LTDC 的读取请求就会被挤到后面FIFO 在下一次行刷新前来不及填满画面就会停一帧甚至卡住。排查思路是看 PSRAM 的接口模式配置。U5G9 的 OctoSPI 接口最好配置成 8 线 DDR 模式日常跑 100MHz 到 133MHz这样理论带宽能到 200MB/s 以上才给视频链路留出足够余量。我之前见过一份工程代码PSRAM 配置成 Single SPI 模式图片多的时候 CPU 占用率直接飙到 80%视频基本没法播。2.3 LTDC FIFO underflow 与 Layer 配置错误LTDC 内部有个 FIFO专门做行数据的缓冲用来平滑总线读取延迟。如果总线带宽不足FIFO 里的数据被消耗完LTDC 就进入 underflow 状态屏幕会停止刷新或者出现一块一块的“花屏残影”。在 U5G9 的 HAL 库中LTDC_IRQHandler 默认的 Line Interrupt 一般大家都会开但 FIFO underflow 相关的状态位很少有人去检查。我建议在调试阶段把 LTDC 的全局中断打开在中断回调里读取 LISRLTDC Interrupt Status Register一旦看到 CFIFUND 位置位就说明显示数据供应确实出了问题而不是程序逻辑卡死。还有个常见问题LTDC Layer 配置错误也会表现为画面静止。比如你启动了 Layer1但 Layer0 的全局透明度设成了全透明画面看起来就像什么都没有——但屏幕本身是实时刷新的只是你什么都看不到。这种“看起来停住”的假象特别容易误导人。2.4 MIPI DSI 在低功耗模式切换时掉链子U5G9 走 MIPI DSI 接口驱动屏幕时还有一个独特的坑DSI 控制器在进入和退出低功耗模式LP Mode时时序非常敏感。正常流程是 DSI 先从 HS高速模式切到 LP低功耗模式然后主控发送 DCS 命令比如 Sleep In、Sleep Out再切回 HS 模式继续传像素数据。如果你在代码里只在初始化和结束播放时各调用一次那些 DSI 命令函数播放中间一旦某个命令没发完整或者 GPIO 电平配错面板可能就停留在某个奇怪状态后续像素数据发过去它也不刷新。这种问题最坑的地方在于它不是每次都必现而是看 DSI 物理层时序的微小漂移可能跑十分钟才出现一次画面定格非常难复现。处理办法是确定你用的面板芯片手册把 Sleep In、Sleep Out 之后的延时参数按手册严格写不要在 CubeMX 里随便填一个值就完事。2.5 双 Buffer 撕裂被误认为“卡死”还有一种情况画面在停与动之间极快地抖动但人眼看起来更像“卡住不动”。这通常是双缓冲切 Buffer 时出了问题。U5G9 的 LTDC 支持基于中断的行同步切换显示 Buffer。常见做法是LTDC 进入 VBLANK 中断后软件把 LTDC_LayerxCFBAR 寄存器改成新一帧的地址。如果切换时机没对准或者 LTDC 正在扫描中间时改了地址硬件可能读到一半新 Buffer 一半旧 Buffer 的数据形成撕裂。撕裂一般表现为画面割裂但如果你的 Buffer 地址配置刚好播到了同样的内容撕裂会表现出来“画面偶尔跳一帧”再叠加播放速度偏差就容易被误判为 Video Stop。这种问题要结合帧计数、Buffer 地址一起看不能光盯着屏幕。3. 排查 Video Stop 的方法与工具3.1 让错误“开口说话”中断挂钩子排查 Any Video Stop 的第一步是让所有可能出问题的外设把异常告诉你而不是让它们静默地卡住。U5G9 上至少要把下面几类中断的 Error 回调都挂出来JPEG 错误中断包括解码格式错误、DMA 传输错误等MIPI DSI 中断DCS 命令未完成、PHY 状态异常、ECC 错误LTDC 中断FIFO underflow、行同步丢失DMA2D 错误中断访问越界或传输冲突。我在调试初期会在每个中断回调里往一个环形缓冲区写一条记录包括中断源、当前时间戳、当前帧号。这样发生 Video Stop 后按一下复位键从环形缓冲区读最后几条记录就能判断问题发生在哪一级。这一步非常重要因为很多 Video Stop 是瞬时性的你来不及实时观察必须有日志。3.2 Dump 现场停帧时刻的寄存器值如果日志里能看到是 LTDC 或者 DSI 的问题下一步是读寄存器。U5G9 的 HAL 库虽然提供了不少读函数但排查时还是直接读寄存器最直观。我个人会在故障中断里做这样一件事void Error_Dump_On_Stop(void) { uint32_t ltdc_isr LTDC-LISR; uint32_t dsi_isr DSI-ISR; uint32_t jpeg_isr JPEG-SR; printf([VideoStop] LTDC ISR0x%08lX\r\n, ltdc_isr); printf([VideoStop] DSI ISR0x%08lX\r\n, dsi_isr); printf([VideoStop] JPEG SR0x%08lX\r\n, jpeg_isr); printf([VideoStop] Frame%lu, PSRAM_RD%lu\r\n, g_frame_index, g_psram_read_cnt); }这些寄存器值其实已经告诉你答案了。比如 LTDC ISR 里如果 CFIFUND1那就是带宽问题DSI ISR 里如果出现 PHY 错误那就去查 DSI 时钟配置。不要一上来就猜代码逻辑先把故障现场固定下来。3.3 变量法的局限加 printf 和不加打印表现不一样做嵌入式显示开发最烦的一件事某个问题打印调试信息时总不复现把 printf 去掉就频繁复现。这是典型的时序敏感型 Bug——printf“消耗了时间”恰好让某个等待条件满足了问题就消失。所以在 U5G9 的视频链路调试中我建议不要在关键路径上打大量日志尤其是 LTDC 的 VBLANK 中断和 JPEG 解码完成回调里严禁直接调用 printf。我一般会做一个“GPIO 标记波”手段在关键时间点拉高某根 GPIO另一根 GPIO 拉低用逻辑分析仪抓波形看各环节的时序是否正确对齐。这种方法不打断时序又能精确到微秒级定位问题。4. 实操把视频链路调稳的七步配置4.1 第一步时钟树里先把像素时钟算准一切视频显示问题都可以追溯到时钟。U5G9 内部 PLL 可以生成 LTDC 需要的 Pixel Clock你需要先算清楚目标分辨率和刷新率对应的像素时钟再反推 PLL 配置。以一个 720x720 的圆形屏、60fps 为例像素时钟 ≈ 720 x 720 x 60 x 1.2porch 余量≈ 37.3MHz这里我习惯在 CubeMX 时钟树里直接把 LTDC Pixel Clock 配置到 40MHz 左右留一点点余量。LTDC 的 PLL 是从系统时钟链里分出来的改系统时钟会影响其他外设所以先想好用哪个 PLL 输出再动参数。我的经验是用 PLL1 的 Q 输出专门给 LTDC这样调试播放器时改频率不会把 JPEG 和 Flash 的时钟搞乱。算完之后在 CubeMX 里核对生成代码中 PLL 的 N/M/R 参数实际测量 Pixel Clock 是否等于理论值。没有示波器也没关系可以通过 LTDC 的当前计数器配合一个定时器验证刷新率如果刷新率和理论值差太多说明时钟树配置有误。4.2 第二步PSRAM 时序和接口模式必须选对U5G9 外接 PSRAM 时我强烈建议优先选择支持 Octal DDR 的 PSRAM 颗粒并且把 OctoSPI 配置成 DDR 模式。就算你的应用只是简单 GUILCD 刷新也需要持续读内存Single SPI 模式在低分辨率下还能撑到视频播放一定扛不住。初始化 PSRAM 时注意三个参数读延迟Read Latency要根据 PSRAM 芯片手册算不要照搬 demo写延迟Write Latency同上错一个周期数据就全乱地址映射方式建议把 PSRAM 映射到 Cortex-M33 的地址空间的 Memory-Mapped 区域这样可以直接用指针读写不需要手动发命令DMA 也能直接操作。我踩过的一个坑PSRAM 初始化时读 ID 正常但跑一会儿就开始随机花屏。后来才发现是读延迟设得偏小高速访问时偶发不稳定而表面看起来就像 Video Stop。白折腾了好几天最后用示波器对比了 PSRAM 上 DQ 线的时序才发现是延迟窗口不够。4.3 第三步LTDC 时序务必按屏幕手册配置别猜LTDC 初始化时很多人对 Horizontal Sync、Vertical Sync、Back Porch、Front Porch 这些参数不太理解就直接用 CubeMX 默认值。这是一个非常高危的行为。每块屏的时序参数都不同默认值通常是某块特定开发板的参考值换屏之后刷新率和相位可能都不对。这些参数的作用我来解释一下它们定义了每一行扫描的空白区域让屏幕有时间调整行驱动。如果 Back Porch 太短面板还没来得及稳定就开始刷下一行如果 Front Porch 太短像素数据还没传完就进入消隐区。这些都会导致显示异常严重时就是画面停住。正确的配置方法很简单打开你的屏手册找到 Typical Timing 那一节把 VSYNC Width、HSYNC Width、VBP、VFP、HBP、HFP 全部老老实实填进 CubeMX。千万不要自己预估。4.4 第四步Buffer 策略与 MPU 缓存一致性视频播放时 Buffer 一般放在外部 PSRAM因为片内 SRAM 虽然大也放不下几帧 720p 图像。但用外部内存有一个躲不开的问题Cortex-M33 的 DCache 与 PSRAM 之间的一致性。如果 Buffer 区域被配置成 CacheableDMA 从 PSRAM 写入数据后CPU 读的时候可能读到 DCache 里的旧数据画面就出现随机陈旧帧。反之LTDC 从 PSRAM 读数据时如果 Buffer 数据还留在 DCache 里没回写硬件读到的就是旧内容表现出来就是画面不更新。我的做法是给视频 Buffer 所在的内存区配置 MPU 为 Non-cacheable或者 Write-Through 模式。U5G9 的 CubeMX 里可以单独配置 MPU Region把 OctoSPI 映射的内存区设为 Device 或 Strongly Order 属性。代价是 CPU 读写稍微慢一点但换来的是一致性。void MPU_Config_VideoBuffer(void) { MPU_Region_InitTypeDef MPU_InitStruct {0}; HAL_MPU_Disable(); MPU_InitStruct.Enable MPU_REGION_ENABLE; MPU_InitStruct.Number MPU_REGION_NUMBER3; MPU_InitStruct.BaseAddress 0x70000000; // 外部PSRAM映射基址 MPU_InitStruct.Size MPU_REGION_SIZE_16MB; MPU_InitStruct.SubRegionDisable 0; MPU_InitStruct.TypeExtField MPU_TEX_LEVEL1; MPU_InitStruct.AccessPermission MPU_REGION_FULL_ACCESS; MPU_InitStruct.DisableExec MPU_INSTRUCTION_ACCESS_ENABLE; MPU_InitStruct.IsShareable MPU_ACCESS_NOT_SHAREABLE; MPU_InitStruct.IsCacheable MPU_ACCESS_NOT_CACHEABLE; MPU_InitStruct.IsBufferable MPU_ACCESS_BUFFERABLE; HAL_MPU_ConfigRegion(MPU_InitStruct); HAL_MPU_Enable(MPU_CONTROL_PRIVILEGED_DEFAULT); }这段代码是一个基本框架实际使用时地址和大小按你的 PSRAM 映射来替换。这样配置之后DMA 和 CPU 访问视频缓冲区就统一了不会再出现“改了数据但画面不变”的诡异问题。4.5 第五步DMA2D 与 NeoChrom GPU 的配合视频数据在显示之前往往需要格式转换。JPEG 解码出来可能是 YCbCr 4:2:2屏幕需要的可能是 RGB565 或 ARGB8888这个转换交给 CPU 做太浪费U5G9 给了你两个选择DMA2D 或者 NeoChrom GPU。我的习惯是简单的格式转换、填充矩形、纯色背景这类操作直接用 DMA2D涉及 Alpha 混合、旋转、缩放这类较复杂的操作交给 NeoChrom GPU。原因是 DMA2D 配置简单、实时性好适合高频小任务NeoChrom 功能强但初始化复杂适合低频率大计算量的画面合成。这两者在同一帧画面里是可以同时使用的。比如 DMA2D 先把解码出来的 JPEG 数据从 YCbCr 转成 ARGB8888放入中间 Buffer再用 NeoChrom GPU 把多路 UI 图层和视频层混合输出到 LTDC。分工明确后CPU 基本只做业务逻辑和调度画面会稳定很多。4.6 第六步启动阶段的彩条自检写长视频播放代码前先写一个几行代码就能完成的彩条自检初始化 LTDC 和 DSI 之后让 LTDC 输出一屏固定颜色条纹不需要外设解码也不需要 DMA。如果彩条显示正确说明 LTDC 到面板的链路是通的接下来再加 JPEG 解码问题定位就缩小到解码端。如果彩条就不对别往下走先查 DSI 配置和 LTDC 时序。这个习惯救过我很多次否则一上来就是全部外设一起跑出了问题根本不知道往哪查。void LTDC_Test_ColorBars(void) { uint32_t colors[8] { 0xFFFF0000, 0xFF00FF00, 0xFF0000FF, 0xFFFFFF00, 0xFFFF00FF, 0xFF00FFFF, 0xFFFFFFFF, 0xFF000000 }; for (int i 0; i 8; i) { LTDC_Layer_Clear(0, colors[i]); } }运行后屏幕应该显示 8 个彩色色块。如果显示正常就说明 LTDC 与 DSI 的握手已经成功Panel 也在正常刷新后面解码、Buffer 的问题就能逐步排查。4.7 第七步设计一个播放状态看门狗最后一步是在软件上设计一帧播放的超时监控防止真出现 Video Stop 时系统无限期卡死。我习惯用一个 1ms 周期的系统 Tick每帧播放开始时记录当前帧号解码完成或显示切换时清零计数器如果超过预期帧间隔比如 300ms还没成功切换就打印日志并复位播放任务。这个看门狗不用做得很复杂但必须要有。它解决的问题是当 Video Stop 发生并且现场日志被覆盖你可以通过看门狗抛出的信息快速判断是“解码环节卡住”还是“显示环节卡住”避免测试人员只会复述“画面卡住了”而你只能干瞪眼。5. 主动停止 Video 的工程处理别硬断电5.1 为什么直接停止 HAL_JPEG_Decode_DMA 停不下来说完被动 Video Stop再说主动场景。播放中用户按了暂停或者退出很多人的第一反应是直接调用 HAL_JPEG_Decode_DMA 的停止函数。但实际你会发现硬件解码器可能正在处理当前帧的中间位置DMA 也正在搬运数据。直接停止后再启动新任务时 JPEG 内部状态机可能还停留在“上一帧未结束”的状态导致后续所有解码都异常。我建议不要直接依赖某个 HAL 函数停机而是自己维护一个简单的播放器状态机让各个硬件单元按顺序停下来。5.2 软件“软停止”流程推荐的状态机定义为四个状态Playing、Stopping、Stopped、Idle。用户触发停止时先把状态置为 Stopping播放任务检查当前帧是否已送入显示设置 Stopping 标志新的播放任务不再提交新帧等待当前 LTDC 正在显示的一帧走到 VBLANK在 VBLANK 中断里确认没有后续帧提交后停止 JPEG 解码等待 JPEG 解码的 DMA 完成或超时然后复位 JPEG 外设停止 DMA2D 或 GPU 的任务关闭 LTDC 和 DSI回到低功耗模式。这不是一步到位的但每个步骤都有明确的状态检查可以避免硬件外设处于中间状态。很多项目里你不做这个收尾直接停显示再进入睡眠模式就会发现唤醒后屏幕花屏、解码器报错都是因为这个“中间状态”没清理干净。5.3 面板断电的时序先 Sleep In 再关背光停止视频播放后如果还要关屏面板的时序比很多人想象的讲究。正确的是先通过 DSI 发送 Sleep In 命令让面板进入睡眠模式等面板响应完通常要几十毫秒再关闭背光最后才断电。如果顺序反了——先关背光再 Sleep In或者直接断电——面板可能没有完成内部状态保存下次开机时可能出现闪屏、残影、白屏、或者颜色偏色。这些现象看起来像是硬件坏了其实是时序问题。U5G9 上我用过几款不同品牌的 MIPI 面板Sleep In 的等待时间从 50ms 到 120ms 不等一定要以面板手册为准。6. U5G9 Video Stop 常见问题速查表现象可能原因排查步骤解决方案播放过程画面冻结偶尔恢复LTDC FIFO underflow在 LTDC 中断检查 CFIFUND提高 PSRAM 带宽、降低分辨率/色深画面完全停止无报错JPEG 解码 DMA 超时检查 JPEG SR、DMA 状态确保输入 Buffer 未提前复用增加超时保护画面随机花屏然后停住PSRAM 读延迟配置不当测 PSRAM 读写稳定性调整 Read/Write Latency 参数画面每次启动都白屏面板 Sleep Out 时序不对逻辑分析仪抓 DSI 命令时序按手册调整上电时序与延时停止播放后唤醒花屏主动停止顺序不对检查停止状态机按 VBLANK 等待、JPEG 复位、DSI Sleep In 顺序收尾视频首帧偶尔卡顿首帧 Buffer 未准备好检查首帧就绪标志首帧提交前保留黑色背景避免显示垃圾帧播放越久越卡内存泄漏或 DMA 描述符耗尽监控内存占用检查每次 DMA 传输的释放逻辑同屏多个图层时画面停GPU 或 DMA2D 同步失败打印各外设中断状态使用信号量同步各硬件任务这张表别只当速查我排查新问题时一般会先把现象归到某一列再决定往哪条链路走效率比漫无目的地看代码高很多。问题定位最怕的是“现象一句话、代码一万行”的情况有点方向性排查就快得多。7. 我在这颗芯片上踩过的几个坑最后分享几个不用环境复现也能避开的坑。第一个是 DMA2D 的传输完成事件和 LTDC 的 VBLANK 事件的先后关系。刚开始我在 DMA2D 传输完成中断里直接改 LTDC 的 Buffer 地址结果偶尔会出现画面撕裂。后来改成等 LTDC 进入 VBLANK 之后再做 Buffer 切换撕裂问题彻底消失。这个顺序设计在文档里写得比较隐晦实际踩过才知道。第二个是 printf 逗号可以导致问题“消失”。我碰到过一次把 printf 加进 JPEG 解码回调后Video Stop 怎么测都测不出来去掉 printf 就必现。后来才想到是 printf 消耗了时间恰好让某个等待条件满足。之后我将打印全部改为 GPIO 翻转加逻辑分析仪方案效率反而更高。第三个是 U5G9 的低功耗模式。播放视频时进去低功耗模式必须把外部 PSRAM 保持自刷新状态。这个动作如果放在 Sleep In 之后做唤醒时 PSRAM 数据会完好如果顺序反了PSRAM 可能掉数据唤醒后视频画面就是花的。项目里这两个操作我只调过一次顺序就把一个“休眠唤醒后必花屏”的问题解决掉了。第四个也是最想提醒大家的CubeMX 生成的代码只是“能跑”不是“跑得好”。LTDC、DSI、JPEG 这些外设的初始化参数中有很多和硬件强相关的细节CubeMX 不可能替你做产品级的适配。每一块屏、每一颗 PSRAM、每一版 PCB 布线都需要你自己去量时序、验稳定性。我见过太多人拿到 CubeMX 生成的工程改两行代码就以为自己调好了一上量产品就各种奇奇怪怪的问题。U5G9ZJT6Q 这颗芯片的视频链路能力是真的强但也要承认它把桌面级 SoC 才有的显示外设集成到了 MCU 上调试复杂度也跟着提升。我个人在实际项目中的体会是遇到 Video Stop先别急着改业务代码按照“时钟 - 内存带宽 - 缓存一致性 - 外设时序 - 状态机”的顺序一层层排查比来回试参数靠谱得多。上面这些方法和坑都是我实际在这颗芯片上验证过的。如果你的项目也卡在某个视频显示问题上不妨照着这套思路走一遍应该能省下不少时间。