高质量软件之路--平台与框架

差一点

我们就擦肩而过了

有趣

有用

有态度

前言

近两年来，平台和框架可谓是当今嵌入式开发的香馍馍。得益于开源运动日渐兴盛，很多以往从事单片机行业的工程师，已经逐渐改变了单打独斗的开发模式。意识到了引入平台、框架概念对软件质量持续提高和发展的重要性。

毫无疑问，这是嵌入式行业的一大进步，在一定程度上缩小了嵌入式软件开发与计算机软件开发的差距。长期以来，岗位特性决定了嵌入式工程师需要学习繁多软硬件知识，但又因为两者都很难精通，于是嵌入式工程师就有了"万金油"、"万能胶水"、"混子"等标签。

随着更多先进的软件工程理论逐渐普及到嵌入式行业，假以时日，嵌入式工程师也必定能逐渐摆脱这些标签。

初看系统库、平台、框架

我们先来了解一下系统库、平台和框架这三者，在一个项目中的层次关系。从抽象层次上说，从低到高依次是系统库、平台、框架。然后应用程序位于框架之上，因此平时我们也会听到"上层软件"这样的概念。画个示意图给大伙瞧瞧:

这里提到了抽象这个概念，大部分人对抽象的理解都是指代码层面上的抽象，即越底层的代码，抽象层次越高，我这里也不例外。

系统库

对于系统库，在嵌入式领域其实主要就是指c库。嵌入式开发人员应该对这个都不陌生。我们在日常开发时经常要跟它打交道，比如下面这一句，应该能勾起你不少回忆。

#include <stdio.h>

嵌入式开发使用频率最高的两个c库，当属Keil里面的microlib和GNU的glibc(当然，它远不止是c库)。一个用在裸机和RTOS上，另一个用在嵌入式linux上。两者的共同特点是都实现了很多通用、硬件无关的函数，而且丝毫不关心应用软件的业务模型。但它们却是所有上层应用软件开发的基石。

在这里，必须要向开发glibc和一系列自由软件的大佬们致敬！

GNU组织大佬stallman

平台

平台的概念有着比系统库更高层次的抽象。一般来说，平台主要干两件事情，一是使用系统库函数中的函数来实现某些更加复杂的功能。二侧是对系统库函数进行封装。

平台干的这两个事情始终是紧紧围绕着它的本质。那么平台的本质又是啥？说起平台，脱离不了一个"跨"字。且不说桌面软件领域，单就嵌入式领域，恐怕已经不止上千种操作系统了。作为一个想摆脱咸鱼命运的程序员，力求开发出兼容多个操作系统的应用，会更有利于程序的发扬光大。现在人人学QT，不就是最好的证明吗????

要跨平台，自然要避讳直接使用操作系统的系统库，因为操作系统之间的系统库差异非常大。如果将这种不一致直接牵涉到自己的应用程序中的话，以后怕是加班到秃头也难以完成移植工作。搞不好甚至得大改一番，给项目引入很多潜在风险的bug。程序引入平台概念，是一种有大局观的表现，展示了你富有服务他人的情怀，自然你的代码就会引来很多其他开发者的好感。

框架

最后是框架，框架的话题比较泛。狭义上来说，框架是针对一定的应用领域进行开发的，比如， Netty就是针对网络通讯而开发的一个框架。框架通常对于应用进行了一定的抽象，将需要的一些通用的功能做成了软件模块。当用户（或开发人员）需要对应用进行开发时（即实现应用的功能时），如果采用框架，则只要实现针对应用的特定代码就行了。

简单来说，我们可以这样理解：框架是为相类似的应用设计了一个骨架，而具体的应用只是在这个骨架上填上肉和皮肤。框架之于系统库和平台有一个很明显的特点，就是使用系统库和平台的话，我们得主动去调用它们的函数以实现我们需要的功能，但框架不一样。一旦初始化好框架以后，我们并不需要主动调用框架的功能。相反，框架会在合理的时刻，通过"回调"、"信号与槽"这样子的机制来调用我们所实现的"皮"和"肉"。