飞控计算机，说白了就是飞行器的"大脑"——姿态解算、导航逻辑、控制律计算、执行机构驱动，全在这个盒子里完成。而大脑做判断的速度和一致性，直接决定了飞行器稳不稳、能不能安全落地。我这些年看过的飞控项目不算少，一个特别容易踩的坑就是：功能逻辑写得没问题，结果栽在操作系统调度上。某个通信任务占着CPU不放，控制周期被悄悄拖长，姿态一抖，整个系统就开始发散。所以做飞控软件，首先要把"硬实时操作系统"这几个字吃透。

这篇文章就围绕飞控计算机常用的硬实时操作系统展开，讲清楚硬实时和软实时到底差在哪、飞控对系统的真实需求有哪些、VxWorks/RTEMS/FreeRTOS这些主流方案怎么选，以及任务调度、中断管理、内存分区、适航认证这些核心环节的实操细节。适合刚入门的飞控开发者，也适合正在做机载软件选型和排障的工程师参考。

1. 硬实时操作系统：飞控软件的地基

1.1 硬实时和软实时，区别在于"晚了会怎样"

很多人一提"实时"，就以为系统跑得快。实际上实时性恰恰不是"快"，而是"确定性"。我用一个生活里的例子来说明：你看视频缓冲，偶尔卡一下，刷新出来就好了，这叫软实时；手术室里的心电监护仪，心跳数据晚输出一毫秒甚至丢了，那是要出人命的，这叫硬实时。

两者的关键差别就是"违反时间约束的后果"。对硬实时系统来说，任务必须在指定截止时间（deadline）之前完成，晚到等于失败，失败可能带来灾难性后果。飞控系统就是最典型的硬实时场景：传感器数据采集、姿态解算、控制律输出必须在严格的周期内完成，比如一个控制周期是5ms，那么每个周期里数据必须按时到达、按时算完、按时输出。如果某个任务偶尔迟到，控制律的输出相位就会滞后，系统阻尼特性变化，轻则抖动，重则直接振荡发散。

软实时系统则不同，它允许一定概率下的超时，系统性能下降顶多是体验变差，不会危及安全。所以在做飞控选型时，绝对不能拿一个"通用实时Linux"或者普通桌面系统去硬扛飞控任务——那不是性能够不够的问题，而是机制上就不保证你"一定在期限内完成"。

1.2 飞控为什么必须用硬实时

飞控系统的控制律本质上是离散控制器的实现，它的正确性依赖两个基本假设：采样周期固定、执行延迟可忽略。你如果用软实时系统，任务调度偶尔被高负载任务挤占，采样间隔忽长忽短，控制器模型会拿到不规则的时间戳数据。实际表现就是：控制器低频振荡、执行机构动作延迟、姿态反馈滞后。

这不是理论推导，我在模拟项目X里就亲眼见过。当时用的是某通用嵌入式Linux做飞控原型，控制周期设定5ms，CPU负载不高的时候跑得很顺，一旦同时开日志记录和图像处理，调度延迟一下飙到30ms，飞控输出肉眼可见地抽动。换到硬实时操作系统之后，同样的控制算法完全没有改动，飞行品质立即恢复正常。

原因也很简单：硬实时RTOS的调度器是优先级抢占式的，高优先级任务只要就绪，就能在极短且可预测的时间内抢到CPU，不会被低优先级任务"拖住"。再加上中断响应时间有明确的上界，整个软件关键路径上的时间就可以做规划和验证。飞控软件是要被验证和认证的，如果你的操作系统连最坏执行时间都说不清，那整个系统的时间特性就是一笔糊涂账。

1.3 评估实时性的四个硬指标

选型和验收的时候，我一般先看下面四个指标：

• 中断响应时间：硬件中断发生到中断服务程序开始执行的时间。这个越短越稳定越好，飞控里传感器数据到达中断、定时器心跳中断都依赖它。
• 上下文切换时间：操作系统从一个任务切换到另一个任务的开销。这个时间决定了同样一个控制周期里，你能塞多少个任务而不爆掉。
• 调度抖动（Jitter）：一个周期任务每次被唤醒启动的实际时间点相比理想周期的波动。飞控最恨的就是抖动，抖动会让控制律的执行时刻忽早忽晚。
• 阻塞与死锁处理机制：系统是否支持优先级继承、死锁检测这些机制。飞控任务之间会共享外设和缓冲区，如果不能妥善处理资源竞争，高优先级任务会被低优先级任务"绑架"。

