c/s模式在移动便携系统应用的一点理解

本文只是用于记录个人在技术历程中的一点唠叨，没有什么清晰的思路，还望见谅。

接触过几个面向移动便携应用的系统，有简单的也有复杂的。

我将就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 

于上海