1. 项目概述一个被严重低估的“每日记录清单”其实是 FreeRTOS 系统健康度的终极仪表盘很多人看到“每日记录清单”这五个字第一反应是待办事项、打卡表格、手账本——但在这个嵌入式开发语境下它根本不是管理生活的工具而是你 FreeRTOS 项目里最沉默、最可靠、也最容易被忽视的“系统体检报告单”。我带过二十多个基于 STM32F4、GD32F303、TC387 的实时项目凡是稳定运行超过一年没出过偶发死机的无一例外都有一份雷打不动的“每日记录清单”而那些反复排查栈溢出、任务挂起、Tick 中断丢失的团队翻看他们的日志目录往往连一份连续三天的完整记录都没有。这份清单的核心价值从来不是“记了什么”而是“为什么能持续记下来”——它强制你暴露系统底层的真实状态CPU 负载是否在临界点徘徊Tick 中断是否被高优先级 ISR 长时间阻塞空闲任务是否真正在执行堆栈余量是否已跌破安全水位线这些信息不会出现在 IDE 的调试窗口里也不会在串口打印的“Task running…”提示中浮现它们只安静地躺在每天自动生成的文本行里2024-06-15 08:23:41 | idle: 92% | heap: 48.2KB | taskA_stack: 321B/1024B | tick_late: 0 | isr_max: 42us。它不教你怎么写xTaskCreate()但它会用连续七天的tick_late值告诉你你的 CAN 接收 ISR 里那句printf()正在把整个系统的实时性拖进泥潭。适合谁不是刚学完《FreeRTOS 快速入门教程》的新手而是已经能把vTaskDelay()写顺手、却还在为“偶尔重启”挠头的中级开发者是正点原子开发板上跑着 LVGL 图形界面、却搞不清为什么滑动列表时网络 socket 突然断开的工程师是 TC387 上启用 SMP 模式后发现两个核的任务调度节奏越来越不同步的系统架构师。它解决的不是“功能怎么实现”而是“系统为什么不可靠”这个更本质的问题。2. 清单背后的设计逻辑为什么必须是“每日”为什么必须包含这五项核心指标2.1 “每日”不是时间单位而是系统可观测性的最小可靠周期很多团队尝试做“实时监控”结果在串口上疯狂打印uxTaskGetStackHighWaterMark()每秒刷屏二十行最后发现不仅没定位问题反而因为printf占用大量 CPU 时间把原本轻微的负载问题放大成系统卡死。这里的“每日”设计本质是一次精心计算的取舍它放弃了毫秒级的瞬时快照换取了宏观趋势的可信度与工程落地的可持续性。我做过一组对比实验在 STM32F407 上以 10ms 间隔调用vTaskList()和vApplicationStackOverflowHook()并写入 Flash连续运行 72 小时后Flash 寿命损耗达额定值的 17%且因频繁擦写导致日志文件碎片化解析脚本崩溃三次。而改用“每日零点触发一次全量快照”配合环形缓冲区缓存关键事件如栈溢出告警、Tick 延迟超阈值Flash 每日写入量稳定在 1.2KB三年内无一例因日志写入导致的存储故障。更重要的是“每日”天然形成了一个分析锚点你可以清晰对比“昨天此时”和“今天此时”的heap余量变化判断内存泄漏是否存在可以拉出过去三十天的isr_max曲线识别出那个在温度升高后才暴露的硬件 ISR 延迟缺陷。这种时间粒度恰好落在人类运维响应周期小时级和芯片物理特性漂移周期天级的交界处既不过于粗糙失去预警价值也不过于精细增加系统负担。它不是偷懒而是对嵌入式系统“可观测性”边界的精准把握。2.2 五项核心指标的选取逻辑每一项都直指 FreeRTOS 最脆弱的神经这份清单绝非随意拼凑每一项都是从上百个潜在参数中筛选出的“高信息熵、低采集成本、强问题指向性”指标idle CPU 使用率它不是简单的100% - (taskAtaskB...)计算结果。FreeRTOS 的uxTaskGetSystemState()返回的是各任务运行时间占比但prvGetExpectedIdleTime()才是真相。我见过太多项目把configUSE_IDLE_HOOK里加个 LED 闪烁当“空闲任务在运行”结果实际idle占比只有 5%而开发者坚信系统很空闲。真正的idle率必须通过portGET_RUN_TIME_COUNTER_VALUE()在vApplicationIdleHook()中精确采样它直接反映系统是否长期处于高负载边缘——当连续三天idle 10%基本可以判定存在隐性资源争抢或算法效率瓶颈。Heap 剩余空间这里特指xPortGetFreeHeapSize()而非xPortGetMinimumEverFreeHeapSize()。后者是历史最低值对日常监控意义有限前者是当前瞬时可用空间结合每日快照能画出清晰的内存消耗曲线。我在 GD32F303 项目中曾发现heap从初始 64KB 缓慢降至 48KB 后停滞表面看没问题但深入检查发现是pvPortMalloc()分配的struct netconn对象未被netconn_delete()彻底释放导致内存池碎片化。若只看“最低值”这个缓慢泄漏会被完全掩盖。关键任务栈使用量必须指定具体任务如taskA_stack: 321B/1024B。全局uxTaskGetStackHighWaterMark(NULL)没有意义。我坚持要求团队为每个非空闲任务配置独立栈大小并在清单中显式列出其水位线。原因很简单configCHECK_FOR_STACK_OVERFLOW只能在溢出发生时触发钩子而uxTaskGetStackHighWaterMark()能让你在溢出前就看到风险。例如taskA栈设为 1024B某日记录显示987B/1024B这就是明确的扩容信号比等它真溢出再查HardFault_Handler快十倍。Tick 延迟次数tick_late这是configUSE_TICK_HOOK的延伸应用。标准 FreeRTOS 不提供 Tick 是否准时的信息但你可以修改xTaskIncrementTick()在每次 Tick 中断服务程序SysTick_Handler退出前用portGET_RUN_TIME_COUNTER_VALUE()记录实际进入时间与理论时间比对。若延迟超过configTICK_RATE_HZ周期的 150%即 1.5 个 Tick计数器tick_late加一。连续三天tick_late 0几乎可以锁定存在长时阻塞型 ISR 或高优先级任务霸占 CPU。最长 ISR 执行时间isr_max必须用硬件定时器如 STM32 的 DWT_CYCCNT在 ISR 进入和退出时采样而非软件计时。DWT-CYCCNT在 Cortex-M 系列上精度达 1 个 CPU 周期远超HAL_GetTick()。我曾在一个 TC387 SMP 项目中发现isr_max从常规的 25us 突然跳至 87us最终定位到是某次 CAN 总线错误帧处理时__disable_irq()范围过大意外阻塞了另一个核的中断响应。这个指标是穿透多核调度迷雾的唯一探针。提示这五项指标的采集必须全部在中断安全上下文中完成严禁在vApplicationIdleHook()中调用printf或f_write。所有日志数据先存入 RAM 环形缓冲区由低优先级日志任务在空闲时批量写入 Flash 或 SD 卡。否则日志本身就会成为系统不稳定源。3. 实操细节拆解从 FreeRTOSConfig.h 配置到每日快照生成的完整链路3.1 FreeRTOSConfig.h 的关键配置项深度解析每一行都是为清单服务的基石清单的可靠性始于FreeRTOSConfig.h的精准配置。这不是照抄模板的事而是要理解每一行背后的硬件约束与软件意图/* 必须开启否则无法获取任务运行时间 */ #define configGENERATE_RUN_TIME_STATS 1 /* 运行时统计依赖的宏必须指向高精度、低开销的计数器 */ #define portCONFIGURE_TIMER_FOR_RUN_TIME_STATS() (DWT-CTRL | DWT_CTRL_CYCCNTENA_Msk, DWT-CYCCNT 0) #define portGET_RUN_TIME_COUNTER_VALUE() DWT-CYCCNT /* 栈溢出检测必须启用且选择模式2可定制钩子 */ #define configCHECK_FOR_STACK_OVERFLOW 2 /* 钩子函数必须实现用于捕获溢出瞬间的上下文 */ extern void vApplicationStackOverflowHook( TaskHandle_t xTask, signed char *pcTaskName ); /* Tick Hook 是获取 tick_late 的唯一途径必须启用 */ #define configUSE_TICK_HOOK 1 /* 注意此钩子在 SysTick_Handler 内部调用务必极简 */ extern void vApplicationTickHook( void ); /* 空闲钩子是采集 idle 率和触发每日快照的入口 */ #define configUSE_IDLE_HOOK 1 extern void vApplicationIdleHook( void ); /* 关键CPU 主频必须与硬件真实频率严格一致否则所有时间计算全错 */ #define configCPU_CLOCK_HZ (SystemCoreClock) // 必须确保 SystemCoreClock 已正确初始化 /* Tick 频率决定时间分辨率过高则中断开销大过低则调度不精准 */ #define configTICK_RATE_HZ ((TickType_t)1000) // 1ms Tick平衡精度与开销 /* 抢占式调度是清单有效的前提非抢占式下 idle 率无意义 */ #define configUSE_PREEMPTION 1其中configCPU_CLOCK_HZ是最容易出错的点。我见过太多项目在SystemInit()后忘记调用SystemCoreClockUpdate()导致SystemCoreClock仍为默认的 16MHz而实际 PLL 已将主频升至 168MHz。结果portGET_RUN_TIME_COUNTER_VALUE()返回的周期数按 16MHz 解释所有时间计算误差达 10.5 倍。解决方案只有一个在main()开头HAL_Init()之后立即调用SystemCoreClockUpdate()并在FreeRTOSConfig.h中用#error强制校验#if (configCPU_CLOCK_HZ ! SystemCoreClock) #error configCPU_CLOCK_HZ must match actual SystemCoreClock! #endifconfigTICK_RATE_HZ的选择同样关键。1000Hz1ms是通用推荐值但如果你的系统有微秒级定时需求如 PWM 波形生成可设为 10000Hz100us但必须同步调整configMINIMAL_STACK_SIZE因为更高频率的 Tick 中断会占用更多栈空间。实测在 STM32F407 上从 1000Hz 升至 10000Hz空闲任务栈消耗增加约 42B这是必须计入的“时间精度税”。3.2 五项指标的采集代码实现精简、安全、可验证所有采集逻辑必须遵循“中断安全、无阻塞、低开销”三原则。以下是经过生产环境千次验证的核心代码片段1. Idle CPU 率采集在vApplicationIdleHook()中static uint32_t ulTotalRunTime 0; static uint32_t ulLastIdleTime 0; void vApplicationIdleHook( void ) { static uint32_t ulIdleStartTime 0; static uint32_t ulIdleDuration 0; /* 在空闲任务首次进入时记录起始时间 */ if( ulIdleStartTime 0 ) { ulIdleStartTime portGET_RUN_TIME_COUNTER_VALUE(); } /* 每次进入空闲钩子累加本次空闲持续时间 */ uint32_t ulCurrentTime portGET_RUN_TIME_COUNTER_VALUE(); ulIdleDuration (ulCurrentTime - ulIdleStartTime); ulIdleStartTime ulCurrentTime; /* 每隔 100ms 计算一次瞬时 idle 率避免单次测量噪声 */ static uint32_t ulSampleCount 0; ulSampleCount; if( ulSampleCount 100 ) { // 100 * 1ms 100ms uint32_t ulTotalTime portGET_RUN_TIME_COUNTER_VALUE() - ulTotalRunTime; if( ulTotalTime 0 ) { uint32_t ulIdlePercent (ulIdleDuration * 100) / ulTotalTime; /* 存入 RAM 日志缓冲区非直接打印 */ log_append_idle_percent(ulIdlePercent); } ulTotalRunTime portGET_RUN_TIME_COUNTER_VALUE(); ulIdleDuration 0; ulSampleCount 0; } }2. Tick 延迟检测在vApplicationTickHook()中static volatile uint32_t ulTickLateCount 0; static volatile uint32_t ulLastTickTime 0; void vApplicationTickHook( void ) { uint32_t ulCurrentTime portGET_RUN_TIME_COUNTER_VALUE(); uint32_t ulExpectedTime ulLastTickTime (configCPU_CLOCK_HZ / configTICK_RATE_HZ); /* 计算实际延迟考虑计数器溢出 */ uint32_t ulDelay (ulCurrentTime ulExpectedTime) ? (ulCurrentTime - ulExpectedTime) : (0xFFFFFFFFUL - ulExpectedTime ulCurrentTime 1); /* 延迟超过 1.5 个 Tick 周期则计数 */ uint32_t ulTickPeriodCycles configCPU_CLOCK_HZ / configTICK_RATE_HZ; if( ulDelay (ulTickPeriodCycles * 3 / 2) ) { ulTickLateCount; } ulLastTickTime ulCurrentTime; } /* 提供外部访问接口 */ uint32_t get_tick_late_count(void) { return ulTickLateCount; }3. 最长 ISR 时间捕获以 STM32 HAL CAN 接收中断为例void HAL_CAN_RxFifo0MsgPendingCallback(CAN_HandleTypeDef *hcan) { uint32_t ulEnterTime DWT-CYCCNT; /* ... 实际的 CAN 接收处理逻辑 ... */ uint32_t ulExitTime DWT-CYCCNT; uint32_t ulIsrDuration (ulExitTime ulEnterTime) ? (ulExitTime - ulEnterTime) : (0xFFFFFFFFUL - ulEnterTime ulExitTime 1); /* 更新全局最大值需保证原子性 */ if( ulIsrDuration ulMaxIsrDuration ) { ulMaxIsrDuration ulIsrDuration; } }注意DWT-CYCCNT在某些低功耗模式下会停止若系统进入STOP模式需在唤醒后重新使能DWT-CTRL | DWT_CTRL_CYCCNTENA_Msk。这是 GD32F303 项目中一个隐蔽的坑曾导致isr_max长期为 0误判系统无问题。3.3 每日快照生成机制如何让清单真正“每日”更新且不丢数据快照不能依赖RTC的闹钟中断因为RTC本身可能受电源波动影响。我们采用“滚动窗口 首次启动校准”策略typedef struct { uint32_t year; uint32_t month; uint32_t day; } Date_t; static Date_t xLastSnapshotDate {0}; static bool bFirstBootAfterPowerOn true; void vApplicationIdleHook( void ) { /* 获取当前 RTC 时间假设已初始化 */ RTC_DateTypeDef sDate; HAL_RTC_GetDate(hrtc, sDate, RTC_FORMAT_BIN); Date_t xCurrentDate {sDate.Year 2000, sDate.Month, sDate.Date}; /* 首次上电强制生成快照并记录日期 */ if( bFirstBootAfterPowerOn ) { generate_daily_snapshot(xCurrentDate); xLastSnapshotDate xCurrentDate; bFirstBootAfterPowerOn false; return; } /* 判断是否跨日简单比较日期结构体 */ if( (xCurrentDate.year xLastSnapshotDate.year) || (xCurrentDate.year xLastSnapshotDate.year xCurrentDate.month xLastSnapshotDate.month) || (xCurrentDate.year xLastSnapshotDate.year xCurrentDate.month xLastSnapshotDate.month xCurrentDate.day xLastSnapshotDate.day) ) { generate_daily_snapshot(xCurrentDate); xLastSnapshotDate xCurrentDate; } } void generate_daily_snapshot(Date_t* pxDate) { /* 1. 采集所有五项指标 */ uint32_t ulIdlePercent get_idle_percent(); uint32_t ulHeapFree xPortGetFreeHeapSize(); uint32_t ulTaskAStack uxTaskGetStackHighWaterMark(xTaskAHandle); uint32_t ulTickLate get_tick_late_count(); uint32_t ulIsrMax get_isr_max_duration(); /* 2. 格式化为字符串存入 RAM 缓冲区 */ char pcLogLine[128]; snprintf(pcLogLine, sizeof(pcLogLine), %04d-%02d-%02d %02d:%02d:%02d | idle: %d%% | heap: %dKB | taskA_stack: %dB/%dB | tick_late: %d | isr_max: %dus\r\n, pxDate-year, pxDate-month, pxDate-day, 0, 0, 0, // 时间固定为 00:00:00代表当日快照 ulIdlePercent, ulHeapFree/1024, ulTaskAStack, configMINIMAL_STACK_SIZE, ulTickLate, ulIsrMax); /* 3. 触发日志任务写入存储 */ xQueueSend(xLogQueue, pcLogLine, portMAX_DELAY); }关键点在于bFirstBootAfterPowerOn的管理。它不能仅靠 RAM 变量必须结合备份寄存器如 STM32 的RTC_BKP_DR0或 Flash 标志位。我在 TC387 项目中使用RSTSR寄存器的PORFPower On Reset Flag位来区分是上电复位还是软件复位确保首次上电必生成快照。4. 从清单到问题定位一份真实故障排查记录的完整复盘4.1 故障现象STM32F407 FATFS W25Q64 FreeRTOS运行 3-5 天后随机死机这是正点原子论坛上高频提问的场景。用户描述“系统跑得好好的就是隔几天就卡死串口没输出JTAG 连不上必须断电重启。用vTaskList()看所有任务状态都是Running但实际没响应。”我们的排查路径完全基于每日清单日期idleheaptaskA_stacktick_lateisr_max2024-06-1087%42.1KB215B/1024B038us2024-06-1185%41.9KB218B/1024B041us2024-06-1282%41.5KB225B/1024B045us2024-06-1378%40.8KB238B/1024B052us2024-06-1472%39.2KB256B/1024B068us2024-06-1565%36.5KB289B/1024B087us2024-06-1658%32.1KB321B/1024B0102us2024-06-1749%26.8KB358B/1024B0125us2024-06-1838%19.2KB392B/1024B0148us2024-06-1925%12.5KB421B/1024B0167us2024-06-2012%6.3KB452B/1024B0189us2024-06-218%2.1KB478B/1024B0203us清单揭示的关键线索idle率从 87% 持续、线性下降至 8%表明系统负载在稳定增加而非突发性冲击。heap从 42.1KB 降至 2.1KB降幅达 95%且taskA_stack水位线同步上升指向内存泄漏。isr_max从 38us 持续爬升至 203us说明某个 ISR 的执行时间在恶化。针对性验证聚焦isr_max上升源在W25Q64的HAL_SPI_TransmitReceive_IT()回调中插入 DWT 测量发现SPI传输完成中断处理时间随heap减少而增长。根源是FATFS的ff_memalloc()在内存紧张时搜索空闲块的链表遍历时间指数级增长。验证内存泄漏启用configUSE_MALLOC_FAILED_HOOK在pvPortMalloc()失败时触发钩子记录分配请求的调用栈。发现f_open()在打开一个不存在的文件时f_stat()失败后未释放DIR结构体内存。交叉验证tick_late为 0证明问题不在 Tick 中断本身而在任务级调度——idle率低是因为FATFS任务在while(1)中忙等 SPI 传输完成而非被抢占。最终修复在f_open()前增加f_stat()预检失败则直接返回避免无效DIR分配。为FATFS任务栈增加 512B并启用configUSE_TIMERS创建一个看门狗定时器在f_open()超时500ms后强制关闭并清理资源。将W25Q64的SPI速率从 36MHz 降至 18MHz降低isr_max峰值。修复后清单数据显示idle率稳定在 85±3%heap余量波动小于 0.5KBisr_max回落至 45us 以内。系统连续运行 47 天无异常。4.2 常见问题速查表清单数据异常时的快速诊断指南清单异常现象最可能原因排查指令/方法我的实操心得idle率突然归零0%某个高优先级任务陷入死循环或vTaskSuspend()了所有其他任务vTaskList()查看所有任务状态vTaskGetRunTimeStats()看 CPU 时间分布归零前 1 小时的清单isr_max往往会先飙升这是 ISR 占用 CPU 的铁证heap余量每日减少固定值如 128B典型内存泄漏malloc()与free()不匹配或对象析构未释放内部指针启用heap_4.c在pvPortMalloc()中添加__FILE__和__LINE__记录固定值泄漏往往来自struct数组分配检查sizeof(struct)是否被误算taskX_stack水位线单日暴涨 200B该任务中新增了大型局部数组或递归调用深度意外增加arm-none-eabi-objdump -t firmware.elf | grep taskX查看符号表栈大小STM32F4 的__libc_init_array()会调用 C 构造函数若构造函数里new大数组极易被忽略tick_late连续多日 0SysTick_Handler被更高优先级中断如 NMI、HardFault长时间阻塞检查NVIC_SetPriority()调用用SCB-ICSR寄存器读取当前挂起的中断号TC387 的 SMP 模式下tick_late常出现在核 0而核 1 正常需检查核间同步锁的持有时间isr_max在特定操作后激增如触摸 LVGLLVGL 的lv_disp_drv_register()注册的刷新回调中执行了阻塞式SPI传输在lvgl_port_disp_init()的flush_cb中插入 DWT 测量隔离图形驱动代码freertos移植lvgl项目中90% 的isr_max问题源于flush_cb里调用了HAL_SPI_Transmit()而非IT版本注意所有排查必须基于连续至少 3 天的清单数据。单日异常可能是偶发干扰连续趋势才是系统性问题的指纹。5. 清单的进阶应用从故障记录到系统优化的闭环5.1 将清单数据转化为可执行的自动化优化策略清单的价值不止于“发现问题”更在于“驱动优化”。我们构建了一个轻量级闭环系统1. 动态栈大小调整当清单连续 5 天显示taskA_stack水位线 80% 且呈上升趋势时自动触发栈扩容// 在每日快照生成后调用 void auto_adjust_task_stack(TaskHandle_t xTask, uint16_t usMinWaterMarkPercent) { uint32_t ulCurrentWaterMark uxTaskGetStackHighWaterMark(xTask); uint32_t ulCurrentStackSize get_task_stack_size(xTask); // 需自行实现 if( (ulCurrentWaterMark * 100 / ulCurrentStackSize) usMinWaterMarkPercent ) { uint32_t ulNewStackSize ulCurrentStackSize * 1.5; // 增加 50% // 重建任务需确保任务可安全删除 vTaskDelete(xTask); xTaskCreate(taskA_func, taskA, ulNewStackSize, NULL, tskIDLE_PRIORITY 2, xTask); } }这避免了工程师凭经验“拍脑袋”设栈让资源分配数据驱动。2. Tick 频率智能降级当idle率连续 7 天 5% 且tick_late 0系统自动将configTICK_RATE_HZ从 1000Hz 降至 500Hz并通知上位机// 在 vApplicationTickHook() 中 if( ulTickLateCount 10 get_idle_percent() 5 ) { static uint8_t ucDowngradeCount 0; if( ucDowngradeCount 100 ) { // 连续 100 次 Tick 延迟 configTICK_RATE_HZ 500; // 修改宏定义需重新编译此处为示意 send_alert_to_pc(TICK_RATE_DOWNGRADED_TO_500HZ); ucDowngradeCount 0; } }这为资源受限的低端 MCU 提供了优雅的降级路径。3. 基于isr_max的 ISR 重构建议清单自动分析isr_max的分布若 95% 的isr_max 50us建议保持现状若 5% 的isr_max 100us 且集中在某类外设如 USB则生成重构报告“USB ISR 中的memcpy()应替换为 DMA 传输”。5.2 与主流开发板生态的无缝集成正点原子、野火、ST 官方库的适配要点正点原子 ALIENTEK 系列其sys文件夹下的delay.c重写了SysTick_Handler会覆盖 FreeRTOS 的xPortSysTickHandler()。必须在FreeRTOSConfig.h中注释掉#define xPortSysTickHandler SysTick_Handler并手动在delay.c的SysTick_Handler末尾添加xPortSysTickHandler()调用否则tick_late永远为 0。野火 STM32F407 开发板其bsp库中bsp_led.c的LED_Toggle()函数使用了HAL_Delay()而HAL_Delay()依赖HAL_GetTick()后者又依赖SysTick。若 FreeRTOS 的configUSE_TICK_HOOK与HAL的HAL_IncTick()冲突会导致idle率计算错误。解决方案是禁用HAL的SysTick完全由 FreeRTOS 管理并在HAL_GetTick()中返回xTaskGetTickCount()。ST 官方 CubeMX 生成代码MX_FREERTOS_Init()中默认创建的defaultTask栈大小为 128 字远低于安全值。必须在FreeRTOSConfig.h中将configMINIMAL_STACK_SIZE设为 256并在CubeMX的 GUI 中手动修改任务栈为 512。否则清单中的taskX_stack会从第一天就显示512B/128B毫无参考价值。我的体会是没有“开箱即用”的 FreeRTOS 移植。所谓“正点原子 freertos 笔记”、“stm32f4 freertos” 教程教的只是如何让第一个Hello World任务跑起来而让系统稳定运行三年不重启靠的是对FreeRTOSConfig.h每一行的敬畏以及一份日复一日、不容篡改的“每日记录清单”。它不炫技不讨巧只是用最笨的办法把嵌入式系统里那些看不见的熵变成一行行可读、可比、可行动的数据。当你开始认真对待这份清单你就已经超越了 80% 的同行。