这四个指标不一定都要最顶尖，但要可预测、可验证。你宁可要一个"稳定在微秒级抖动"的系统，也不要一个"平均延迟极低但偶尔爆个百毫秒"的系统，因为后者根本没法做安全分析。这个观点在我后面讲的调度和排障章节里会反复印证。

2. 飞控计算机的选型需求清单

2.1 硬件环境决定了系统选型的边界

飞控计算机的硬件通常不是随便选的。小型的消费级无人机常用ARM Cortex-M系列微控制器，资源有限、没有MMU，内存可能只有几百KB；中大型无人机和通航飞控则常用带MMU的PowerPC、ARM Cortex-A系列甚至x86平台，可以跑内存管理、分区隔离这些高级特性。这就决定了操作系统选型的第一层约束：你的RTOS到底跑在什么CPU上，有没有对应的BSP（板级支持包）。

BSP这个东西往往是被低估的关键点。操作系统内核写得再好，没有适配你板子的BSP，中断控制器初始化、定时器驱动、串口映射这些都得自己搞定。我之前在某开发板上移植RTEMS，内部RAM初始化地址配置错了，系统启动阶段就卡住，排查了整整一天。所以选型的时候一定要确认目标RTOS在目标硬件平台上的成熟度，而不是只看它功能多不多。

2.2 确定性、安全性、可验证性

飞控软件对操作系统的要求，可以归纳成三个词：确定性、安全性、可验证性。

确定性是指系统对外部事件和内部任务调度的响应时间有严格上界。你需要在设计阶段就能算出最坏情况下的任务延迟，而不是靠实测"感觉还行"。安全性是指系统必须有内存保护、看门狗、健康监控等机制，能防止一个故障任务把整个系统拖垮。可验证性则涉及代码质量、标准符合度和测试覆盖，这在民航领域尤其重要。

有些通用操作系统（比如桌面版Linux）在功能上完全够用，可为什么不能直接上飞控？因为它引入了太多不可控因素：后台进程、缓存刷盘、不确定的调度策略、庞大的驱动栈。你没法简单证明某个高优先级任务一定在指定时间内完成。真实飞控项目里，哪怕用Linux，也一定要加实时扩展或者把关键任务挪到实时域，目的就是重建确定性和可验证性。

2.3 适航认证不是可选项

很多做无人机原型的人会觉得适航认证离自己很远，但如果你做的产品要正式商用，尤其是载人或进入空域，软件适航就是绕不过去的坎。民航领域的软件安全标准主要在DO-178C里定义，系统越关键，软件等级越高，对开发过程、测试工具、验证证据的要求就越严格。飞控通常属于最高那几个等级，代码覆盖率、需求追踪、测试独立性全是硬性要求。

这就意味着，操作系统的选择不仅是技术选型，也是适航策略的一部分。商用RTOS供应商一般会提供完整的认证证据包（Certification Artifact），这些都是前人花大量时间和金钱积累出来的合规成果。如果你自己用开源RTOS然后从零去做适航认证，那工作量会大到让你怀疑人生。所以不管你现在做不做认证，都要把这个因素放进选型考量里。

3. 主流硬实时操作系统横向对比

3.1 VxWorks：航空领域的经典选择

一提到飞控用操作系统，很多人第一反应就是VxWorks。它在航空航天领域装机量极大，是经过长期实战验证的商业RTOS。内核采用微内核架构，功能模块按需裁剪，支持优先级抢占调度、时间片轮转、确定性中断响应等硬实时特性。它同时支持MMU、网络协议栈、文件系统、DSP库等完整组件，适合大型复杂的机载系统。

VxWorks的优势在于生态成熟，工程资料和疑难问题解答相对充分，很多机载设备商都在它上面积累过大量的应用层代码。代价也很明显：商业授权费用不低，内核闭源，出了问题你只能依赖厂商支持。另一个关键点是，VxWorks虽然灵活，但使用它做高安全等级飞控同样需要配套的工程流程，操作系统本身过关不代表你的应用软件自动过关。

3.2 RTEMS：开源阵营的稳健派

