最近在调一块基于ESP32-P4的HMI板子双核RISC-V跑到400MHz配的是MIPI-DSI接口的圆形屏。一开始图像变换全部压在CPU上旋转一张ARGB8888图标、做双线性缩放、叠加Alpha混合LVGL动画一到60fps就掉帧CPU占用直接飙到80%以上。后来我把这些像素级操作统一扔给PPAPixel Processing Accelerator像素处理加速器CPU占用压到了20%以内动画顺了系统也终于有空去处理网络和交互逻辑了。这篇文章就从PPA的原理讲起把驱动模型、实际调用步骤、以及我在这块板子上踩过的坑一次说清楚给正在用ESP32-P4做UI或者图像处理的朋友做个参考。1. 为什么ESP32-P4需要一块PPA1.1 从“UI把CPU吃光”说起传统MCU做UI图像处理全靠CPU逐像素算。一张320x320的ARGB8888图片旋转90度意味着对10万个像素做坐标重映射再加上双线性插值每个像素要读4个点、做加权平均。这种计算量在主频400MHz的RISC-V核上一次操作就是几毫秒如果UI动画里有多个图层同时在动CPU马上就满负荷。ESP32-P4虽然把主频拉到400MHz但它终究不是应用处理器不能指望靠高主频去硬扛图像变换。芯片里集成PPA的初衷很明确把“逐像素搬移和变换”这类高数据量、低逻辑复杂度的工作从CPU核里剥离出来让主核专心跑UI逻辑、协议栈和业务代码。这就好比做饭的时候切菜这种重复劳动不应该由大厨亲自做配一个专门的切菜师傅会快得多PPA就是那个切菜师傅。P4这颗芯片的定位是多媒体MCU它带了MIPI-DSI显示接口、MIPI-CSI摄像头接口还有2.5D GPU和PPA。2.5D GPU主要负责图形渲染加速比如填色、画线、纹理映射而PPA更像一个“图像搬运预处理”引擎专门处理像素数据在不同内存区域之间的搬移以及搬移过程中的格式转换、缩放、旋转、混合。两者配合使用UI链路才算完整。1.2 PPA在P4内部的数据通路PPA不是一个独立的处理器它是一个挂在芯片内部总线上的DMA外设核心能力是“从内存读一段像素做完变换后写回另一段内存”。它在P4里的位置大致是内存通常是大容量PSRAM→ PPA引擎 → 内存之后再由显示控制器或者其他DMA引擎把结果取走送入屏幕、编码器或者网络。这里有一个关键点PPA的输入输出都是缓冲区不是某个外设寄存器。这意味着它可以和任何东西配合比如把摄像头DMA写进内存的YUV帧用PPA转成RGB并缩放到屏幕分辨率再放进显示缓冲也可以把LVGL渲染好的图层通过PPA做Alpha混合后刷到屏幕上还可以在JPEG解码之后用PPA把解码出来的图像做旋转缩放再送显示。数据要么在内存里要么在往内存里写整个链路是“内存到内存”的。在实际工程里我通常把PPA的数据流分成三类显示链路输入前处理摄像头YUV数据转RGB、缩放、格式修正为显示或后续算法做准备。UI合成多个图层做Alpha混合实现透明度渐变、淡入淡出、全景图平移缩放。编码前处理图像旋转到目标朝向再交给H.264/H.265编码器减少编码器压力。这三类场景有一个共性如果要让CPU逐像素去做性能会很难看用PPA做CPU只负责配置参数和等待完成中断中间大块时间可以拿去跑别的任务。1.3 PPA到底能替CPU干哪些活PPA的功能集合可以理解成一个“带特效的DMA”它不像GPU那样可以跑任意shader但常见的2D像素操作基本都有硬件支。根据ESP32-P4参考手册和ESP-IDF驱动说明PPA支持的操作包括功能类别具体能力典型用途旋转90度、180度、270度横竖屏切换、摄像头方向修正镜像水平/垂直翻转自拍预览、UI镜像缩放最近邻、双线性图标放大缩小、缩略图生成Alpha混合前景与背景混合可配置混合模式UI淡入淡出、阴影、半透控件颜色格式转换RGB565 / RGB888 / ARGB8888 / YUV422 / YUV420等摄像头预处理、不同显示缓冲互转颜色键指定颜色透明抠图、精灵图透明处理填充用单一颜色填满矩形区域UI背景刷色、清屏拷贝数据搬运可带格式转换帧缓冲复制、截图注意PPA的操作对象是矩形区域不是任意的多边形。做复杂UI特效还是得靠2.5D GPU或者软件手段PPA负责的是那类“规则区域内的批量像素操作”。把工作切分清楚才能把P4多媒体的性能吃到最大。2. 核心细节解析与实操要点2.1 把PPA当成一个“图像DMA”来理解我第一次看PPA的驱动文档时觉得环节很多后来想明白一个类比就通透了PPA类似PC上显卡的DMA2D引擎或者单片机里的DMA控制器只是它搬的不再是连续字节而是“图像像素”。普通DMA搬运时源地址按字节递增目的地址按字节递增中间没有任何处理。PPA则要复杂得多源数据是一个二维矩形有宽度、高度、每像素字节数、行偏移stride目标可能旋转了90度意味着宽的映射到高、高的映射到宽而且每像素的字节格式可能也变了。PPA硬件内部把这些复杂索引和插值计算全部固化软件只要告诉它“源在哪、目标在哪、做哪个变换”剩下的搬运和像素计算都在硬件流水线里完成。这个类比的另一个价值在于理解延迟模型。PPA操作不是瞬间完成的它搬多大区域、做什么变换就有对应的处理时间。比如操作一块320x320的ARGB8888图片即使有硬件加速也需要几百微秒到几毫秒不等。驱动设计成异步模型提交操作后立刻返回后台DMA搬运完成后产生中断或者状态标志这样可以不阻塞CPU。2.2 必须搞懂的参数格式、尺寸、旋转、缩放、混合PPA操作的配置参数比较多但核心就是下面几个我按优先级逐个说。第一是颜色格式。PPA要求明确源和目标的颜色格式支持RGB565、RGB888、ARGB8888以及YUV422、YUV420等多种。这里最容易被忽略的是“行字节对齐”一个宽度为奇数像素的RGB565图像每行字节数可能是奇数硬件DMA按行读取时需要知道实际的行长度。ESP-IDF驱动里一般用pic_w和pic_h表示实际有效尺寸用buffer_w和buffer_h表示缓冲区的整行宽度两者不一样时行尾会有无效的padding字节。我在工程里就吃过亏摄像头采集是320宽对齐到328字节直接交给PPA后输出全部错位后来发现是没设置好行偏移。第二是旋转角度和缩放因子。旋转90度会让宽高互换所以配置目标缓冲区尺寸时要算清楚否则缓冲溢出轻则花屏重则踩坏相邻内存。缩放因子是浮点数硬件支持双线性和最近邻两种模式。双线性效果好但计算量大最近邻快但锯齿明显。对UI里的图标放大我一般选双线性对游戏精灵或者需要精准像素映射的场景选最近邻更合适。第三是Alpha混合。PPA混合操作涉及两个输入前景层和背景层。混合公式通常是output src * alpha dst * (1 - alpha)alpha可以来自前景图像自身的透明度通道也可以由外部配置一个固定透明度值。多数PPA驱动要求前景是ARGB8888格式因为透明度信息存在A通道里。如果源图像是RGB565又想整体半透明就得使用外部固定alpha值不能做到每个像素独立透明度。第四是颜色键。颜色键的意思是“指定某个颜色值在拷贝或混合时当作透明处理”类似绿幕抠图。配置时指定一个键值PPA在读取源像素时发现匹配该键值就跳过或者按透明处理。这个功能做UI贴图很方便可以避免给每个小图标做Alpha通道。2.3 地址对齐与Cache一致性新手最容易翻车的地方PPA通过DMA直接读写内存地址这带来两个硬性要求地址对齐和Cache一致性。我在这两个问题上栽过好几次跟头花了好多时间才定位出来。地址对齐方面PPA的输入输出缓冲区起始地址通常要求对齐到缓存线或者总线位宽在ESP-IDF里一般用MALLOC_CAP_DMA内存分配这个flag分配的地址和大小都会满足DMA访问要求。实际操作中我习惯把多个图像缓冲区统一分配在一块连续PSRAM里起点用heap_caps_aligned_alloc(64, size, MALLOC_CAP_SPIRAM | MALLOC_CAP_DMA)这样能确保64字节对齐既满足PPA要求也能减少后续cache操作时的额外开销。Cache一致性则要区分两种情况。如果缓冲区在内部SRAMCPU写过的数据可能还留在Cache里PPA使用DMA绕过Cache直接读内存读到的可能是旧数据。如果缓冲区在PSRAM虽然数据直接访问内存但CPU和外部RAM之间也可能存在Cache缓冲。因此在提交PPA操作之前需要对源缓冲区做一次“clean”操作把CPU Cache里新写的数据写回物理内存操作完成后对目标缓冲区做一次“invalidate”操作让CPU下次访问时重新从物理内存读取最新数据。ESP-IDF里对应的接口是esp_cache_msync。以我实际代码里的一个例子来说// PPA操作前把源数据从Cache刷到物理内存 esp_cache_msync(src_buf, src_size, ESP_CACHE_MSYNC_FLAG_DIR_C2M); // PPA操作完成并等待后让CPU重新读取目标内存 esp_cache_msync(dst_buf, dst_size, ESP_CACHE_MSYNC_FLAG_DIR_M2C);如果漏掉esp_cache_msync现象就是调度一次两次没问题跑一段时间后图像随机花屏、颜色错位而且是时好时坏。这种问题最难查因为不是必现。建议从一开始就把缓存操作写进统一的封装函数里不要让这个步骤依赖调用者自觉。2.4 驱动框架client、operation、回调ESP-IDF的PPA驱动不是简单的func_init func_process模式它采用了“客户端异步操作”的设计。第一次用的朋友可能会觉得绕我解释完就清晰了。驱动初始化后需要先注册一个client。类似的模型可以理解为线程池里的任务队列你的代码是“提交方”PPA引擎是“执行方”client就是你和引擎之间的通道。注册client时需要指定处理的操作类型、队列深度、中断优先级等参数。不同类型操作可以注册成不同client比如一个client专门做旋转缩放另一个做混合互不干扰也可以共用一个大队列由驱动自行调度。操作提交时调用esp_ppa_operation_start传入配置结构体驱动会把操作排入硬件队列然后立即返回一个操作句柄。之后你可以调用esp_ppa_operation_wait_done阻塞等待完成也可以注册完成回调在操作完成中断里做后续处理。这种异步模型对UI开发来说非常友好提交PPA处理一帧图像后CPU可以立刻返回去跑下一帧LVGL渲染两边并行帧率自然就上去了。用回调模式时我习惯在完成回调里发送一个任务通知让一个专门的任务做后续显示切换。不要直接在中断回调里做耗时操作这一点和所有MCU中断处理原则一致。3. 实操过程与核心环节实现3.1 环境准备IDF版本与menuconfig要跑PPA建议使用ESP-IDF v5.3以上版本PPA驱动在后续版本里逐步完善。我当前用的是v5.4分支接口相对稳定。工程配置上主要做两件事。第一是启用PPA驱动。在menuconfig里找到Component config - ESP PPA driver - Enable PPA driver把它打开。同时确认目标芯片是ESP32-P4并开启对应的PSRAM支持因为大多数图像缓冲区都会放在PSRAM里。如果用的是官方BSP或者特定开发板配置很多选项可能已经默认配好但仍建议手动检查一遍。第二是配置DMA内存选项。为了确保缓冲区可以同时被CPU和PPA的DMA访问我通常在menuconfig里把SPIRAM的malloc策略设置为允许MALLOC_CAP_SPIRAM分配这样应用程序和驱动层都能从外部RAM拿到可用缓冲区。内部SRAM虽然块但是容量小放几帧图像就不够了PSRAM容量大是图像缓冲的主要存放区域。如果是在自己的工程里集成还需要在idf_component.yml或CMake依赖里显式加入esp_driver_ppa组件。官方SDK里其实已经包含但如果做了裁剪务必加上否则编译时找不到esp_ppa.h头文件。3.2 最小示例旋转缩放一张ARGB8888图像下面这个示例是我实际工程里抽出的一小段做“旋转90度双线性缩放”的操作。它把一张320x240的ARGB8888图像旋转90度并缩放到240x320目标尺寸正好是一次典型的横竖屏切换。#include string.h #include freertos/FreeRTOS.h #include freertos/task.h #include esp_log.h #include esp_heap_caps.h #include esp_cache.h #include esp_ppa.h #include esp_ppa_operations.h static const char *TAG ppa_demo; static esp_ppa_client_handle_t s_ppa_client; static void ppa_client_init(void) { esp_ppa_engine_init(); esp_ppa_client_config_t client_cfg { .oper_type PPA_OPERATION_ROTATE_SCALING, .queue_size 4, }; esp_ppa_engine_register_client(client_cfg, s_ppa_client); } static void do_rotate_scale(void) { const uint32_t src_w 320, src_h 240; const uint32_t dst_w 240, dst_h 320; const size_t src_size src_w * src_h * 4; const size_t dst_size dst_w * dst_h * 4; // 分配DMA可访问缓冲区64字节对齐 uint8_t *src_buf heap_caps_aligned_alloc(64, src_size, MALLOC_CAP_SPIRAM | MALLOC_CAP_DMA); uint8_t *dst_buf heap_caps_aligned_alloc(64, dst_size, MALLOC_CAP_SPIRAM | MALLOC_CAP_DMA); if (!src_buf || !dst_buf) { ESP_LOGE(TAG, alloc failed); return; } // 这里模拟填充源数据实际工程中可能来自JPEG解码或LVGL渲染 memset(src_buf, 0x80, src_size); // 源数据从CPU视角写完后同步回物理内存 esp_cache_msync(src_buf, src_size, ESP_CACHE_MSYNC_FLAG_DIR_C2M); esp_ppa_rotate_scaling_mixer_cfg_t op_cfg { .input { .buffer src_buf, .buffer_size src_size, .pic_w src_w, .pic_h src_h, .buffer_w src_w, .buffer_h src_h, .color_type PPA_COLOR_TYPE_ARGB8888, }, .output { .buffer dst_buf, .buffer_size dst_size, .pic_w dst_w, .pic_h dst_h, .buffer_w dst_w, .buffer_h dst_h, .color_type PPA_COLOR_TYPE_ARGB8888, }, .rotation_angle PPA_ROT_ANGLE_90, .scaling { .x (float)dst_w / (float)src_h, .y (float)dst_h / (float)src_w, .mode PPA_SCALING_MODE_BILINEAR, }, .enable_mixer false, }; esp_ppa_operation_handle_t op NULL; esp_err_t ret esp_ppa_operation_start(s_ppa_client, op_cfg, op); if (ret ! ESP_OK) { ESP_LOGE(TAG, operation start failed: %s, esp_err_to_name(ret)); return; } ret esp_ppa_operation_wait_done(op, pdMS_TO_TICKS(1000)); if (ret ! ESP_OK) { ESP_LOGE(TAG, operation wait failed: %s, esp_err_to_name(ret)); return; } // 操作完成后确保CPU能看到最新的目标数据 esp_cache_msync(dst_buf, dst_size, ESP_CACHE_MSYNC_FLAG_DIR_M2C); ESP_LOGI(TAG, rotate scale done); heap_caps_free(src_buf); heap_caps_free(dst_buf); } void app_main(void) { ppa_client_init(); do_rotate_scale(); }这个例子有几处容易被忽视的细节。旋转90度后输出宽度应该等于输入高度输出高度应该等于输入宽度所以缩放因子的分子分母要对应好。如果配反了输出的宽高就变了目标缓冲可能溢出。enable_mixer表示这次操作是否要带混合这里我们只做旋转缩放所以置为false。如果要做混合还需要把mixer_cfg字段配好指定前景和背景两个输入源。整体跑起来后通过逻辑分析仪或者示波器看GPIO翻转时间能明显感受到主循环不再被长时间阻塞。PPA操作期间CPU可以去跑GUI刷新、触摸扫描或者网络任务这是整个设计最大的收益。3.3 实战在LVGL项目里用PPA做图标旋转动画前面说过用户搜“esp32-p4 ui 源码”的时候大部分是想在官方或社区的UI例程里找到这个加速器的用法。我以LVGL为例说明一下PPA和UI源码的结合方式。LVGL本身有软件实现旋转和缩放的API比如lv_img_set_angle、lv_img_set_zoom但软件实现要逐像素计算动画尺寸一大CPU就会吃紧。用PPA的思路是把LVGL需要旋转/缩放的图片先在后台用PPA处理好再把处理结果交给LVGL渲染。具体做法可以拆成几步。第一步准备一块PPA输出缓冲区作为“中转图像”。比如图标原始大小64x64动画时需要放大到128x128那就分配一块128x128的ARGB8888缓冲区。第二步在动画的每一帧或每隔几帧把原始图标通过PPA旋转和缩放到中转缓冲区。第三步把中转缓冲区作为一张图片用LVGL一次性绘制到屏幕上。因为PPA处理是异步的LVGL可以边渲染上一帧边让PPA生成下一帧。如果是官方移植好的工程通常能在sdkconfig.defaults里看到PPA相关配置项源码里也可能已经有封装好的PPA调用函数。拿到源码后我建议先搜索ppa关键字把初始化和client注册逻辑找出来然后在最基础的操作函数上打断点或者加日志确认通路是通的。然后再去改动画回调把PPA处理的结果送进LVGL。下面是动画回调中提交PPA操作的简化示意我把参数封装成一个结构体传给任务static void animation_timer_cb(lv_timer_t *timer) { // 根据当前动画进度更新旋转角度和缩放系数 esp_ppa_rotate_scaling_mixer_cfg_t cfg build_cfg(current_angle, current_zoom); esp_ppa_operation_handle_t op; if (esp_ppa_operation_start(s_ppa_client, cfg, op) ! ESP_OK) { return; } // 这里不要等太久可以注册回调之后在完成通知里刷新LVGL esp_ppa_operation_wait_done(op, pdMS_TO_TICKS(16)); esp_cache_msync(dst_buf, dst_size, ESP_CACHE_MSYNC_FLAG_DIR_M2C); lv_img_set_src(ui_img, lv_img_dsc_from_buf(dst_buf, dst_w, dst_h)); }这里有一个实际经验不要在LVGL的flush_cb里做PPA操作。flush_cb是显示驱动刷新回调它直接影响LVGL的渲染节奏如果在这里阻塞等待PPA会把整个渲染管线卡死帧率反而更差。正确做法是让PPA操作和LVGL渲染双缓冲并行LVGL往A缓冲画PPA往B缓冲处理下一帧图片处理完通过事件通知LVGL切换。如果要在自己的UI源码里加PPA支持可以参考这个分层思想UI层只管坐标、动画和事件中间层负责把“用户看到的图层”转化为“需要PPA处理的像素矩形”底层统一调PPA驱动所有缓冲区、cache同步、超时判断都在这一层处理。这样上层代码干净底层也能做统一优化。3.4 实战摄像头YUV转RGB并缩放另一个常见的PPA用法是摄像头数据处理。P4的MIPI-CSI接口能接摄像头但摄像头输出通常是YUV422或YUV420系列格式而显示和大部分UI库直接使用RGB。如果让CPU做YUV转RGB一帧1080p图像要转换约200万个像素每个像素都要做几次乘加运算主核基本就废了。用PPA做转换CPU只需要配置源格式和目的格式转换过程全在硬件里流水线完成。我的一个测试项目里摄像头输出1280x720的YUV422屏幕只有480x480可以用一次PPA操作同时完成YUV到RGB565的格式转换和缩小。操作配置和旋转缩放类似重点是把输入颜色类型设为PPA_COLOR_TYPE_YUV422输出设为PPA_COLOR_TYPE_RGB565然后设置缩放因子。注意YUV数据有固定的内存布局pic_w和buffer_w的关系要比RGB格式更小心尤其遇到YUV420的UV平面分开排列时行偏移配置错了图像颜色就会整体偏绿或偏紫。这样处理后摄像头预览的CPU占用几乎可以忽略主核还有余量跑人脸检测、UI叠加等任务。做这类项目时我强烈建议把PPA的输入输出缓冲区全部放在PSRAM并分配足够大的内存因为摄像头帧率一到30fps内存带宽需求非常可观。内部SRAM容量有限一旦内存碎片化后期就会频繁分配失败。4. 常见问题与排查技巧实录4.1 图像花屏、撕裂怎么查花屏是最常见的现象原因通常集中在三个方面。第一是缓存一致性问题。前面专门提到过如果源缓冲区刚被CPU写入就直接交给PPA读取没有做C2M同步PPA读到的是旧数据如果PPA写完后CPU直接读目标缓冲区没有做M2C同步CPU看到的可能是Cache里的旧内容。排查方法很简单先全流程不加esp_cache_msync跑一遍确认是否花屏再加上同步对比现象。如果加上同步后好了说明问题就在这里。第二是缓冲区地址对齐或大小不足。如果目标缓冲区分配得太小PPA写操作会越过边界踩到相邻内存不仅输出图像错乱还可能破坏其他任务的数据。用heap_caps_aligned_alloc分配并严格按照旋转后的宽高去计算大小能避免大部分问题。第三是行偏移配置错误。当pic_w不等于buffer_w时错误配置会让每一行的数据错位表现是一条条斜线或者颜色条纹。我把源图像填成红绿蓝三色竖条纹去测试一眼就能看出行偏移对不对。4.2 操作超时、卡死怎么解PPA操作超时主要原因可能是没有初始化、client没有注册、或者队列被占满。如果esp_ppa_operation_start返回错误先确认初始化函数是否真的执行如果是在某个任务里第一次调用就超时检查是不是没有给PPA操作注册中断。P4的PPA完成通知依赖中断机制如果中断被禁用或者优先级配置不对wait_done就会一直等下去。另一个容易忽略的情况是同一个client被多个任务同时使用。驱动内部虽然有队列但如果队列深度只有一个多个任务同时提交后面的请求会排队。实际工程中我把动画相关的PPA操作单独用一个client摄像头转RGB单独用一个client两者互不挤占。这样即使摄像头任务频繁提交操作UI动画也不会被堵死。调试时可以在每次操作后打印时间戳和返回值形成日志大致判断操作耗时是否异常。正常情况下一块320x240的ARGB8888旋转双线性缩放操作时间大概在几百微秒这个量级如果一执行就是几十毫秒多半是配置有问题或者DMA访问的Memory区域带宽异常。4.3 缩放锯齿、颜色偏色的处理锯齿多半是因为用了最近邻缩放。最近邻速度快但放大后马赛克明显。PPA支持双线性缩放效果会好很多。要注意的是双线性缩放耗时比最近邻高不少对性能敏感的场景需要在画质和帧率之间取舍。颜色偏色则要查三点。第一源数据和目标数据的颜色格式是不是真的匹配。ARGB8888的字节顺序是A、R、G、BRGB565的高低字节在不同编译器、不同库之间的排列也可能不同。第二YUV转RGB时是否指定了正确的色彩空间标准。摄像头常用的BT.601和显示常用的BT.709转换系数不同如果PPA内部按某个固定系数转换而你的图像是按另一个标准编码的颜色就会发灰或者偏色。第三Alpha混合时是否包含预乘Alpha信息。很多UI素材的Alpha通道并不是预乘的而某些硬件混合模式要求预乘Alpha颜色会边缘发暗。建议用纯色色块和半透明色块做基准测试逐步定位。4.4 和LVGL共用缓冲区的坑最后说一个和UI开发关系很大的问题PPA和LVGL共用缓冲区时的同步。LVGL渲染时会把draw buffer和flush buffer切来切去如果PPA正在处理某块缓冲区而LVGL同时又在往里面写新数据结果必然错乱。我的做法是给PPA单独划“工作缓冲区”不让它直接操作LVGL当前正在使用的draw buffer。需要一个横屏转竖屏结果时把LVGL已经渲染完的完整帧拷贝到PPA的输入缓冲区再让PPA旋转到目标缓冲区最后由显示驱动读取目标缓冲区。虽然多了一次拷贝开销但避免了复杂的同步逻辑工程上稳定得多。另外LVGL的flush回调里不要直接wait_done等PPA除非你确认整个渲染管线只有这一个显示任务。否则一旦等待时间超过LVGL的刷新周期就会出现帧率掉到一半甚至卡死的现象。正确做法是把PPA操作放在后台任务完成后再交换缓冲区。我在实际项目中最后养成了一个习惯每个PPA操作都封装成带超时和错误码的接口日志里把源地址、目标地址、宽高、颜色格式全部打出来。后续现场联调或者同事接手只要看到一行日志就能定位问题省了非常多时间。如果你也在P4上跑UI建议从一帧最简单的旋转开始把通路走通之后再叠Alpha混合和YUV转换。PPA本身不难难的是把你手里的数据链路彻底理解透包括格式、对齐、缓存这几关过了后面就非常顺畅了。