多平台适配的代码设计

一个成功的软件系统,往往需要根据需求在不同的系统平台上运行,为了解决系统在多个平台的移植带来的风险,业务架构往往会设计相应的平台适配层来隔离不同平台的差异,如何设计一个易于扩展的平台适配层,是软件设计人员需要考虑的问题。

设计1:

1: 提供平台接口文件os.h

2:定义如下:

#ifdef OS1
#define OS_Fun OS1_Fun
#endif
#ifdef OS2
#define OS_Fun OS2_Fun
#endif

void OS_Fun();

3:通过定义不同的系统宏,这个头文件展开后也就成了对应的平台的接口层。

4:业务代码直接调用OS_Fun()这个统一的接口即可。

5:该设计只需要一个通用的接口文件和对应不同平台的实现文件。

设计2:

1:提供平台接口文件os.h,并且提供一个平台的接口实现文件os.c

2:os.h定义如下:

void OS_Fun();

3:os.c定义如下:

#ifdef OS1
#include "OS1.h"
#endif

#ifdef OS2
#include "OS2.h"
#endif

#ifdef OS1
void OS_Fun()
{
    OS1_Fun();
}
#endif
#ifdef OS2
void OS_Fun()
{
    OS2_Fun();
}
#endif

4: 通过定义不同的系统宏,源文件对应不同的平台实现。

5:业务代码直接调用OS_Fun()这个统一的接口。

第一种设计看起来更加简洁,所有的适配都在一个头文件里面搞定,问题是第一种设计扩展性好吗?笔者曾经遇到一个项目,平台提供一个消息发送接口,本 系统的所有消息发送都需要调用这个接口,在原有系统上都运行的没问题,但后来需要切换平台,由于两套系统的具有不同的大小端模式,这就要求我们对所有出口 消息进行大小端转换,如果用第一种设计方式,处理起来就比较麻烦了,就算想办法解决了,但也破坏了原有的设计思想。用第二种设计方式我们只需要在适配层加 一个统一大小端的处理函数即可。

#ifdef OS1
void OS_SendMsg()
{
    HTON();
    OS1_SendMsg();
}
#endif
#ifdef OS2
void OS_SendMsg()
{
    HTON();
    OS2_SendMsg();
}
#endif

在设计框架的时候,我们尽量要考虑到变化,我可能不知道未来是否会变化,但可以一开始就设计出适应变化的架构。

时间: 2024-12-12 05:58:36

多平台适配的代码设计的相关文章

产品经理必须知道:三大移动平台上的交互设计差异

iOS,Android,WindowsPhone是现在移动互联网上面主流的三个平台了,我也都分别参与过这三个平台的设计.在设计的过程中,因为这三个平台的不同特性,往往要角色切换,不断的换位思维.可能新手和外行人觉得iOS和Android没什么区别,有的甚至拿Android直接照抄iOS设计就可以了.还有一些人可能对WindowsPhone平台一直觉得魔幻无比,但就是找不到应该如何下手.今天我总结了一下这三个平台之间交互设计上的差异性,在开展交互设计的过程中,必须要注意的问题: 一,布局形式的差异

平台化软件的设计与应用前景分析

平台化软件的设计与应用前景分析 http://www.cnblogs.com/spring_wang/p/3344305.html 1.背景描述 近年来,在政策和市场的双重拉动下,中国软件市场保持了持续快速的增长.2002年,中国软件市场实现了21.1%的增长率,销售额达到345 亿元.2003年,中国软件市场销售额达到400亿元左右,软件市场进一步升温.在几百亿元的市场规模下,掩盖了这样一个事实:软件项目成功率非常低.根据统计,超过80%的项目不能在最初估计的预算和进度内成功交付.这对用户和厂

(转)微服务架构 互联网保险O2O平台微服务架构设计

http://www.cnblogs.com/Leo_wl/p/5049722.html 微服务架构 互联网保险O2O平台微服务架构设计 关于架构,笔者认为并不是越复杂越好,而是相反,简单就是硬道理也提现在这里.这也是微服务能够流行的原因,看看市场上曾经出现的服务架构:EJB.SCA.Dubbo等等,都比微服务先进,都比微服务功能完善,但它们都没有微服务这么深入民心,就是因为他们过于复杂.简单就是高科技,苹果手机据说专门有个团队研究如何能让用户更加简单的操作.大公司都是由小公司发展起来的,如果小

