从前后台编程向操作系统编程思维转变

题记：适用于那些仅有一种编程经验的人员

   不得不说一点，经常做前后台编程的人，很不容易向操作系统编程转变，觉得操作系统很玄乎，自己无从下手，少了控制感；而经常做操作系统编程的人，觉得为什么要前后台编程那么麻烦，什么事情都得自己做，就不能把一些任务交给操作系统去完成，而专心于任务的实现。

   其实，我觉得这里面主要是思路以及思维方式的不同而引起的。首先，古老的前后台编程很直观简单，所有的事情都有程序员一力完成，所有的情况都被控制在手里。这个时候，程序员会有安全的感觉，如果让他立马转换成操作系统编程，立马傻眼了，我的这些工作怎么变成了任务了，这任务之间怎么会有切换，谁干的？这玩意为什么不直接操作IO口，还得交给某个我也不懂的任务去完成等等。相信大家肯定有类似的经历，至少是心理的。在前后台编程模式里面，所有的事情都是串行发生的，出了ISR程序偶尔插入执行完毕然后回到原来的主循环。对于没有操作系统概念和开发经验的程序员来说，这种自然的程序开发方式多么的无为而治。

   但是前后台编程模式有其天然的缺陷：1、CPU利用效率低下，2、编程效率低，3、移植性差。对于第一点，相应大家都知道，如主程序里面要delay几个ms一下，我们就让CPU在那里空计数玩，其实这么宝贵的CPU时间完全没必要浪费的。第二点，效率低，体现在很多方面：每个不同的项目，你都需要不同的程序组织方式，从定义到实现需要花费更多的时间；对于底层的操作，需要自己编写（尤其是移植到新的CPU上）。第三点就不用说了，一个用于STM32的程序移植到MSP430上面，它们的寄存器架构都不一样，包括固件方式都不一样，需要重写的东西太多，代价大。

   从上面这段论述，我们也可以大概解释一下只做前后台编程和操作系统编程的人员的差异和思维模式。总而言之就是，前后台编程人员对于硬件底层细节理解比较深（相对的，否则他也没法编程），而操作系统编程人员对于软件理解较深（操作系统就是要向你屏蔽硬件细节，提供API接口以及系统服务，让你摆脱datasheet和reference manual不断的烦恼）。

   因此，要想学习操作系统编程的程序员，首先要建立操作系统的基本概念，这么多年的软件工程实践已经总结出很多操作系统的基本框架和共识。然后要意识到，使用操作系统意味着什么——意味着方便快捷以及放权，方便快捷来源于操作系统编程的实现，放权意味着操作系统接管硬件并且帮你协调工作（专业点将就是调度，通俗点将就是请了一个管家）。第三，就是要敢于实践和使用，学习一项新的事物，最好的方式不是先去搞懂它是怎么工作的，而是搞清楚它能干什么，以建立直观印象。最后，如果不想止于此，去看操作系统内核实现吧，小型操作系统的内核都比较简短，一定要深入挖掘里面的东西。目前我也是在学习FreeRTOS，之前有学习uCOS-II的经验，两相交互对比，更加深了我对操作系统的理解，但是路依然很长。

   个人愚见，两种编程方式锻炼的是人的不同能力，目前嵌入式编程，操作系统的使用是很普遍的，因此有了解底层硬件的基础，对于学习和工作是有好处的。能让你了解软件如何控制硬件的工作，基础扎实，贯通上下。

   鉴于本人水平有限，文章中有错误处请读者不吝斧正。
————————————————
版权声明：本文为CSDN博主「wuxianglonghaohao」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/wuxianglonghaohao/article/details/18257507