操作系统抽象层（OSAL）让软件脱离目标操作系统，迁移RTOS的痛苦对比

[[硬件抽象层HAL让硬件成为实现细节可以无限分层]]能保证代码不与运行环境绑得太紧，但只适用于裸机系统——一旦嵌入式系统用了实时操作系统（RTOS）或某种嵌入式Linux/Windows，操作系统本身也必须被当成实现细节对待，否则软件会跟操作系统层产生依赖：如果直接调用操作系统服务，一旦要更换RTOS厂商、授权费涨价、质量下降，或者需求变化导致当前RTOS无法满足，就得大量修改代码——不仅要调整语法适配新API，很可能还要重新适应新操作系统的语义和原语，迁移RTOS的痛苦，经历过的人都懂。整洁嵌入式架构的解法是引入操作系统抽象层（OSAL），把软件和操作系统分隔开——有时实现这层抽象只是给函数改个名字那么简单，有时需要把几个函数封装到一起。让软件依赖OSAL而非直接依赖操作系统的好处很直接：要换操作系统时，只需要写一个兼容旧OSAL接口的新实现即可，对比”修改一堆复杂的现有代码”和”按接口和行为定义写一套新代码”，后者显然轻松得多。这样做还能顺带带来两个额外收益：一是把使用操作系统产生的重复性代码集中隔离，代码膨胀的担忧因此没那么严重；二是可以借OSAL定义一套公用结构（比如标准的消息传递机制），让应用的每个线程不用各自发明一套并行模型。最后，OSAL还能撑起目标操作系统之外的测试——由整洁嵌入式架构构建的软件，理应能脱离目标平台、目标操作系统被测试，设计良好的OSAL正是为这种测试提供支撑点。