一、想清楚到底要做BS还是做CS

      做CS架构的缺点很明显，研发成本太高，因为手机平台实在太多了。SYMBIAN，WINDOWS MOBILE，MTK，用C/C++的主要就三个了，然后再加上JAVA。客户端程序开发测试的工作量是很大的。到了项目后期，一旦需求变动或增加新功能，维护量那是嗷嗷的爽。

      但是CS架构的优点也和它的缺点一样明显。首先是我认为CS架构才能真正发挥出手机“移动”的特点来；其次，做CS架构的软件才不容易受到门户网站、互联网巨头的冲击。

      所以，如果有足够的预算和野心，就做CS架构；如果只是做来玩玩，或者是某个主营业务的拓展分支，就做BS。

      我现在是决定做CS，所以后面都是以CS架构来讨论的

二、客户端多瘦，服务端多胖

      现在的主流模式是瘦客户端&胖服务端。主要的处理逻辑、数据存储都放在服务端做。但这样的缺点就是网络流量大，用户花费高；而且由于网络延迟，用户体验会降低。所以必须考虑把一些不太经常变化的、相对稳定的逻辑和数据存储可以缓存在客户端。但一味地缓存又会使客户端越来越肥；而且先取本地缓存，没有的话再取从服务端取的策略，也会降低数据的时效性。因此，我们需要一种在客户端数据缓存管理策略，一方面可以管理缓存的总量（比如不能超过5M），一方面可以管理缓存的时效（比如早于一周下载的数据会被清理掉）。这个策略会被各模块所共用。

三、通信协议

      CS架构里最烦的一件事就是通信协议。不论是用Web Service接口，或者XML，或者私定义的什么格式，我归纳了下每个字段都跑不开这么三个要素：在某次传输中的序号、数据类型、值。然后需要维护一份巨大无比的文档来说明每个包每个字段的物理意义。这真是件无比痛苦的事情。

      现在可能还有人在用最原始、但传输量最小的方法，就是字节对齐、第几字节到第几字节是什么量什么物理意义。神啊救救我吧，那真是停留在石器时代了。

      GOOGLE开发了一套叫"Protocal Buffer"的开源小项目，专门用来做这事。http://code.google.com/intl/zh-CN/apis/protocolbuffers/docs/overview.html 支持C++，JAVA，和Python三种语言。要知道GOOGLE和MSFT是竞争对手，所以没支持C#，C#程序员可以到一边凉快去了。据说这套方法本质上还是基于XML的，只不过中间用了一层压缩和解压缩算法，使得在网络上传输的字节数，比直接用XML传节省了6/7左右。

      可惜我是在花费十来天做完自己一套方法后，才知道有Protocal Buffer这东西的。不过我觉得抽象概念上都差不多。怎么搞都跳不开几个要点：

1、模糊的值类型。上层应用想传输的可能是数值，或者字符串，或者一个数组，或者是一个MAP映射表。再来传个N字节的二进制BUFFER。这数组里面每个元素的值类型还不同的还不同的，有的是数值有的是字符串；***还能数组套数组，数组套映射，无限级联……。很神奇的是，我居然很臭屁地用C++做出来了。

2、序列化和反序列化。我是做个容器来放上面描述的模糊数据类型，然后能把这个容器序列化和反序列化，这样就能实现CS通讯了。GOOGLE那套Protocal Buffer里头用XML会更简单些，本来就是纯字符串，右面对字符串压缩一下就可以了。

3、数据包错误时自恢复。CLIENT端或SERVER端收到了错误的、不完整的数据包，能够辨认出来，扔掉，下个正确的数据包拿到后可以恢复正常工作。这其实很简单，参考MP3等可以流式传输的文件格式设计思路就可以了。其实系统底层的网络通信协议都封装得那么好，应用层拿到错包时你应该赶快去买体彩了。

四、UI方案

      做UI这事，说难也难，说简单也简单。全世界每天都有无数的程序员在摆弄DIALOG、BUTTON、IMAGE和STATIC TEXT之类玩意儿。想起来真是无聊之极，不过倒也解决了N多人的就业问题。但就是有些不甘无聊的UI程序员，做了套牛B闪闪放光芒的UI系统，于是iPhone就横空出世并且大卖特卖了。

      如果你是一个想扩张自己***地盘的项目经理，那么就可以趁机招一大票手下。移动互联重在互动，所以即使是个中型的CS架构移动互联应用，每个手机平台上至少会有30~50个、甚至更多的对话框，层层递进的对话框逻辑关系至少能有三到四层。而且你需要完成三到四个手机平台。那么保守估计你的项目组一共需要在CLIENT端实现并维护150个以上的对话框。可能某一天你把产品递给老板看，老板一拍脑袋觉得这对话框太复杂了要改一下，那对话框颜色要调整一下，这里控件拜访要调整一下位置，那么恭喜恭喜，大家又有事做不会下岗了，赶快把每个平台都改过去一遍吧。

      如果有人觉得维护多个平台上一共150个对话框代码是在藐视架构师智力的话，那么过来咱们握一下手吧。

      我的设想是用一套XML方案来描述UI和逻辑。包括两方面，一是这个会对话框呈现哪些控件，相互的空间关系如何，二是应用逻辑，如某个控件被点击时发什么包给服务器，或者被关联到执行哪个函数。另外再一套样式外观XML方案来描述各控件的缩进、底图、背景色等等风格，类似网页上用的CSS样式描述表。所以我需要维护的代码不是150份，而是只有三四份，就是如何从两份XML动态地生成UI上的对话框，每个手机平台上各一份。UI/逻辑XML维护50份，每个对话框一份，无视平台差异。样式外观XML维护20~30份，针对每个控件定义几种外观，够用就可以了。

      那么我只需要找一个够彪悍的程序员写完从XML动态生成UI的代码就可以了，测试也只要针对这一块。剩余的XML可以交给廉价的初级程序员写，或者UI设计师，甚至部门文员都能帮着写。而如果用前面傻逼兮兮的方案，那么大概需要用三四个水平中上的程序员，除了开发，还需要浪费测试资源，后期持续地维护更新还离不开他们，整体下来研发/测试/维护成本都会更高。

本文转自Walzer博客园博客，原文链接：http://www.cnblogs.com/walzer/archive/2009/05/26/1490450.html，如需转载请自行联系原作者