RTEMS是一个开源实时操作系统，在航天和航空领域有大量真实使用案例。它支持多种处理器架构，提供POSIX API和经典的RTEMS API两套接口，任务调度、信号量、消息队列、事件、定时器等一应俱全，实时性表现稳定。它的一个突出优点是开源且许可相对宽松，你可以在自己的商业产品里使用而不需要开源应用代码。

相比VxWorks，RTEMS的缺点是商业支持不如商业货品完善，部分驱动和BSP需要自己适配。但它给的是一种"可控感"：内核代码就摆在面前，出问题可以自己去追根溯源。对预算有限、又想保留高等级安全开发可能性的团队来说，RTEMS是我比较常推荐的开源选项。在模拟项目X的迭代中，我们就是从RTEMS起步，后期把自定义驱动逐步补全，整个系统的可调性比换用其他方案好得多。

3.3 FreeRTOS：轻量化原型利器

FreeRTOS是消费级无人机和飞控原型里的常客，开源、轻量、上手极快。它小巧的内核可以跑在资源极紧张的MCU上，提供任务调度、队列、信号量、软件定时器等基本组件。很多飞控方案的原型阶段都用FreeRTOS验证算法和控制逻辑，包括我在内，最早接触的RTOS就是它。

但FreeRTOS毕竟是面向嵌入式通用场景设计的，它提供了硬实时调度的基础机制，却不强制你实现内存分区、时间分区、健康监控这类航空级能力。如果你想把它往正式飞控上推，就要自己补齐内存保护、故障隔离、安全的通信机制等一大堆东西。这是可行的，但成本一点不低。原型和研究阶段它是利器，量产商用高安全飞控则需要谨慎评估。

3.4 Linux+Xenomai：双域方案能做飞控吗

Linux+Xenomai属于一种双内核方案：一个实时内核与Linux内核共享硬件，硬实时任务跑在Xenomai域，普通Linux任务跑在Linux域。它的优势是能够复用Linux生态里的丰富驱动和应用，实时性和通用性两头都沾。在很多地面站系统、半实物仿真平台和工业控制器里，这套方案很常见。

它能不能做飞控？分场景。如果做地面站、仿真测试、实验平台，它足够好；如果做需要载人适航的高保证飞控，那就很难说了。原因在于双内核方案的时间确定性分析极其复杂，两个内核共享中断和资源，如何证明每个实时任务的最坏执行时间都有界？这本身就需要大量认证工作。加上Linux驱动栈和后台行为不可预测，适航难度非常高。所以在正式飞控选型时，我不会把它排在前面。

3.5 选型建议：从场景反推系统

我用一个表格把各个方案的适用场景摆一下，方便你对照自己的项目：

我的建议是，先想清楚你的产品最后要走向什么等级，再来定操作系统。如果只是课堂作业和原型验证，FreeRTOS完全够用；如果做正式的商用飞控且奔着适航去，趁早考虑VxWorks或者RTEMS加认证咨询。不要等算法都定型了再换系统，换OS等于把整个软件架构重做一遍。

4. 任务调度与中断机制：实时性的命脉

4.1 优先级抢占调度：让重要的事先办

硬实时操作系统几乎都采用优先级抢占调度。我一般用"排队办业务"来跟你解释：普通排队是轮询式的，每个人不管事急不急都按先来后到；优先级抢占调度就是来了个VIP大客户，直接插队到最前面，正在办业务的人也得先让出来。

在飞控系统里，设计任务优先级表是一件很讲究的事情。通常的做法是：把周期短、对抖动敏感、故障后果严重的任务放到高优先级，比如IMU采样、姿态解算、控制律输出；把周期长、允许延迟的放到低优先级，比如日志存储、遥测链路、地面指令解析。任务优先级的设定直接决定系统的实时行为，写错一个优先级，可能比写错一段算法影响还大。

很多刚接触RTOS的人会问：为什么不把控制律任务放在中断里？这样更快。理论上确实更快，但中断上下文里不适合做浮点密集运算和控制律解算，大量时间花在中断里会导致系统无法响应其他事件。正确做法是让中断极简、只做必要的硬件交互和数据搬运，真正的计算放到高优先级任务里完成。

4.2 中断响应：从硬件到任务执行的链路

中断响应时间可以拆成几段：硬件中断信号到来、CPU完成当前指令并保存现场、操作系统进入中断服务程序、然后是中断服务执行、最后把结果传递给等待的任务。每一段都有开销，硬实时操作系统要做的是把这些开销压到最低，并且保证上界可控。