基于token的多平台身份认证架构设计

基于token的多平台身份认证架构设计 1   概述 在存在账号体系的信息系统中,对身份的鉴定是非常重要的事情. 随着移动互联网时代到来,客户端的类型越来越多, 逐渐出现了 一个服务器,N个客户端的格局 . 不同的客户端产生了不同的用户使用场景,这些场景: 有不同的环境安全威胁 不同的会话生存周期 不同的用户权限控制体系 不同级别的接口调用方式 综上所述,它们的身份认证方式也存在一定的区别. 本文将使用一定的篇幅对这些场景进行一些分析和梳理工作. 2   使用场景 下面是一些在IT服务常见的一些

8、生鲜电商平台-购物车模块的设计与架构

说明:任何一个电商无论是B2C还是B2B都有一个购物车模块,其中最重要的原因就是客户需要的东西放在一起,形成一个购物清单,确认是否有问题,然后再进行下单与付款. 1. 购物车数据库设计: 说明:业务需求: 1>购物车里面应该存放,那个买家,买了那个菜品的什么规格,有多少数量,然后这个菜品的加工方式如何.(如果存在加工方式的话,就会在这里显示处理.) 2>买家存在购物起送价.也就是用户放入购物车的商品的总价格如果低于配置的起送价,那么这个提交按钮就是灰色的.(不可能你点一个洋葱我们就送过去,成本

9、生鲜电商平台-推荐系统模块的设计与架构

业务需求: 对于一个B2B的生鲜电商平台,对于买家而言,他需要更加快速的购买到自己的产品,跟自己的餐饮店不相关的东西,他是不关心的,而且过多无用的东西掺杂在一起,反而不便 于买家下单,用户体验也很差,严重的会因此丢了客户.(客户觉得太难用了.一般都就会放弃使用.) 对于卖家而言,他自己就调整下自己的商品的上架与下架,然后就是调整下自己商品的价格.(蔬菜类的商品会随着市场的供求关系会有相应的波动.) 业务分析: 推荐系统:根据买家的行为习惯以及购买行为来推荐些他可能需要的东西的一套算法系统. 对于

易于跨引擎和测试的游戏客户端代码设计方法

一.前言 本文讲的设计方法,不涉及算法.优化.接口讲解等技术介绍. 该设计方法基于MVC设计模式(主要是抽出控制类),而且本文主要面向游戏开发的一些问题. 该设计方法样例由python编写,但是实际上都是伪代码,有一点代码基础的问基本看得懂. 该设计方法由师兄教授,在项目使用过之后,感觉确实不错,特地提取一个方法论出来以记录. 二.MVC简介 在游戏开发中,目前用到架构主要分为MVC和ESC架构(这部分如有异议欢迎指正,有其他架构也希望能提出,博主也可以学习). 在一个功能复杂的模块中,通常会有

Flutter多平台适配机制就是这么简单

我们都知道到Flutter在表现层做到了多端一致性,通过Android.iOS各自平台下的渲染实现了一致的UI效果. 那么如果你只是要开发一个适配Android, iOS, Web的三方库,有什么好的简单思路? Flutter网络请求 在开发Flutter的时候可以使用http核心库.也可以使用社区的其他封装类库,比如dio.两者的底层实现都是http_parser 如果开发者不小心在flutter中直接使用了平台相关的类库,则会导致扩平台运行出错,比如使用io包下的http在浏览器下执行肯定会

基于UDP的客户端和服务器端的代码设计

实验平台 linux 实验内容 编写UDP服务器和客户端程序,客户端发送消息,服务器接收消息,并打印客户端的IP地址和端口号. 实验原理 UDP是无需连接的通信,其主要实现过程如下: 同样,我们可以按照上一篇博客:基于TCP的客户端和服务器端的代码设计 的办法,将服务器代码分成两部分,一个是初始化,一个是收发数据.但是UDP服务器初始化较为简单,也可以直接写在main函数里. UDP和TCP在读写数据上较为不同的是,sendto()和recvfrom(),这两个函数较为复杂.通过man手册查询得