引言
在当今的软件设计中，为了在不同的产品线上重复使用相同的代码，需要将代码从一个平台移植到另一个平台。虽然这种代码的重复利用非常重要，但是很少有人讨论该采用何种方法来减少设计可移植软件的成本，本文将介绍一种可行的设计方案。
可移植代码的重要性
过去，嵌入式应用程序一般不需要运行在不同的硬件平台和不同的操作系统上，因此开发者也不需要考虑让代码运行到多平台上的问题。
随着技术的发展，市场竞争的激烈，厂家必须不断开发新产品。如果是需要为新产品重新设计新软件，一来开发周期长，另一方面，代码要经过严格测试后才能推出，就会影响产品的面市时间。因此，将已有的、已经过测试的代码移植到新产品上就是一个很好的办法，进而开发者被要求 设计出可运行在不同硬件平台或不同操作系统下的应用程序。但是，由于系统设计可选择不同的设备、不同的子系统以及CPU，范围非常广泛，这样的不确定性势必会增加开发多平台软件的难度。
使用抽象层设计可移植代码
抽象层的先进之处在于它能够提取应用程序的基本内容，并将其与系统实现相隔离。这里关键是要将应用程序的逻辑算法与其运行环境相隔离。例如，在读取文件时，应用程序应该只关心文件的内容，而不在意文件是存在于FAT文件系统中，还是EXT2文件系统中；在数据通信中，通信双方应该只关心收发的数据本身，至于数据传输的媒体则不是应用程序该考虑的。
多平台软件的系统构成如图1所示，这种方法可广泛地应用在各种应用程序中。就像系统的机械组件可以被抽象，通信接口、CPU资源、存储设备等也可以被抽象。灵活使用抽象层可以将应用程序简化为一个紧凑并可重复利用的代码。
图1 多平台软件系统构成图
操作系统抽象层
操作系统函数永远不要被直接调用，应将其包装到一个“操作系统抽象层”的库中，把应用程序从底层的操作系统中脱离出来。于是，当将应用程序移植到其他操作系统时，只要简单地移植操作系统抽象层即可，无需修改应用程序的代码。 这不仅将原应用程序的正确性和可靠性带到了新平台上，还加速了移植过程。此外，当在向新平台移植的过程中发现错误时，操作系统抽象层将是调试的最有效的起点。
操作系统抽象层应该输出函数原型，同时，不管底层的操作系统是如何实现的，抽象层应该对应用程序隐藏它们的一些特殊行为。例如，拿对信号量的操作来说，在大多数操作系统中，相同的进程可以多次获取一个信号量，而某些操作系统在递归获取信号量时会阻塞调用者。这里假设操作系统抽象层库输出一个信号量获取函数OS_SemTake（），那么它必须禁止该系统的标准操作，完成通用信号量获取的功能，使该函数独立于底层的操作系统。在递归获取信号量这个例子中，开发者必须实现递归行为本身。具体实现中，一些操作系统可能要比较两个任务的ID，这两个任务一个是上次要求获取信号量的任务，另一个是本次要求获取信号量的任务。如果两个ID相同，说明是在同一进程中，函数将增加信号量的计数器，且不调用操作系统的信号量获取函数。相应的，信号量释放函数必须对信号量的计数器进行递减操作，直到计数器为0，才调用操作系统 程序中编写的函数封装应该保证在所有的操作系统中具有相同的行为，这可以避免底层操作系统的特殊性对应用程序的影响。
Socket库函数中的select（）提供了一个很好的例子来说明函数封装的重要性。对于不同的操作系统来说，可选择的设备有相当大的差异，一些系统只允许选择插口，而其它系统可以选择插口、管道和消息队列。在移植过程中，对底层操作系统实现的抽象使应用程序免于不必要的、杂乱的修改。如果某个操作系统没有实现select（）的超时功能，只要在抽象层库中就能够完成修改。否则，就需要对应用程序的结构进行重大修改。
逻辑接口
这一步需要将物理接口转换为逻辑接口。比如一个系统中所有的外围设备都连接到一个总线上，那么就可以建立一组访问总线的函数，例如读总线数据函数BusReadFrom（）、向总线发送数据函数BusSendTo（）等，这可以有效地将总线操作从应用程序中提取出来。这样，无论总线是用PCI、VME、串口或其它形式实现，都可使用逻辑接口将应用程序与物理接口隔离开。
逻辑接口特别适用于数据通信应用。如果一个系统利用TCP/IP协议在以太网上参与一次会话，那么可将会话从IP连接中划分出来，通过编写函数来实现逻辑会话，如：SessionOpen（）、SessionClose（）、SessionSend（）、SessionReceive（）等。逻辑接口将底层的物理接口隐藏，使得应用程序便于移植到不同的物理接口上。真正的移植工作将在逻辑接口中完成，而会话实现没有改变，改变的是会话传输的媒体。如果能很好地创建逻辑接口，应用程序将能移植到不同类型的、具有多种接口的设备中。
当应用程序需要运行在多种处理器上时，可以使用相同的方法实现应用程序代码。将与处理器相关的代码提取出来，应用程序就可以自由地从一种处理器移植到另一种处理器上。例如进程间的通信机制，只要在抽象层中完成不同处理器的进程间通信功能，应用程序就可以毫无修改地运行在新的处理器上。
控制系统也可以使用相同的方法，控制系统只关心命令本身，至于命令到底是来源于人机命令接口、还是红外线、或是SNMP代理，都不是控制系统要关注的。控制命令的输入机制应该被分离出来，形成独立的一层。
协议隔离
实现某种协议时，协议本身不应与具体的传输媒体打交道，同时应用程序中的一些特殊功能也不该在协议中实现。
协议的最终传输应在抽象层中完成，其核心部分只完成数据处理工作。这种代码的组织方式可以将协议自由地嵌入到各种设备中。同时，还可以不依赖硬件而测试协议自身的正确性。因此，在硬件完成之前就可以调试代码，当硬件完成时即可保证协议是正确的，如果有错误则应该发生在与硬件的接口上或硬件本身。
还有一点很重要，一定不要将应用程序的一些特殊功能放到协议中，这样会影响协议的独立性。应用程序的特殊功能也应该放到抽象层中，而不是在协议中实现。
使用系统服务
系统服务是一组软件组件，它向应用级软件提供服务。系统服务隐藏各种硬件平台的差异，向用户提供一组标准服务。系统服务能用来管理非易失性存储器、处理器资源、提供硬件级的精确定时服务。同时，它还能用于管理继电器、开关或其他外围硬件。
系统服务还可以提供不依赖于某些特殊的物理硬件的软件服务，包括进程间通信、软件健壮性检查、事件日志、时间戳服务等。
建立程序框架
为了使程序便于移植，还有一个工作就是建立应用程序框架，将所有与硬件平台相关的初始化代码放到一个模块当中。当系统启动时，首先调用与平台相关的框架模块来对系统硬件进行初始化和置。一旦这些特殊的硬件的信号量释放函数释放信号量。初始化完毕，框架便开始执行应用程序。由于这些特殊的平台代码是与应用程序分离的，因此应用程序可以运行在任何其它的框架结构中。
当开发的应用程序需要运行在不同平台上时，最好要考虑两种开发环境的差异。比如：Windows和Linux。有些Windows环境在文件路径中既可以使用斜杠“/”，也可以使用反斜杠“/”，而Linux环境中只能使用斜杠“/”。Linux对文件的大小写敏感，因此程序中头文件的大小写必须与文件系统中的完全匹配，而在Windows系统中则没有这种要求。另外，这两种环境下的编辑器对特殊字符的处理也不尽相同，这些字符包括：“Tab”、换行、“Enter”等。在开发过程中需要避免因为这些差异而要修改已完全测试通过的源代码的情况。
实例
接下来本文将以一个TCP/IP协议栈的开发例子来介绍抽象化的设计方法。首先为它规划一个框架：
Core：TCP、IP协议的核心代码；
API：与上层代码实现接口的函数；
Arch：与体系相关的代码；
Netif：网络接口函数。
Core部分是实现TCP/IP协议的核心代码，不是本文要讨论的内容。
API部分是协议栈提供的与高层应用的接口，主要实现TCP/IP协议的标准接口，包括select、绑定函数bind、监听函数listen、接收连接函数accept等，此外还有各种IP地址转换函数、各种TCP/IP协议用到的数据结构等。
Arch部分是协议栈与体系结构相关的代码，主要实现与操作系统以及与处理器相关的代码。与处理器相关的内容包括：数据结构的对齐方式、存储器的存储格式（大端或小端）、协议栈用到的数据类型等。与操作系统相关的内容包括：进程处理、信号量处理、消息队列处理、定时功能等。
Netif部分是协议栈使用的网络接口代码，主要实现IP包在物理媒体上的传输，实际上是数据链路层和物理层的实现。
设计时将TCP/IP协议本身放到Core部分，而将其它的放到抽象层中，这样，协议运行的操作系统支持由Arch部分完成，传输媒体支持由Netif部分完成，与高层的应用由API部分完成。当需要将协议移植到新的平台上时，要做的工作是修改Arch部分，利用新的操作系统提供的函数实现进程处理、信号量处理、消息队列处理和定时功能等，并根据所用处理器修改与处理器相关的内容。若网络接口发生改变，例如使用另一种芯片时，则只要完成Nefif中的相应驱动即可。
结语
抽象是多平台开发强有力的工具。通过抽象，把应用程序的核心部分分离出来，将其它系统支持部分在抽象层中完成，这样就能够把代码的移植工作集中在抽象层里。合理地利用抽象，就能以最小的代价完成代码的移植。
引言
在当今的软件设计中，为了在不同的产品线上重复使用相同的代码，需要将代码从一个平台移植到另一个平台。虽然这种代码的重复利用非常重要，但是很少有人讨论该采用何种方法来减少设计可移植软件的成本，本文将介绍一种可行的设计方案。
可移植代码的重要性
过去，嵌入式应用程序一般不需要运行在不同的硬件平台和不同的操作系统上，因此开发者也不需要考虑让代码运行到多平台上的问题。
随着技术的发展，市场竞争的激烈，厂家必须不断开发新产品。如果是需要为新产品重新设计新软件，一来开发周期长，另一方面，代码要经过严格测试后才能推出，就会影响产品的面市时间。因此，将已有的、已经过测试的代码移植到新产品上就是一个很好的办法，进而开发者被要求 设计出可运行在不同硬件平台或不同操作系统下的应用程序。但是，由于系统设计可选择不同的设备、不同的子系统以及CPU，范围非常广泛，这样的不确定性势必会增加开发多平台软件的难度。
使用抽象层设计可移植代码
抽象层的先进之处在于它能够提取应用程序的基本内容，并将其与系统实现相隔离。这里关键是要将应用程序的逻辑算法与其运行环境相隔离。例如，在读取文件时，应用程序应该只关心文件的内容，而不在意文件是存在于FAT文件系统中，还是EXT2文件系统中；在数据通信中，通信双方应该只关心收发的数据本身，至于数据传输的媒体则不是应用程序该考虑的。
多平台软件的系统构成如图1所示，这种方法可广泛地应用在各种应用程序中。就像系统的机械组件可以被抽象，通信接口、CPU资源、存储设备等也可以被抽象。灵活使用抽象层可以将应用程序简化为一个紧凑并可重复利用的代码。
图1 多平台软件系统构成图
操作系统抽象层
操作系统函数永远不要被直接调用，应将其包装到一个“操作系统抽象层”的库中，把应用程序从底层的操作系统中脱离出来。于是，当将应用程序移植到其他操作系统时，只要简单地移植操作系统抽象层即可，无需修改应用程序的代码。 这不仅将原应用程序的正确性和可靠性带到了新平台上，还加速了移植过程。此外，当在向新平台移植的过程中发现错误时，操作系统抽象层将是调试的最有效的起点。
操作系统抽象层应该输出函数原型，同时，不管底层的操作系统是如何实现的，抽象层应该对应用程序隐藏它们的一些特殊行为。例如，拿对信号量的操作来说，在大多数操作系统中，相同的进程可以多次获取一个信号量，而某些操作系统在递归获取信号量时会阻塞调用者。这里假设操作系统抽象层库输出一个信号量获取函数OS_SemTake（），那么它必须禁止该系统的标准操作，完成通用信号量获取的功能，使该函数独立于底层的操作系统。在递归获取信号量这个例子中，开发者必须实现递归行为本身。具体实现中，一些操作系统可能要比较两个任务的ID，这两个任务一个是上次要求获取信号量的任务，另一个是本次要求获取信号量的任务。如果两个ID相同，说明是在同一进程中，函数将增加信号量的计数器，且不调用操作系统的信号量获取函数。相应的，信号量释放函数必须对信号量的计数器进行递减操作，直到计数器为0，才调用操作系统 程序中编写的函数封装应该保证在所有的操作系统中具有相同的行为，这可以避免底层操作系统的特殊性对应用程序的影响。
Socket库函数中的select（）提供了一个很好的例子来说明函数封装的重要性。对于不同的操作系统来说，可选择的设备有相当大的差异，一些系统只允许选择插口，而其它系统可以选择插口、管道和消息队列。在移植过程中，对底层操作系统实现的抽象使应用程序免于不必要的、杂乱的修改。如果某个操作系统没有实现select（）的超时功能，只要在抽象层库中就能够完成修改。否则，就需要对应用程序的结构进行重大修改。
逻辑接口
这一步需要将物理接口转换为逻辑接口。比如一个系统中所有的外围设备都连接到一个总线上，那么就可以建立一组访问总线的函数，例如读总线数据函数BusReadFrom（）、向总线发送数据函数BusSendTo（）等，这可以有效地将总线操作从应用程序中提取出来。这样，无论总线是用PCI、VME、串口或其它形式实现，都可使用逻辑接口将应用程序与物理接口隔离开。
逻辑接口特别适用于数据通信应用。如果一个系统利用TCP/IP协议在以太网上参与一次会话，那么可将会话从IP连接中划分出来，通过编写函数来实现逻辑会话，如：SessionOpen（）、SessionClose（）、SessionSend（）、SessionReceive（）等。逻辑接口将底层的物理接口隐藏，使得应用程序便于移植到不同的物理接口上。真正的移植工作将在逻辑接口中完成，而会话实现没有改变，改变的是会话传输的媒体。如果能很好地创建逻辑接口，应用程序将能移植到不同类型的、具有多种接口的设备中。
当应用程序需要运行在多种处理器上时，可以使用相同的方法实现应用程序代码。将与处理器相关的代码提取出来，应用程序就可以自由地从一种处理器移植到另一种处理器上。例如进程间的通信机制，只要在抽象层中完成不同处理器的进程间通信功能，应用程序就可以毫无修改地运行在新的处理器上。
控制系统也可以使用相同的方法，控制系统只关心命令本身，至于命令到底是来源于人机命令接口、还是红外线、或是SNMP代理，都不是控制系统要关注的。控制命令的输入机制应该被分离出来，形成独立的一层。
协议隔离
实现某种协议时，协议本身不应与具体的传输媒体打交道，同时应用程序中的一些特殊功能也不该在协议中实现。
协议的最终传输应在抽象层中完成，其核心部分只完成数据处理工作。这种代码的组织方式可以将协议自由地嵌入到各种设备中。同时，还可以不依赖硬件而测试协议自身的正确性。因此，在硬件完成之前就可以调试代码，当硬件完成时即可保证协议是正确的，如果有错误则应该发生在与硬件的接口上或硬件本身。
还有一点很重要，一定不要将应用程序的一些特殊功能放到协议中，这样会影响协议的独立性。应用程序的特殊功能也应该放到抽象层中，而不是在协议中实现。
使用系统服务
系统服务是一组软件组件，它向应用级软件提供服务。系统服务隐藏各种硬件平台的差异，向用户提供一组标准服务。系统服务能用来管理非易失性存储器、处理器资源、提供硬件级的精确定时服务。同时，它还能用于管理继电器、开关或其他外围硬件。
系统服务还可以提供不依赖于某些特殊的物理硬件的软件服务，包括进程间通信、软件健壮性检查、事件日志、时间戳服务等。
建立程序框架
为了使程序便于移植，还有一个工作就是建立应用程序框架，将所有与硬件平台相关的初始化代码放到一个模块当中。当系统启动时，首先调用与平台相关的框架模块来对系统硬件进行初始化和置。一旦这些特殊的硬件的信号量释放函数释放信号量。初始化完毕，框架便开始执行应用程序。由于这些特殊的平台代码是与应用程序分离的，因此应用程序可以运行在任何其它的框架结构中。
当开发的应用程序需要运行在不同平台上时，最好要考虑两种开发环境的差异。比如：Windows和Linux。有些Windows环境在文件路径中既可以使用斜杠“/”，也可以使用反斜杠“/”，而Linux环境中只能使用斜杠“/”。Linux对文件的大小写敏感，因此程序中头文件的大小写必须与文件系统中的完全匹配，而在Windows系统中则没有这种要求。另外，这两种环境下的编辑器对特殊字符的处理也不尽相同，这些字符包括：“Tab”、换行、“Enter”等。在开发过程中需要避免因为这些差异而要修改已完全测试通过的源代码的情况。
实例
接下来本文将以一个TCP/IP协议栈的开发例子来介绍抽象化的设计方法。首先为它规划一个框架：
Core：TCP、IP协议的核心代码；
API：与上层代码实现接口的函数；
Arch：与体系相关的代码；
Netif：网络接口函数。
Core部分是实现TCP/IP协议的核心代码，不是本文要讨论的内容。
API部分是协议栈提供的与高层应用的接口，主要实现TCP/IP协议的标准接口，包括select、绑定函数bind、监听函数listen、接收连接函数accept等，此外还有各种IP地址转换函数、各种TCP/IP协议用到的数据结构等。
Arch部分是协议栈与体系结构相关的代码，主要实现与操作系统以及与处理器相关的代码。与处理器相关的内容包括：数据结构的对齐方式、存储器的存储格式（大端或小端）、协议栈用到的数据类型等。与操作系统相关的内容包括：进程处理、信号量处理、消息队列处理、定时功能等。
Netif部分是协议栈使用的网络接口代码，主要实现IP包在物理媒体上的传输，实际上是数据链路层和物理层的实现。
设计时将TCP/IP协议本身放到Core部分，而将其它的放到抽象层中，这样，协议运行的操作系统支持由Arch部分完成，传输媒体支持由Netif部分完成，与高层的应用由API部分完成。当需要将协议移植到新的平台上时，要做的工作是修改Arch部分，利用新的操作系统提供的函数实现进程处理、信号量处理、消息队列处理和定时功能等，并根据所用处理器修改与处理器相关的内容。若网络接口发生改变，例如使用另一种芯片时，则只要完成Nefif中的相应驱动即可。
结语
抽象是多平台开发强有力的工具。通过抽象，把应用程序的核心部分分离出来，将其它系统支持部分在抽象层中完成，这样就能够把代码的移植工作集中在抽象层里。合理地利用抽象，就能以最小的代价完成代码的移植。
举报