我实测过不同RTOS的中断响应时间，好的系统能稳定在几微秒到十几微秒量级。需要注意的是，这个数值会受到中断关闭时间的影响：如果你的代码在临界区里长时间关中断，那所有其他中断都会被堵在外面，实时性再好的系统也没用。所以我有个习惯：写飞控代码时，临界区越短越好，能用关抢占就不用关中断，能用无锁环形缓冲就不用锁。

在调试中断问题时，我推荐用GPIO翻转法。在中断服务程序入口和任务唤醒点各拉一个GPIO引脚，用逻辑分析仪看这两个引脚之间的时间差，能非常直观地看到中断响应和任务调度延迟。这个技巧在我后面的排障章节还会详细展开。

4.3 优先级反转与解决方案

优先级反转是嵌入式实时系统里最经典的坑。我举个例子：高优先级任务要使用某个外设，这个外设当前被低优先级任务占用，于是高优先级任务被阻塞；这时来了一个中等优先级任务抢占了CPU，它又不让出，导致低优先级任务迟迟拿不到CPU去释放外设。结果是高优先级任务被一个低优先级任务间接"踩"在脚下，系统实时性崩溃。

解决优先级反转的常见手段是优先级继承：当低优先级任务持有一个高优先级任务需要的资源时，低优先级任务临时把自己的优先级抬高到那个高优先级任务的级别，直到释放资源为止。VxWorks的互斥量就有priority inheritance选项，RTEMS也有类似的priority ceiling协议。实际项目中，我除了依赖协议本身，还会在设计上尽量避免高优先级任务长时间等待共享资源，能通过把共享数据拷贝一份再处理，就不要用锁保护长临界区。

5. 内存管理与ARINC 653分区机制

5.1 分区操作系统的由来

随着机载软件越来越复杂，飞控里往往要同时运行多个功能子系统：导航解算、任务管理、武器或者载荷管理、故障记录。这些子系统如果全部跑在一个无隔离的操作系统实例里，一个任务越界访问或非法跳转就能把整个系统搞挂，这是高安全系统不能接受的。于是出现了分区操作系统，ARINC 653就是这样一套标准。

ARINC 653的核心思想是把每个应用当作独立分区（Partition），每个分区拥有自己的时间窗口和内存区域，互不干扰。即使某个分区崩溃，其他分区照常运行。你可以把分区想象成同一个办公大楼里的不同公司——每家有自己的办公室门禁和上班时段，一家公司着火了，其他公司不受该部分波及，可以继续运行。

5.2 时间分区与空间分区的实现方式

时间分区是靠系统级调度表实现的。比如一个主循环周期取10ms，在这个周期里：分区A分到0到5ms运行导航解算，分区B分到5到8ms运行任务管理，分区C分到8到10ms做健康监控和系统预留。每个分区内部，再按优先级抢占调度它自己的任务。这样就把不同功能子系统的运行时间在物理上隔离了，不会出现一个分区洪水般占用CPU导致其他分区饿死的情况。

空间分区依赖MMU或MPU实现内存隔离。每个分区拥有独立的地址空间和资源配置，分区内的非法访问会被硬件拦截而不是直接篡改其他分区的内存。带MMU的处理器可以做得比较精细，每个分区有自己的页表；带MPU的MCU则可以实现有限的地址区域保护。在做飞控系统的时候，空间分区的最直接好处就是故障隔离：导航分区的野指针不会把任务管理分区的数据毁掉。

5.3 分区内调度与分区通信

分区内的调度还是实时操作系统那套优先级抢占，只不过边界被限制在分配给该分区的时间窗口里。分区之间如果需要传递数据，比如导航解算出结果要给控制律用，ARINC 653提供采样口和队列口两类通信机制。采样口是最新数据覆盖旧数据，适合周期性状态数据；队列口是先进先出传递消息，适合事件型数据。

分区操作系统的设计哲学是"牺牲一部分灵活性，换取隔离和可验证性"。你可能觉得10ms周期里留给导航分区5ms不够用，所以系统设计阶段的资源预算就非常重要。你需要估算每个分区的最坏执行时间，再反推主周期长度和分区时间分配。我在做分区配置时有个稳办法：先按各分区计算量的两倍分时间，再用实测数据逐步收紧，而不是一上来就扣得很死。

6. DO-178C与飞控软件安全开发

6.1 DAL等级怎么定

