软件或框架可移植性评价

软件可移植性指与软件从某一环境转移到另一环境下的难易程度。为获得较高的可移植性，在设计过程中常采用通用的程序设计语言和运行支撑环境。尽量不用与系统的底层相关性强的语言。可移植性是软件质量之一，良好的可移植性可以提高软件的生命周期。代码的可移植性主题是软件；可移植性是软件产品的一种能力属性，其行为表现为一种程度，而表现出来的程度与环境1密切相关。（注1：环境包括软件环境，硬件环境和系统的组织环境）。

wikipedia未找到相关词条。高屋建瓴的看，可移植性首先是软件的语言选择和架构设计，比如Java宣称的一次编译，多次运行，大部分脚本语言都具有良好的跨平台特性。悲剧的是和硬件&底层打交道的语言，比如汇编和C，但这也不是无解。软件架构上通过合理的分层和模块化可以一定程度上提升软件（必然是部分软件模块）的可移植性。有这么一句经典的话：软件科学的大部分问题都可以通过一个中间层解决。引入中间层即是分层、模块划分的一种常用手段，也是实现可移植性的关键。

另一方面，从细节入手，比如C语言，是如何解决可移植性的问题呢？

这里有一篇翻译稿：http://antkillerfarm.blog.sohu.com/102734995.html，可以学习一下。

前几天在公司写了一个胶片，信息安全问题无法拷贝出来，大概的提纲如下：

1、对OS、软件平台封装，避免形成依赖。

2、对驱动进行功能抽象，脱离硬件约束。

3、主机序和网络序问题

4、大小端和字节序问题

5、依赖倒置法则DIP，另外一个说法是好莱坞法则

6、考虑代码从vxworks到Linux的演进

7、考虑单核向多核的演进

1、OS、软件平台的封装

搞应用的同学，一般os相关东西折腾的比较少，估计POSIX的接口使用不到10分之一。而大公司呢，往往会有决心去做OS的封装（比如H公司的dopra），所以一般就可以借用公司平台的OSAL平台即可，如果没有，自己简单封装一下，也不是什么难的问题，比如很多芯片商的SDK就提供了稳定可用的封装代码。

2、驱动的抽象。

这是个难题。什么是抽象，功能的提取？哪些应该作为接口？这个程度往往很难把握。需要经验，对过去硬件&驱动的总结，对未来的演进要有一定的前瞻性。

3、主机序和网络序

这个很简单，两组宏可以搞定，主要是编码要养成习惯，发到网络或从网络接收的数据，要注意这个转换。

4、大小端和字节序。

这其实是两个东西，一个是字节在16b，32bit中的存放顺序，一个是0-7，或0-31的顺序。前者往往只需要做一下字节位置调整，后者一般在结构体中定义两套顺序。使用场景都是从硬件获取数据时需要考虑。

5、好莱坞法则是，don't call me, i will call you later。

作为平台来说，调用别人，别人就成为自己的依赖，移植就会束手束脚。怎么解决？倒置调用顺序，并严格控制接口定义，不要滥开接口。要调用别人的时候，提供一个钩子注册接口，让别人主动注册。

6、linux是大势所趋，windriver被intel收购之后，CT行业都开始琢磨上linux了。linux和vxworks的差异还蛮大，主要是驱动框架和任务管理。vxworks就一个大进程，linux要复杂的多。这一块暂时讲不清楚，后面再补充。

7、多核。多核其实不难。单核的代码，如果软表、硬件资源保护到位，多核则在这个基础上增加核间保护即可。主要不要滥用核间锁（自旋锁），锁应该用于保护硬件资源和关键软表，锁中间不允许任务切换。否则导致核间死锁问题就大了。

注：blog画图不方便，所以只能絮絮叨叨的说一堆废话。另，刚去注册了ms的skydriver，发现免费版也不能画图，看了web office还有待发展。