【IT168 新闻】应用开发人员不需要每次都对他们编写的一项应用进行重复的劳动。工具和应用开发架构已获得了长足的发展，以至于应用开发人员能够集中精力创造他们的附加价值，而不需要担心底层的应用架构和细节。那么嵌入式系统的开发是否也朝着同样的方向发展？

    开发人员需要利用有限的时间和/或资源来创建硬件/软件解决方案，这是存在的情况；开发人员应该将时间和精力集中在创造产品的附加价值方面，而不是底层的细节。

    回顾过去的几年，嵌入式系统通常是由工程师自行利用汇编语言设计，并且在定制硬件上运行，不需要任何通信技术或安全架构（时代已经改变！）。这些系统会像独立设备一样运行，在许多情况下甚至不用操作系统的支持；事实上，这些系统只会运行一个专用的单任务或进程(现在的设备当然也是如此)，开发人员将负责系统的每个方面、系统与底层硬件的互动以及用户的输入和输出（若有必要）。设备的每个方面都需要由开发人员进行编码。一般来说，应用开发人员必须非常熟悉底层硬件，而且或许还曾经参与硬件的设计。

    随着时间的推移，开发人员不再使用汇编语言自行设计操作系统程序，他们改用C/C++等高级语言或利用软件库开发字符串处理、文件I/O、图形、音频和视频等常用的软件。许多知名的软件开发工具都提供软件库以协助应用软件开发，如Borland OWL和Microsoft Foundation Classes (MFC) 就是应用开发软件库的很好例子，它们让开发人员摆脱操作系统API的纠缠，并且提供各种函式和类别来支持常见的程序设计工作。我们可以将这些软件库视为操作系统和应用软件之间的中介层，但在许多情况下应用开发人员仍然需要控制对象的生命周期、线程和内存管理。

     许多应用开发软件库其实就是应用软件和底层操作系统之间的中介层，而许多软件库还提供原代码以方便设计人员了解软件库的工作方式，并通过检查源代码来确定软件库调用本地操作系统API的速度有多快。应用开发软件库提供原代码的另一优点是设计人员可借此扩大软件库功能。只要将应用开发和操作系统抽象模型往前推进一步，我们就能得到 (在多数情况下) 与操作系统和处理器无关的应用开发模型，Java和.NET就是很好的例子。在这个模型里，应用开发人员与底层操作系统的距离会更远，对象生命周期是由应用软件的运行时间环境(JVM或.NET运行时间)、类别、对象、事件，以及与底层操作系统API没有多大关系的方法来处理的。从C/C++转向管理应用开发将带来更多好处，这就像应用开发人员从汇编语言转到C/C++语言后，就能加快产品开发的脚步一样。

     底层硬件的抽象化是将应用软件开发从汇编语言通过C/C++转换到管理应用开发环境的附带效果之一。应用开发人员多半不需知道硬件细节，硬件抽象层则可搭配设备驱动程序将应用软件与实际硬件隔开。例如，一个串行端口可能作为UART或FPGA来执行，但这些硬件的相关问题都由驱动程序负责处理，应用软件只需要使用串行端口即可，完全不需要知道它的硬件细节。图形、音频和许多其它外围设备也是如此。