c/s模式在移动便携系统应用的一点理解
2011-11-27 10:33
218 查看
本文只是用于记录个人在技术历程中的一点唠叨,没有什么清晰的思路,还望见谅。
接触过几个面向移动便携应用的系统,有简单的也有复杂的。
我将就Android为例,说下我的理解。
app
...............................................................................
framework
................................................................................
native ( services | davik|libs)
................................................................................
os (process,thread,device,system call)
原则上下一层只向相邻的上一层提供服务。
1,os为native提供运行环境诸如process,device module,system call .
这样native 就可以运行,并具备系统调用,访问设备等功能。以视频解码为例,可以是软解或硬解,或者使用
半硬半软,哈哈。这里以硬解为例,native 应该是有一个负责解码的service,因为目前大多只支持同时解一路
视频流,所以可能看到的只是一个调用过程,而不是一个一对多的分发服务过程,将这个服务命名 native_vdecode_service。
native_vdecode_service将首先初始化硬解模块device,并将上层传下来的关于需要解码视频的一些参数通过
device handle设置到该模块。接下来的过程就是一个典型的生产和消费的过程。
2,native将os的服务封装成上层更易于使用或者实现某些特殊目的。
还是以视频解码为例,当framework向native请求解码视频服务时。这是一个一对多的过程,既native_vdecode_service
需要向framework提供视频解码服务,所以他必须提供一个开发的接口来接受framework 种的client的解码请求。
当前大多数系统种视频解码时独占资源,所以native_vdecode_service需要某种策略来进行仲裁以决定向其中那一个client
提供服务。
3,framework 中可能更多是把native提供的服务封装成他所需要的接口,以适应他的框架架构。
4,app通过规定的接口向framework请求视频解码的服务,framework将会对该请求作出处理并决定是否把该请求传定到下一层
处理。
结合上面提到的几个过程,我觉得主要好处有:
1,降低耦合度。通过接口降低了app 和 native_vdecode_service 的耦合。
2,正基于第一点,耦合度降低了,则只要维持接口的稳定性,app和native_vdeoce_service 内部实现可以灵活多变。
这正符合面向接口编程。用较少的(接口)不变性换取更多的(实现)可变性,其实设计也是一笔买卖,哈哈。
其实上面忽略了一个很重要的话题,就是关于如何建立client 和service的关系。这是一个很基础的模块,也是做系统架构
初期应该考虑的问题,因为这决定了client 和service之间的接口定义实现。实现了这个模块系统才能以一个整体进行
运行调试。
1,Binder, Android 中用的比较多的时binder机制。至于具体如何实现网上资料牛多。
我觉得选用哪种方式重要的一点是易于使用。其次是易于调试。当然还应该满足带宽需求,不至于出现某些应用场景实现困难。
简单是最朴素和重要的原则。
2,DBus,也有一些使用DBus(http://zh.wikipedia.org/wiki/DBUS)作为client和service之间的通信架构。从使用效果来看,
还是相当靠谱的。个人感觉client 和service之间command最重要的接口莫过于request (sync,async),response,notification,实现好这几个接口则可以满足
绝大多数的需求。
3,其他,最近在关注zeroMQ,感觉将他作为一个系统基础组建是一个不错的选择。在其之上可以很容易的封装出用于IPC 通信的基础部件。
感兴趣的朋友可以关注下(http://www.zeromq.org/intro:get-the-software)。
总结:关键是要选择合适的方案,如果是自己搭系统,最好是选择开源的东西,避免重复造轮子。做完这一步只是完成了基本的部分。
音视频,2d/3d,app系统,gui等更多的东西需要研究。
wangyinrong@gmail.com
2011,11,27
于上海
接触过几个面向移动便携应用的系统,有简单的也有复杂的。
我将就Android为例,说下我的理解。
app
...............................................................................
framework
................................................................................
native ( services | davik|libs)
................................................................................
os (process,thread,device,system call)
原则上下一层只向相邻的上一层提供服务。
1,os为native提供运行环境诸如process,device module,system call .
这样native 就可以运行,并具备系统调用,访问设备等功能。以视频解码为例,可以是软解或硬解,或者使用
半硬半软,哈哈。这里以硬解为例,native 应该是有一个负责解码的service,因为目前大多只支持同时解一路
视频流,所以可能看到的只是一个调用过程,而不是一个一对多的分发服务过程,将这个服务命名 native_vdecode_service。
native_vdecode_service将首先初始化硬解模块device,并将上层传下来的关于需要解码视频的一些参数通过
device handle设置到该模块。接下来的过程就是一个典型的生产和消费的过程。
2,native将os的服务封装成上层更易于使用或者实现某些特殊目的。
还是以视频解码为例,当framework向native请求解码视频服务时。这是一个一对多的过程,既native_vdecode_service
需要向framework提供视频解码服务,所以他必须提供一个开发的接口来接受framework 种的client的解码请求。
当前大多数系统种视频解码时独占资源,所以native_vdecode_service需要某种策略来进行仲裁以决定向其中那一个client
提供服务。
3,framework 中可能更多是把native提供的服务封装成他所需要的接口,以适应他的框架架构。
4,app通过规定的接口向framework请求视频解码的服务,framework将会对该请求作出处理并决定是否把该请求传定到下一层
处理。
结合上面提到的几个过程,我觉得主要好处有:
1,降低耦合度。通过接口降低了app 和 native_vdecode_service 的耦合。
2,正基于第一点,耦合度降低了,则只要维持接口的稳定性,app和native_vdeoce_service 内部实现可以灵活多变。
这正符合面向接口编程。用较少的(接口)不变性换取更多的(实现)可变性,其实设计也是一笔买卖,哈哈。
其实上面忽略了一个很重要的话题,就是关于如何建立client 和service的关系。这是一个很基础的模块,也是做系统架构
初期应该考虑的问题,因为这决定了client 和service之间的接口定义实现。实现了这个模块系统才能以一个整体进行
运行调试。
1,Binder, Android 中用的比较多的时binder机制。至于具体如何实现网上资料牛多。
我觉得选用哪种方式重要的一点是易于使用。其次是易于调试。当然还应该满足带宽需求,不至于出现某些应用场景实现困难。
简单是最朴素和重要的原则。
2,DBus,也有一些使用DBus(http://zh.wikipedia.org/wiki/DBUS)作为client和service之间的通信架构。从使用效果来看,
还是相当靠谱的。个人感觉client 和service之间command最重要的接口莫过于request (sync,async),response,notification,实现好这几个接口则可以满足
绝大多数的需求。
3,其他,最近在关注zeroMQ,感觉将他作为一个系统基础组建是一个不错的选择。在其之上可以很容易的封装出用于IPC 通信的基础部件。
感兴趣的朋友可以关注下(http://www.zeromq.org/intro:get-the-software)。
总结:关键是要选择合适的方案,如果是自己搭系统,最好是选择开源的东西,避免重复造轮子。做完这一步只是完成了基本的部分。
音视频,2d/3d,app系统,gui等更多的东西需要研究。
wangyinrong@gmail.com
2011,11,27
于上海
相关文章推荐
- OpenGL 关于全局固定坐标系统与局部移动坐标系统的理解
- 访问eeprom设备的方法三(理解iic总线接口应用以及创建sysfs文件系统的bin文件访问接口(新的访问设备的文件接口))
- JEECG移动解决方案 - 针对移动应用的应用系统转换的中间件解决方案
- 关于DataRow和DataColumn的一点个人简单理解-.NET教程,数据库应用
- 黑马程序员_学习笔记2交通灯系统中面向对象思想的理解以及工厂模式的应用
- 右值引用与移动构造函数的一点理解
- Smobiler基于.NET框架开发移动应用内部系统(开发日志二)
- Smobiler基于.NET框架开发移动应用内部系统—消息列表功能(开发日志五)
- Smobiler基于.NET框架开发移动应用内部系统(开发日志一)
- 基于BBB的4轮移动轮式机器人系统设计与实现(五)--BeagleBone Black编码器开发应用
- TI C66x DSP 系统events及其应用 - 5.3.1(Interrupt之eventCombiner理解)
- 全球定位系统在移动上的应用
- 开发嵌入式系统的一点理解
- 关于移动设备系统的浅显理解
- linux应用领域-----移动客户端====Android系统和linux内核的关系详解
- Smobiler基于.NET框架开发移动应用内部系统—工作单功能(开发日志七)
- JEECG移动方案 - 应用系统转换移动应用的中间件实现方案
- HTML5 Mobile App移动框架Sencha Touch实战OA系统开发(PhoneGap打包应用)
- linux之理解文件系统上的复制,移动,删除
- 系统架构:Web应用架构的新趋势---前端和后端分离的一点想法