DO-178C把机载软件按失效后果的严重程度分成A到E五个等级：A级指失效会导致灾难性事故，B级指危险级，C级指主要级，D级指次要级，E级是无影响。飞控计算机里的软件大多落在A级或者B级，它的开发工作量会比普通嵌入式项目大一个数量级。

DAL等级不是自己拍脑袋定的，它通过系统安全评估过程推导出来：先做系统功能危险分析，识别各种失效状态及严重程度，再把安全性需求分配到软件和硬件上。这也就是说，操作系统选型在需求阶段就要介入——如果你的系统是A级，你需要一个满足A级开发证据的操作系统，这里的"满足"指的是一整套需求、设计、编码、测试、配置管理的证据链。

6.2 认证对RTOS和开发流程的要求

认证对RTOS本身的要求可以分为两个层面。第一个层面是功能层面：调度必须确定性、内存保护要生效、分区隔离要可证明、健康监控要能检测和响应故障。第二个层面是过程层面：操作系统供应商需要提供完整的需求文档、设计说明、测试报告、覆盖率分析、问题报告等认证证据包。

对应用开发团队来说，DO-178C带来的最大冲击是流程规范性。你需要为每一个软件需求建立追踪关系，从系统需求到高层需求再到低层需求，最后到测试用例；你需要按照规定做代码标准检查、单元测试、集成测试、验证测试；你还要保证开发代码和验证代码是隔离的，不能自己测自己。我以前写代码是"一把梭"，后来做高安全等级项目才意识到，工程活动和编码活动同样重要，甚至更耗时。

6.3 从需求到验证的完整链条

一个合格的飞控软件生命周期大致是：系统需求定义、软件需求定义、软件架构设计、软件详细设计、编码、单元验证、集成验证、系统验证。每一步都有明确的输入输出和评审节点。操作系统作为软件组件也要纳入这个链条：它的需求可能来自系统对调度时间、内存资源、故障响应速度的约束，它的验证则涉及时序分析、压力测试和故障注入。

这里尤其要补一句：很多人以为代码覆盖率达到100%就万事大吉，实际上DO-178C要求的是语句覆盖、判定覆盖、MC/DC覆盖（针对A级）等不同层次的结构覆盖。MC/DC覆盖要求每个判定里的每个条件都能独立影响判定结果，这会让测试用例数量大幅上升。这个阶段的工作量往往会超过写代码本身，我在做模拟项目X时深有体会——真到认证阶段，你缺的不是聪明的程序员，而是严谨的验证工程师。

7. 从零搭建一个飞控实时系统实例

7.1 BSP与编译环境的搭建

搭建一个可运行的飞控实时系统，第一步是让操作系统在你的目标板上"跑起来"。以RTEMS为例，你需要下载RTEMS源码，使用它的编译工具链和BSP生成工具，针对目标CPU架构做配置编译。通常一个成熟的BSP会包含启动代码、定时器驱动、中断控制器驱动、串口驱动，烧录后串口能输出系统启动信息，就说明BSP基本正常。

这个阶段最典型的问题是时钟配置错误和内存映射不对。系统定时器的频率决定了系统tick和控制周期的时间基准，如果定时器配错，任务调度时间全部偏差。内存方面，如果链接脚本里RAM地址没对准实际布局，系统一初始化就访问非法地址，表现往往是没有输出或者死循环。我的建议是先把系统自带的测试程序跑通，再动手写应用，不要一上来就写控制逻辑。

7.2 控制任务划分与优先级表设计

用RTOS做飞控，任务划分有约定俗成的套路。我通常会把系统拆成以下几个任务：

• 采样任务：从IMU、气压计、GNSS等传感器读取原始数据，周期最短，优先级最高
• 导航解算任务：融合传感器数据，更新姿态、位置、速度，周期和优先级次之
• 控制律任务：根据导航结果和指令生成控制输出，周期和优先级根据控制率确定
• 链路通信任务：处理遥控遥测、地面指令、数据链，周期较长，优先级较低
• 日志存储任务：记录飞行数据，周期不敏感，优先级最低

优先级表可以设计成这样的示意（数值仅为示例，具体看项目）：

任务数量的原则是越少越好。每多一个任务，就可能多一次上下文切换和优先级反转风险。能用中断加一个任务处理的事，绝不用三个任务加一堆信号量去糊。

7.3 时间基准、看门狗与日志

硬实时系统的"心跳"是系统时钟。飞控控制律通常以固定控制周期运行，我的做法是让高精度硬件定时器产生周期性中断，在中断服务里做最少的处理，比如置一个标志位或者发布一个semaphore，让采样任务醒来执行实际工作。这样中断和任务的职责清晰，调度时机也可控。

看门狗是飞控系统最后的装甲。外置看门狗或者CPU内置看门狗，用来检测系统是否死机或调度异常。一个常见的设计是：喂狗任务周期执行，如果某个关键任务超过规定时间没有产生心跳，说明系统可能卡死，看门狗强制复位整个飞控。要注意喂狗别放在中断里，否则就算任务调度完全瘫痪，中断还能喂狗，看门狗形同虚设。应该让看门狗反映任务级调度正常。

日志记录这块，我强烈建议从第一天就加上时间戳。每个日志条目带毫秒甚至微秒级时间戳，排错的时候一眼能看出任务调度间隔是否均匀。我见过很多项目没加时间戳，出了问题只能对着波形猜，效率低得让人抓狂。

8. 常见问题与排查经验

8.1 控制周期抖动：GPIO测出来的真相

飞控最常见的异常现象是控制律输出看起来正常但飞行品质变差，这时候我一般先怀疑调度抖动。测抖动最朴素可靠的办法就是GPIO翻转法：在关键任务入口翻转一个测试引脚，用逻辑分析仪抓取引脚翻转的间隔。如果间隔不是均匀的控制周期而是忽长忽短，那就是调度链路有问题。

抖动来源通常有几类：高优先级中断过于频繁、中断服务占用时间过长、任务间锁竞争、缓存未命中波动、系统tick精度不足。我做过一次排查，发现某个外设驱动在中断服务里做了大量的排队轮询，把CPU时间切得七零八落，导致控制律任务频繁迟到。把轮询工作移出中断后，抖动从几十微秒降到了个位数微秒。

8.2 栈溢出与锁竞争

栈溢出是RTOS里的隐形杀手。任务栈设置过小，平时不爆，偶尔深层函数调用就把栈顶踩穿，造成蹊跷的随机崩溃。调试时我习惯把每个任务栈的栈空间预先填充固定模式值，比如0xAA，系统运行一段时间后检查栈区还剩多少被覆盖，这叫栈水线检查。发现某个任务栈使用率超过80%，就赶紧加大，这是最高效的防爆栈手段。

锁竞争则是性能与实时的天敌。高优先级任务频繁抢占锁，其他任务排队等待，锁的持有时间稍长，调度延迟就上去。我的处理策略是让共享数据尽量以单写者单读者的环形缓冲形式存在，避免加锁；必须加锁的场合，锁临界区只保留赋值操作，绝不在临界区里做耗时的计算和日志输出。

8.3 中断风暴与看门狗复位

有一种故障场景让人很头疼：系统周期性复位，但复位原因不明确。排查时第一件事是看复位状态寄存器，确认是看门狗复位还是外部复位。如果是看门狗复位，多半是某个关键任务长期得不到执行，喂狗任务也随之饿死。这时候不要急着调喂狗逻辑，先查为什么关键任务被饿死。

中断风暴经常是罪魁祸首。某个外设中断没有正确清除pending标志，导致中断服务被无限触发，CPU全部时间花在中断上下文里，任务调度完全停滞。我记得有一次调试，某个传感器中断触发频率比预期高了上百倍，ISR里只是简单读取数据，看似不耗时，但高频触发直接把系统拖垮了。用逻辑分析仪看中断引脚电平翻转频率，立刻就能定位问题。

8.4 经验速查表

我把高频问题整理成一个速查表，方便大家照着排查：

最后分享一点自己的体会

飞控实时操作系统这块，我踩过最大的坑，是前期太重视算法、太不重视调度。代码写得越多，对操作系统时间特性的欠账就越多。后来我养成了一个习惯：在做飞控软件之前，先把RTOS的中断响应、任务切换、锁行为和堆栈水线这些底层数据全部测一遍，记录成文档。之后写应用代码时，心里始终有这根弦。另一个很值得分享的小技巧是，在系统启动阶段打印一次所有关键资源的初始时间戳和配置参数，并保存到非易失区，后面排错时对照这些基线数据，能节省大量时间。希望这篇文章能让你少走一些我走过的弯路。